Windows下蓝牙抓包实战：从HCI日志到BLE空中嗅探

搞嵌入式的兄弟，十有八九都遇到过这种场景：HC-05蓝牙模块配对正常，手机端也显示连接已建立，但串口助手收到的数据就是不对；或者做过蓝牙水控器、蓝牙测距这类项目，发现两台设备之间数据忽快忽慢，怎么调都说不清楚原因。这种时候，最有效的排错手段就是把蓝牙空中接口上的原始数据抓下来看一眼，问题往往一目了然。

Windows下的蓝牙抓包，看起来是个冷门需求，真正干过的人不多，网上资料也散。但这几年做物联网、智能硬件、蓝牙模组调试的人越来越多，抓蓝牙数据几乎成了嵌入式工程师的进阶技能。这篇文章我把自己在Windows上摸过的几条抓包路径完整捋一遍，从经典蓝牙到低功耗蓝牙，从本机HCI日志到空中嗅探器，方案、步骤、坑都会讲到。适合正在调蓝牙模块协议、做BLE应用开发、或者纯粹想搞懂蓝牙数据长什么样的朋友。

1. 抓包之前，先分清蓝牙的两条技术路线

很多人在Windows下抓不到包，不是因为工具不对，而是没搞明白自己要抓的是哪一种蓝牙。蓝牙这个称号底下，其实是两套完全不同的协议体系，抓包思路和工具链也完全不同。

1.1 经典蓝牙（BR/EDR）和低功耗蓝牙（BLE）的区别

经典蓝牙，也就是常说的蓝牙3.0、蓝牙4.0里向下兼容的那套BR/EDR协议，是蓝牙最早期的形态。它擅长连续、大速率的数据传输，典型应用就是蓝牙耳机听歌用的A2DP协议、蓝牙音箱、蓝牙串口透传模块（比如HC-05、JDY-31这类支持SPP协议的模块）、键盘鼠标等。经典蓝牙的逻辑链路种类多，有用于命令和控制的管理链路，也有专门传输音频的SCO链路，还有承载数据的ACL链路。想抓这类数据，核心是抓HCI（Host Controller Interface）层的日志，也就是蓝牙芯片和操作系统驱动之间的通信记录。

低功耗蓝牙则是另一套体系，从蓝牙4.0开始引入，协议的关注点完全不在连续传输，而是“省电、小数据量、低频次”。BLE的核心模型是GATT（通用属性协议），所有数据都组织成服务和特征值的形式。手机APP读取一个温度传感器的数据，本质就是读写某个GATT特征的属性值。BLE物理层只用了40个信道，其中3个广播信道、37个数据信道，而且采用跳频机制，这意味着抓BLE的空中数据比抓经典蓝牙要麻烦得多。

这两种蓝牙在Windows下的抓包难度差距极大。经典蓝牙因为HCI接口是公开的，微软的协议栈也允许外部工具去读，所以抓包相对容易。BLE则复杂得多，一方面Windows对BLE的HCI日志封装得很深，另一方面BLE物理层的跳频机制决定了普通工具很难直接监听数据信道。

1.2 Windows下抓蓝牙数据为什么这么麻烦

Windows不像Linux，Linux底下有现成的bluez协议栈，配合hcidump或者btmon命令就能直接导出发送蓝牙控制器的所有HCI数据。Windows的蓝牙是微软自己维护的协议栈，默认不开放任何抓包接口，普通用户连蓝牙芯片和系统之间交换了什么数据都看不到。

再一个痛点在于，Windows蓝牙底层同时承载了经典蓝牙和BLE两套核心，很多时候两条链路是复用同一个物理天线的。如果你只是想抓某一个应用的数据，但系统后台可能还有其他蓝牙设备在跑，抓出来的整个包就会很杂，过滤起来费劲。

Tool选型也会被操作系统版本限制。老一点的方法比如微软Network Monitor 3.4里带的蓝牙分析器，在新系统上经常无法正常工作；新一点的工具又只支持某些特定型号的蓝牙适配器。所以你必须根据自己手上现有的设备和操作系统版本，选择一个能跑通的方案，而不是一味追求高级工具。

2. 主流抓包方案选型

我试过几条路，从简单到复杂都有。这里先把方案的整体框架拉出来，方便你根据自己的需求判断该走哪条路。

2.1 微软自带工具路线：抓本机HCI日志

这是Windows下抓经典蓝牙的原生方案，本质上是让蓝牙协议栈把每次与蓝牙芯片交互的HCI数据记录成文件，再导入Wireshark分析。这个方案不需要额外硬件，只要有蓝牙适配器就能用。

具体实现有几种变体：比较老但可靠的是微软Network Monitor工具，它自带了Bluetooth解析器，能识别HCI层、L2CAP层、RFCOMM层的数据。还有一个命令行工具btprobe，专门用来采集蓝牙HCI数据流，生成的文件可以用Wireshark打开。这个方案适合调试SPP串口模块、蓝牙耳机协议、或者分析Win下某个蓝牙应用的收发逻辑。

2.2 外部嗅探硬件路线：抓空中射频数据

如果你要抓的是BLE的数据包，或者目标是分析两台设备之间在物理信道上传了什么，那就必须上外部嗅探器。

推荐两个方向：一个是Nordic官方出的nRF Sniffer，配合nRF52840 USB Dongle这类硬件，把固件刷进去之后，Wireshark会多出一个抓包接口，可以直接捕获BLE的广播包和连接数据包。另一个是开源硬件Ubertooth One，它最大的优势是能扫2.4GHz全频段，但抓BLE时对加密数据无能为力。

外部嗅探器最大的好处是“旁观者视角”。它完全不参与通信，就是潜伏在旁边把空中的数据全部收下来，因此能看到连接参数更新、信道跳频规律、RSSI、CRC错误重传这些只能在空中数据里看到的信息。缺点是要额外花钱买硬件，而且很多嗅探工具对加密连接没法解密，只能看到密文。

2.3 通过系统日志捞btsnoop文件

Windows 10和Windows 11其实有一个隐藏能力，就是生成蓝牙的btsnoop日志。这个日志文件记录了蓝牙协议栈内部的大量细节，包括HCI数据帧和事件。问题在于它不是开箱即用的，你需要先在系统设置里打开“可选诊断数据”开关，等到问题复现后，去系统日志目录里捞文件，再想办法转换成Wireshark能读的格式。

这条路对普通项目调试来说偏绕，我一般只在排查系统级蓝牙驱动问题时才用。好处是不装任何额外工具，坏处是实时性差、日志生成滞后，而且默认的ETL格式需要好几步转换，新手很容易卡住。

2.4 方案对比一览

3. 实操：用btprobe + Wireshark抓经典蓝牙数据

如果你手头正好在调SPP蓝牙串口模块，或者蓝牙音箱总有断流问题，想确认A2DP数据到底有没有发出来，这条路最直接。下面是我验证过的一套流程。

3.1 环境准备

系统层面，Windows 10或Windows 11都能跑，但务必先把蓝牙适配器驱动装好。如果你用的是笔记本电脑自带蓝牙，一般没问题；如果是USB蓝牙适配器，最好确认设备管理器的蓝牙图标是正常的，没有黄色感叹号。

软件方面要装两样：Wireshark和微软的抓包工具。

Wireshark版本建议选3.6以上的稳定版，直接到官网下，一路下一步即可。微软的工具方面，优先尝试btprobe。这是一个很老的小工具，网上能搜到绿色版，也可以从Windows Driver Kit（WDK）的历史版本里找到。如果btprobe在你机器上跑不起来，退而求其次装Microsoft Network Monitor 3.4，它自带的蓝牙分析器同样可以把蓝牙数据帧解出来。

注意：这两个工具其实是同一个技术源头，核心都是调用微软蓝牙栈的HCI接口。如果设备管理器里蓝牙驱动是第三方的（比如某些USB蓝牙芯片自带的驱动），工具就可能读不到HCI数据。碰到这种情况，先换成Windows默认的微软蓝牙驱动。

3.2 启动btprobe和Wireshark协同抓包

btprobe是个命令行工具，需要以管理员身份运行。我常用的操作是：

# 进入btprobe所在目录 cd D:\tools\btprobe # 查看工具帮助，确认支持的参数 btprobe -?

实际抓包时，btprobe会把HCI数据流输出成一个文件。不同版本的参数名称略有差异，常见的是指定输出文件名和抓包时长。比如下面这种：

btprobe -f bt_capture.cap

运行之后，工具进入监听状态，不会自动结束。这个时候你去执行蓝牙设备的配对、连接、收发数据等操作。等你觉得抓得差不多了，回到命令行按Ctrl+C停止，btprobe就会把这段时间内发生的所有HCI数据写进指定文件。

这里有一个关键细节，我踩过坑：必须先启动btprobe，再开始设备通信。如果你先把HC-05和手机连上，然后再打开btprobe，那么能抓到的就只有连接建立之后的数据，而连接参数的协商、配对过程中的密钥交换这些关键信息就全漏掉了。调试协议问题时，尤其是初始握手的阶段，这些信息恰恰最重要。

停止抓包后，用Wireshark打开生成的cap文件。Wireshark对btprobe生成的原始格式识别不是100%可靠，如果识别出来的全是乱码或者无法解析的帧，可以在打开文件时手动指定封装类型为“Bluetooth HCI H4”。这个入口在Wireshark的“打开文件”对话框左下角，选“蓝牙HCI H4”选项再打开。

3.3 Wireshark里怎么看蓝牙协议

打开之后，你会看到密密麻麻的帧。Windows下的蓝牙HCI日志内容很丰富，但你不要怕，用Wireshark的过滤表达式就能把感兴趣的内容挑出来。

# 只看HCI命令 bthci_cmd # 只看HCI事件 bthci_evt # 只查看ACL数据，也就是实际要传的数据 bthci_acl # 看L2CAP层，主要看通道建立过程 btl2cap # 看RFCOMM（串口透传的数据在这层） btrfcomm # 看A2DP音频流 btavdtp # 看SDP服务发现 btsdp

我调试SPP模块时最常用的是btrfcomm过滤。RFCOMM是经典蓝牙串口通信的承载协议，HC-05这类模块透传的用户数据，最终就挂在RFCOMM帧的payload里。选中一个RFCOMM帧，展开协议树，找到Data字段，里面就是收发双方真正交换的数据字节。

如果是调试蓝牙耳机或音箱，重点看btavdtp和btavrcp。AVDTP负责音频流的传输控制，AVRCP负责播放暂停等遥控指令。A2DP播放卡顿的问题，往往能从AVDTP的时钟戳和包序号里找到线索。现在很多设备还涉及A2DP到SCO模式的切换，比如TWS耳机在听歌时来电话，协议栈要从A2DP切到HFP的SCO链路，这个切换过程在HCI事件和ACL数据里都留了痕迹，翻一翻就能定位是哪里卡住。

3.4 实测案例：分析HC-05蓝牙模块收发的数据

我用一个实际例子演示思路。假设你有个HC-05模块，电脑端通过USB蓝牙连接它，然后用串口助手周期性发一串0x01 0x02 0x03 0x04。

抓包结束后，在Wireshark里输入btrfcomm，会看到电脑和模块之间建立了一个RFCOMM会话。随便点开一个方向为“发送”的数据帧，协议树里大概是这么展开的：

• Bluetooth HCI H4
• HCI ACL
• L2CAP
• RFCOMM
  • Frame: Unnumbered Info with credits
  • Payload: 01 02 03 04

看见Payload里的01 02 03 04，就说明电脑确实把数据交给了蓝牙控制器并且已经发送出去。如果对方没收到，那问题就不在电脑端，而在模块那头或者线路连接。反过来，如果这一层数据本身就是乱的，那优先检查上位机串口配置，看波特率、数据位对不对。这个判断逻辑在物联网项目排障时特别受用。

4. 实操：用nRF Sniffer抓BLE空中数据

BLE项目的调试思路跟经典蓝牙完全不同。很多开发者习惯在手机APP端看GATT服务和特征值，但有时候APP显示的数据正常，实际射频链路却不对。想真正弄清问题，抓空中数据是绕不开的。

4.1 硬件准备与固件烧写

nRF Sniffer需要的硬件其实不贵，我用的是nRF52840 Dongle，一块小板子，通过USB口插电脑。Nordic官方的方案是给这个板子刷一个专用的Sniffer固件，固件刷完之后，板子就变成一个专门的BLE数据包嗅探器。

固件烧写非常简单：先去Nordic官网下载nRF Sniffer for Bluetooth LE安装包，里面包括一个hex格式的固件文件、Wireshark扩展插件和使用说明。把Dongle插电脑上，确认系统能识别出nRF52840 USB设备，然后用nRF Connect for Desktop工具里的Programmer功能，把hex固件烧进去。

注意：nRF52840 Dongle的默认固件和Sniffer固件不冲突，你可以随时烧回去，不会把硬件刷坏。推荐多买一块板子专门做抓包用，比反复烧写省心太多。

4.2 在Wireshark里启用nRF Sniffer接口

固件烧好之后，把Wireshark安装包里的nRF Sniffer插件复制到Wireshark的extcap目录。不同Wireshark版本目录位置不同，通常是在C:\Program Files\Wireshark\extcap。插件放好后，重启Wireshark，主界面的“捕获接口”列表里就会多出一个接口，名字大概是“nRF Sniffer for Bluetooth LE”。

选择这个接口，点开始捕获，会自动弹出一个专门针对BLE的抓包窗口。这个窗口顶部有一个目标设备选择框，可以输入你想跟踪的BLE设备的MAC地址。它能自动跟随目标设备的跳频序列，相当于在整个连接过程中一直贴着你关注的那台设备监听。

这个功能比Ubertooth One那种全频段盲扫要友好得多。全频段盲扫会同时看到周围所有BLE设备在广播信道上发的包，但一旦进入连接状态，数据信道变得随机跳频，盲扫基本就跟丢了。nRF Sniffer通过目标MAC地址锁定设备，能一直跟着跳频，所以连接期间的数据包也全都能拿到。

4.3 怎么分析BLE的连接和GATT数据

抓包开始后，最直观的是能看见广播包。这些包里包含了设备的名称、广播的UUID、厂商自定义数据、还有RSSI信号强度。蓝牙测距类的项目，RSSI就是在这里获取的。你可以同时持有多个BLE Beacon，抓包看它们的广播间隔、发射功率和RSSI波动，就能理解为什么测距结果会忽远忽近。

设备进入连接状态后，抓到的包会分成两种：一种是链路层LL包，包含连接参数更新、空包、延长广播这些控制信息；另一种是L2CAP层的真正的数据包。对于一个标准的GATT读取操作，你可以看到完整的过程：

1. 客户端发送一个属性读取请求（Read Request）
2. 服务端返回属性读取响应（Read Response）

Wireshark会自动把GATT层的操作码解析成Read Request、Write Request、Notification等可读文本，你不需要去查蓝牙规范里每个操作码的含义。

我调试一个透传蓝牙模块时，遇到APP能连上、但收不到设备数据的问题。抓包后发现设备端其实一直在发Notification，而且数据内容是对的，只是APP没有订阅这个特征的CCCD。那个Notification请求就是在连接建立后，由设备主动发起的，Wireshark帧列表里一眼就能看出特征句柄和值。后来在APP端加上订阅逻辑，问题立刻解决。这种问题用传统串口观察法是很难定位的。

4.4 抓加密连接时的限制

需要提醒的是，BLE的链路层加密是针对空口数据的，数据被加密后，除非你知道链路密钥（LTK），否则Sniffer抓到只能是密文。nRF Sniffer对加密连接的支持有限，适合分析非加密、或者明文裸传的调试型设备。

如果要抓加密设备的数据，前面提到用Nordic方案加一个配套功能，可以导入配对时的密钥。但这个功能依赖具体的配对过程，操作很繁琐。通常我的建议是：研发阶段让设备固件先关掉加密，把协议调通之后再考虑加密。

5. 补充方案：从Windows系统日志里捞蓝牙btsnoop文件

除了主动抓包，Windows本身也会在后台记录蓝牙协议栈的运行日志，只是默认不给普通用户暴露。在某种场景下，这个被动日志反而能派上大用场，尤其是驱动故障排查或者无法复现的偶发问题。

5.1 打开系统诊断数据开关

要让Windows记录蓝牙日志，需要先进入“设置 -> 隐私和安全性 -> 诊断和反馈”，打开“发送可选诊断数据”选项。这个开关在Windows 10和Windows 11上都能找到，打开之后系统会开始收集蓝牙等设备的诊断信息。

注意：这个开关不是即时生效的，打开后需要重新启动一次蓝牙适配器，或者重启一次电脑，确保蓝牙的ETW会话已经创建。

5.2 复现问题并导出日志

开关打开后，就正常去复现你遇到的问题。比如蓝牙耳机总是断连，就连续播放几首歌，等着它断。问题出现后，在Win+R里输入%SystemRoot%\Logs\Bluetooth，回车进入蓝牙日志目录。

这个目录通常存在名为BlueLog.etl之类的ETL文件。直接用Wireshark打不开ETL文件，所以需要转换。最简单的办法是把ETL转成Wireshark能读的btsnoop格式，我常用的步骤是：

1. 用Windows自带的tracerpt命令先把ETL转换成XML或CSV，再用脚本解析出蓝牙相关的部分。
2. 我实际用过一次，格式非常乱，解析成本很高。所以一般情况我不会折腾这条路，除非系统日志里能看到明确的HCI错误码。

说句实话，这个被动方案对普通开发者来说性价比不高。我在只有系统日志但没有抓包工具的环境下救过一次急，之后还是老老实实把btprobe和nRF Sniffer的U盘带在身边。

5.3 什么时候值得用这条路径

系统日志方案最主要的价值是系统级问题的回溯。如果问题是偶发的、事件比较分散，你不可能一直开着btprobe去守着，但Windows的诊断日志是后台一直在记录的，出问题后再去翻日志，能看到问题发生前后的协议活动。它更适合故障发生后的事后分析，而不是项目调试期的实时观察。

如果你问我的选择偏好，我会说：能主动抓包就主动抓包，实在够不着才用被动日志。

6. 常见问题与排查技巧实录

这部分是我在Windows上折腾蓝牙抓包时踩过的一些坑，很多问题在官方文档里根本不会提。我整理成几个典型场景。

6.1 btprobe和Network Monitor抓不到任何数据

最常见的现象是工具启动正常，但抓包没有任何输出。多半原因是蓝牙适配器的驱动不是微软默认驱动，而是厂商的定制驱动。btprobe走的是微软蓝牙栈的HCI接口，第三方驱动往往绕过这部分，导致工具无法连接到控制器。

解决办法是先到设备管理器，找到蓝牙设备，右键更新驱动，选择“浏览我的电脑以查找驱动程序”，再选“让我从计算机上的可用驱动程序列表中选取”，切换成“Microsoft 蓝牙适配器”或类似名称的微软通用驱动。切换后重新插拔一次蓝牙设备，再跑btprobe试试。不过要注意，切换驱动之后，部分厂商专属功能（比如某些网卡带的蓝牙增强功能）可能会失效，抓完包记得换回来。

6.2 用Wireshark打开捕获文件，显示的全是未知帧

一般发生在btprobe生成的原始文件格式和Wireshark识别格式不一致的时候。打开文件时手动指定封装类型为“Bluetooth HCI H4”或者“Bluetooth HCI with headers”，多半就能解出来。如果还不行，尝试用Wireshark自带的“Tools -> Bluetooth -> HCI data import”功能导入，它会把原始字节按HCI帧结构重新切分。

6.3 蓝牙设备连着电脑，但nRF Sniffer找不到目标设备

这种情况通常不是Sniffer的问题，而是目标设备的广播周期太长了。很多省电设备把广播间隔设置为1秒甚至更长，Sniffer一打开就盯着当前信道看，可能会错过设备的广播包。

解决方法是先让Sniffer跑一小会，确认屏幕上能看到其他设备的广播，再在目标设备列表里搜索。如果直接搜不到，可以先在PC端关掉目标设备，再重新上电，让它在Sniffer处于监听状态时发出广播，这样捕捉率会高很多。

6.4 电脑自带蓝牙和外置嗅探器互相干扰

如果你同时开着电脑的蓝牙和nRF Sniffer抓包，外置嗅探器偶尔会收到电脑自己发出的包。这不算Bug，真正的干扰在于电脑蓝牙可能会占用某些信道，造成抓包时偶发丢包。我的习惯是抓空口数据时，把电脑自带蓝牙关掉，让嗅探器独自监听，数据更干净。

6.5 蓝牙驱动方面的问题

抓包过程中还有一个容易被忽视的环节，就是适配器在Windows下被识别成了“Microsoft 蓝牙枚举器”而不是“蓝牙无线电”，这种情况会导致Wireshark或btprobe拿不到HCI接口。排查方法是在设备管理器里看蓝牙节点的层级：正常的蓝牙适配器应该出现在“蓝牙”分类下，带有具体型号名称。如果变成“未知USB设备”，那就是驱动或者USB口供电问题，跟抓包工具没关系，先换一个USB口，再重装驱动。

7. 抓包之后，怎么用数据反推问题

工具链跑通之后，真正的技术含量在于怎么解读那堆十几万帧的数据包。说白了，抓包不是目的，把问题定位出来才是。

7.1 先看概况，再用会话过滤

拿到一个完整的抓包文件，我第一件事不是逐帧翻，而是先看Wireshark的“统计 -> 协议分级”。它会按协议比例列出HCI、ACL、L2CAP、RFCOMM等各层的数据量。如果某个层的包占比异常，或者压根没出现，说明问题就出在那一段。这个习惯能快速缩小范围。

比如抓蓝牙音频流，协议分级里应该有大量的AVDTP媒体包。如果看到AVDTP包极少，但HCI命令包很多，那问题多半在连接建立阶段，音频流压根没起来。顺着这个方向再过滤btavdtp，观看连接过程，基本就能推断出是SDP服务发现失败，还是AVDTP能力协商失败。

7.2 利用时间戳和IO图表看异常波动

蓝牙问题经常是间歇性的。Wireshark底部的“IO图表”功能可以按时间维度统计包的数量和字节数。我调一个蓝牙测距项目时，用IO图表看到RSSI在某个时间段内跳变特别剧烈，峰值和谷值相差超过10dBm，而其他时间段稳定。这种异常波动直接指向环境干扰或设备天线问题，根本不用管协议层内容。

7.3 结合应用层场景做交叉验证

抓包数据终究是协议层的表现，最终的判断还得结合应用场景。蓝牙水控器这类透传设备，数据量小、格式固定，抓包时重点看RFCOMM层或ATT层的data字段与设备固件文档里的协议帧格式是否一致。如果抓包显示的数据跟预期一致，那问题直接转移到设备端，别在电脑端瞎耗时间。

A2DP切SCO这种场景，不仅看AVDTP和HFP的HCI事件，还要对照时间戳计算切换耗时。切换过程中如果出现超过几百毫秒的空白期，那用户体验上一定有明显中断，这个差异就是优化方向的证据。

7.4 把抓包沉淀成团队排查工具

抓包这件事单打独斗价值有限，真正有用的是把它变成团队里的标准排查手段。我现在会把几种典型问题的抓包配置存成Wireshark的配置文件，新来的同事遇到蓝牙问题时，直接用配置文件打开抓包结果，过滤器和着色规则都已经预设好。省去了每次手动输入过滤表达式的麻烦，排查效率提升得非常明显。

结尾的一些心得体会

我在Windows下折腾蓝牙抓包也走过不少弯路，最大的感受是：不要指望一个方案通吃所有场景。经典蓝牙的HCI日志适合看协议栈内部状态，BLE空中嗅探适合看射频链路真实情况，系统日志则留给突发问题的事后复盘。三个工具各管一块，组合起来才能真正覆盖Windows蓝牙开发的日常需求。

最后再分享一个小技巧：无论用哪条抓包路径，抓包前一定要先在笔记本上记下目标设备的MAC地址、广播名、连接方式这些基本参数，同时记录抓包过程中的操作时间线。没有时间线，抓下来的数据就是一坨没有锚点的乱码，回去复盘时会非常痛苦。我见过太多人抓了包却因为不知道哪一段对应哪个操作，最后只能重抓。这个习惯，比任何高级技能都实用。