Digi Connect ME Discovery

I have a Digi Connect ME powered device that I’ve been trying to interface with from Mac OS X, the only platform Digi does not provide their RealPort drivers for. The Digi Connect ME is a serial to ethernet bridge that runs embedded Linux on an ARM processor. Their RealPort driver that doesn’t exist for OS X is a virtual serial port driver which routes data over a TCP connection to the Connect ME where it is de-muxed and sent over TTL serial to your device.

In typical fashion I decided to simply reverse engineer the so called “Advanced Digi Discovery Protocol” or ADDP in able to discover devices on the network. ADDP makes use of UDP broadcast packets sent to port 2362. The packets take the form of a magic character sequence of ‘DIGI’ followed by a two byte sequence number and a series of elements. These elements are of the form: one byte element ID, one byte element length and then element length bytes of data. In the data below, magic characters are in red, sequence numbers are in orange, packet length is in green, element IDs are in blue, element lengths are in purple and element data is in yellow.

The ADDP discovery broadcast UDP packet is structured as follows:

0000   44 49 47 49 00 01 00 06 ff ff ff ff ff ff       DIGI..........

This packet has sequence 0001 and element 0 has length of 6 with data as six 0xFF bytes.

A network device that implements ADDP data will respond to the device that sent the broadcast on port 1181 with something like the following:

0000   44 49 47 49 00 02 00 60 01 06 00 40 9d 33 d2 94 DIGI...`...@.3..
0010   02 04 XX XX 70 07 03 04 ff ff 00 00 0b 04 00 00 ....p...........
0020   00 00 0d 0f 44 69 67 69 20 43 6f 6e 6e 65 63 74 ....Digi Connect
0030   20 4d 45 10 01 01 07 01 00 08 1e 56 65 72 73 69  ME........Versi
0040   6f 6e 20 38 32 30 30 30 38 35 36 5f 46 36 20 30 on 82000856_F6 0
0050   37 2f 32 31 2f 32 30 30 36 0e 04 00 00 03 03 13 7/21/2006.......
0060   04 00 00 04 03 12 01 01                         ........

This packet has sequence 0002 and has a length of 0×0060 or 96 bytes – not including the bytes up to this point. Element 1 has length 6 and is the MAC address of the device. Element 2 has length 4 bytes and is the device’s IP. Element 3 has length 4 and is the device’s Netmask. Element 0xB has length 4 and is the device’s Gateway. Element 0xd has 15 bytes and is the device’s name. Element 10 has length 1 and I think it is the number of serial devices. Element 7 has length 1 and is unknown. Element 8 has length 30 and is the device’s Firmware version. Element 0xe has 4 bytes and is has unknown value 0×00000303. Element 0×13 has length 4 and unknown value 0×0000403. Element 0×12 has length 1 and unknown value 1.

I have attached a simple python script that I have written to find DIGI Connect ME enabled devices on your network. Note that it requires that you have the netifaces Python library installed. This should also detect the Connect WI-ME and possibly other DIGI network enabled products.

FUSE for Windows

Many times in the past I’ve had want for the most excellent FUSE to have a Windows equivalent. There are many internet posts on the issue and why it is roughly a million times more complex to do on Windows than on *nix/BSD/OS X and hence why it hasn’t been done by the OSS community.

After my most recent need for a FUSE equivalent on Windows I came across this paper which was written in 2007 by Evan Driscoll, Jonathan Beavers and Hidetoshi Tokuda from the University of Wisconsin-Madison. Unfortunately they come to the same conclusion as everyone else and fall back to implementing a FUSE compatibility layer on top of FIFS which implements a SMB server to provide access to other filesystems.

UPDATE: as Frederico resports in the comments, Dokan is a capable Windows equivalent to FUSE.

64-bit Filezilla for Vista x64

So I just managed to get a 64-bit version of Filezilla to compile for Vista x64 – FTP and SFTP seem to be working fine although I haven’t had a chance to check proxy or FTP+TLS yet. I’m off to Mammoth Mountain for a weekend of boarding and then I’ll make a beta release right here for the rest of you to test. The only thing I really had to change was disabling the IDNA support (Internationalizing Domain Names in Applications) since it uses libidn which I haven’t been able to get to compile under Visual Studio.

Things would be much easier if there was a 64-bit version of gcc for windows.

PuTTY 0.59 x64 build

I just uploaded a 64bit x64 build of PuTTY 0.59 made with Visual Studio 2005 and it can be found at http://www.kelley.ca/amd64

vhdTools v0.3.1 Released

This release is a bugfix release and fixes bugs caused by using 32-bit integers (size_t is not 64-bit!) which caused problems with images > 2GB. Grab it here

Note: the 0.3.0 release link is symlinked to the 0.3.1 release.