Research Pre GSM Modem Protocol
From WebOS Internals
Here we are collecting informations about the modem protocol. At the moment all the research is done on the european UMTS version of the Palm Pre. The CDMA version is likely to be pretty similar to the UMTS variant with regards to the protocol.
What we are doing to get used to the protocol is to strace the different applications that talk to the modem and log everything that goes over /dev/modemuart to the actual modem. From this wire protocol traces we are working backwards to the actual protocol and packet format.
There is a first implementation of the protocol. You can find it at:
Be careful: Nothing is in a usable state! It's a first implementation to play around with the protocol.
A new packet starts with: 0xFA (This may be an address instead as rfc1662 uses only one flag for frame separation).
As we found out that the CRC is calculated even over the flag 0xFA and with assuming that the basic for the protocol is HDLC we can say that 0xFA is not the starting flag of the frame. It should be an adress if we have a real implemenation of HDLC that follows the rfc.
A packet ends with: 0x7E
For the packet end marker there is an escaping sequence inside the packet. It is used 0x7D 0x5E instead. Therefore 0x7D is escaped as 0x7D 0x5D as well.
Header consists of 3 bytes. The first byte seems to be an adress or something like that, cause it's everytime the same byte 0xFA.
The second byte contains the type of the frame. It's stored in the lower for bytes (header >> 4) There are six types.
- 1: Sync Message
- 2: Sync Response Message
- 3: Configuration Message
- 4: Configuration Response message
- 5: Acknowledge Message
- 6: Data Message
The third byte contains the sequence and acknowledge number (look at the HCI Transport specification to find out how this two numbers are used in the protocol)
- sequence number: header >> 4
- acknowledge number: header & 0xf
No informations about the payload format have been gathered yet.
The last two bytes before the packet ending marker are a CRC16-FCS checksum. (See rfc1662 for polynom and table)
Similarity to RFC1662
The usage of CRC-16-FCS but even more the frame boundary packet as well as the escaping for it looks similar to what we found about this protocol. Even a grep -i HDLC over the binary firmware image reports the usage of PPP and HDLC as communication protocol format. So we can be almost sureley that HDLC+PPP is used.
Similarity to Bluetooth HCI
The protocol on the lower level has many similarities with the HCI Link Layer protocol used in Bluetooth for Serial transports.
Identified byte sequences
- Sync Message: 0xfa 0x10 0x0
- Sync Response Message: 0xfa 0x30 0x0
- Configuration Message: 0xfa 0x30 0x00 0x1
- Empty Configuration Message: 0xfa 0x40 0x0
- Configuration Response Message: 0xfa 0x40 0x0
- Acknowledge Message: 0xfa 0x50 0x0
- SIM PIN on startup is sent with: 0xfa 0x60 0xe3 0x0f 0x0e 0x00 0x13 0x00 0x00 0x00 0x00 <4 ASCII digits> 0x00 0x00 0x00 0x00 0x00
- SIM PIN acknowledgement from modem: 0xfa 0x50 0x0f
The GPS receiver is part of the modem in Palm Pre and all data received and sent related to location goes over the same port using the same frame coding as GSM. GPS functionality can not be enabled (at least not using the Palm-provided drivers) until modem radio is enabled and seemingly until the modem successfully registers to the network.
Tracing the data sent over /dev/modemuart the following hostnames can be seen being sent from the OS to the modem chip: xtra1.gpsonextra.net, xtra2.gpsonextra.net, xtra3.gpsonextra.net
They point to the RX Network's company website (rxnetwork.ca) that claims to provide better geolocation by combining GPS, wifi signals, GSM CellID and live reports downloaded over GPRS. The modem downloads the following files: http://xtra1.gpsonextra.net/xtra.bin, http://xtra2.gpsonextra.net/xtra.bin, http://xtra3.gpsonextra.net/xtra.bin