- 1尝试了一个自然语言模型BLOOM_bloom预训练模型
- 2[玩转AIGC]如何训练LLaMA2（模型训练、推理、代码讲解，并附可直接运行的kaggle连接）_llama2 如何训练
- 3基于OSPF的企业内网安全优化
- 4【Vulnhub 靶场】【Funbox: GaoKao】【简单】【20210606】_vulnhub靶场下载
- 5java毕业设计——基于JAVA+Bootstrap+MySQL的图书推荐系统设计与实现（毕业论文+程序源码）——图书推荐系统_推荐系统 数据库设计
- 612种常用的LINUX版本介绍_linux guofang 主流版本
- 7记录一次由Vite生成的Vue模板使用 vite-plugin-dts 插件无法正常生成类型文件的问题
- 8个人关于IaaS、Saas、Paas、DaaS平台的理解_软件架构图中的iaas,paas,daas层
- 9【开题报告】基于SpringBoot的个人博客的设计与实现_基于springboot的个人博客系统的开题报告
- 10阿里发布AI编码助手：通义灵码，兼容 VS Code、IDEA等主流编程工具_通义灵码官网
蓝牙相关学习：4.2.BLE空口包结构 - PDU_蓝牙pdu
赞
踩
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
-
PDU Type：标识ADV
-
RFU ： 预留
-
ChSel：如果本机支持跳频（Hopping）算法 #2，这设置成为 1
-
TxAdd：如果为 0 代表 ADV 是 public 类型的 Address，否则为 1，是 random 类型的 Address
-
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连接建立过程：https://www.cnblogs.com/iini/p/8972635.html
Payload length
数据包：长度域包含5个比特，有效值的范围是0~31。（原BLE4.0 4.1中 规定数据长度5个比特）
广播包：长度域包含6个比特，有效值的范围是6~37。
广播包和和数据包的长度域有所不同，主要原因是：广播包除了最多31个字节的数据之外，还必须要包含6个字节的广播设备地址。6+31=37，所以需要6比特的长度域。
转 ：https://www.cnblogs.com/debugdabiaoge/p/15772546.html
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）。
分类：
蓝牙协议分析(6)_BLE地址类型：http://www.wowotech.net/bluetooth/ble_address_type.html
一个BLE设备两种地址都可以使用（Public Device Address和Random Device Address）
Public Device Address
需要向IEEE购买；管理申请繁琐；不安全
Advertising Data
转：蓝牙协议分析(5)_BLE广播通信相关的技术分析 http://www.wowotech.net/bluetooth/ble_broadcast.html
广播数据（或者扫描应答数据）由一个一个的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，以及相应的数据格式，例如
参考地址：
https://www.pianshen.com/article/7755244605/
https://www.jianshu.com/p/7d814c22a085
| 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）https://stephenzhou.blog.csdn.net/article/details/95938674
-
LLID ： 用于区分这个 Connection 的包是普通的数据包（L2CAP 的起始/连续/空包），还是 Control PDU
-
NESN：下一个期望的对端包的 Sequence Number
NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传 -
SN：当前包的 Sequence Number
NESN 和 SN 来决定了数据包是否传输 OK，也就是是否需要重传 -
MD：是否有 More Data
MD 决定了后面是否跟有更多的数据。有了这个 MD，对端才会开窗继续来收数据。 -
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 预留 |
CtrData
待续，先这样吧
参考地址
抄的大佬，做的学习笔记。
转 ：BLE（3）—— 空口数据包组成 ：https://stephenzhou.blog.csdn.net/article/details/94676596
转：详解BLE空口包格式—兼BLE Link layer协议解析 https://www.cnblogs.com/iini/p/8977806.html
蜗窝科技：http://www.wowotech.net/sort/bluetooth
BLE:https://blog.csdn.net/zhoutaopower/category_9083143.html
https://blog.csdn.net/freemote/article/details/120165736
