Why EDID/HDCP information is important in monitoring solutions

EDID stands for "Extended Display Identification Data" and in IPTV solutions is used to provide detailed information on TV set capabilities and manufacturing information. HDCP ("High-bandwidth Digital Content Protection") is used for protecting high resolution content from being stolen by DVR. We typically count failed and successful HDCP connections.  This data is usually reported to central server using TR-69 protocol and/or proprietary protocols like Agama.

STB Development: TFTP+NFS boot methods - for dummies :-)

STB (Set Top Box) devices usually run from NAND partitions. All the rootfs is persisted in read-only filesystem (squashfs) and mounts additional R/W locations if needed (ramdisk for /tmp storage, at least). This setup works quite well for final deployment, but might be a bit problematic if you, actually, develop software stack and need to update and test many times per day.

This is the place where long-time forgotten network boot method comes to play.

In the old days (university) I remember "thin Solaris clients" that were used for programming classes. They had no hard disk and booted from network. What the boot process does look like?

Buildroot basics

If you are an embedded software developer like me chances are you use embedded Linux for the purpose. It's Open Source, has great tools support and is a great software environment where (almost) everything could be automated through command line interfaces.

Once you decide about operating system used the next step is to choose a build system that would be used for the task of building the software. There are few choices you can select from:

• use pre-built toolchain and rootfs and add your binaries and configuration files (i.e. STLinux for ST-based devices)
• use OpenEmbedded for full-featured buildsystem with packaging system included
• use BuildRoot for simple build system without packaging system included

Today I'm going to tell you about the 3rd option. Buildroot states their view on packaging systems for embedded development this way:

We believe that for most embedded Linux systems, binary packages are not necessary, and potentially harmful. When binary packages are used, it means that the system can be partially upgraded, which creates an enormous number of possible combinations of package versions that should be tested before doing the upgrade on the embedded device. On the other hand, by doing complete system upgrades by upgrading the entire root filesystem image at once, the image deployed to the embedded system is guaranteed to really be the one that has been tested and validated.

After few years with OpenEmbedded and few months with Buildroot I like the simplicity of Buildroot model. Below you can find basic (the most important in my opinion) concepts of Buildroot.

[SOLVED] VPN connectioin error: short read (-1): Message too long

If you encounter the following error during VPN connection:

pptp[12549]: nm-pptp-service-12543 warn[decaps_gre:pptp_gre.c:331]: short read (-1): Message too long

there's an easy fix. You have to lower your MTU (automatically obtained value was invalid).

First, you have to locate your VPN gateway address in syslog:

NetworkManager[11926]: <info> VPN Gateway: X.X.X.X

Then, you have to check minimum MTU toward this address:

$ traceroute --mtu X.X.X.X
traceroute to X.X.X.X (X.X.X.X), 30 hops max, 65000 byte packets
1  192.168.43.1 (192.168.43.1)  4.309 ms F=1380  4.042 ms  2.535 ms
2  * *^C

Then you have to change MTU it in your primary connection settings (network manager on Ubuntu below):



That's all!. No more spurious disconnects!

PayU apologizes for ...

The best idea PR guys from PayU might have:

Dear Sir or Madam,

We would like to apologize for the INCORRECT INFORMATION in our last communication.

During the break which will take place on 27 November 2014 from 05:00 am to 05:30 am you could not be able to log in into the system but all transactions WILL BE SETTLED. A message informing about unavailability of the service may be displayed during login attempt.

We are very sorry for the inconvenience and misrepresentation.
--
Kind regards,
PayU Team

The funny thing is that I haven't got any e-mail on the technical break in the first place.

LOL.

Easy SSLv3 "poodle" vulnerability test (and the fix for Jboss/Tomcat)

Recently new vulnerability ("poodle") has been discovered in SSLv3 protocol. "man in the middle" attack could be performed using protocol version negotiation feature built into SSL/TLS to force the use of SSL 3.0 then exploit the "poodle" vulnerability.

In order to remove the threat from our servers we have to drop SSLv3 from negotiation list. Secured server should respond as follows:

$ echo | openssl s_client -connect 192.168.1.100:80 -ssl3 2>&1 | grep Secure
Secure Renegotiation IS NOT supported
$ echo | openssl s_client -connect 192.168.1.100:80 -tls1 2>&1 | grep Secure
Secure Renegotiation IS supported

We use openssl command to open HTTPS connection and check if requested protocol could be negotiated or not.

And the fix itself (for JBoss/Tomcat service): you have to locate Connector tag responsilble for HTTPS connection and:

• remove any SSL_* from ciphers attribute
• limit sslProtocols="TLSv1, TLSv1.1, TLSv1.2"

Example:

<Connector port="80" protocol="HTTP/1.1" SSLEnabled="true" ciphers="TLS_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
maxThreads="100" scheme="https" secure="true" minSpareThreads="25" maxSpareThreads="50"
keystoreFile="${jboss.server.home.dir}/conf/tm.keystore" keystorePass="MyKeyStore1"
clientAuth="false" sslProtocols="TLSv1, TLSv1.1, TLSv1.2" />

It will effectively block any SSLv3 connections as visible by "openssl s_client" test above.

Simple mailing list on Debian in 3 simple steps

Few days ago I launched simple low-traffic mailing list using naive /etc/aliases method, but got the following error:

<example1@onet.pl> (expanded from <example@myserver.com>): host
mx.poczta.onet.pl[213.180.147.146] said: 554 5.7.1 <example1@onet.pl>:=
Recipient address rejected: Spf check: fail (in reply to RCPT TO command)

If you think for a moment the reason for error it's obvious. My server tried to forward e-mail using original From address.Onet.pl checked TXT record (using SPF standard) for my server domain myserver.com and noticed it's not allowed to send e-mails from me.

In order to make things work properly one have to rewrite envelope From field properly. Mailing list managers usually do that properly (/etc/aliases is not enough).