BFB Protocol
Used for serial cable connection to Siemens Mobile Equipment
- 2002-02-06 Christian Zuckschwerdt (zany at triq.net)
- 2002-06-22 added unknown S35i commands from Thierry’s logs
(0) Disclaimer
It is possible to harm your mobile phone.
Use the information in this document at your own risk.
(1) Preface
This document is a result of many hours of studying the
Siemens Mobile Equipment BFB protocol
by the author, in an attempt to implement a way to access
Flex.Mem. Like all tools, this document
was born out of frustration with the lack of documention
available on the subject.
Though every attempt has been made to ensure the correctness
of this document, the author cannot make any guarantees as
to its accuracy.
(2) Transport encapsulation
[ type ][ len ][ chk ][ payload ]
Types are
- 0x01 crc’ed sequence to change interface (speed)
- 0x02 single bytes used for connecting and data reading
- 0x05 Keypress and such
- 0x06 AT-Command
- 0x09 unkown (return code from mobile?)
- 0x0E unkown (return code from mobile?)
- 0x14 EEPROM block manipulation
- 0x16 crc’ed generic data (like OBEX)
Len is from 1 to max 32 for a max MTU of 35 bytes.
[Chk] equals to [type]XOR[len].
(3) OBEX encapsulation (transport type = 0x16)
[ cmd ][ chk ] for cmd 0x01
[ cmd ][ chk ][ seq ][ len16 ][ data… ][ crc16 ] for cmd 0x02 and 0x03.
Chk is ~cmd (bitwise not cmd)
- Cmd 0x01: “ack” command. If some packet isn’t acknowledged it will be resent.
- Cmd 0x02: first transmission in a row. Sequence counter is 0
- Cmd 0x03: continued transmission. Sequence counter is incremented with each subsequent packet
Seq is 1 byte. TA increments, ME replies.
Len is 2 bytes in network byte order.
Data is an OBEX frame.
Crc16 is 2 bytes CCITT-CRC16 in network byte order. Rendered over the the whole packet except for cmd and chk.
(4) Conclusion
This seems to cover all the bits.
My test-implementation works great – YMMV.