================================================================ BFB protocol as used by Siemens Mobile Equipment (e.g. S45/ME45) over a serial connection ================================================================ Christian Zuckschwerdt 2002-02-06 added unknown S35i commands from Thierry's logs 2002-06-22 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 0x02 - single bytes used for connecting and data reading 0x01 - crc'ed sequence to change interface (speed) 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 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 resend. 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.