Hacking the Flucard Part 1:
OR Just Jump to the code... https://github.com/Augmentous/flucard
Interest and current State of the Art...
While working on the Augmentous project with a few friends [1], we came across the idea and thought that it would be great to upload images in semi-real time to the net. It would be sort-of like a live cam, but easier to deal with the data, less fast head movements, etc. This lead down the path of the, now commonplace, Eye-Fi.
We have had one for some time at HeatSync Labs, successfully uploading images to our Flickr feed from the Lab Camera where people shoot images of their projects for blogging etc. It has worked pretty well for the last few years. Their cloud platform puts the images up to Flickr through some of their servers and an unknown magical service. The card may or may not upload the images before the the camera powers down the SD card. It's all very non determinant of what will happen and when and how. It works though.
Eventually we got the Eye-Fi uploading to our web servers via FTP via the Eye-Fi cloud platform. No Doubt the Eye-Fi cloud platform made the process more efficient using some compression and their own protocols for talking with the card, once it was working. However, still, the card took 10-30 seconds to start connecting to Wifi and their it would upload at an unknown rate for unknown time. Periodically the camera would turn the SD card off and nothing would happen at all. Other times pictures would flow in and we didn't know they were. Writes also seemed slow. The card would cause the camera to take extra time to write the file to disk, causing the image to be lost before the camera would turn off.
The questions / goals are:
- Will it work for thousands of pictures a day and be able to upload to our own web server of sorts within minutes of taking the picture?
- How will this effect the battery life of a wearable camera with an already tight battery profile?
- Can we upload directly to out own servers without going through some other cloud service?
- Can we choose which pictures to upload in an intelligent way and possibly upload snapshots or thumbnails to conserve bandwidth and time?
We started searching for an alternative in order to get more feedback and tune the parameters better.
Possible options and ordering:
Two major alternatives exist: The PQI AirCard and the Trek Flucard.
After some quick Googling, it seemed that the FluCard at least had a Linux direction of it with possible configuration options, CGI servers, something.
I went ahead and purchased one via an Amazon provider.
It looked as though it would not arrive until late December. I was surprised to see it arrive on a two-day air-mail delivery from Singapore. Moreover, there were TWO of them in the package. Two for the price of one. OK. Now I can play with one and use the other.
The FluCard:
The FluCard in it's normal intended setup seems to be a bit confusing and not ready for prime-time yet. With no configuration it puts itself into some Wifi AP mode, generating a "Trek-FLUCARD-AP" SSID for you to connect to. It appears to provide a DHCP server as well, allowing 1 (later 8 in the 3.70 firmware) computers to connect. The configuration is done through a web interface. The interface allows you to add APs and Upload location either through FTP, the FluCard portal sever, or "Gallery3" services for the "Server Upload" mode. The mode must be activated by deleting a specific static picture on the card which will then trigger some magic on the card and start the upload mode. Unfortunately I never got this upload mode to work. It would decidedly not connect and beep forever. The first week or so with the card was spent in frustration of trying to a make the card work like a normal Eye-Fi to at least gain the same level of service and get a timing and power profile.
Then we tried an nmap against the card to see what services it had open and check the web server type. To our surprise, it had a telnet server running! A quick telnet session revealed it was root on the card with no password. Amazing. Suddenly tons of possibilities opened.
INSERT code snapshots of uname etc
Basic services seemed to be missing and most command line options were through the standard micro-binary busybox. Other seemingly custom functions such as "server_upload", etc, were also through busybox. This said to me that they must have appended busybox with more functions that called within it self. That is, instead of making another binary to call the different busybox ones, just jump around functions inside it. Smart idea. Also most of the start-up scripts were just simple shell scripts, so it was fairly easy to see the process of getting to the point where it started the web server, got on some wifi, etc.
The system itself is loaded from a ramdisk image (or two) in to RAM at boot time, thus changes to the system are lost at reboot.
Some googling of "flucard telnet" turned up a few Japanese blogs where the writer was able to make additions to the firmware by building some binaries, putting them on the SD Card partition, and symlinking the binaries in to the running system. In the startup scripts there is a second to run a file called "/mnt/sd/autorun.sh" if it exists at startup. This is to finalize firmware updates and set setting that may have changed between versions. The Japanese blogger used this script to put the symlinks in the running ramdisk after bootup. Success! His blog shows that over time he was able to use the code sourcery arm compile to compile a "Hello World" app in C. After that, he ported basic PHP, Ruby, Perl, dropbear SSH server (not client), and a larger more-full featured busybox to the system. These are all part of a "deploy" package. With this deploy in place we can modify or change most of the start-up process order and timing.
It should be noted, we also worked on a few different firmware levels to test the functionality of each. Initial firmware with the card:
- 3.52: Functional but not very featured. No FTP Server, Telnet is on, Less symlinks to busybox. Safe.
- 3.65: Doesnt seem to do uploads, telnet enabled, no "flucard android app support". Not on the website oddly enough.. even though it's on the card.
- 3.68: Seem to comment out telnet in the startup, change a few libraries, and add some sort of "flucard android app" support. Appears to be via FTP and the web interface.
- 3.70: Most functional, except for broken telnet. Included flu_app for supporting Android and iPhone apps. The most commands and libraries
Existing work
A few people, mostly Japanese, have already worked on the FluCard via the telnet interface. The most progress was made by "Ameblo.jp" website, where the author corsscompiled many binaries including PHP, Ruby, a better Busybox, dropbear SSH server, etc. The site is: http://ameblo.jp/tonsuke-usagi/entry-11212317428.html There are many other sites. See below [2].
With this package and combinations from other sites, I thought we could make some progress in creating an upload script that uploaded the right files, thumbnails, etc, in the right order at the right time.
End Part 1 .. for now.. to be continued..
OR Just Jump to the code... https://github.com/Augmentous/flucard