DeviceMaster protocol, part 2: UDP fields

We ended the last post having split up the UDP scan/refresh response into individual fields, with each consisting of a value identifier, a length, and the actual content of the field. Now we come to deciphering the meaning of those fields.

DeviceMaster protocol, part 1: UDP protocol

The DeviceMaster range, at least with current firmware and drivers, uses a UDP-based protocol for discovery. The obvious first step, then, was to start Wireshark and log a few scans performed via PortVision DX. The Scan function within PortVision DX sent messages of the following form to the UDP broadcast address 255.255.255.255 on port 4606:

a9 8d fd 53 7a 1c b0 de 00 00 2c 00 0c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

A lot of zeros there, not much to go on. Performing more scans showed the the 0x2c in byte 11 was incrementing, so this was presumably a sequence number of some kind. Leaving PortVision DX open overnight showed that it was a 16 bit count in little-endian byte order. The 0x0c byte could be specifying a function—in this case a scan.

DeviceMaster protocol, part 0: My device and software

This is the first post of a short series describing my effort to reverse engineer the protocol used by Comtrol for their DeviceMaster range of Ethernet device servers. These allow RS-232/422/485 connected devices to be communicated with over an ethernet network.

Error building grep for OpenEmbedded

This is another error related to using a newer version of texinfo than expected. It’s also another “wait for it to fail and then edit in the working directory” solution unless someone can provide a better option.

Once the build has failed with the following message:

grep.texi:291: @itemx must follow @item

open up $GUMSTIXTOP/tmp/work/x86_64-linux/grep-native-2.5.1-r2/grep-2.5.1/doc/grep.texi and delete lines 286 to 290 (inclusive). Side-effect: your generated documentation will no longer be perfect.

Error fetching packages for OpenEmbedded

For my third post on compiling OpenEmbedded for Gumstix on a modern system, we come across errors downloading base-passwd, busybox, curl, dosfstools, fakeroot, file, gconf-dbus, git, iana-etc, ipkg, ipkg-utils, libxml-parser-perl, libxml2, mime-support, module-init-tools, netbase, openssl, pax-utils, pcmciautils, popt, pxaregs.c, setserial, sysvinit, tinylogin, tslib, udev, update-alternatives, update-rc.d, usbutils, util-linux, and zlib.

This is a simple problem and a simple fix: old versions of these packages are either moved to a different location or removed entirely, so we change the URLs that the build process uses. Beware: using alternate sources for these packages carries an inherent risk – you may be downloading a modified version without knowing. Where possible you should also add hash entries for each file based on a known good value.

gcc error building Python in OE

This error message provides very little clue as to what the actual problem is when compiling Python during the OpenEmbedded build process:

gcc: error: directory”: No such file or directory

As it turns out (thanks to the tip here), this is caused by a change in subversion.

Luckily it’s easy to inject your own copy earlier in the path than the one it usually finds. Simply create a script called svnversion in $GUMSTIXTOP/bitbake/bin and insert the following:

#!/bin/sh
echo exported

Your problem should be solved.

Missing find.pl compiling OE

I received the following error when compiling OpenEmbedded due to a file that is no longer included in Perl distributions:

| Can’t locate find.pl in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.18.2 /usr/local/share/perl/5.18.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.18 /usr/share/perl/5.18 /usr/local/lib/site_perl .) at perlpath.pl line 7.

There are ways to integrate a copy of the file into the build process, but my inexperience with bitbake et al. meant that when they didn’t work I couldn’t troubleshoot very well myself. Instead, I simply placed the file in /etc/perl. The contents of the file, which should be called find.pl, can be found below.

binutils errors compiling OE

The second problem I encountered in building OpenEmbedded for our Gumstix devices was a failure when downloading binutils. Specifically, the checksum found for the downloaded file didn’t match the one that the build process expected. The message given is:

NOTE: The MD5Sums did not match. Wanted: ‘9d22ee4dafa3a194457caf4706f9cf01’ and Got: ‘ccd264a5fa9ed992a21427c69cba91d3’
NOTE: Task failed: Checksum of ‘ftp://ftp.gnu.org/gnu/binutils/binutils-2.18.tar.bz2’ failed
NOTE: package binutils-cross-2.18-r1: task do_fetch: failed
ERROR: TaskFailed event exception, aborting
NOTE: package binutils-cross-2.18: failed
ERROR: Build of /home/kemp/gumstix/gumstix-oe/org.openembedded.snapshot/packages/binutils/binutils-cross_2.18.bb do_fetch failed
ERROR: Task 317 (/home/kemp/gumstix/gumstix-oe/org.openembedded.snapshot/packages/binutils/binutils-cross_2.18.bb, do_fetch) failed

The error is due to an incompatibility between older versions of binutils and newer versions of texinfo. This post show you how to resolve this.

patch version error compiling OE

I have had to check out our Gumstix stock and find out if it’s still usable. They are a mix of old Connex and (non-Pro) Verdex boards and so the only OS I can build for them is OpenEmbedded. I have yet to find out if the currently available version from the Gumstix website actually works with these versions of the boards, but one step at a time…

This post walks through how to solve the following error message when building OpenEmbedded on modern systems:

| configure: error:
| quilt requires at least version 2.4 of GNU patch. You can download a
| current version of patch from ftp.gnu.org, or if you already have GNU patch
| then you can supply its path with the ‘–with-patch=’ option.