Difference between revisions of "Research Pre GSM Modem Protocol"

From WebOS Internals
Jump to navigation Jump to search
(Add more information about the frame header and first implementation of the protocol)
 
(10 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
Here we are collecting informations about the modem protocol. At the moment all the research is don on the european UMTS version of the Palm Pre. The CDM version is likely to be pretty similar to the UMTS variant with regards to the protocol.
+
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.
 
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.
 +
 +
=== Implementation ===
 +
 +
There is a first implementation of the protocol. You can find it at:
 +
* http://git.freesmartphone.org/?p=msmcomm.git;a=summary
 +
 +
Be careful: Nothing is in a usable state! It's a first implementation to play around with the protocol.
  
 
=== Packet Start ===
 
=== Packet Start ===
  
−
A new packet starts with: '''0xFA''' (This may be an address instead as rfc1662 uses only one flag for frame separation)
+
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.
  
 
=== Packet End ===
 
=== Packet End ===
Line 13: Line 22:
 
=== Escaping ===
 
=== Escaping ===
  
−
For the packet end marker there is an escaping sequence inside the packet. It is used '''0x7D 0x5E''' instead. Therefor '''0x7D''' is escaped as '''0x7D  0x5D''' as well.
+
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 ===
 
=== Header ===
  
−
No informations about the header format have been gathered yet.
+
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[1] >> 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[2] >> 4'''
 +
* acknowledge number: '''header[2] & 0xf'''
 +
 
  
 
=== Payload ===
 
=== Payload ===
Line 25: Line 47:
 
=== Checksum ===
 
=== Checksum ===
  
−
The last two(?) bytes before the packet ending marker seem to be a CRC16 checksum. For now we think it is the CRC-16-CCITT variant.
+
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.
 +
 
 +
http://tools.ietf.org/html/rfc1662
 +
 
 +
=== 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.
 +
 
 +
http://www.bluetooth.com/NR/rdonlyres/24C24181-5B5D-4566-BB4F-D4C302910B9D/1766/Volume4_SPEC.pdf
  
−
=== Similarity to HDLC ===
+
=== 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 usage of CRC-16-CCITT but even more the frame boundary packet as well as the escaping for it looks similar to what we found about this protocol. Using HDLC would of course make sense and we need to do further investigation on this.
+
=== GPS ===
 +
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.
  
−
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
+
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
  
−
http://en.wikipedia.org/wiki/HDLC
+
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

Latest revision as of 22:03, 11 November 2009

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.

Implementation

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.

Packet Start

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.

Packet End

A packet ends with: 0x7E

Escaping

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

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[1] >> 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[2] >> 4
  • acknowledge number: header[2] & 0xf


Payload

No informations about the payload format have been gathered yet.

Checksum

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.

http://tools.ietf.org/html/rfc1662

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.

http://www.bluetooth.com/NR/rdonlyres/24C24181-5B5D-4566-BB4F-D4C302910B9D/1766/Volume4_SPEC.pdf

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

GPS

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

Retrieved from "http://wiki.webos-internals.org/index.php?title=Research_Pre_GSM_Modem_Protocol&oldid=7104"