Card communication on the local network

Chris Davies saw this blog and was nice enough to point me to some tools he has written. They somewhat take the place of the Eye-Fi manager. In Chris's words:

> It's all fairly trivial. After the card gets a DHCP
> response, it sends out a flood of ARP requests ... for
> each host in the subnet.  It then does a triple handshake
> on the predesignated port of each host in turn, until it
> finds one that's running a server on it. After that it
> just tries to authenticate with that host, and send it
> pictures.

"That host" is, of course, the one running the Eye-Fi manager. Chris's tools will listen on that predesignated port for the card to contact it, and start accepting pictures.

Well, here's the problem: I don't see any of this behavior!! I set up a second ethernet card in one of my Linux machines and turned on bridging with it and a normal card, then put my wifi access point on that second card. That makes my PC act like an ethernet switch that allows me to monitor all the traffic that goes over it with network monitoring tools.

I used a filter in Wireshark to narrow down the traffic to just the Eye-Fi card with this filter

(eth.addr == 00:18:56:aa:bb:cc) &&
!(ip.addr == 216.218.219.2)

That's because "00:18:56:aa:bb:cc" is the MAC address of the Eye-Fi card, and "216.218.219.2" is the IP address of the Eye-Fi server. So, this let me look at all of the card's communication with things other than the Eye-Fi server.

After the DNS requests to talk to the Eye-Fi server, I don't see the card do much of anything.

Wine patch

Well, it turns out that wine doesn't respect the Windows CreateFile() flags FILE_FLAG_NO_BUFFERING or FILE_FLAG_WRITE_THROUGH. I have a really simple wine patch to "fix" that. I really haven't thought it through in too much detail, but it seems to work.

Basically, whenever wine sees either of those two flags, it just disables all of Linux's filesystem caching with the open() flag O_DIRECT. You can apply the patch to the latest version of wine out of its git repository. and probably earlier versions, too. Here's my patch.

I'll probably be trying to get this into the upstream wine distribution soon.

BTW, if you want some help building wine, I'd be happy to help, so just email me.

Eye-Fi Manager Working in Linux!!!

First of all, this is perhaps the most significant progress I've made so far in unraveling this device. Getting it to work in Linux means that I have a very complete set of debugging tools to use on it to see how it works.

I'm running the "Eye-Fi Manager.exe" with wine. The issues that I was seeing with it were because Linux is not reading back the actual disk contents, but cached disk contents. I noticed this by enabling debugging on the usb_storage driver, then accessing the card multiple times with both O_SYNC and O_DIRECT set.

Those options should have caused Linux to do real reads from the card each time, but I didn't see the usb_storage debugging kicking in each time I did a read. See this post if you're curious why it's important to do real reads each time.

Anyway, I instructed wine to have the kernel throw away its cached copies just before each read() of the control files. I did it with this call:

posix_fadvise(unix_handle, 0, 0, POSIX_FADV_DONTNEED);

The result: a working Eye-Fi Manager in Linux. You need to hack and rebuild wine, but it is at least a proof of concept. It works!!

Now, I just need to go find out why the reads() aren't obeying O_DIRECT. It's probably either the usb_storage driver or the vfat filesystem code.

Alternative to Upload to Computer

Since I run Linux don't have a Windows machine, I can't simply use the Eye-Fi manager's ability to copy all pictures down to a PC. But, I noticed that Google's Picasa has an open API for accessing it (and 1GB of free storage). So, I changed my picture service to Picasa and started digging. There is an apparently Google-written implementation of a perl libarary to access Picasa.

I used this library to create a little script called picasa-upload.pl. You can run this script to automatically download all pictures directly from picasa, and store them on your PC. You can get my script along with a slightly hacked up version of the Picasa libary here:

http://www.sr71.net/~dave/projects/picasa-download

Run this every few minutes in a cronjob and, for me, it's just as good as the built-in Eye-Fi capability!

Eyefi software uses Curl!

I was grepping through the Windows binaries looking to see from where messages come when I ran across a little surprise. The Eye-Fi manager software uses a piece of free software called curl. Specifically, they statically link in a library portion of curl, libcurl. It basically implements a little tiny web browser inside of their application so it can talk back to the Eye-Fi web servers.

It is a bit of a shame that Eye-Fi would choose to use free software inside of its products, but neglect Free Software users by not providing specs or software that run on Free operating systems.

By the way, nobody is violating any license or legal terms here. Curl is free to use in the way Eye-Fi uses it. I just don't think it is very nice.

Request encoding

I've noticed that the data written to the REQM file changes dramatically, despite the command being the exact same. I can only assume that there's some kind of encoding going on there. Maybe not encryption per-se, but there something scrambling it, and with something more than just the simple command. There's some value that changes each time getting thrown into the calculation. But, without going in and doing something against the license agreement like disassembling, I can't think of any easy way to figure out what is going on in there. Suggestions welcome!