抓取手机的蓝牙HCI日志并分析

我们在进行蓝牙开发时，如果遇到和手机端连接的问题，可以通过抓取手机端的HCI日志来协助判断。

什么是HCI日志

那什么是HCI日志呢？

蓝牙主机控制器接口（HCI）日志抓取与分析 ，属于系统级蓝牙协议调试 ，用于捕获手机蓝牙芯片（Controller）与主机（Host）之间的所有 HCI 指令、事件与数据包，覆盖经典蓝牙（BR/EDR）与低功耗蓝牙（BLE），是定位连接、配对、扫描或数据传输问题的核心手段。

---

🧩 它是什么

• 本质：抓取 HCI 层原始流量，记录手机与蓝牙芯片的交互，包括扫描、连接、配对、读写属性等全流程。
• 格式 ：安卓多为BTSnoop 格式（RFC 1761） ，文件名为btsnoop_hci.log；iOS 为PacketLogger 格式 ，文件后缀.pklg，均可在Wireshark打开分析。
• 价值 ：能看清经典蓝牙的信号强度（RSSI）、链路状态、错误码与协议交互，解决 "BLE 能扫、经典扫不到 / 连不上" 等问题。

---

✅ 关键技巧

• 抓包前关闭无关蓝牙设备，减少干扰；记录复现时间点，便于定位日志片段。
• 经典蓝牙重点看：HCI Inquiry/Inquiry Response（扫描）、Connection Request/Accept（连接）、RSSI 值（信号强度）。
• 常见问题：错误码0x0c（连接被主机拒绝）、0x13（页面超时）、RSSI 持续 <-80dBm（信号弱）。

---

⚠️ 注意事项

• 安卓日志存于受保护目录，非 Root 可能需先复制到外部存储。
• iOS 必须安装开发者描述文件，个人账号可抓，企业账号无额外限制。
• 日志体积大，抓包后及时关闭，避免占用存储。

---

一句话总结：这是系统级 HCI 抓包，能完整还原经典蓝牙与 BLE 的底层交互，是排查蓝牙连接、扫描、配对问题的 "终极手段"。

具体能看哪些内容

这种抓 HCI 日志，就是把手机和所有蓝牙设备之间的每一句 "对话" 都录下来 ，包括：扫描、配对、连接、发数据、断开、信号强弱、报错......全部底层交互都能看到。

我用最直白的话给你讲清楚：

---

1. 这个调试方式叫什么？

官方叫法：HCI 抓包 / HCI Log / Bluetooth Snoop Log

通俗理解：蓝牙版的 "抓网卡包"，相当于给蓝牙装了个录音笔。

---

2. 你能看到什么？（重点）

只要你手机和别的蓝牙设备（经典蓝牙 / BLE 都行）发生交互，日志里会完整记录：

① 扫描过程

• 手机发：我要搜索设备（HCI_Inquiry）
• 周围设备回复：我在这里，名字是 XX，MAC 是 XX（Inquiry Result）
• 你能看到：
  • 设备什么时候出现
  • 什么时候消失
  • 信号强度 RSSI
  • 是经典蓝牙还是 BLE

② 配对过程

• 手机 → 设备：请求配对
• 设备 → 手机：回复配对请求
• 交换密钥、认证、加密一步不落全部可见

③ 连接过程

• 手机发起连接（Create Connection）
• 设备同意连接（Connection Complete）
• 建立链路（ACL 连接）
• 经典蓝牙会建立 SPP 通道

④ 数据传输

• 你发的每一包数据
• 对方回的每一包数据
• 丢包、重传、延迟

⑤ 信号强度 RSSI

不管是经典蓝牙还是 BLE，只要连上，就能读到实时 RSSI这就是你之前想测 "距离远了信号弱" 的最准方法。

⑥ 断开原因

• 是远端断开？
• 是信号弱断开？
• 是超时？
• 是手机主动断？日志里都有错误码，一查就知道。

---

3. 为什么这个方法比任何 APP 都强？

因为：

• APP 只能看上层结果
• HCI 日志看的是蓝牙芯片底层真实对话

你之前遇到的：

距离远了手机搜不到经典蓝牙

用 HCI 日志一打开，就能看到：

• 设备还在广播，但RSSI 太弱
• 或者手机根本没发出扫描指令
• 或者设备回复了，但手机丢掉了

这是定位蓝牙问题的终极手段。

---

4. 用什么工具看？

• 安卓抓出来：btsnoop_hci.log
• 用 Wireshark 直接打开

Wireshark 能解析：

• 经典蓝牙（BR/EDR）
• BLE
• HCI 指令
• ACL 数据
• SPP 数据
• RFCOMM
• L2CAP

---

5. 最简单总结（你只要记住这句）

抓 HCI 日志 = 把手机和蓝牙设备之间的所有交互全部录下来，用 Wireshark 打开就能一步一步看它们怎么聊天、怎么连接、信号多强、为什么断。

不管是经典蓝牙还是 BLE，全都能看。

HCI日志局限性和其它排查手段

一、HCI 日志（抓 btsnoop / 蓝牙 snoop）的局限性

1. 只能看到 手机侧 的数据，看不到从机侧

• 手机发了什么 → 能看到
• 从机收到没、从机内部怎么处理 → 完全看不到
• 所以：
  • 手机发了查询 → 日志里有
  • 但从机没回应 → 你不知道是距离远信号弱 ，还是从机死机 / 没广播

2. 看不到 空中无线环境

HCI 日志是手机与蓝牙芯片之间的交互日志 ，不是空中抓包。

你看不到：

• 同频干扰
• 2.4G WiFi 干扰
• 信号反射、遮挡
• 空中丢包只能看到 "手机发出去了 / 没收到回应"，看不到空中到底发生了什么。

3. 经典蓝牙 RSSI 只能在 连接后 获取

未连接时，经典蓝牙的 Inquiry 包里不自带 RSSI，所以你没法像 BLE 那样，远距离实时看信号强弱。

4. 看不到底层 RF 性能

比如：

• 从机发射功率真实多少
• 接收灵敏度
• 频偏
• 晶体精度这些 HCI 日志完全看不到。

5. 日志量大、容易淹没关键信息

不熟悉协议的人打开 Wireshark 会懵：几万条包，不知道看哪条。

---

二、除了 HCI 日志，还有哪些类似 / 更强的排查方式？

我按从简单 → 专业 → 顶级给你排好：

1）手机 / 电脑端工具（最常用）

• bluetoothctl / blueman看连接状态、RSSI、连接失败原因
• nRF Connect (BLE)
• Serial Bluetooth Terminal (经典蓝牙 SPP)
• 安卓开发者选项：蓝牙调试日志、蓝牙分析仪

用途：快速判断能不能扫到、能不能连、信号大概强不强。

---

2）空中抓包（Air Sniffing）------ 比 HCI 日志强一个等级

这是真正能看到空中无线信号的方法。

工具：

• nRF Sniffer
• Ellisys
• Frontline
• Cypress BLE Sniffer
• 部分国产蓝牙抓包器

能看到：

• 设备是否真的在广播
• 信号强度
• 空中丢包
• 干扰
• 手机发的查询包有没有发出来
• 从机有没有回应

这是定位 "距离远了搜不到" 的最佳手段。

---

3）从机端日志（MCU 日志 / 模块日志）

最直接、最真实。

比如：

• HC05 / HC06 串口日志
• 蓝牙模块 AT 指令 log
• 从机 MCU 打印的状态：广播状态、连接状态、RF 状态

能看到：

• 从机是否在正常广播
• 有没有收到手机的查询
• 是不是自身进入低功耗停发广播
• 是不是天线 / 硬件问题

HCI 日志 + 从机日志 = 问题 99% 能定位

---

4）RF 仪器测试（最硬核，工厂用）

• 频谱仪：看 2.4G 功率、干扰
• 蓝牙综测仪（如 Anritsu, R&S）：测灵敏度、发射功率、频偏、调制带宽

一般开发 / 硬件定位才用。

---

5）空口衰减模拟（专业测试距离）

加射频衰减器模拟远距离，看信号降到多少时手机搜不到 / 连不上。

---

三、最简单总结（你最需要记住）

HCI 日志的定位：

只能看手机侧发生了什么，看不到空中、看不到从机。

更强的组合排查法（工程标准流程）

1. HCI 日志 → 看手机侧行为
2. 空中抓包 → 看无线链路
3. 从机日志 → 看从机是否正常工作
4. RSSI 监测 → 看信号距离

三个一起用，蓝牙问题没有查不出来的。

小米14pro测试

有个参考：

https://blog.csdn.net/weixin_41477306/article/details/127042849

教程中都说要先打开开发者模式，但是我用小米14pro，没有打开开发者模式，直接拨号，也能捕获，不知道这里面有没有啥影响，暂时就先不打开开发者模式了。

按如下步骤操作：

1. 拨号*#*#5959#*#* 开始记录日志

2. 重启蓝牙，复现蓝牙的操作或者问题

3. 再次拨号*#*#5959#*#* 开始保存日志

注意：小米14pro算是不太老的手机了，新版本好像都有个"服务与反馈"的APP，这个HCI日志抓取后，也会触发这个反馈，但是别搞混了，这个和抓取HCI日志没有必然联系，只是将日志反馈给手机部门，后续方便他们修复bug。

在哪里保存？

我们进入内部存储目录，找到MIUI/debug_log/，注意，这里面存了bugreport_xxx.zip

这个就是服务与反馈的内容，包含了很多系统日志，内容很大，但这个不是我们想要的。

我们继续从这个目录进入到./common/com.android.bluetooth，在这里面可以找到一个btsnoop_hci_xxx.log文件

这个就是我们需要的HCI日志。

frontline安装与基本使用

其实用wireshark也能看这个HCI日志，但是不好用，需要手动筛选，使用起来很不方便。

我们使用frontline来分析蓝牙协议更加清晰明了。

下载frontline 分析手机的HCI log

1. fronline下载安装 (参考：https://blog.csdn.net/yyyang88/article/details/128883751)

2. 将btsnoop_hci.log重命名为btsnoop_hci.cfa就可以直接打开

Frontline 基本使用参考：https://www.jianshu.com/p/73f7366161d1

Frontline ComProbe Protocol Analysis System 是Frontline提供的一款蓝牙协议log分析工具，Frontine这家公司主要是做抓取蓝牙Air sniff log设备的，购买他们的抓包工具就会附带log分析工具，也可以在Frontine官网上下载，下载的时候需要填一些信息，觉得麻烦的同学可以去其他非官网途径进行下载。

安装完成后，在开始菜单中找到Frontline ComProbe Protocol Analysis System，使用Capture File Viewer可以打开HCI log

ComProbe Protocol Analysis System

Step 1 . 首先，选择要打开的HCI log ，并选择log类型为BtSnoop Files ，即以*.log结尾的文件。

还有一种方式是将btsnoop_hci.log的后缀修改为btsnoop_hci.cfa，就可以直接用Capture File Viewer打开。

Step 2 . 打开log文件后，选择Frame Display就可以看到我们抓取的HCI log了

Step 3 . Frame Display窗口中有很多Tab，将协议栈中各类协议分类显示，例如：HCI相关的log放在HCI的Tab中，Hands-Free（HFP） 属于应用层的Bluetooth Profile，和HFP相关操作的log都放在Hands-Free这个Tab中。

frontline帧界面介绍

看下这个界面

现在打开的是 Frontline 15 的 Frame Display（帧显示窗口） ，当前停在 HCI 标签页。

界面 3 大区域，一眼看懂分工

1. 左侧：Packet Tree（包详情树）

• 作用：展开当前选中包的完整协议细节
• 你当前选中第 1 个包：HCI_Reset（蓝牙复位指令）
  • HCI UART：底层传输层
  • HCI Command Packet：这是一个 HCI 指令包
  • Packet from Host：手机系统（Host）发给蓝牙芯片（Controller）
  • Opcode: 0x0c03：指令编码，对应「Reset（复位）」
  • Command: HCI_Reset：指令名称，就是让芯片重启蓝牙
• 用法：点任意一行包，这里会自动展开它的所有参数、含义，不用自己查协议手册
• 注意，每一个包对应的左侧，都是从上到下，从底层到上层来排列的

Frontline 视图的对应关系：

层级	名称	Frontline 位置	作用
最底层	物理传输层	HCI UART	这是 HCI 指令的运输通道（比如 USB/UART），只有物理传输意义，没有业务意义。
指令层	HCI	HCI 标签	手机 (Host) 与芯片 (Controller) 的指令对话 （复位、连接、断开）。这是控制中枢。
通道层	L2CAP	L2CAP 标签	外部蓝牙设备之间的逻辑数据通道 （音箱↔手机）。这是修路盖桥。
服务层	SDP	SDP 标签	服务发现（查询音箱支持什么功能）。这是问路牌。
音频信令层	AVDTP	AVDTP Signaling	音频流的配置、协商（比如告诉音箱用什么音质播放）。这是定播放规则。
实际数据流	AVDTP Data	AVDTP 标签	真正的音乐数据 （Media Packet）。这才是音箱发出的声音。
控制层	AVCTP / AVRCP	AVCTP / AVRCP	远程控制（暂停、上一曲、音量）。这是操作面板。

2. 中间：Packet List（包列表，核心！）

顶部有一排标签页，是蓝牙协议的分层结构，按顺序对应蓝牙通信的不同阶段：

• HCI：底层主机 - 控制器交互（你现在看的）
• L2CAP：逻辑链路控制（蓝牙连接的基础）
• SDP：服务发现（确认音箱支持 A2DP 音频）
• AVDTP Signaling：音频传输信令
• AVDTP/AVCTP/AVRCP：A2DP 音频数据、遥控器控制（音箱出声的核心）
• Data：原始业务数据

这些标签页是frontline给你做好的分类，不用再手动去筛选了，相比wireshark更方便。

这些标签页也是从左到右，从底层到上层排列的。

这是你最常用的区域，每一行 = 1 个蓝牙包，按时间顺序排列，列含义如下：

列名	含义	你要关注什么
Frame#	包序号	按时间顺序编号，方便回溯
Type	包类型	Command=HCI 指令（Host→芯片）；Event=HCI 事件（芯片→Host）
Opcode	指令编码	对应具体指令，比如0x0c03=Reset
Opcode Group	指令分组	Ctl/BB= 控制 / 基带（基础蓝牙功能）；Low Energy= 低功耗蓝牙
Opcode Command	指令名称	这个包在干嘛（比如Reset= 复位，Set_Event_Mask= 设置事件掩码）
Event	事件类型	Command Complete= 指令执行完成（芯片给 Host 的反馈）
Status	执行状态	Success= 执行成功；报错会显示具体原因码
Length	包长度	正常初始化包长度固定，异常包会有大小突变

注意：在不同的标签页中，可能有相同的frame号，表示的其实是同一个帧，只是从不同的视角来看而已。

3. 底部：Radix Pane（原始数据区）

• 作用：显示 16 进制原始字节，小白完全不用管，只有专业调试才用
• 你当前看到的01 03 0c 00，就是HCI_Reset指令的原始二进制数据

判断哪种包在哪个标签页

哪个包属于哪个标签页，完全看蓝牙的 "协议层级"。从下往上走，就不会找错。

下面我按你的界面，给你直接讲清楚👇

---

一、Frontline 标签页 = 蓝牙协议栈

你看到的那些标签：

• HCI
• L2CAP
• SDP
• AVDTP Signaling
• AVDTP
• AVCTP
• AVRCP
• Data

它们对应蓝牙的 从底层到上层 的一个完整协议栈。

你要判断 "哪个包在哪看"，就是看这个包属于哪层协议。

---

二、最核心的规则（99% 的包都能按这个判断）

下面这条规则，你照着记，Frontline 里再也不会迷路：

---

规则 1：所有芯片与手机的指令 → 都在 HCI 页

只要是 Host（手机系统）↔ Controller（蓝牙芯片） 的 HCI 指令 / 事件，全都在 HCI 标签。

例如：

• Reset
• Set Event Mask
• Read Local Version
• Create Connection
• Disconnect
• Write LE Host Support
• Number of Completed Packets

这些包都在 HCI 页显示。

你当前截图就是在 HCI 页，因为它们都是 HCI 指令 / 事件。

---

规则 2：真正 "外部设备之间" 的连接 → L2CAP 页

L2CAP 是蓝牙的 "传输层"，相当于外部设备之间的 "通信管道"。

所以只要是和外部蓝牙设备（音箱、耳机）的连接相关包，都在 L2CAP 页。

比如：

• L2CAP Connection Request
• L2CAP Connection Response
• L2CAP Configure Request
• L2CAP Disconnection Request

只要包名里有 "L2CAP" → 就去 L2CAP 页。

---

规则 3：服务发现（查音箱支持什么服务）→ SDP 页

SDP 是蓝牙的 "服务查询协议"，比如手机问音箱："你支持 A2DP 音频吗？""你支持 HFP 通话吗？"

这些包：

• Service Search Attribute Request
• Service Search Attribute Response

全部都在 SDP 页。

---

规则 4：音频播放（A2DP）→ AVDTP 页

蓝牙音箱播放音乐，靠的是 A2DP → 底层就是 AVDTP。

所以：

• Media Packet（音频数据）
• AVDTP Signaling（音频配置）

全部都在 AVDTP 或 AVDTP Signaling 页。

---

规则 5：音箱控制（暂停、切歌、音量）→ AVCTP / AVRCP 页

• 暂停 / 播放
• 上一曲 / 下一曲
• 音量增减

这些都属于 AVRCP → 并显示在 AVCTP / AVRCP 标签页。

---

规则 6：任意上层业务数据 → Data 页

比如某些非标准数据、厂商私有数据，会直接丢在 Data 页。

HCI日志的理解补充

HCI日志不应该只能看到HCI层的信息吗，为啥还有L2CAP SDP这些内容？

你这个问题问到点子上了，很多人都被 "HCI 日志" 这个名字误导了。我给你一次性讲透，为什么 HCI 日志里会有 L2CAP、SDP 这些上层协议内容👇

---

一、先纠正一个误区：HCI 日志≠只能看到 HCI 层

你理解的 "HCI 日志"，其实是蓝牙 HCI Snoop 日志，它记录的是「主机（Host）和控制器（Controller）之间的所有交互数据」，而不只是 HCI 指令本身。

在蓝牙协议栈里，上层的 L2CAP、SDP、AVDTP 等数据，都是封装在 HCI 的 ACL 数据包里传输的。

打个通俗的比方：

• HCI 就像一个 "快递员"
• L2CAP/SDP/AVDTP 就像 "包裹里的货物"
• HCI 日志记录的是「快递员运送的所有包裹」，所以你能看到快递单（HCI 指令），也能拆开看到里面的货物（上层协议数据）

---

二、蓝牙数据是怎么一层层封装的？

所有上层协议数据，都会按下面的顺序被层层打包，通过 HCI 发送给蓝牙芯片：

1. 应用层（A2DP/AVRCP）：生成音频数据、控制指令
2. AVDTP/SDP 层：给数据加上音频 / 服务发现的协议头
3. L2CAP 层：给数据加上逻辑通道的包头
4. HCI 层 ：把整个 L2CAP 数据包，封装成一个HCI ACL 数据包，发给蓝牙芯片
5. 控制器（芯片）：把 HCI 包转换成射频信号，发给外部蓝牙设备

反过来，外部设备发回的数据，也会被芯片封装成 HCI ACL 包，再交给主机逐层解析。

所以，HCI 日志里的 ACL 数据包，本质就是 "被 HCI 打包的上层协议数据"。

---

三、为什么 Frontline/Wireshark 能直接解析出 L2CAP/SDP？

专业蓝牙分析工具（Frontline、Wireshark）会自动做解封装：

1. 读取 HCI 日志里的 ACL 数据包
2. 把 HCI 包头剥掉，取出里面的 L2CAP 数据
3. 再把 L2CAP 包头剥掉，取出里面的 SDP/AVDTP 数据
4. 最后解析出完整的上层协议内容，分标签页展示给你

这就是为什么你在 HCI 日志里，能看到完整的 L2CAP、SDP、AVDTP 数据 ------不是日志里本身存了这些，而是工具帮你一层层拆开了。

---

四、举个你日志里的例子

你之前看到的Frame# 1361这个包：

• 它在 HCI 标签页里，是一个HCI ACL Data Packet
• 工具剥掉 HCI 包头后，发现里面是一个 L2CAP 数据包
• 再剥掉 L2CAP 包头，发现里面是一个 AVDTP 信令
• 所以在 L2CAP 和 AVDTP 标签页里，你也能看到它

它本质上是同一个 HCI 包，只是工具帮你拆到了不同的协议层级。

---

五、一句话总结

HCI 日志记录的是「主机和控制器之间的所有交互」，包括：

• 控制指令（HCI Command/Event）
• 封装了上层数据的 ACL 数据包

专业工具会自动把 ACL 包层层解封装，所以你能看到完整的 L2CAP、SDP、AVDTP 内容。

HCI_CMD 和 HCI_EVT

HCI（Host Controller Interface，主机 - 控制器接口）是蓝牙系统里手机系统（Host）和蓝牙芯片（Controller）之间的通信桥梁 ，HCI_CMD 和 HCI_EVT 就是这座桥上的两种核心「对话类型」，本质是指令 - 响应的关系。

---

核心定义与角色分工

先明确两个核心角色，所有交互都围绕它们展开：

• Host（主机）：就是你的小米 14 Pro 的安卓系统 / 蓝牙协议栈，负责上层逻辑（比如蓝牙设置、音乐播放、APP 交互）。
• Controller（控制器）：就是手机里的蓝牙硬件芯片，负责底层射频收发、蓝牙协议执行、和外部蓝牙设备（音箱 / 耳机）通信。

1. HCI Command（HCI_CMD，主机→控制器）

本质：Host 给 Controller 发的「指令 / 命令」

• 方向：单向，只能从 Host → Controller
• 作用：Host 指挥蓝牙芯片干活，比如「开机复位」「扫描设备」「发起连接」「配置参数」
• 类比：就像你给员工发任务：「去把 XX 设备连上」「把音频参数设成 XX」
• 你日志里的典型例子：
  • Sent Reset：Host 让芯片复位蓝牙
  • Sent Create Connection：Host 让芯片给蓝牙音箱发连接请求
  • Sent Write Extended Inquiry Response：Host 让芯片配置扫描广播信息

2. HCI Event（HCI_EVT，控制器→主机）

本质：Controller 给 Host 发的「事件 / 响应 / 通知」

• 方向：单向，只能从 Controller → Host
• 作用：芯片给系统反馈结果、上报状态、通知事件，比如「指令执行完成」「扫描到新设备」「连接成功 / 断开」
• 类比：员工给你汇报：「任务完成了」「我扫到一个新设备」「XX 设备连上了」「XX 设备断开了」
• 你日志里的典型例子：
  • Rcvd Command Complete (Reset)：芯片回复「复位完成」
  • Rcvd Connection Complete：芯片通知「和音箱连接成功」
  • Rcvd Number of Completed Packets：芯片定期上报「已发送完的数据包数量」

怎么看和音箱的连接过程

用frontline来看，看不大懂，然后我就又用wireshark来看了下。

其实可以结合两个工具去看，各有优势，互相补充！！！！！！

经典蓝牙连接到底是怎么样的过程

经典蓝牙（BR/EDR）的连接，本质上是 **"物理链路建立 + 安全认证 + 逻辑通道协商 + 服务发现"** 的分层过程，我按「标准理论流程」和「实际重连流程」两部分给你讲清楚，你就能明白为什么你的日志里看不到 Inquiry/Page 了。

---

一、课本里的「标准完整连接流程」（首次配对 / 陌生设备）

这是蓝牙规范定义的通用流程，也是你在理论中学到的版本，共分 5 个阶段：

阶段 1：设备发现（Inquiry）

1. 主机（手机）发送 HCI_Inquiry 命令，广播扫描周围的蓝牙设备。
2. 附近设备收到后，回应 Inquiry Result，把自己的 BD_ADDR（蓝牙地址）、时钟偏移等信息发回主机。
3. 主机收到所有设备的响应后，发送 HCI_Inquiry_Cancel 结束扫描。

对应你日志：已配对设备不会走这一步，因为地址已知，不需要扫描。

---

阶段 2：寻呼与物理链路建立（Page）

主机用扫描到的地址，呼叫目标设备，建立物理链路：

1. 主机发送 HCI_Create_Connection 命令，把目标设备地址传给蓝牙控制器。
2. 控制器在空口执行 Page 过程：
   • 发送 Page ID 包，目标设备回应 Page Response。
   • 交换 FHS（Frequency Hopping Synchronization）包，同步时钟和跳频序列。
3. 链路建立完成后，控制器向主机上报 HCI_Connection_Complete 事件。

对应你日志：HCI_Create_Connection 和 Connection Complete 是你能看到的，但中间的 Page 空口包，完全由控制器内部执行，不经过 HCI，所以日志里看不到。

---

阶段 3：安全认证（Authentication & Encryption）

物理链路建好后，双方验证身份、开启加密：

1. 主机发送 HCI_Link_Key_Request，目标设备回应链路密钥。
2. 完成 Authentication Request/Response 交互，验证密钥。
3. 主机发送 HCI_Set_Connection_Encryption 命令，开启链路加密。
4. 控制器上报 Encryption Change 事件，通知主机加密已生效。

对应你日志：你看到的 Set Connection Encryption 和 Encryption Change，就是这一步的结果。已配对设备会直接用已存的链路密钥，跳过重新认证的过程。

---

阶段 4：L2CAP 逻辑通道建立

物理加密链路建好后，建立上层服务的专用通道：

1. 主机发送 L2CAP_Connection_Request，申请建立 PSM=1 的 SDP 服务发现通道。
2. 目标设备回复 L2CAP_Connection_Response，通道建立成功。
3. 双方发送 L2CAP_Configure_Request/Response，协商 MTU、重传机制等参数。

对应你日志：你截图里的 L2CAP Connection Request/Response，就是这一步的 SDP 通道建立过程。

---

阶段 5：SDP 服务发现

主机通过 SDP 通道，查询目标设备支持的服务：

1. 主机发送 SDP_Service_Search_Attribute_Request，查询设备的服务列表。
2. 目标设备回复 SDP_Service_Search_Attribute_Response，包含支持的服务（如 A2DP、HFP、AVRCP）。
3. 查询完成后，临时 SDP 通道断开，为后续业务通道建立做准备。

对应你日志：你截图里的 SDP Service Search Attribute Request/Response，就是这一步的完整交互。

---

二、你日志里的「实际重连流程」（已配对设备）

已配对设备的连接，会跳过最耗时的 Inquiry 和完整认证，走快速重连路径，所以流程会 "短很多"：

理论流程	实际重连流程（你日志里的样子）	日志可见性
Inquiry（设备发现）	直接用已知地址，跳过扫描	❌ 日志无
Page（空口寻呼）	控制器内部自动执行	❌ 日志无
Connection Complete	控制器直接上报事件	✅ 日志可见
Authentication（认证）	用已存密钥，简化为加密开启	✅ 日志可见
L2CAP 通道建立	正常建立 SDP/A2DP 通道	✅ 日志可见
SDP 服务发现	正常查询服务	✅ 日志可见

---

三、为什么你的日志和理论对不上？

核心原因有 3 个：

1. 场景不同：理论是「首次配对 / 陌生设备」，你的日志是「已配对设备重连」，后者会跳过 Inquiry。
2. HCI 日志的边界限制：Page 过程属于控制器 / 基带层，不经过 HCI 主机接口，所以 HCI 日志里看不到。
3. 协议优化：蓝牙 2.1+ 引入了 Secure Simple Pairing（SSP）和快速重连，简化了认证流程，所以日志里看不到完整的 Authentication 交互。

---

四、完整连接的关键标志（你可以对照日志找）

一个正常的经典蓝牙连接，日志里必须出现这些关键事件：

1. HCI_Create_Connection（主机发起连接）
2. HCI_Connection_Complete（物理链路建立）
3. HCI_Set_Connection_Encryption / Encryption_Change（加密开启）
4. L2CAP_Connection_Request/Response（通道建立）
5. SDP_Service_Search_Attribute_Request/Response（服务发现）

更多技巧补充

1. 一键看「蓝牙连接时间线」

点击顶部 View → Timeline，生成可视化时间轴：

• 蓝色条：手机→音箱的包
• 绿色条：音箱→手机的包
• 红色标记：异常 / 断连事件
• 不用看包，一眼看清：什么时候连上、什么时候播音乐、什么时候断连

2. 用「Errors」标签，一键排查异常

点顶部 Errors 标签页，工具会自动汇总所有异常包：

• 比如连接失败、指令超时、丢包、断连
• 不用自己逐行找，直接看问题点

3. 用「Summary」筛选，快速定位

右上角 Summary 下拉框，当前是 HCI，可以切换：

• A2DP：只看音频包
• L2CAP：只看连接包
• SDP：只看服务发现包
• 一键过滤，不用手动输规则