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.