Difference between revisions of "Research Pre GSM Modem Protocol"

From WebOS Internals
Jump to navigation Jump to search
(Add assume about 0xfa as non-starting-flag)
Line 34: Line 34:
  
 
http://tools.ietf.org/html/rfc1662
 
http://tools.ietf.org/html/rfc1662
 +
 +
=== 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

Revision as of 19:25, 21 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).

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. 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 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.

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

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