蓝牙数据包用wireshark

PDU

• PDU 基本数据结构

• LL Header

• 广播包（广播报文）

• Advertising Header

• PDU Type

• Advertising PDU
• Scanning PDU
• Initialing PDU

• Payload length
• Payload （有效数据包）

• Advertising Address
• Advertising Data

• 完整数据包

• 数据包（数据报文）

• Data Header

• LL DATA PDU
• LL Control PDU

• Payload Length
• Payload

• LL DATA PDU

• L2CAP PDU Length
• L2CAP Channel ID （L2CAP CID）

• LL Control PDU

• Opcode
• CtrData

• 参考地址

BLE 4.0 - BLE 5.0 ，BLE 5.1 的部分内容没有加入到里面，待添加

PDU 基本数据结构

PDU（protocol data unit，协议数据单元，BLE 数据传送的基本单元）前两个字节固定为LL header（1个字节长）和 payload length（1个字节长，又称data length），即可以展开为：

协议数据单元，又分为广播通道PDU和数据通道PDU

LL Header

长度为一个字节。
在广播包里他是 Advertising Header；在数据包里他是 data header

广播包（广播报文）

Advertising Header

1. PDU Type：标识ADV
2. RFU ： 预留
3. ChSel：如果本机支持跳频（Hopping）算法 #2，这设置成为 1
4. TxAdd：如果为 0 代表 ADV 是 public 类型的 Address，否则为 1，是 random 类型的 Address
5. RxAdd：如果为 0 代表期望的对端地址类型为 public，否则为1，代表期望对端的 Target Address 为 random（在指向性广播中使用，因为指向性广播，携带了对端地址，其他类型广播，这个 bit 没用）

PDU Type

Advertising PDU

	Control PDU Name	Description
	ADC_IND(通用广播)	Advertiser发送的、可被连接的、无方向的广播数据（connectable undirected advertising event）
	ADV_DIRECT_IND(定向广播)	Advertiser发送的、可被连接的、单向广播数据（connectable directed advertising event）
	ADV_NONCONN_IND(不可连接广播)	Advertiser发送的、不可被连接的、无方向的广播数据（non-connectable undirected advertising event）
	ADV_SCAN_IND(可扫描广播)	Advertiser发送的、可接受SCAN_REQ请求的、无方向的广播数据（scannable undirected advertising event）

Scanning PDU

	Control PDU Name	Description
	SCAN_REQ(扫描请求)	Scanner发送的、向Advertiser请求额外信息的数据包（一般需要在收到ADV_SCAN_IND后才可发送）
	SCAN_RSP(扫描响应)	Advertiser发送的、响应SCAN_REQ请求的数据包

Initialing PDU

	Control PDU Name	Description
	CONNECT_REQ(连接请求)	Initiater 发起的、请求建立连接的数据包
	CONNECT_IND（5.1）

根据蓝牙spec规定，advertiser发送完一个广播包之后150us（T_IFS），advertiser必须开启一段时间的射频Rx窗口，以接收来自observer的数据包。Observer就可以在这段时间里给advertiser发送连接请求。如下图所示，手机在第三个广播事件的时候扫到了设备B，并发出了连接请求CONN_REQ(CONN_REQ又称为CONNECT_IND)。

转：详解BLE连接建立过程：

Payload length

数据包：长度域包含5个比特，有效值的范围是0~31。（原BLE4.0 4.1中 规定数据长度5个比特）

广播包：长度域包含6个比特，有效值的范围是6~37。

广播包和和数据包的长度域有所不同，主要原因是：广播包除了最多31个字节的数据之外，还必须要包含6个字节的广播设备地址。6+31=37，所以需要6比特的长度域。

转 ：

Payload （有效数据包）

在广播包中，Payload由两部分组成，Advertising Address 和 Advertising Data组成，如下：

Advertising Address

Device Address，广播包中的强制字段（数据包里没有），俗称蓝牙MAC地址。
如果是广播包，则是advertiser的MAC地址；如果是scan包或者连接请求包，则是scanner的MAC地址。
蓝牙device address为6个字节，这样Advertising data最长为：37-6 = 31B，这就是广播包数据最长只能31个字节的由来（1M PHY）。

分类：

 

需要向IEEE购买；管理申请繁琐；不安全

Advertising Data

 

广播数据（或者扫描应答数据）由一个一个的AD Structure组成，对于未满31bytes的其它数据，则填充为0（无效数据）；

每个AD Structure由两部分组成：1byte的长度信息（Data的长度），和剩余的Data信息；
Data信息又由两部分组成：AD Type（长度不定）指示该AD Structure的类型，以及具体的AD Data。

无效数据部分
广播包的长度必须是 31 个 byte，如果有效数据部分不到 31 自己，剩下的就用 0 补全。这部分的数据是无效的。

最关键的还是AD Type，BLE协议根据实际的应用场景，定义了各种各样的AD type，以及相应的数据格式，例如 

AD Type	Value	描述	备注
Flags	0x01	标注蓝牙特性
Service UUIDs	0x02	标注服务UUID	非完整的16 bit UUID列表
Service UUIDs	0x03	标注服务UUID	完整的16 bit UUID列表
Service UUIDs	0x04	标注服务UUID	非完整的32 bit UUID列表
Service UUIDs	0x05	标注服务UUID	完整的32 bit UUID列表
Service UUIDs	0x06	标注服务UUID	非完整的128 bit UUID列表
Service UUIDs	0x07	标注服务UUID	完整的128 bit UUID列表
Local Name	0x08	标注名称	设备简称
Local Name	0x09	标注名称	设备全名
TX Power Level	0x0A	标注射频发射功率	表示设备发送广播包的信号强度
Simple Pairing Option OOB Tags	0x0D	标注安全管理带我外标签	设备类别
Simple Pairing Option OOB Tags	0x0E	标注安全管理带我外标签	设备配对的Hash值
Simple Pairing Option OOB Tags	0x0F	标注安全管理带我外标签	设备配对的随机值
Security Manager TK Value	0x10	标注 带外方式配对绑定时的TK	TK安全管理
Security Manager Out of Band	0x011	标注带外特性标志	带外安全管理
Slave Connection Interval Range	0x012	标注连接参数范围	外设（Slave）连接间隔范围
List of 16-bit Service Solicitation UUIDs	0x014	标注主机特定服务	服务搜寻16 bit UUID列表
List of 128-bit Service Solicitation UUIDs	0x015	标注主机特定服务	服务搜寻128 bit UUID列表
Service Data	0x016	服务数据	16 bit UUID Service，前两个字节是UUID，后面是Service的数据
Public Target Address	0x17		公开目标地址，表示希望这个广播包被指定的目标设备处理，此设备绑定了公开地址
Random Target Address	0x18		：随机目标地址，表示希望这个广播包被指定的目标设备处理，此设备绑定了随机地址
Appearance	0x19		表示设备的外观
Advertising Interval	0x1A		广播区间
LE Bluetooth Device Address	0x1B		LE设备地址
LE Role	0x1C		LE设备角色
Simple Pairing Hash C-256	0x1D		256位设备配对的Hash值
Simple Pairing Randomizer R-256	0x1E		256位设备配对的随机值
Service Data - 32-bit UUID	0x20		32 bit UUID Service，前4个字节是UUID，后面是Service的数据
Service Data - 128-bit UUID	0x21		128 bit UUID Service，前16个字节是UUID，后面是Service的数据
3D Information Data	0x3D		3D信息数据
Manufacturer Specific Data	0xFF	厂商信息	厂商自定义数据，厂商自定义的数据中，前两个字节表示厂商ID，剩下的是厂商自己按照需求添加，里面的数据内容自己定义。

Flags
bit 0: LE有限发现模式
bit 1: LE普通发现模式
bit 2: 不支持BR/EDR
bit 3: 对Same Device Capable(Controller)同时支持BLE和BR/EDR
bit 4: 对Same Device Capable(Host)同时支持BLE和BR/EDR
bit 5…7: 预留

Security Manager Out of Band
bit 0: OOB Flag，0-表示没有OOB数据，1-表示有
bit 1: 支持LE
bit 2: 对Same Device Capable(Host)同时支持BLE和BR/EDR
bit 3: 地址类型，0-表示公开地址，1-表示随机地址

完整数据包

0d 03 4e 00 00 80 03 26 aa d6 be 89 8e 00 24 40 9c d0 38 c1 a4 02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 93 52 e4

我们传输的数据结构：

aa d6 be 89 8e 00 24 40 9c d0 38 c1 a4 02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 93 52 e4

aa – 前导帧(preamble)
d6 be 89 8e （0x8E89BED6） – 访问地址(access address)
00 – LL帧头字段(LL header)
24 – 有效数据包长度(payload length)
40 9c d0 38 c1 a4 （0xA4C138D09C40）– 广播者设备地址(advertiser address)
02 01 06 03 03 1a 18 09 ff 5a a5 a4 c1 38 d0 9c 40 0c 09 44 46 53 4b 30 34 2d 39 43 34 30 – 广播数据
93 52 e4 – CRC24值

数据包（数据报文）

Data Header

转：BLE（8）—— 连接态数据包组成（ Connection Packets PDUs）

1. LLID ： 用于区分这个 Connection 的包是普通的数据包（L2CAP 的起始/连续/空包），还是 Control PDU
2. NESN：下一个期望的对端包的 Sequence Number
   NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传
3. SN：当前包的 Sequence Number
   NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传
4. MD：是否有 More Data
   MD 决定了后面是否跟有更多的数据。有了这个 MD，对端才会开窗继续来收数据。
5. RFU：预留

LL DATA PDU

当 Connection 的包体中 LLID 是 01’b 或者 10’b 的时候，说明这个是个数据包（L2CAP的）

如下，是01的时候，是数据包

如下，是10的时候，是数据包

如上，01的时候数据包是空包，10的时候数据包是普通数据包

LL Control PDU

当 Connection 的包体中 LLID 是 11’b 的时候，说明这个是个控制包（LL Control PDU）

如下，11的时候是控制包

Payload Length

数据包：长度域包含5个比特，有效值的范围是0~31。
原BLE4.0 4.1中 规定数据长度5个比特。BLE4.2以后可以修改。

Payload

LL DATA PDU

LL DATA PDU数据包就是 L2CAP的数据包。

如果包含MIC部分

mic是消息完整性检查分场景的（如果payload 为空或者该linklayer 没有加密可以不添加mic部分，反之添加mic部分）

L2CAP PDU Length

表示后面information payload的长度，information payload最大长度除了受这个L2CAP length字段约束，同时还受MTU的限制。

MTU，Maximum Transmission Unit，是ATT层与L2CAP层可以交互的最大数据长度，或者说是Client与Server可以交互的最大长度。

总结一下，蓝牙spec里面定义了2个长度字段：
LL data length和L2CAP length，同时ATT层还定义了一个MTU，以限制ATT PDU最大长度。
LL data length可以通过LL_LENGTH_REQ和LL_LENGTH_RSP来动态改变，MTU size则可以通过后面要讲到的Exchange MTU Request和Exchange MTU Response来改变，而L2CAP length无法动态改变，也就是说不能超过65535。

L2CAP Channel ID （L2CAP CID）

逻辑通道的ID，BLE使用固定的通道编号，也就是说虽然蓝牙spec里面也允许BLE使用connection oriented channel，但大部分BLE协议栈实现的时候都是使用固定的通道编号，通道编号定义如下所示：

	Value	描述
	0x0004	用于ATT协议
	0x0005	用于L2CAP信令
	0x0006	用于安全管理

待续，先这样吧

LL Control PDU

连接建立之后，Master或者Slave可以借助Link Layer Control Protocol (LLCP)，通过LL Control PDU，对连接进行管理控制

数据格式如下：

LL Control PDU是在Link layer层直接进行交互的，他们不会经过后面的L2CAP层。

Opcode

Opcode	Control PDU Name	Description
0x00	LL_CONNECTION_UPDATE_IND	更新链接参数
0x01	LL_CHANNEL_MAP_REQ（4.2）	更新链接的 Channel Map
0x01	LL_CHANNEL_MAP_IND（5.1）	更新链接的 Channel Map
0x02	LL_TERMINATE_IND	断开连接请求
0x03	LL_ENC_REQ	加密流程相关交互
0x04	LL_ENC_RSP	加密流程相关交互
0x05	LL_START_ENC_REQ	加密流程相关交互
0x06	LL_START_ENC_RSP	加密流程相关交互
0x07	LL_UNKNOWN_RSP	收到未知的 LLCP 后的回复
0x08	LL_FEATURE_REQ	请求交换 Feature 的交互，蓝牙设备连接后用于数据
0x09	LL_FEATURE_RSP	请求交换 Feature 的交互
0x0A	LL_PAUSE_ENC_REQ	重启加密流程相关交互
0x0B	LL_PAUSE_ENC_RSP	重启加密流程相关交互
0x0C	LL_VERSION_IND	交换蓝牙协议版本
0x0D	LL_REJECT_IND	拒绝请求
0x0E	LL_SLAVE_FEATURE_REQ	Slave 请求 Feature
0x0F	LL_CONNECTION_PARAM_REQ	更新链接参数
0x10	LL_CONNECTION_PARAM_RSP	更新链接参数
0x11	LL_REJECT_EXT_IND	扩展类型的拒绝请求
0x12	LL_PING_REQ	加密后的 PING 流程交互
0x13	LL_PING_RSP	加密后的 PING 流程交互
0x14	LL_LENGTH_REQ	更新空口数据长度
0x15	LL_LENGTH_RSP	更新空口数据长度
0x16	LL_PHY_REQ	PHY 更新相关交互
0x17	LL_PHY_RSP	PHY 更新相关交互
0x18	LL_PHY_UPDATE_IND	PHY 更新相关交互
0x19	LL_MIN_USED_CHANNELS_IND	Channels 相关的配置
All other values	Reserved for Future	Use 预留