| 1 | BFB PROTOCOL |
|---|
| 2 | ============ |
|---|
| 3 | |
|---|
| 4 | Used for serial cable connection to Siemens Mobile Equipment |
|---|
| 5 | ============================================================ |
|---|
| 6 | |
|---|
| 7 | - 2002-02-06 Christian Zuckschwerdt <zany@triq.net> |
|---|
| 8 | - 2002-06-22 added unknown S35i commands from Thierry's logs |
|---|
| 9 | |
|---|
| 10 | |
|---|
| 11 | (0) Disclaimer |
|---|
| 12 | -------------- |
|---|
| 13 | |
|---|
| 14 | It is possible to harm your mobile phone. |
|---|
| 15 | Use the information in this document at your own risk. |
|---|
| 16 | |
|---|
| 17 | |
|---|
| 18 | (1) Preface |
|---|
| 19 | ----------- |
|---|
| 20 | |
|---|
| 21 | This document is a result of many hours of studying the |
|---|
| 22 | Siemens Mobile Equipment BFB protocol |
|---|
| 23 | by the author, in an attempt to implement a way to access |
|---|
| 24 | Flex.Mem. Like all tools, this document |
|---|
| 25 | was born out of frustration with the lack of documention |
|---|
| 26 | available on the subject. |
|---|
| 27 | |
|---|
| 28 | Though every attempt has been made to ensure the correctness |
|---|
| 29 | of this document, the author cannot make any guarantees as |
|---|
| 30 | to its accuracy. |
|---|
| 31 | |
|---|
| 32 | |
|---|
| 33 | (2) Transport encapsulation |
|---|
| 34 | --------------------------- |
|---|
| 35 | |
|---|
| 36 | [ type ][ len ][ chk ][ payload ] |
|---|
| 37 | |
|---|
| 38 | Types are |
|---|
| 39 | - 0x02 single bytes used for connecting and data reading |
|---|
| 40 | - 0x01 crc'ed sequence to change interface (speed) |
|---|
| 41 | - 0x05 Keypress and such |
|---|
| 42 | - 0x06 AT-Command |
|---|
| 43 | - 0x09 unkown (return code from mobile?) |
|---|
| 44 | - 0x0E unkown (return code from mobile?) |
|---|
| 45 | - 0x14 EEPROM block manipulation |
|---|
| 46 | - 0x16 crc'ed generic data (like OBEX) |
|---|
| 47 | |
|---|
| 48 | Len is from 1 to max 32 for a max MTU of 35 bytes. |
|---|
| 49 | |
|---|
| 50 | Chk equals type xor len. |
|---|
| 51 | |
|---|
| 52 | |
|---|
| 53 | (3) OBEX encapsulation (transport type = 0x16) |
|---|
| 54 | ---------------------------------------------- |
|---|
| 55 | |
|---|
| 56 | [ cmd ][ chk ] for cmd 0x01 |
|---|
| 57 | |
|---|
| 58 | [ cmd ][ chk ][ seq ][ len16 ][ data... ][ crc16 ] for cmd 0x02 and 0x03. |
|---|
| 59 | |
|---|
| 60 | Chk is ~cmd (bitwise not cmd) |
|---|
| 61 | |
|---|
| 62 | = Cmd 0x01: "ack" command. If some packet isn't acknowledged it will be resend. |
|---|
| 63 | = Cmd 0x02: first transmission in a row. Sequence counter is 0 |
|---|
| 64 | = Cmd 0x03: continued transmission. Sequence counter is incremented with each |
|---|
| 65 | subsequent packet |
|---|
| 66 | |
|---|
| 67 | Seq is 1 byte. TA increments, ME replies. |
|---|
| 68 | |
|---|
| 69 | Len is 2 bytes in network byte order. |
|---|
| 70 | |
|---|
| 71 | Data is an OBEX frame. |
|---|
| 72 | |
|---|
| 73 | Crc16 is 2 bytes CCITT-CRC16 in network byte order. Rendered over the the |
|---|
| 74 | whole packet except for cmd and chk. |
|---|
| 75 | |
|---|
| 76 | |
|---|
| 77 | (4) Conclusion |
|---|
| 78 | -------------- |
|---|
| 79 | |
|---|
| 80 | This seems to cover all the bits. |
|---|
| 81 | My test-implementation works great -- YMMV. |
|---|
| 82 | |
|---|
