My quest to unravel the hidden mysteries of the eFrame 1000’s proprietary protocols has been successful and I will start to share my initial findings.
The first significant discovery was that the frame acts as a client and connects to the PC server in response to specially formed broadcast packets or status requests. It also uses standard FTP to retrieve files from the PC.
To discover any photo frames on the network, the PC sends a broadcast UDP message to port 21900 and then waits for a response. The content of the message is as follows:
- The 1st parameter (Search) is the command
- The 2nd & 3rd parameters (PF110) appear to be internal names for the eFrame
- The 4th parameter (20021) is the port number that the FTP server is listening on
- The 5th parameter (21901) is the port number that the message server is listening on
- The 6th & 7th parameters (‘shuttle’ in this case) is the name of the PC server
- The 8th parameter (PF110) is the FTP username
- The 9th parameter (QmitwPF) is the FTP password
- The 10th parameter (192.168.1.2) is the IP address of the server
When the frame receives this message, it responds to the server address and messaging port number with a message similar to the following:
This message contains the port number of the frame’s messaging service and the device’s unique ID / serial number.
The PC server may also send status request messages:
To which the frame responds with:
The response contains the serial number / ID of the frame and the firmware version.
The following status request prompts the frame to report back the amount of free internal storage:
A typical response from the frame is as follows:
I have written some Perl scripts to automate the frame discovery, registration and file transfer which I will attach shortly.
I have just gotten one of these for a song from dabs myself, and done a quick tear down on the unit:
I have previously worked on making a similar thing myself from an NSLU2 plus a USB2VGA adaptor. I got quite far with the software, sadly the hardware really wasn’t up to it, so I abandoned it. Perhaps with your scripts Victor, I can ressurect the concept!
I got one of these frames last week. I’ve got news and weather feeds working along with a few others using http://www.framechannel.com. I’ve documented my efforts here: http://droza.net/blog/2009/04/07/making-the-eframe-more-interesting/
I’m very interested in what you’re doing with the protocol. I knocked together a crude Java app last night to send a UDP message to the frame to try to convince it to retrieve images from an ftp server on my network. Sadly the frame just ignored the message so I guess I got something wrong (although the message I sent looked the same as the one from the BT software when I monitored it with Ethereal). Have you had any success with faking the messages sent from the BT software?
Thanks for this – look forward to reading more about the protocols as you uncover them – if I get time it’d be nice to knock up a simple app to make more use of them. I wonder if there are further discoveries to be made, e.g. eFrame listing its own filesystem contents, eFrame client uploading files to the server, etc.
On a final note, you mentioned in your first eFrame posting that the ability to use Framechannel had been removed from the BT firmware. You may be interested to know that this is still possible, see these pages for info on how to set it up:
Hi there, how is your perl going? I’ve started implementation of a python library for controlling the eframe at http://code.google.com/p/adqmisc/source/browse/trunk/eframe
I’m updating my blog as I make progress at: http://adq.livejournal.com