btsnoop格式解析

斥巨巨巨巨资买了一套蓝牙协议栈的教程，做个笔记

btsnoop 是用来抓取 host 和 controller 之间的交互数据，用来分析蓝牙的问题比较常用。btsnoop 文件存储形式是大端存储，所以直接读就行了

整个的文件格式只有两部分，File Header 和 Packet Record x，其中 File Header 是文件头，只在文件开头有一个，剩下的 Packet Record 是记录的每个数据包，有好多个

File Header 格式

File Header 分为 Identification Pattern、Version Number、Datalink Type 分别表示：识别号、版本、数据格式

识别号其实就是 btsnoop 的 ascii 码值，占用 8 字节，后面是 4 字节的版本，现在就只有 1

再往后 4 字节是 Datalink Type 的编号，对应的是数据类型，像上面 03 EA 换算成十进制就是 1002，也就是说，我这个 log 是 H4 的，安卓默认就是 H4，甚至在代码里直接写死的这个值

Packet Record的格式

Packet Record 就到了具体的数据包了，其格式如下

Original Length，4byte 表示该数据包的长度，如果拆包的话他就比 Included Length 大了

Included Length，4bye 表示本包包含的数据长度

Packet Flags，4byte，表示这个数据包的标志，第 0 位如果是 0 表示数据方向是发送，如果是 1 表示数据方向是接受，第 1 位如果是 0 表示传输的是数据，如果是 1 表示传输的是 Command/Event

拿这个例子来看 Packet Flags 是 00 00 00 02，也就是说 Direction flag = 0，Command flag = 1，表示这个数据包是发出去的 Command

用 wireshark 打开验证一下，第一个包确实是 send 的 HCI_CMD

Cumulative Drops，4 byte 用来统计丢失的数据包的数量，数据包可能因为系统资源不足等原因丢失，如果没这个能力统计这个就设为 0

Timestamp Microseconds，8 byte 时间戳，但不是传统意义的时间戳，它是以公元 0 年 1 月 1 日开始的，而且是以微秒为单位，因此这个值巨大

Packet Data，后面就是数据部分了

接下来看另一个 Packet Record，分析一下各个部分的值

前面两个 00 00 00 07 是 Original Length 和 Included Length，00 00 00 03 表示这个数据包是收到的 Event，00 00 00 00 表示没有丢失的数据包，00 E2 C1 45 47 AA 57 D6 是时间戳，后面 04 0E 04 01 03 0C 00 是数据内容