2026/02/25一、Wireshark 抓取正常 BLE 连接的过程1. 硬件准备Wireshark 本身不能直接抓空口蓝牙信号需要以下硬件之一方案硬件示例特点BLE SnifferNordic nRF52840 Dongle nRF Sniffer 固件最常用、便宜、Wireshark 直接支持你截图就是这个方案BLE SnifferTI CC2540/CC26xx USB Dongle配合 SmartRF Packet Sniffer 软件可导出 pcap专业协议分析仪Ellisys / Frontline / Teledyne Lecroy昂贵但支持全信道同时抓取、解密HCI 抓取电脑自带蓝牙适配器只抓主机到控制器的 HCI 层数据看不到空口广播包2. 软件配置以 nRF Sniffer 为例给 nRF Dongle 刷入 Sniffer 固件安装nRF Sniffer for Bluetooth LE插件Wireshark 3.4 支持Wireshark 中选择接口nRF Sniffer for Bluetooth LE选择要跟踪的设备你截图中选择了DAFQAMC可设置绑定密钥Passkey/OOB key来解密后续加密通信LTK 分发后的数据3. Wireshark 中的正常显示特征一个健康的 BLE 连接抓包在 Wireshark 中应呈现以下特征广播阶段能看到规律的ADV_IND约 20ms~10s 间隔取决于广播参数连接瞬间突然出现CONNECT_REQ随后广播包消失转为数据信道包地址解析连接后 Master/Slave 地址显示为Master_0x.../Slave_0x...或解析后的设备名空包交替即使无应用数据链路层也会定期交换Empty PDU保活截图中大量Empty PDU是正常的服务发现连接后短时间内会有密集的ATT层Read By Group Type/Read By Type请求无重传异常没有大量的LL_REJECT_IND或重复 NESN/SN 序号二、正常的 BLE 连接过程梳理一个标准的 BLE 主从连接Central → Peripheral分为以下阶段┌─────────────────┐ ┌─────────────────┐ │ Peripheral │ │ Central │ │ (IPC设备) │ │ (手机) │ └────────┬────────┘ └────────┬────────┘ │ │ │ 1. ADV_IND │ 1. 扫描Scanning │ (广播信道 37/38/39) │ ←──────────────────── │ │ │ ←──────────────────── │ 2. CONNECT_REQ │ │ (指定连接参数) │ │ │ 3. 进入连接状态 │ 3. 进入连接状态 │ (数据信道跳频) │ (数据信道跳频) │ │ │ ←──────────────────→ │ 4. 链路层控制包交换 │ LL_FEATURE_REQ/RSP │ (特性、版本、包长度) │ LL_LENGTH_REQ/RSP │ │ LL_VERSION_IND │ │ LL_CONN_PARAM_REQ/RSP│ │ LL_CONN_UPDATE_REQ │ │ │ │ ←──────────────────→ │ 5. GATT 服务发现 │ Read By Group Type │ (Discover All Primary Services) │ Read By Type │ (Discover Characteristics) │ Read / Write │ (读写特征值) │ │ │ ←──────────────────→ │ 6. 应用层数据交互 │ Notification/Indication│ (Notify/Write/Read)关键概念说明阶段技术点含义广播ADV_IND从机周期性广播可被连接连接请求CONNECT_REQ主机在收到广播的同一信道37/38/39直接发送无需握手确认跳频Channel Map连接后双方根据信道映射算法在 37 个数据信道间跳频抗干扰DLEData Length ExtensionBLE 4.2 特性将单包 Payload 从 27 字节提升到 251 字节GATTGeneric Attribute Profile定义服务Service和特征值Characteristic的层次结构ATTAttribute Protocol实际传输读写请求/响应的协议层三、抓包实战下面结合三张 Wireshark 截图逐阶段拆解。Phase 1广播与扫描【待补图】1 设备持续广播从抓包看IPC 设备MAC:11:d7:1a:58:a5:c9在37/38/39 广播信道周期性发送ADV_IND包号时间源地址类型长度Info700810:26:56.31111:d7:1a:58:a5:c9LE 1M29ADV_IND700910:26:56.31111:d7:1a:58:a5:c9LE 1M29ADV_IND..................702710:26:56.83211:d7:1a:58:a5:c9LE 1M29ADV_IND设备以固定间隔宣告自身存在等待被扫描或连接。2 手机主动扫描手机MAC:48:d7:c6:21:a0:0b为了获取设备更详细的广播数据发起主动扫描Active Scan包号时间源地址类型长度Info702810:26:56.83248:d7:c6:21:a0:0bLE 1M12SCAN_REQ702910:26:56.83211:d7:1a:58:a5:c9LE 1M15SCAN_RSPSCAN_REQ手机在广播信道发送扫描请求SCAN_RSP设备在同一信道立即回复扫描响应携带额外 31 字节广播数据如完整设备名、服务 UUID 等注意SCAN_REQ / SCAN_RSP只是收集信息并非连接握手。手机收到响应后并不会立即触发连接。Phase 2连接建立与链路层握手【待补图】1 CONNECT_REQ —— 连接的真正起点包号时间源地址类型长度Info704710:26:57.33348:d7:c6:21:a0:0bLE 1M34CONNECT_REQCONNECT_REQ携带了连接的核心参数Access Address本次连接的访问地址后续数据信道跳频使用Channel Map可用数据信道位图Connection Interval连接间隔如 7.5ms ~ 4sSlave Latency从机可跳过的心跳次数Supervision Timeout监督超时断连判定时间从此包开始双方退出广播信道跳转到37 个数据信道进行跳频通信。2 链路层控制LL Control PDUWireshark 将双方解析为Master_0xa1c51aee手机和Slave_0xa1c51aeeIPC随后进行链路层握手包号方向Control Opcode作用7048Master → SlaveLL_FEATURE_REQ交换支持的链路层特性LE 2M、Coded PHY、DLE 等7049Slave → MasterLL_SLAVE_FEATURE_REQ从机特性请求7050Master → SlaveLL_FEATURE_RSP特性响应7052Master → SlaveLL_LENGTH_REQ数据长度扩展DLE协商7055Slave → MasterLL_LENGTH_RSP数据长度响应7056Master → SlaveLL_VERSION_IND交换蓝牙版本号7060Master → SlaveLL_CONNECTION_PARAM_REQ协商连接参数7065Slave → MasterLL_CONNECTION_PARAM_RSP连接参数响应7068Master → SlaveLL_CONNECTION_UPDATE_REQ应用新连接参数这一系列握手确保双方在射频特性、数据包大小、协议版本、连接时序上达成一致是后续 GATT 通信的基础。Phase 3GATT 服务发现连接建立后手机作为 Central 必须认识设备的 GATT 数据库结构。通过ATT 协议发起服务发现包号协议请求类型说明7062ATTRead By Type Request读取 Appearance 特征值7067ATTRead By Type ResponseIPC 返回 Appearance7070ATTRead By Group Type Request读取Primary Service 声明7073ATTRead By Group Type Response返回 Generic Access Service 等7074ATTRead By Type Request(Include)查找被包含的服务7077ATTError ResponseAttribute Not Found—— 正常表示无 Include Service7078ATTRead By Type Request读取Characteristic Declaration7081ATTRead By Type Response返回 Device Name、Appearance 等特征值发现顺序的标准性BLE 规范要求的服务发现顺序为Discover All Primary ServicesRead By Group TypeDiscover All CharacteristicsRead By TypeDiscover All Characteristic DescriptorsFind InformationRead/Write 具体特征值截图中的顺序完全符合规范说明 IPC 设备的 GATT 数据库结构正确手机端的蓝牙栈实现标准。Phase 4空闲保活与主动断开【待补图】1 空闲期的 Empty PDU当应用层无数据时如用户未操作 AppBLE 连接并不会静默而是按Connection Interval周期性交换Empty PDU包号方向Info7307Slave → MasterEmpty PDU7308Master → SlaveEmpty PDU.........7324Master → SlaveEmpty PDU作用维持时序同步、确认双方仍在射频范围内、更新 SN/NESN 序号Length 0表示链路层空包无 ATT 数据2 主动断开 —— LL_TERMINATE_IND当手机端App 或系统蓝牙栈决定关闭连接时发送链路层终止指示包号方向类型长度Info7325Master → SlaveLE LL2LL_TERMINATE_IND7326Slave → MasterLE LL0Empty PDUACKLL_TERMINATE_IND携带1 字节 Error Code说明断开原因0x13Remote User Terminated Connection用户/应用主动关闭0x16Connection Terminated by Local Host本端主机主动断开Slave 用Empty PDU应答后双方立即退出连接状态3 恢复广播包号时间源地址Info732710:27:00.47211:d7:1a:58:a5:c9ADV_IND............IPC 设备在收到终止指示后立即恢复广播重新进入可发现/可连接状态。后续还收到其他设备的SCAN_REQ7334、7342并正常回复SCAN_RSP7343。四、手机连接蓝牙的完整过程扫描 → 连接 → 发现 → 空闲 → 断开 → 恢复广播的完整生命周期时间线10:26:56.311 ~ 10:27:00.909阶段 1广播与扫描第三张图 7008–7046设备(IPC) ──ADV_IND──→ 空口 (持续广播宣告存在) ↑ ↓ └────SCAN_RSP──── 手机 (7028发SCAN_REQ请求更多信息) ↓ [应用层处理/等待/决策] ↓ CONNECT_REQ (7047)IPC 设备在 37/38/39 信道周期性广播ADV_IND手机为了确认设备身份主动发SCAN_REQ7028设备在同一信道立即回复SCAN_RSP7029手机没有立即连接设备继续广播了约 500ms手机最终选定该设备在 7047 发送CONNECT_REQ阶段 2连接建立与链路层握手第一张图 7047–7061手机 ──CONNECT_REQ──→ IPC ↓ ↓ Master_0x... Slave_0x... (分配访问地址进入连接态) ↓ ↓ LL_FEATURE_REQ ←→ LL_SLAVE_FEATURE_REQ (特性协商) LL_LENGTH_REQ ←→ LL_LENGTH_RSP (数据长度扩展) LL_VERSION_IND ←→ LL_VERSION_IND (版本交换) LL_CONN_PARAM ←→ LL_CONN_PARAM_RSP (连接参数协商)7047 的CONNECT_REQ携带了访问地址Access Address、初始信道映射、连接间隔、监督超时等关键参数此后双方跳转到数据信道0-36不再使用广播信道Wireshark 解析为Master_0xa1c51aee/Slave_0xa1c51aee阶段 3GATT 服务发现第一张图 7062–7084手机(ATT) ──Read By Group Type──→ IPC (查Primary Service) ↑ ↓ └────Read By Type Response───────────┘ (返回GAP服务) 手机(ATT) ──Read By Type──────────→ IPC (查Characteristic) ↑ ↓ └────Read By Type Response───────────┘ (返回Device Name等)手机作为 Central必须认识设备的 GATT 数据库结构依次读取Appearance → Primary Service → Include → Characteristic Declaration这是后续一切数据交互读写、Notify的基础阶段 4应用数据交互截图未展示或本次无业务数据如果 App 需要控制 IPC如开关、参数配置会在此阶段发 Read/Write/Notify本次抓包中服务发现后似乎没有应用层业务数据或数据极少阶段 5空闲保活第二张图 7307–7324Master ──Empty PDU──→ Slave Slave ──Empty PDU──→ Master ... 持续约 324ms ...无应用数据时双方严格按连接间隔Connection Interval交换Empty PDU作用是维持时序同步、确认射频链路存活、更新 SN/NESN 序号阶段 6主动断开第二张图 7325–7326手机 ──LL_TERMINATE_IND──→ IPC (Error Code: 0x13 或类似) IPC ──Empty PDU(ACK)────→ 手机手机Master主动发起链路层终止Slave 用空包应答确认断开阶段 7恢复广播第二张图 7327 起IPC ──ADV_IND──→ 空口 (重新进入广播态) ↑ ↓ └─SCAN_RSP── 其他扫描者 (7343)IPC 设备立即恢复广播等待下一次被扫描或连接周围其他设备或同一部手机可以继续发SCAN_REQ与其交互五、问题Q1、为什么有大量Empty PDUBLE 连接建立后Master 和 Slave 必须严格遵循连接事件Connection Event在每个间隔时间点唤醒射频并交换数据。如果应用层无数据双方就发送Length0 的 Empty PDU这既是心跳也是给对方发送 ACK/更新 SNSequence Number的机会如果连续多次通常由Supervision Timeout定义如 5 秒收不到任何包才会判定为连接超时断开Q2、为什么 SCAN_RSP 后没有立即发 CONNECT_REQ*SCAN_REQ / SCAN_RSP 只是扫描收集信息不是连接前握手。手机发完扫描请求后完全有权自主决定何时甚至是否发起连接。
Wireshark蓝牙抓包
2026/02/25一、Wireshark 抓取正常 BLE 连接的过程1. 硬件准备Wireshark 本身不能直接抓空口蓝牙信号需要以下硬件之一方案硬件示例特点BLE SnifferNordic nRF52840 Dongle nRF Sniffer 固件最常用、便宜、Wireshark 直接支持你截图就是这个方案BLE SnifferTI CC2540/CC26xx USB Dongle配合 SmartRF Packet Sniffer 软件可导出 pcap专业协议分析仪Ellisys / Frontline / Teledyne Lecroy昂贵但支持全信道同时抓取、解密HCI 抓取电脑自带蓝牙适配器只抓主机到控制器的 HCI 层数据看不到空口广播包2. 软件配置以 nRF Sniffer 为例给 nRF Dongle 刷入 Sniffer 固件安装nRF Sniffer for Bluetooth LE插件Wireshark 3.4 支持Wireshark 中选择接口nRF Sniffer for Bluetooth LE选择要跟踪的设备你截图中选择了DAFQAMC可设置绑定密钥Passkey/OOB key来解密后续加密通信LTK 分发后的数据3. Wireshark 中的正常显示特征一个健康的 BLE 连接抓包在 Wireshark 中应呈现以下特征广播阶段能看到规律的ADV_IND约 20ms~10s 间隔取决于广播参数连接瞬间突然出现CONNECT_REQ随后广播包消失转为数据信道包地址解析连接后 Master/Slave 地址显示为Master_0x.../Slave_0x...或解析后的设备名空包交替即使无应用数据链路层也会定期交换Empty PDU保活截图中大量Empty PDU是正常的服务发现连接后短时间内会有密集的ATT层Read By Group Type/Read By Type请求无重传异常没有大量的LL_REJECT_IND或重复 NESN/SN 序号二、正常的 BLE 连接过程梳理一个标准的 BLE 主从连接Central → Peripheral分为以下阶段┌─────────────────┐ ┌─────────────────┐ │ Peripheral │ │ Central │ │ (IPC设备) │ │ (手机) │ └────────┬────────┘ └────────┬────────┘ │ │ │ 1. ADV_IND │ 1. 扫描Scanning │ (广播信道 37/38/39) │ ←──────────────────── │ │ │ ←──────────────────── │ 2. CONNECT_REQ │ │ (指定连接参数) │ │ │ 3. 进入连接状态 │ 3. 进入连接状态 │ (数据信道跳频) │ (数据信道跳频) │ │ │ ←──────────────────→ │ 4. 链路层控制包交换 │ LL_FEATURE_REQ/RSP │ (特性、版本、包长度) │ LL_LENGTH_REQ/RSP │ │ LL_VERSION_IND │ │ LL_CONN_PARAM_REQ/RSP│ │ LL_CONN_UPDATE_REQ │ │ │ │ ←──────────────────→ │ 5. GATT 服务发现 │ Read By Group Type │ (Discover All Primary Services) │ Read By Type │ (Discover Characteristics) │ Read / Write │ (读写特征值) │ │ │ ←──────────────────→ │ 6. 应用层数据交互 │ Notification/Indication│ (Notify/Write/Read)关键概念说明阶段技术点含义广播ADV_IND从机周期性广播可被连接连接请求CONNECT_REQ主机在收到广播的同一信道37/38/39直接发送无需握手确认跳频Channel Map连接后双方根据信道映射算法在 37 个数据信道间跳频抗干扰DLEData Length ExtensionBLE 4.2 特性将单包 Payload 从 27 字节提升到 251 字节GATTGeneric Attribute Profile定义服务Service和特征值Characteristic的层次结构ATTAttribute Protocol实际传输读写请求/响应的协议层三、抓包实战下面结合三张 Wireshark 截图逐阶段拆解。Phase 1广播与扫描【待补图】1 设备持续广播从抓包看IPC 设备MAC:11:d7:1a:58:a5:c9在37/38/39 广播信道周期性发送ADV_IND包号时间源地址类型长度Info700810:26:56.31111:d7:1a:58:a5:c9LE 1M29ADV_IND700910:26:56.31111:d7:1a:58:a5:c9LE 1M29ADV_IND..................702710:26:56.83211:d7:1a:58:a5:c9LE 1M29ADV_IND设备以固定间隔宣告自身存在等待被扫描或连接。2 手机主动扫描手机MAC:48:d7:c6:21:a0:0b为了获取设备更详细的广播数据发起主动扫描Active Scan包号时间源地址类型长度Info702810:26:56.83248:d7:c6:21:a0:0bLE 1M12SCAN_REQ702910:26:56.83211:d7:1a:58:a5:c9LE 1M15SCAN_RSPSCAN_REQ手机在广播信道发送扫描请求SCAN_RSP设备在同一信道立即回复扫描响应携带额外 31 字节广播数据如完整设备名、服务 UUID 等注意SCAN_REQ / SCAN_RSP只是收集信息并非连接握手。手机收到响应后并不会立即触发连接。Phase 2连接建立与链路层握手【待补图】1 CONNECT_REQ —— 连接的真正起点包号时间源地址类型长度Info704710:26:57.33348:d7:c6:21:a0:0bLE 1M34CONNECT_REQCONNECT_REQ携带了连接的核心参数Access Address本次连接的访问地址后续数据信道跳频使用Channel Map可用数据信道位图Connection Interval连接间隔如 7.5ms ~ 4sSlave Latency从机可跳过的心跳次数Supervision Timeout监督超时断连判定时间从此包开始双方退出广播信道跳转到37 个数据信道进行跳频通信。2 链路层控制LL Control PDUWireshark 将双方解析为Master_0xa1c51aee手机和Slave_0xa1c51aeeIPC随后进行链路层握手包号方向Control Opcode作用7048Master → SlaveLL_FEATURE_REQ交换支持的链路层特性LE 2M、Coded PHY、DLE 等7049Slave → MasterLL_SLAVE_FEATURE_REQ从机特性请求7050Master → SlaveLL_FEATURE_RSP特性响应7052Master → SlaveLL_LENGTH_REQ数据长度扩展DLE协商7055Slave → MasterLL_LENGTH_RSP数据长度响应7056Master → SlaveLL_VERSION_IND交换蓝牙版本号7060Master → SlaveLL_CONNECTION_PARAM_REQ协商连接参数7065Slave → MasterLL_CONNECTION_PARAM_RSP连接参数响应7068Master → SlaveLL_CONNECTION_UPDATE_REQ应用新连接参数这一系列握手确保双方在射频特性、数据包大小、协议版本、连接时序上达成一致是后续 GATT 通信的基础。Phase 3GATT 服务发现连接建立后手机作为 Central 必须认识设备的 GATT 数据库结构。通过ATT 协议发起服务发现包号协议请求类型说明7062ATTRead By Type Request读取 Appearance 特征值7067ATTRead By Type ResponseIPC 返回 Appearance7070ATTRead By Group Type Request读取Primary Service 声明7073ATTRead By Group Type Response返回 Generic Access Service 等7074ATTRead By Type Request(Include)查找被包含的服务7077ATTError ResponseAttribute Not Found—— 正常表示无 Include Service7078ATTRead By Type Request读取Characteristic Declaration7081ATTRead By Type Response返回 Device Name、Appearance 等特征值发现顺序的标准性BLE 规范要求的服务发现顺序为Discover All Primary ServicesRead By Group TypeDiscover All CharacteristicsRead By TypeDiscover All Characteristic DescriptorsFind InformationRead/Write 具体特征值截图中的顺序完全符合规范说明 IPC 设备的 GATT 数据库结构正确手机端的蓝牙栈实现标准。Phase 4空闲保活与主动断开【待补图】1 空闲期的 Empty PDU当应用层无数据时如用户未操作 AppBLE 连接并不会静默而是按Connection Interval周期性交换Empty PDU包号方向Info7307Slave → MasterEmpty PDU7308Master → SlaveEmpty PDU.........7324Master → SlaveEmpty PDU作用维持时序同步、确认双方仍在射频范围内、更新 SN/NESN 序号Length 0表示链路层空包无 ATT 数据2 主动断开 —— LL_TERMINATE_IND当手机端App 或系统蓝牙栈决定关闭连接时发送链路层终止指示包号方向类型长度Info7325Master → SlaveLE LL2LL_TERMINATE_IND7326Slave → MasterLE LL0Empty PDUACKLL_TERMINATE_IND携带1 字节 Error Code说明断开原因0x13Remote User Terminated Connection用户/应用主动关闭0x16Connection Terminated by Local Host本端主机主动断开Slave 用Empty PDU应答后双方立即退出连接状态3 恢复广播包号时间源地址Info732710:27:00.47211:d7:1a:58:a5:c9ADV_IND............IPC 设备在收到终止指示后立即恢复广播重新进入可发现/可连接状态。后续还收到其他设备的SCAN_REQ7334、7342并正常回复SCAN_RSP7343。四、手机连接蓝牙的完整过程扫描 → 连接 → 发现 → 空闲 → 断开 → 恢复广播的完整生命周期时间线10:26:56.311 ~ 10:27:00.909阶段 1广播与扫描第三张图 7008–7046设备(IPC) ──ADV_IND──→ 空口 (持续广播宣告存在) ↑ ↓ └────SCAN_RSP──── 手机 (7028发SCAN_REQ请求更多信息) ↓ [应用层处理/等待/决策] ↓ CONNECT_REQ (7047)IPC 设备在 37/38/39 信道周期性广播ADV_IND手机为了确认设备身份主动发SCAN_REQ7028设备在同一信道立即回复SCAN_RSP7029手机没有立即连接设备继续广播了约 500ms手机最终选定该设备在 7047 发送CONNECT_REQ阶段 2连接建立与链路层握手第一张图 7047–7061手机 ──CONNECT_REQ──→ IPC ↓ ↓ Master_0x... Slave_0x... (分配访问地址进入连接态) ↓ ↓ LL_FEATURE_REQ ←→ LL_SLAVE_FEATURE_REQ (特性协商) LL_LENGTH_REQ ←→ LL_LENGTH_RSP (数据长度扩展) LL_VERSION_IND ←→ LL_VERSION_IND (版本交换) LL_CONN_PARAM ←→ LL_CONN_PARAM_RSP (连接参数协商)7047 的CONNECT_REQ携带了访问地址Access Address、初始信道映射、连接间隔、监督超时等关键参数此后双方跳转到数据信道0-36不再使用广播信道Wireshark 解析为Master_0xa1c51aee/Slave_0xa1c51aee阶段 3GATT 服务发现第一张图 7062–7084手机(ATT) ──Read By Group Type──→ IPC (查Primary Service) ↑ ↓ └────Read By Type Response───────────┘ (返回GAP服务) 手机(ATT) ──Read By Type──────────→ IPC (查Characteristic) ↑ ↓ └────Read By Type Response───────────┘ (返回Device Name等)手机作为 Central必须认识设备的 GATT 数据库结构依次读取Appearance → Primary Service → Include → Characteristic Declaration这是后续一切数据交互读写、Notify的基础阶段 4应用数据交互截图未展示或本次无业务数据如果 App 需要控制 IPC如开关、参数配置会在此阶段发 Read/Write/Notify本次抓包中服务发现后似乎没有应用层业务数据或数据极少阶段 5空闲保活第二张图 7307–7324Master ──Empty PDU──→ Slave Slave ──Empty PDU──→ Master ... 持续约 324ms ...无应用数据时双方严格按连接间隔Connection Interval交换Empty PDU作用是维持时序同步、确认射频链路存活、更新 SN/NESN 序号阶段 6主动断开第二张图 7325–7326手机 ──LL_TERMINATE_IND──→ IPC (Error Code: 0x13 或类似) IPC ──Empty PDU(ACK)────→ 手机手机Master主动发起链路层终止Slave 用空包应答确认断开阶段 7恢复广播第二张图 7327 起IPC ──ADV_IND──→ 空口 (重新进入广播态) ↑ ↓ └─SCAN_RSP── 其他扫描者 (7343)IPC 设备立即恢复广播等待下一次被扫描或连接周围其他设备或同一部手机可以继续发SCAN_REQ与其交互五、问题Q1、为什么有大量Empty PDUBLE 连接建立后Master 和 Slave 必须严格遵循连接事件Connection Event在每个间隔时间点唤醒射频并交换数据。如果应用层无数据双方就发送Length0 的 Empty PDU这既是心跳也是给对方发送 ACK/更新 SNSequence Number的机会如果连续多次通常由Supervision Timeout定义如 5 秒收不到任何包才会判定为连接超时断开Q2、为什么 SCAN_RSP 后没有立即发 CONNECT_REQ*SCAN_REQ / SCAN_RSP 只是扫描收集信息不是连接前握手。手机发完扫描请求后完全有权自主决定何时甚至是否发起连接。
