在嵌入式开发和无线调试圈子里蓝牙相关的问题永远是最折磨人的耳机偶尔断流、自己写的App收不到设备数据、HC05模块明明指示灯正常但就是配对不上。这些问题到了应用层往往看不出任何端倪最后的真相都藏在协议栈下面。想看到协议栈里的东西就得抓蓝牙数据。这篇文章要聊的就是Windows系统下做蓝牙抓包的几条实测可用的路线以及我在实际调试中踩过的坑和总结出的经验。先说清楚适合谁看。如果你在搞ESP32、HC05、JDY-31这类蓝牙模块的开发或者你在调试蓝牙耳机、手柄、键盘这类外设的连接问题再或者你在做Android/iOS与外设的通信联调这篇文章应该能帮你少走不少弯路。文章里既有纯软件的方案也有需要几十块钱硬件的方案丰俭由人。1. 抓包前先搞懂你到底要抓哪一层很多人在蓝牙抓包这件事上卡住根本原因不是工具不会用而是没想清楚自己要抓什么。蓝牙协议栈是分层的不同层的调试手段完全不一样你先得知道自己面对的问题在哪个层。1.1 蓝牙协议栈的四层结构拿日常最常用的蓝牙场景来说从下往上大致分四层控制器Controller、主机Host、应用层协议Profile、应用程序。控制器就是蓝牙芯片里的射频部分负责收发电波主机是协议栈的核心逻辑负责连接管理和数据分发应用层协议就是我们常说的SPP、A2DP、HID、GATT应用程序就是手机上那个App或者电脑里的驱动软件。如果你要查“为什么连不上”“为什么连接老断开”这类连接层的问题要看的是HCIHost Controller Interface层的数据。如果你要查“为什么收不到传感器数据”“为什么收到的是乱码”那要看L2CAP层以及更上层的ATT/GATT或者RFCOMM。如果你要查“蓝牙耳机音质为什么这么差”那还得看A2DP协议里的媒体帧。搞清楚自己在哪一层直接决定了你用哪种抓包方式。这一点至关重要否则你辛辛苦苦抓了一堆数据结果发现层次对不上纯属浪费时间。1.2 两个核心概念本机通信日志和空中无线包Windows下抓蓝牙数据要区分两个场景。第一个场景是抓自己电脑和某个设备之间的通信数据。这种数据在自己的蓝牙适配器里就有不需要额外硬件Windows系统自己就能记录关键在于怎么把日志导出成可读的格式。第二个场景是抓两个设备之间的空中通信数据比如手机和ESP32之间的通信你的电脑完全没参与。这种场景只能靠带监听模式的硬件嗅探器来解决任何纯软件方案都搞不定因为你的电脑蓝牙适配器压根收不到和自己无关的数据包。这条分界线决定了你的工具选型。我见过不少新手拿Wireshark折腾半天想抓手机和耳机之间的空包结果什么都抓不到就是没搞清楚这个区别。1.3 Windows下抓蓝牙的三条路线纯软件路线A开启Windows自带的蓝牙HCI日志再把日志导入Wireshark解析。成本为零适合抓自己电脑参与通信的蓝牙数据这是本文的重点。纯软件路线BWireshark配合系统接口实现实时捕获同样是抓本机参与通信的数据但稳定性受蓝牙适配器驱动的影响比较大。硬件路线C使用蓝牙嗅探器BLE Sniffer被动监听空中的数据包可以抓任意两个设备之间的通信但需要额外硬件成本从几十到上万不等。三条路线各有利弊我后面会分别展开讲实操细节。2. 路线A开启Windows内置HCI日志并导入Wireshark这一节是大家问得最多的也是Windows下抓蓝牙数据最朴素的方案不花一分钱把系统里的蓝牙协议日志导出然后用Wireshark打开分析。2.1 HCI日志到底是什么HCI是主机和控制器之间的接口你可以把它理解为蓝牙芯片和电脑操作系统之间的“对话记录”。Windows在系统层面有一个蓝牙日志模块它可以把HCI层的数据包记录下来。数据包里至少有连接事件、扫描结果、配对过程、ACL数据帧等关键信息足够覆盖大部分连接问题的调试场景。我特别想强调一点HCI日志记录的是主机和控制器之间的数据交换而不是空中传播的原始射频信号。它不包含物理层的跳频、调制解调信息但对于“两个设备之间发了什么数据”这个问题HCI日志已经能回答绝大多数疑问了。2.2 开启日志的具体操作开启HCI日志的方法是通过修改注册表按下WinR组合键输入regedit回车打开注册表编辑器。定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters。在右侧空白处右键新建一个DWORD32位值命名为EnableKHALLogging。双击这个值把数值数据改为1。关闭注册表重启蓝牙适配器或重启电脑。重启蓝牙适配器的方法是在“设备管理器”里找到蓝牙设备右键选择“禁用设备”再右键选择“启用设备”。如果你在设备管理器里把它禁用后整个蓝牙图标消失直接重启电脑更省事。2.3 日志生成后怎么处理完成上面操作后正常使用你的蓝牙设备让它出现一次连接、断开、数据传输等操作然后打开目录C:\Windows\System32\LogFiles\BTH\。你会看到类似bt-...cetlog或bth...khlog之类的文件这些就是日志文件。注意要是这个目录里空空的多半是蓝牙适配器的驱动不是微软通用驱动。如果你装了某个品牌定制的驱动比如笔记本厂商自带的蓝牙驱动或者博通、英特尔的部分老驱动HCI日志可能压根不生成。这种情况我建议先卸载第三方驱动让Windows安装微软通用蓝牙驱动再试一次。日志文件本身Wireshark不一定能直接识别不同Windows版本下格式有差异。我实测过的做法是先看看Wireshark能不能直接打开。Wireshark 3.6以上版本对部分cetlog文件已经能自动识别。如果打开乱码或提示格式不支持可以试试把文件扩展名改成.pcapng再拖进去或者借助微软官方的bthlog工具做一次格式转换。这一步因系统版本不同差异很大不用钻牛角尖多试几种方式就行。2.4 实操心得日志应该在什么时候看有不少人和我说“我开了日志但抓到的包好少都是莫名其妙的HCI事件看不懂”。这很正常。HCI日志里大量的是HCI Event和HCI Command它们是控制面的内容能看到扫描、配对、连接参数协商的过程但看不到真正的用户数据载荷。如果你要分析的是数据内容光看HCI日志还不够需要配合抓到的ACL数据包做深度解析。我的实操经验是当你遇到连接建立不了、连接反复断、配对失败这些问题时HCI日志是最快定位的。比如两个设备半天连不上日志里如果出现频繁的Connection Timeout或者PIN or Key Missing问题方向基本就锁定了。但要分析数据载荷本身建议直接上Wireshark的实时接口或硬件嗅探器。3. 路线BWireshark直接抓取本机蓝牙接口数据相比导日志文件直接用Wireshark抓蓝牙接口的数据显然爽得多因为它能实时看到数据包并且直接解析好协议层。这一节说说我能跑通的做法和需要注意的地方。3.1 准备工作与接口识别先确保你的蓝牙适配器已经启用HCI日志也就是上一节注册表里的EnableKHALLogging还等于1。然后打开Wireshark在捕获接口列表里找正常会看到一个名字带蓝牙或Bluetooth的接口。如果看不到多半是接口没有被系统识别为可捕获状态或者Wireshark版本太老。我用Wireshark 4.x版本实测当前Windows版本Windows 10 22H2和Windows 11 23H2下蓝牙接口是可以直接选择的。选中后点击开始捕获然后去连接你的蓝牙设备或者让设备主动连接电脑Wireshark里就会开始刷新数据包。3.2 抓包演示连一次蓝牙耳机或者ESP32这里用一个简单场景演示让手机通过蓝牙向Windows电脑传一个文件或连接一个BLE外设。操作步骤如下Wireshark选好蓝牙接口点击开始捕获。在Windows设置里打开蓝牙搜索设备并配对连接。连接成功后传输一些数据比如发一个文本文件过去。停止Wireshark捕获。抓到的包会按照协议层次自动解析你会在报文列表里看到类似Bluetooth HCI、L2CAP、RFCOMM、ATT、GATT这些协议标识。双击任意一个包下方会展开协议树从HCI层到L2CAP层到上层Payload每一层都能看到。3.3 常用过滤器过滤器的使用是效率的关键不然上百个包根本看不过来。我最常用的几个btl2cap只看L2CAP层的数据适合分析逻辑通道和分段重组的问题。btrfcomm只看串口协议数据调试HC05这类SPP蓝牙模块时必备。btatt只看BLE的属性协议调试ESP32这类BLE设备时最常用。btgap只看广播和扫描数据用来分析设备广播内容。bthci_acl只看ACL数据包定位数据帧异常时用。举个例子。你用一个App连接ESP32ESP32每秒回传一组传感器数据但App里偶尔会漏包。用Wireshark抓包后输入btatt过滤直接拉到ATT层的数据看有没有出现重传或长度异常的包。如果看到很多Prepare Write Request和Execute Write Request说明MTU协商值太小数据被拆成很多片段传输这就是丢包的根源之一。3.4 实时接口抓包的坑实时接口抓包整体可用但实测有几个需要注意的坑。第一不是所有蓝牙适配器都支持实时抓包。很多廉价的USB蓝牙适配器在Windows下只暴露HCI接口没有做数据捕获接口导致Wireshark根本识别不出蓝牙接口。遇到这种情况不要死磕老实走路线A导日志或者直接上硬件嗅探器。第二数据包里有些帧是乱序的。原因是蓝牙链路本身有重传机制以及HCI传输存在队列延迟Wireshark解析时有时会提示TCP out-of-order类似的警告在蓝牙里是L2CAP segment reassembly相关警告这多是被重传机制影响的不必紧张。第三抓包会影响数据传输的时序。这是软件抓包的天然副作用因为捕获过程要消耗一定的系统资源。你要是做高精度蓝牙测距或时间敏感的场景普通抓包工具本身就成了干扰源这时候硬件嗅探器的优势就体现出来了。4. 路线C硬件嗅探器被动监听空中数据包前面两条路都只能抓“自己电脑参与的通信”但实际工作中更常见的问题是手机和ESP32之间的通信出了问题电脑全程没参与。这种场景就需要硬件嗅探器做被动监听了业内一般叫Sniffer。4.1 为什么非得上硬件蓝牙的空中数据包默认是加密的只有参与配对的设备才能解密数据。如果电脑不在这个连接里纯软件的方式根本收不到数据。硬件嗅探器的思路是额外用一个带监听功能的蓝牙芯片让它混杂在空气中监听信道捕获所有经过的数据包。如果你已经掌握了链路密钥还能在Wireshark里手动填入密钥解密出Payload内容。我一向认为做蓝牙开发的人迟早要有至少一个嗅探器。它就像网络工程师的抓包工具一样平时吃灰关键时刻能救命。4.2 常用设备选型设备抓包范围价格区间上手难度推荐场景nRF52840 DongleBLE 4.0/5.x100-200元低开发nRF系列或BLE外设CC2540 USB DongleBLE 4.030-80元仿低学习用老的教程最多Ubertooth OneBLE 经典蓝牙基础速率1000元左右中想兼顾经典蓝牙和BLE的开发者Ellisys/Frontline分析仪全协议覆盖数万到数十万高专业认证实验室或大厂如果你只是需要调试ESP32或HC05这类常见模块一块带nRF Sniffer固件的nRF52840 Dongle就够用了性价比很高。Ubertooth One能抓经典蓝牙的Basic Rate数据这是nRF52840做不到的地方但Ubertooth的操作门槛更高驱动和固件都要自己折腾。4.3 nRF Sniffer在Windows下的安装以最常见的nRF52840 Dongle为例安装步骤大概是这样的从Nordic官网下载nRF Connect for Desktop安装后用它的Programmer工具把Sniffer固件烧录到Dongle上。烧录固件时需要按住Dongle上的按钮再插入USB进入DFU模式。在nRF Connect for Desktop里安装“Bluetooth Low Energy”工具这个工具自带Wireshark插件和驱动。打开Wireshark在捕获接口列表里选择nRF Sniffer接口。装好以后Wireshark里点开始就能看到空中所有BLE广播包和连接数据包了。nRF Sniffer强在能自动跟随一个连接的跳频序列也就是说只要锁定了一个主从连接它会跟着跳频信道走持续监听那个连接的数据。4.4 抓包实例看BLE广播和连接事件拿手机上的LightBlue App和ESP32连接做个演示。打开Wireshark的nRF Sniffer接口后你会第一时间看到一堆ADV_IND广播包。这些广播包就相当于设备在喊“我在这里我叫XX我能提供这些服务”。点开一个广播包能看到完整的广播内容设备名称、UUID、厂商自定义数据、发射功率等。如果你做低功耗蓝牙测距RSSI值就在射频层里每个广播包都带着可以直接看信号强度变化。连接建立后嗅探器自动切换到这个连接的跳频序列后续的包会标注LL Data PDU里面再拆出L2CAP、ATT/GATT层的内容。你会清晰地看到手机发出Read By Type RequestESP32回一个Read By Type Response一来一回清清楚楚。这一步做完你基本就能理解蓝牙协议栈里“属性读取”是怎么回事了对后续开发会有很大帮助。4.5 解析加密数据需要密钥注入如果连接启用了加密Sniffer抓到的是密文Wireshark里会看到一堆无法解码的数据。两个办法一是关闭加密再抓适合开发阶段自己控制设备的情况二是在Wireshark里填入LTK或IRK等密钥让它解密。填密钥的方式是在Wireshark的“蓝牙”协议首选项里配置需要你知道配对时生成的LTK是多少。很多BLE芯片的日志里会打印出这部分密钥信息找到后复制进Wireshark就能解密。如果拿不到密钥那就只能在设备固件里把加密暂时关掉来做调试。5. 实战复盘从抓包数据倒推几个经典问题的根因讲了这么多理论来三个我实际遇到过的案例看抓包数据怎么快速定位问题。5.1 HC05模块连不上手机App很多人手里的HC05模块明明之前能用突然就连接不上了。从抓包数据看最常见的两种情况情况一扫描阶段没问题但一连接就立即断开。抓包日志里会看到设备反复发送Connection Update Request然后主设备拒绝或超时。这种多半是模块的从机角色配置不对或者主设备连接参数要求太苛刻模块响应不了。情况二连接稳定但收不到数据。这种通常是RFCOMM通道没有成功建立。抓包数据里能看到SDP查询的结果为空说明模块没有正确广播自己的SPP服务UUID。那就要回到底层去检查模块的AT指令配置重新设置SPP服务。HC05在Windows下连接不上还有个因素是驱动兼容性。比如某些电脑装了第三方蓝牙驱动对SPP的支持并不好。抓包时能看到连接已经建立了但数据通道始终打不开。这种情况下换一个支持SPP协议的USB蓝牙适配器往往立竿见影。5.2 蓝牙水控器数据乱码有段时间我帮朋友调一个蓝牙水控器的数据上报问题。水控器用的是BLE每次上报的数据长度不固定App那边经常解析出乱码。用nRF Sniffer抓包后发现问题出在MTU协商上。水控器侧把MTU设成了默认的23字节而App这边用的是Android机的默认MTU大约512字节。每次水控器上报超过23字节的数据时就得分片传输。分片传输本身没问题但水控器的固件对分片重组处理得不好导致App收到的是残缺帧。知道问题在哪之后就好办了让水控器固件把MTU调大同时在发送之前做一次MTU Exchange Request协商问题直接解决。这事要是没有抓包工具光靠App看日志可能排查三天都找不到方向。5.3 蓝牙耳机频繁断开还有个案例是蓝牙耳机在电脑上频繁断开换了耳机也没用。用HCI日志抓包后发现在连接稳定运行的情况下电脑每隔几十秒就发出一次Disconnect命令原因是Remote User Terminated。这个信息说明是对面设备主动断开的不是电脑的问题。再往深挖发现耳机在断开前频繁收到电脑端的Audio Stream Control切换命令导致耳机在两个模式之间反复横跳。问题的根源是电脑里的某个驱动在抢占蓝牙音频通道把耳机的A2DP模式切到了SCO模式这个切换动作本身就会导致连接中断。定位到这一步后在设备管理器里禁用掉那个冲突的驱动就能解决问题了。6. 常见问题速查表与避坑技巧为了让这篇文章更实用我把实际调试中遇到的高频问题整理成一个速查表按现象、原因、排查思路三列排好。现象最常见原因排查思路Wireshark里没有蓝牙接口蓝牙适配器驱动不兼容或未开启HCI日志检查注册表EnableKHALLogging是否为1换微软通用驱动日志目录里没有生成文件适配器不支持或驱动是定制版在设备管理器里看驱动版本卸载第三方驱动抓到全是一些看不懂的HCI Event抓的是控制面数据没有用户载荷用btl2cap或btatt过滤器过滤或看ACL数据包只能抓到广播包连接包一闪就没没有锁定连接或连接加密开启用nRF Sniffer等硬件工具锁定连接连接阶段开启密钥注入HC05连不上日志显示PIN或Key Missing配对信息过期或蓝牙模块角色不对清空配对记录重新配对确认模块是主机还是从机模式蓝牙音频断断停停音频模式在A2DP和SCO之间反复切换抓包看Audio Stream Control切换频率数据长度不对或乱码MTU协商错误或分片重组逻辑有问题抓包看ATT层的Prepare Write和Execute Write用某第三方驱动后抓包数据大量缺失驱动对HCI日志支持不完整换成微软通用驱动或直接用硬件嗅探器6.1 独家避坑技巧聊几个文档里不会写的经验。第一开启HCI日志后尽量先禁用再启用蓝牙适配器而不是直接重启电脑。我遇到过不少系统重启后日志模块不工作的情况反而是热重启蓝牙适配器更容易让日志模块正常写入。第二Wireshark里抓蓝牙数据时建议关闭IPv4/IPv6的DNS解析否则加载大量协议名时会卡顿严重。具体操作是Wireshark的“偏好设置”里把“Name Resolution”下能关的选项都关掉。蓝牙协议名本来就短根本不需要域名解析。第三抓包时尽量让设备贴近电脑或嗅探器距离不超过1米。蓝牙数据包没有校验和保护机制信号弱的时候丢包率极高丢包会导致Wireshark里出现大量不完整包或乱序帧很容易误导分析。第四如果你是用nRF Sniffer做监听注意避免附近有其他BLE设备的干扰。BLE有37、38、39三个广播信道设备多的时候它会频繁跳到别的信道如果你手动给Wireshark设定了固定信道容易漏抓。建议用自动模式。6.2 驱动层面的大坑顺便提一个很多人在Windows下用非通用蓝牙驱动时会遇到的坑部分厂商的驱动在数据量大的时候会丢包。这个很难从系统层面感知但抓包数据里会频繁出现断帧或长度异常。我记得有个热词叫“brlink蓝牙驱动”这类第三方的蓝牙驱动在部分山寨蓝牙适配器上很常见。如果抓到的数据包总是不完整而换一台电脑又正常先想想驱动的问题。6.3 关于经典蓝牙和BLE的区别最后补充一点常识级的东西。很多人一上来就问“能不能用Wireshark抓经典蓝牙的数据”答案是可以但要看层次。经典蓝牙BR/EDR的HCI日志和Wireshark解析已经比较成熟因为它走的是RFCOMM、SPP、A2DP这些老协议。BLE的抓包则意味着要处理广播事件、连接事件、ATT/GATT分层。两者数据分析的侧重点完全不同。刚才提到的nRF Sniffer等硬件嗅探器大部分主力支持的是BLE抓经典蓝牙的能力有限。如果你要抓经典蓝牙耳机或音箱的数据只能走Windows自带的HCI日志或者购买非常高端的分析仪。这一点选型时就要想明白。7. 写在最后抓包这个事值得下点功夫蓝牙抓包是我认为无线开发调试中最值得投入时间掌握的一项技能没有之一。很多时候设备问题看起来像固件bug实际上是对端协议交互的问题抓包数据一出来谁对谁错一目了然。Windows下抓包的方案虽然没有Linux下那么直接但用对了方法一样能把问题看得明明白白。我个人习惯的做法是日常调试优先用Wireshark的实时接口遇到数据异常就叠加导HCI日志做二次确认涉及自己不参与通信的场景就上nRF Sniffer这类硬件嗅探器。这套组合在我这些年调试ESP32、HC05、BLE外设的过程中帮了大忙。最后再分享一个小技巧平时抓包时把关键的抓包文件分门别类存好备注好设备型号、连接参数、问题描述。蓝牙问题很多时候是间歇性的当时没来得及分析的包过几天回看往往会有新发现。有这个习惯之后你排查问题的速度会快很多。
在嵌入式开发和无线调试圈子里蓝牙相关的问题永远是最折磨人的耳机偶尔断流、自己写的App收不到设备数据、HC05模块明明指示灯正常但就是配对不上。这些问题到了应用层往往看不出任何端倪最后的真相都藏在协议栈下面。想看到协议栈里的东西就得抓蓝牙数据。这篇文章要聊的就是Windows系统下做蓝牙抓包的几条实测可用的路线以及我在实际调试中踩过的坑和总结出的经验。先说清楚适合谁看。如果你在搞ESP32、HC05、JDY-31这类蓝牙模块的开发或者你在调试蓝牙耳机、手柄、键盘这类外设的连接问题再或者你在做Android/iOS与外设的通信联调这篇文章应该能帮你少走不少弯路。文章里既有纯软件的方案也有需要几十块钱硬件的方案丰俭由人。1. 抓包前先搞懂你到底要抓哪一层很多人在蓝牙抓包这件事上卡住根本原因不是工具不会用而是没想清楚自己要抓什么。蓝牙协议栈是分层的不同层的调试手段完全不一样你先得知道自己面对的问题在哪个层。1.1 蓝牙协议栈的四层结构拿日常最常用的蓝牙场景来说从下往上大致分四层控制器Controller、主机Host、应用层协议Profile、应用程序。控制器就是蓝牙芯片里的射频部分负责收发电波主机是协议栈的核心逻辑负责连接管理和数据分发应用层协议就是我们常说的SPP、A2DP、HID、GATT应用程序就是手机上那个App或者电脑里的驱动软件。如果你要查“为什么连不上”“为什么连接老断开”这类连接层的问题要看的是HCIHost Controller Interface层的数据。如果你要查“为什么收不到传感器数据”“为什么收到的是乱码”那要看L2CAP层以及更上层的ATT/GATT或者RFCOMM。如果你要查“蓝牙耳机音质为什么这么差”那还得看A2DP协议里的媒体帧。搞清楚自己在哪一层直接决定了你用哪种抓包方式。这一点至关重要否则你辛辛苦苦抓了一堆数据结果发现层次对不上纯属浪费时间。1.2 两个核心概念本机通信日志和空中无线包Windows下抓蓝牙数据要区分两个场景。第一个场景是抓自己电脑和某个设备之间的通信数据。这种数据在自己的蓝牙适配器里就有不需要额外硬件Windows系统自己就能记录关键在于怎么把日志导出成可读的格式。第二个场景是抓两个设备之间的空中通信数据比如手机和ESP32之间的通信你的电脑完全没参与。这种场景只能靠带监听模式的硬件嗅探器来解决任何纯软件方案都搞不定因为你的电脑蓝牙适配器压根收不到和自己无关的数据包。这条分界线决定了你的工具选型。我见过不少新手拿Wireshark折腾半天想抓手机和耳机之间的空包结果什么都抓不到就是没搞清楚这个区别。1.3 Windows下抓蓝牙的三条路线纯软件路线A开启Windows自带的蓝牙HCI日志再把日志导入Wireshark解析。成本为零适合抓自己电脑参与通信的蓝牙数据这是本文的重点。纯软件路线BWireshark配合系统接口实现实时捕获同样是抓本机参与通信的数据但稳定性受蓝牙适配器驱动的影响比较大。硬件路线C使用蓝牙嗅探器BLE Sniffer被动监听空中的数据包可以抓任意两个设备之间的通信但需要额外硬件成本从几十到上万不等。三条路线各有利弊我后面会分别展开讲实操细节。2. 路线A开启Windows内置HCI日志并导入Wireshark这一节是大家问得最多的也是Windows下抓蓝牙数据最朴素的方案不花一分钱把系统里的蓝牙协议日志导出然后用Wireshark打开分析。2.1 HCI日志到底是什么HCI是主机和控制器之间的接口你可以把它理解为蓝牙芯片和电脑操作系统之间的“对话记录”。Windows在系统层面有一个蓝牙日志模块它可以把HCI层的数据包记录下来。数据包里至少有连接事件、扫描结果、配对过程、ACL数据帧等关键信息足够覆盖大部分连接问题的调试场景。我特别想强调一点HCI日志记录的是主机和控制器之间的数据交换而不是空中传播的原始射频信号。它不包含物理层的跳频、调制解调信息但对于“两个设备之间发了什么数据”这个问题HCI日志已经能回答绝大多数疑问了。2.2 开启日志的具体操作开启HCI日志的方法是通过修改注册表按下WinR组合键输入regedit回车打开注册表编辑器。定位到HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters。在右侧空白处右键新建一个DWORD32位值命名为EnableKHALLogging。双击这个值把数值数据改为1。关闭注册表重启蓝牙适配器或重启电脑。重启蓝牙适配器的方法是在“设备管理器”里找到蓝牙设备右键选择“禁用设备”再右键选择“启用设备”。如果你在设备管理器里把它禁用后整个蓝牙图标消失直接重启电脑更省事。2.3 日志生成后怎么处理完成上面操作后正常使用你的蓝牙设备让它出现一次连接、断开、数据传输等操作然后打开目录C:\Windows\System32\LogFiles\BTH\。你会看到类似bt-...cetlog或bth...khlog之类的文件这些就是日志文件。注意要是这个目录里空空的多半是蓝牙适配器的驱动不是微软通用驱动。如果你装了某个品牌定制的驱动比如笔记本厂商自带的蓝牙驱动或者博通、英特尔的部分老驱动HCI日志可能压根不生成。这种情况我建议先卸载第三方驱动让Windows安装微软通用蓝牙驱动再试一次。日志文件本身Wireshark不一定能直接识别不同Windows版本下格式有差异。我实测过的做法是先看看Wireshark能不能直接打开。Wireshark 3.6以上版本对部分cetlog文件已经能自动识别。如果打开乱码或提示格式不支持可以试试把文件扩展名改成.pcapng再拖进去或者借助微软官方的bthlog工具做一次格式转换。这一步因系统版本不同差异很大不用钻牛角尖多试几种方式就行。2.4 实操心得日志应该在什么时候看有不少人和我说“我开了日志但抓到的包好少都是莫名其妙的HCI事件看不懂”。这很正常。HCI日志里大量的是HCI Event和HCI Command它们是控制面的内容能看到扫描、配对、连接参数协商的过程但看不到真正的用户数据载荷。如果你要分析的是数据内容光看HCI日志还不够需要配合抓到的ACL数据包做深度解析。我的实操经验是当你遇到连接建立不了、连接反复断、配对失败这些问题时HCI日志是最快定位的。比如两个设备半天连不上日志里如果出现频繁的Connection Timeout或者PIN or Key Missing问题方向基本就锁定了。但要分析数据载荷本身建议直接上Wireshark的实时接口或硬件嗅探器。3. 路线BWireshark直接抓取本机蓝牙接口数据相比导日志文件直接用Wireshark抓蓝牙接口的数据显然爽得多因为它能实时看到数据包并且直接解析好协议层。这一节说说我能跑通的做法和需要注意的地方。3.1 准备工作与接口识别先确保你的蓝牙适配器已经启用HCI日志也就是上一节注册表里的EnableKHALLogging还等于1。然后打开Wireshark在捕获接口列表里找正常会看到一个名字带蓝牙或Bluetooth的接口。如果看不到多半是接口没有被系统识别为可捕获状态或者Wireshark版本太老。我用Wireshark 4.x版本实测当前Windows版本Windows 10 22H2和Windows 11 23H2下蓝牙接口是可以直接选择的。选中后点击开始捕获然后去连接你的蓝牙设备或者让设备主动连接电脑Wireshark里就会开始刷新数据包。3.2 抓包演示连一次蓝牙耳机或者ESP32这里用一个简单场景演示让手机通过蓝牙向Windows电脑传一个文件或连接一个BLE外设。操作步骤如下Wireshark选好蓝牙接口点击开始捕获。在Windows设置里打开蓝牙搜索设备并配对连接。连接成功后传输一些数据比如发一个文本文件过去。停止Wireshark捕获。抓到的包会按照协议层次自动解析你会在报文列表里看到类似Bluetooth HCI、L2CAP、RFCOMM、ATT、GATT这些协议标识。双击任意一个包下方会展开协议树从HCI层到L2CAP层到上层Payload每一层都能看到。3.3 常用过滤器过滤器的使用是效率的关键不然上百个包根本看不过来。我最常用的几个btl2cap只看L2CAP层的数据适合分析逻辑通道和分段重组的问题。btrfcomm只看串口协议数据调试HC05这类SPP蓝牙模块时必备。btatt只看BLE的属性协议调试ESP32这类BLE设备时最常用。btgap只看广播和扫描数据用来分析设备广播内容。bthci_acl只看ACL数据包定位数据帧异常时用。举个例子。你用一个App连接ESP32ESP32每秒回传一组传感器数据但App里偶尔会漏包。用Wireshark抓包后输入btatt过滤直接拉到ATT层的数据看有没有出现重传或长度异常的包。如果看到很多Prepare Write Request和Execute Write Request说明MTU协商值太小数据被拆成很多片段传输这就是丢包的根源之一。3.4 实时接口抓包的坑实时接口抓包整体可用但实测有几个需要注意的坑。第一不是所有蓝牙适配器都支持实时抓包。很多廉价的USB蓝牙适配器在Windows下只暴露HCI接口没有做数据捕获接口导致Wireshark根本识别不出蓝牙接口。遇到这种情况不要死磕老实走路线A导日志或者直接上硬件嗅探器。第二数据包里有些帧是乱序的。原因是蓝牙链路本身有重传机制以及HCI传输存在队列延迟Wireshark解析时有时会提示TCP out-of-order类似的警告在蓝牙里是L2CAP segment reassembly相关警告这多是被重传机制影响的不必紧张。第三抓包会影响数据传输的时序。这是软件抓包的天然副作用因为捕获过程要消耗一定的系统资源。你要是做高精度蓝牙测距或时间敏感的场景普通抓包工具本身就成了干扰源这时候硬件嗅探器的优势就体现出来了。4. 路线C硬件嗅探器被动监听空中数据包前面两条路都只能抓“自己电脑参与的通信”但实际工作中更常见的问题是手机和ESP32之间的通信出了问题电脑全程没参与。这种场景就需要硬件嗅探器做被动监听了业内一般叫Sniffer。4.1 为什么非得上硬件蓝牙的空中数据包默认是加密的只有参与配对的设备才能解密数据。如果电脑不在这个连接里纯软件的方式根本收不到数据。硬件嗅探器的思路是额外用一个带监听功能的蓝牙芯片让它混杂在空气中监听信道捕获所有经过的数据包。如果你已经掌握了链路密钥还能在Wireshark里手动填入密钥解密出Payload内容。我一向认为做蓝牙开发的人迟早要有至少一个嗅探器。它就像网络工程师的抓包工具一样平时吃灰关键时刻能救命。4.2 常用设备选型设备抓包范围价格区间上手难度推荐场景nRF52840 DongleBLE 4.0/5.x100-200元低开发nRF系列或BLE外设CC2540 USB DongleBLE 4.030-80元仿低学习用老的教程最多Ubertooth OneBLE 经典蓝牙基础速率1000元左右中想兼顾经典蓝牙和BLE的开发者Ellisys/Frontline分析仪全协议覆盖数万到数十万高专业认证实验室或大厂如果你只是需要调试ESP32或HC05这类常见模块一块带nRF Sniffer固件的nRF52840 Dongle就够用了性价比很高。Ubertooth One能抓经典蓝牙的Basic Rate数据这是nRF52840做不到的地方但Ubertooth的操作门槛更高驱动和固件都要自己折腾。4.3 nRF Sniffer在Windows下的安装以最常见的nRF52840 Dongle为例安装步骤大概是这样的从Nordic官网下载nRF Connect for Desktop安装后用它的Programmer工具把Sniffer固件烧录到Dongle上。烧录固件时需要按住Dongle上的按钮再插入USB进入DFU模式。在nRF Connect for Desktop里安装“Bluetooth Low Energy”工具这个工具自带Wireshark插件和驱动。打开Wireshark在捕获接口列表里选择nRF Sniffer接口。装好以后Wireshark里点开始就能看到空中所有BLE广播包和连接数据包了。nRF Sniffer强在能自动跟随一个连接的跳频序列也就是说只要锁定了一个主从连接它会跟着跳频信道走持续监听那个连接的数据。4.4 抓包实例看BLE广播和连接事件拿手机上的LightBlue App和ESP32连接做个演示。打开Wireshark的nRF Sniffer接口后你会第一时间看到一堆ADV_IND广播包。这些广播包就相当于设备在喊“我在这里我叫XX我能提供这些服务”。点开一个广播包能看到完整的广播内容设备名称、UUID、厂商自定义数据、发射功率等。如果你做低功耗蓝牙测距RSSI值就在射频层里每个广播包都带着可以直接看信号强度变化。连接建立后嗅探器自动切换到这个连接的跳频序列后续的包会标注LL Data PDU里面再拆出L2CAP、ATT/GATT层的内容。你会清晰地看到手机发出Read By Type RequestESP32回一个Read By Type Response一来一回清清楚楚。这一步做完你基本就能理解蓝牙协议栈里“属性读取”是怎么回事了对后续开发会有很大帮助。4.5 解析加密数据需要密钥注入如果连接启用了加密Sniffer抓到的是密文Wireshark里会看到一堆无法解码的数据。两个办法一是关闭加密再抓适合开发阶段自己控制设备的情况二是在Wireshark里填入LTK或IRK等密钥让它解密。填密钥的方式是在Wireshark的“蓝牙”协议首选项里配置需要你知道配对时生成的LTK是多少。很多BLE芯片的日志里会打印出这部分密钥信息找到后复制进Wireshark就能解密。如果拿不到密钥那就只能在设备固件里把加密暂时关掉来做调试。5. 实战复盘从抓包数据倒推几个经典问题的根因讲了这么多理论来三个我实际遇到过的案例看抓包数据怎么快速定位问题。5.1 HC05模块连不上手机App很多人手里的HC05模块明明之前能用突然就连接不上了。从抓包数据看最常见的两种情况情况一扫描阶段没问题但一连接就立即断开。抓包日志里会看到设备反复发送Connection Update Request然后主设备拒绝或超时。这种多半是模块的从机角色配置不对或者主设备连接参数要求太苛刻模块响应不了。情况二连接稳定但收不到数据。这种通常是RFCOMM通道没有成功建立。抓包数据里能看到SDP查询的结果为空说明模块没有正确广播自己的SPP服务UUID。那就要回到底层去检查模块的AT指令配置重新设置SPP服务。HC05在Windows下连接不上还有个因素是驱动兼容性。比如某些电脑装了第三方蓝牙驱动对SPP的支持并不好。抓包时能看到连接已经建立了但数据通道始终打不开。这种情况下换一个支持SPP协议的USB蓝牙适配器往往立竿见影。5.2 蓝牙水控器数据乱码有段时间我帮朋友调一个蓝牙水控器的数据上报问题。水控器用的是BLE每次上报的数据长度不固定App那边经常解析出乱码。用nRF Sniffer抓包后发现问题出在MTU协商上。水控器侧把MTU设成了默认的23字节而App这边用的是Android机的默认MTU大约512字节。每次水控器上报超过23字节的数据时就得分片传输。分片传输本身没问题但水控器的固件对分片重组处理得不好导致App收到的是残缺帧。知道问题在哪之后就好办了让水控器固件把MTU调大同时在发送之前做一次MTU Exchange Request协商问题直接解决。这事要是没有抓包工具光靠App看日志可能排查三天都找不到方向。5.3 蓝牙耳机频繁断开还有个案例是蓝牙耳机在电脑上频繁断开换了耳机也没用。用HCI日志抓包后发现在连接稳定运行的情况下电脑每隔几十秒就发出一次Disconnect命令原因是Remote User Terminated。这个信息说明是对面设备主动断开的不是电脑的问题。再往深挖发现耳机在断开前频繁收到电脑端的Audio Stream Control切换命令导致耳机在两个模式之间反复横跳。问题的根源是电脑里的某个驱动在抢占蓝牙音频通道把耳机的A2DP模式切到了SCO模式这个切换动作本身就会导致连接中断。定位到这一步后在设备管理器里禁用掉那个冲突的驱动就能解决问题了。6. 常见问题速查表与避坑技巧为了让这篇文章更实用我把实际调试中遇到的高频问题整理成一个速查表按现象、原因、排查思路三列排好。现象最常见原因排查思路Wireshark里没有蓝牙接口蓝牙适配器驱动不兼容或未开启HCI日志检查注册表EnableKHALLogging是否为1换微软通用驱动日志目录里没有生成文件适配器不支持或驱动是定制版在设备管理器里看驱动版本卸载第三方驱动抓到全是一些看不懂的HCI Event抓的是控制面数据没有用户载荷用btl2cap或btatt过滤器过滤或看ACL数据包只能抓到广播包连接包一闪就没没有锁定连接或连接加密开启用nRF Sniffer等硬件工具锁定连接连接阶段开启密钥注入HC05连不上日志显示PIN或Key Missing配对信息过期或蓝牙模块角色不对清空配对记录重新配对确认模块是主机还是从机模式蓝牙音频断断停停音频模式在A2DP和SCO之间反复切换抓包看Audio Stream Control切换频率数据长度不对或乱码MTU协商错误或分片重组逻辑有问题抓包看ATT层的Prepare Write和Execute Write用某第三方驱动后抓包数据大量缺失驱动对HCI日志支持不完整换成微软通用驱动或直接用硬件嗅探器6.1 独家避坑技巧聊几个文档里不会写的经验。第一开启HCI日志后尽量先禁用再启用蓝牙适配器而不是直接重启电脑。我遇到过不少系统重启后日志模块不工作的情况反而是热重启蓝牙适配器更容易让日志模块正常写入。第二Wireshark里抓蓝牙数据时建议关闭IPv4/IPv6的DNS解析否则加载大量协议名时会卡顿严重。具体操作是Wireshark的“偏好设置”里把“Name Resolution”下能关的选项都关掉。蓝牙协议名本来就短根本不需要域名解析。第三抓包时尽量让设备贴近电脑或嗅探器距离不超过1米。蓝牙数据包没有校验和保护机制信号弱的时候丢包率极高丢包会导致Wireshark里出现大量不完整包或乱序帧很容易误导分析。第四如果你是用nRF Sniffer做监听注意避免附近有其他BLE设备的干扰。BLE有37、38、39三个广播信道设备多的时候它会频繁跳到别的信道如果你手动给Wireshark设定了固定信道容易漏抓。建议用自动模式。6.2 驱动层面的大坑顺便提一个很多人在Windows下用非通用蓝牙驱动时会遇到的坑部分厂商的驱动在数据量大的时候会丢包。这个很难从系统层面感知但抓包数据里会频繁出现断帧或长度异常。我记得有个热词叫“brlink蓝牙驱动”这类第三方的蓝牙驱动在部分山寨蓝牙适配器上很常见。如果抓到的数据包总是不完整而换一台电脑又正常先想想驱动的问题。6.3 关于经典蓝牙和BLE的区别最后补充一点常识级的东西。很多人一上来就问“能不能用Wireshark抓经典蓝牙的数据”答案是可以但要看层次。经典蓝牙BR/EDR的HCI日志和Wireshark解析已经比较成熟因为它走的是RFCOMM、SPP、A2DP这些老协议。BLE的抓包则意味着要处理广播事件、连接事件、ATT/GATT分层。两者数据分析的侧重点完全不同。刚才提到的nRF Sniffer等硬件嗅探器大部分主力支持的是BLE抓经典蓝牙的能力有限。如果你要抓经典蓝牙耳机或音箱的数据只能走Windows自带的HCI日志或者购买非常高端的分析仪。这一点选型时就要想明白。7. 写在最后抓包这个事值得下点功夫蓝牙抓包是我认为无线开发调试中最值得投入时间掌握的一项技能没有之一。很多时候设备问题看起来像固件bug实际上是对端协议交互的问题抓包数据一出来谁对谁错一目了然。Windows下抓包的方案虽然没有Linux下那么直接但用对了方法一样能把问题看得明明白白。我个人习惯的做法是日常调试优先用Wireshark的实时接口遇到数据异常就叠加导HCI日志做二次确认涉及自己不参与通信的场景就上nRF Sniffer这类硬件嗅探器。这套组合在我这些年调试ESP32、HC05、BLE外设的过程中帮了大忙。最后再分享一个小技巧平时抓包时把关键的抓包文件分门别类存好备注好设备型号、连接参数、问题描述。蓝牙问题很多时候是间歇性的当时没来得及分析的包过几天回看往往会有新发现。有这个习惯之后你排查问题的速度会快很多。
