Difference between revisions of "Research Pre GSM Modem Protocol"

From WebOS Internals
Jump to navigation Jump to search
Line 27: Line 27:
 
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 seem to be a CRC16 checksum. For now we think it is the CRC-16-CCITT variant.
  
=== Similarity to HDLC ===
+
=== Similarity to RFC1662 ===
  
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.
+
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.
  
http://en.wikipedia.org/wiki/Cyclic_redundancy_check
+
http://tools.ietf.org/html/rfc1662
 
 
http://en.wikipedia.org/wiki/HDLC
 

Revision as of 23:57, 20 October 2009

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.

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.

Packet Start

A new packet starts with: 0xFA (This may be an address instead as rfc1662 uses only one flag for frame separation)

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. Therefor 0x7D is escaped as 0x7D 0x5D as well.

Header

No informations about the header format have been gathered yet.

Payload

No informations about the payload format have been gathered yet.

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.

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.

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