做 BLE 开发这几年抓包工具就是我的另一双眼睛。不管是调试连接参数、看广播包格式、排查断连原因还是确认手机和从机之间到底聊了什么没有一套顺手的抓包环境基本等于盲人摸象。在众多方案里PC 端 Wireshark 配合 nRF52832/nRF52840 Sniffer Dongle 算是性价比最高、用得最多的一套组合但说实话它的环境配置并不像装个 QQ 那么无脑。我印象最深的一次光把 dongle 固件烧进去、让 Wireshark 认出来就折腾了一整个下午最后发现是驱动和插件版本不对付。这篇文章就把我踩过的坑、试出来的解决办法以及日常抓包分析的一些小习惯一次性整理出来给正在被这套环境折磨的朋友一个参考。1. 环境搭建的整体思路与组件盘点1.1 这套抓包方案由哪几部分组成很多人第一次接触 BLE 抓包容易以为“买个 dongle 插上电脑就能抓”真上手才发现要正常跑起来背后其实是四层东西在协作硬件 dongle、板载固件、PC 端驱动、上位机软件 Wireshark 及其插件。哪一层出问题表现都是“抓不到包”或者“设备不识别”但排查路径完全不同。具体来说硬件是 nRF52832 或 nRF52840 核心的 USB dongle最常见的是 Nordic 官方的 nRF52840 Dongle也就是 PCA10059还有第三方做的 52832 版本。固件方面官方提供的是 nRF Sniffer for BLE 的 hex 文件需要烧录进 dongle 后它才能把空中的 2.4G BLE 数据包抓下来并通过 USB 转成逻辑帧送给 PC。PC 端需要有对应的串口驱动比如 dongle 上用的 J-Link OB 芯片或者直接 USB CDC 枚举出来的 COM 口。最后Wireshark 里要装 Nordic 提供的 nRF Sniffer 插件插件以 extcap 的方式工作把串口数据解析成 Wireshark 能识别的 pcap 格式。这四层里最容易出问题的就是固件和插件版本不匹配。我见过太多人把最新版 Wireshark 和旧版 nRF Sniffer 插件搭在一起结果 extcap 接口在 Wireshark 里根本不显示。所以搭建之前最好先把“固件版本 插件版本 Wireshark 版本”这个三角关系理顺后面能少走很多弯路。1.2 为什么推荐 nRF52 系列而不是其他抓包器市面上 BLE 抓包硬件其实不少有国产的、有 TI 的 CC2540 方案的、也有高端一点的 Ellisys 或 Frontline 协议分析仪。但 nRF52 系列 dongle 能被大家广泛使用我认为核心优势有三个第一是价格友好。官方 dongle 或者其他基于 nRF52840 的 USB 棒子几十块到一百多块就能搞定对比动辄上万的专业协议分析仪学习成本和试错成本都很低。第二是抓包能力够用。nRF52840 支持 BLE 5.0能抓 1M、2M PHY也支持 Coded PHY125k/500k对于绝大多数 BLE 开发调试场景——广播、扫描、连接、配对、GATT 读写——已经完全够用。nRF52832 虽然只支持 BLE 4.x 的 1M PHY但抓个基本连接、看看广播包也绰绰有余。第三是软件生态成熟。Nordic 出了配套的 nRF Connect for Desktop里面直接集成了 Programmer 和 Sniffer 相关的工具最方便的是它能把 dongle 刷成 Wireshark 可识别的工作模式。再加上 Wireshark 本身对 BLE 协议解析的支持已经很完善两者配合基本等于拿一台“民用协议分析仪”。不过我要提前打个预防针这套方案本质上是“单信道抓包”也就是一次只能抓到 dongle 所在信道的空中数据。BLE 连接会跳频所以你抓到的包并不完整。这是硬件方案的通病不是配置问题。理解这一点后面抓连接过程的时候就不会一头雾水了。2. 驱动与设备识别问题从“插上没反应”到“稳定出包”2.1 dongle 插上后毫无反应先别急着怪硬件我先说一个最常见也最让人崩溃的场景dongle 插上电脑设备管理器里啥也没多或者多了一个带黄色感叹号的未知设备。这时候大概率不是硬件坏了而是固件状态不对或者驱动没对上。nRF52840 Dongle 出厂时默认跑的是 bootloader首次插上电脑在设备管理器里会看到一个叫 “OpenBootloader” 或者类似的 USB 设备。这个状态下你是没法直接用它抓包的必须先把 Sniffer 固件烧进去。如果你是在设备管理器里看到一个未知设备可以先右键属性看一下硬件 ID如果 VID 是 0x1915Nordic 的 USB Vendor ID那基本就可以确认是 Nordic 设备只是驱动和固件的问题。另一个常见情况是之前用这个 dongle 刷过其他固件比如跑过 Zephyr 的 BLE 示例或者当普通串口用过再插回来发现 Wireshark 不认。这就需要用 nRF Connect for Desktop 里的 Programmer 工具重新烧回 Sniffer 固件。我自己的习惯是专门拿一个 dongle 只当 Sniffer 用不拿它刷乱七八糟的例程免得每次换固件都要重新折腾一遍驱动识别。2.2 串口驱动选不对Wireshark 永远看不到接口如果设备管理器里已经能看到一个 COM 口了但 Wireshark 的接口列表里就是没有 nRF Sniffer 相关的入口这时候问题多半出在驱动类型上。nRF52840 Dongle 官方固件在烧录成功后会以 USB CDC ACM 的方式枚举出一个串口。Windows 10/11 系统一般会自动装一个 “USB 串行设备” 的驱动但某些精简版系统或者装了其他串口工具的电脑可能会被占掉或者装错。我的经验是如果 COM 口能正常识别但 Wireshark 里就是不出接口先去设备管理器里看看这个 COM 口是不是被识别成了 “通信端口”右键属性 → 驱动程序详细信息看驱动文件是不是 usbser.sys。如果是别的什么第三方驱动尤其是某些 USB 转串口芯片的万能驱动会干扰 extcap 的正常调用。另外要提一个很多人忽略的点nRF Connect for Desktop 自带的 J-Link 驱动有时候会和 dongle 的 USB CDC 串口冲突导致设备反复枚举。解决方法是去设备管理器里把那个“J-Link CDC UART Port”禁用一个只保留一个 COM 口给 Wireshark 用不然 extcap 会随机选到一个不对的串口结果就是抓包界面起得来但一包数据都没有。2.3 设备管理器操作速查一步步排查驱动状态这里我直接给一个排查顺序照着走基本能把“插上没反应”这类问题解决掉插上 dongle打开设备管理器看在“端口 (COM 和 LPT)”里有没有出现 COM 口。如果出现了说明 USB 枚举和串口驱动都正常问题在 Wireshark 插件层。如果出现在“其他设备”或者“通用串行总线设备”里右键更新驱动手动指定驱动路径到 C:\Windows\System32\drivers 下的 usbser.sys或者直接卸载设备后重新插拔让系统重新枚举。如果连设备都没有换个 USB 口最好是直连主机后置口别用前置面板或者 USB Hub。我遇到过因为 USB Hub 供电不稳导致 dongle 反复掉线的问题后来插主机后面就再没犯过。确认无误后打开 nRF Connect for Desktop 的 Programmer看能否识别到设备。如果 Programmer 能读到设备信息基本说明硬件链路没问题。最后一步也是我强烈建议做的烧录完固件后拔插一次 dongle让设备重新枚举。因为固件切换不会自动触发 USB 重枚举有时候你以为没烧成功其实就是没拔插。3. 固件烧录与 Wireshark 插件版本匹配最常见的坑都在这3.1 烧录工具选哪个nrfutil 命令行还是图形化 Programmer烧录 Sniffer 固件有两种主流方式用 Nordic 官方的 nrfutil 命令行工具或者用 nRF Connect for Desktop 里的 Programmer 图形界面。对新手来说我推荐用图形化 Programmer因为可以看到烧录进度和结果也减少输错命令的风险。但如果你用的是第三方 nRF52832 dongle尤其是那种不带 USB bootloader 的版本可能没法直接通过 USB 烧录。这时候需要用到 SWD 调试接口也就是拿一个 J-Link、DAP-Link 之类的调试器配合 nrfutil 或者 Keil、IAR 烧录。nRF52832 的 dongle 一般会引出 SWD 的 4 个引脚SWCLK、SWDIO、GND、VDD用杜邦线连上调试器就行。注意 nRF52832 烧录时如果芯片有保护位可能需要先用 nrfjprog --recover 解锁不然会报错。如果你用的是 nrfutil 命令行方式核心命令是nrfutil dfu usb-serial -pkg sniffer_ble_3.2.0.zip -p COM5这个命令适用于 dongle 里已经有 DFU bootloader 的情况。它会通过串口把 zip 包里的固件烧进去烧完自动运行。注意这里 -pkg 参数要求的是 zip 包而不是 hex 文件很多新手卡在这一步不知道去哪里找 zip 包。其实 Nordic 官网下载的 nRF Sniffer for BLE 安装包里除了 hex 文件还带了一个 zip 格式的 DFU 包专门用来给 bootloader 升级用的。3.2 Wireshark 版本和 nRF Sniffer 插件版本的匹配关系版本匹配这件事我放在最后说但它是所有坑里最坑的一个。nRF Sniffer 插件的 extcap 接口依赖 Wireshark 的 extcap 框架而 Wireshark 不同版本之间对 extcap 的接口规范有过变化导致旧版插件往往无法在新版 Wireshark 里正常加载。以我实际测试的情况给出一个保守的搭配表Wireshark 版本nRF Sniffer 插件版本实测结果4.0.x / 4.2.x3.2.0正常3.6.x3.1.0 / 3.2.0正常3.4.x3.1.0正常3.2.x 及更早2.x / 3.0需确认具体版本这个表不是绝对的因为 Nordic 在新版插件里也修复了不少旧 Wireshark 的兼容问题但如果你用的组合特别新或特别旧建议优先按表里的组合试。插件的安装路径在 Windows 上一般是 C:\Program Files\Wireshark\extcap安装完插件后一定要完全退出 Wireshark 再重开不是关闭窗口而是确认进程管理器里没有 Wireshark 在跑否则 extcap 不会重新加载。还有一个细节有些用户装插件时会把整个文件夹放错位置导致 Wireshark 的接口列表里多了个灰色的 “nRF Sniffer for BLE” 但怎么点都报错。这种情况直接去 extcap 目录看看有没有 nrf_sniffer_ble.py 文件或者对应的 exe 文件。插件没放全、依赖的 Python 环境不对都会导致这种“看得到用不了”的症状。3.3 烧录完成后Wireshark 里怎么确认环境就绪烧完固件、装好插件、重开 Wireshark 之后正确的检查步骤是这样的在 Wireshark 首页的接口列表里应该能看到一个叫 “nRF Sniffer for BLE” 的接口点旁边的齿轮图标可以设置信道、包过滤等参数。双击接口进入抓包界面后在显示过滤器里输入btle应该能看到一堆广播包或者数据包在滚动。如果界面上方显示 “No packets captured” 但设备明明在发广播多半是信道没选对或者 dongle 固件没跑起来。另外抓包界面有一个专门的 “Nordic BLE Sniffer” 工具栏里面可以选 Advertising 信道37/38/39或者 Follow 一个连接。如果这个工具栏没出现可能是在视图 → 界面工具栏里被隐藏了勾选出来就行。Wireshark 4.x 版本默认不显示所有工具栏这个细节能卡住不少人。我建议烧完固件后先用手机开一个 BLE 调试助手随便发点广播数据再回到 Wireshark 里看能不能抓到手机发出的广告包。能抓到说明整条链路已经通了抓不到优先检查信道选择手机广播默认在 37/38/39 三个信道上轮流发你如果固定在一个信道上有概率漏掉。4. 抓包过程疑难杂症与数据分析技巧4.1 为什么抓不到广播包或者抓到的包断断续续这个问题我把原因分成三类大家可以对照自查第一类是硬件问题。dongle 天线周围有金属遮挡、USB 线过长导致供电不足、或者电脑 USB 口本身供电不稳都会让 dongle 灵敏度下降。我试过用一个延长线把 dongle 放到离被测设备更近的位置抓包成功率明显提升。另外如果同时插了多个 USB 3.0 设备2.4G 频段的干扰会非常大因为 USB 3.0 的时钟谐波正好落在 2.4GHz 附近这个干扰是实打实的。第二类是信道问题。BLE 广播数据在 37、38、39 三个信道上轮发连接数据则在 0 到 36 号数据信道上跳频。Sniffer dongle 单次只能监听一个信道所以如果 dongle 停在 37 信道手机在 38 信道发广播你就抓不到。解决办法是抓广播时把 Sniffer 设置成 “All Advertising Channels” 模式它会在这三个信道间快速切换抓连接时要用 “Follow” 模式锁定一个连接让 dongle 模拟从机跟着主机跳频。第三类是软件层面的过滤。Wireshark 默认的显示过滤器可能会过滤掉你不关注的数据比如你只输出了btle过滤器但有些广播包是带 CRC 错误的在 Wireshark 里会被标成坏包并默认不显示。这时候需要在显示过滤器里加上!btle.advertising_header.crc_bad把坏包也显示出来方便排查信号干扰问题。4.2 连接包抓不全这是单信道抓包的物理限制很多人在抓连接过程的时候会发现一个现象广播连接请求CONNECT_IND抓到了但连接建立后的数据包断断续续隔几个事件才冒出来一个。这不是配置问题而是 BLE 连接本身的跳频机制决定的。BLE 连接建立后主从双方会按照一个伪随机序列在 37 个数据信道间跳频每次连接事件换一个信道。你的 Sniffer dongle 只有一个射频前端同一时间只能守在一个信道上所以不可能把每个连接事件都抓到。官方的 Sniffer 固件在 Follow 模式下会通过监听 CONNECT_IND 里的 Channel Map 和 Hop Increment 等信息计算出下一次连接事件在哪个信道上然后提前跳过去等包。但因为时序同步有误差或者设备修改了连接参数经常会出现“跟上了一个事件丢了下一个”的情况。应对办法也比较实用尽量让 dongle 靠近从机端因为从机是在 CONNECT_IND 之后才切换信道信号相对容易跟上把抓包时长拉长多抓几个连接事件截取关键帧分析结合从机端的日志比如用 RTT 或者串口打印来互补Sniffer 拿射频层数据日志拿协议栈状态两边对照能拼出完整图景。另外要说一点nRF Sniffer for BLE 的 Follow 功能并不是百分百可靠尤其在连接参数更新Connection Parameter Update之后它需要重新同步。实际工作中如果遇到 Follow 跟不上我一般会退回“守某一两个常用信道”的方式虽然拿不到完整连接数据但至少能看到广播、扫描请求这些低频类型。4.3 解密配对后的数据包LTK 从哪里来、怎么填抓到了连接数据但如果设备之间做了配对加密你会发现 Wireshark 里的 ATT/GATT 数据全部是加密后的密文根本看不懂。这时候需要把配对过程产生的 LTKLong Term Key喂给 Wireshark它才能解密后面的数据。获取 LTK 的方式有几种如果你是做嵌入式端的开发最常见的办法是从协议栈里把 LTK 打印出来。比如用 Zephyr 的bt_conn_info或者 Nordic SDK 里的pm_peer_data_load接口在配对完成后把 LTK 以十六进制形式打出来然后填进 Wireshark。如果是手机和从机配对就得从手机端想办法iOS/Android 一般拿不到所以实际工作中更多是在从机端抓。在 Wireshark 里填 LTK 的位置是编辑 → 首选项 → Protocols → BLE然后找到 “Decryption keys” 部分添加一条记录Key 类型选 LTK值填 32 位十六进制数。填完之后 Wireshark 会自动用这个 LTK 解密后续的加密包。注意一点需要配合配对过程中产生的 SKDSession Key Diversifier和 IVWireshark 才能正确派生会话密钥。但 nRF Sniffer 插件会自动从空中抓到这些参数你只需要填 LTK 就够了。实测下来最容易出错的坑是 LTK 填反了端。BLE 配对后主从两端各自持有一份相同的 LTK 用于加密但安全分发时还有 EDIV 和 Rand 来区分哪一端。Wireshark 里填 LTK 时默认按“本地设备”处理如果你是从从机端抓包但把主机端的 LTK 填进去了解密会失败。我一般建议从设备协议栈里拿到 LTK 后先看一下它是哪一端的填到 Wireshark 后立刻发一个 Read Request 测试能解出来就对了解不出来换另一端试试。4.4 双 dongle 协作抓包把单信道变“伪双信道”前面说过单信道抓包有物理限制那有没有办法提升覆盖率呢有而且成本不高。如果你手头有两个 nRF52 dongle可以同时插在电脑上分别打开两个 Wireshark 实例一个 dongle 设为在新连接事件中优先跟随主机另一个跟随从机视角。虽然不可能做到全覆盖但两个 dongle 同时守在不同信道能显著提高抓到连接事件的比例。这个方法在分析连接参数更新、断连原因、多连接并发时特别好用。比如排查“设备连接后 5 秒必断”问题单 dongle 抓到的包可能刚好错过了断开那一刻的信道双 dongle 至少多一倍的覆盖率。操作上有个小技巧两个 Wireshark 实例分别用不同的显示过滤器一个只看 HCI 事件和控制 PDU另一个只看 ATT/GATT这样可以减少视觉干扰也方便对照时间戳。另外 Wireshark 支持把抓包结果导出为 CSV 或者 pcap两个实例抓完后可以用 mergecap 合并成一个文件再统一分析。4.5 常用过滤器和显示技巧别在密密麻麻的包里迷失最后分享几个我日常高频使用的过滤器和界面设置能明显提高分析效率。只看广播包btle.advertising_address存在或者用btle.type 0ADV_IND 等广播类型。只看某个设备的包btle.advertising_address 12:34:56:78:9a:bc或者btle.master_address/btle.slave_address。设备地址是蓝牙地址注意是小端格式显示Wireshark 会直接解析好不用手工翻转。只看连接相关的包btle.type 5CONNECT_IND 类型配合btle.ll_control_opcode可以看连接参数更新、LL_VERSION_IND 等控制 PDU。只看 ATT 读写操作att.opcode存在再配合att.handle过滤某个具体句柄的读写。快速定位抓包起点可以用frame.time_relative X这种时间过滤但更推荐直接在 Wireshark 的 IO Graph 里按 btle 包类型做一个简单统计看整个抓包周期里的流量分布能快速找到异常点。显示方面我建议在首选项里把 BLE 协议的时间显示改成 “Seconds since beginning of capture”配合相对时间分析连接间隔、扫描间隔这些时序参数会非常直观。另外Wireshark 的颜色规则里可以自定义一下把 CONNECT_IND 标成醒目的颜色把 MIC 错误或者 CRC 错误的包标成红色一打开就知道哪里出了问题。5. 常见问题速查表与避坑心得5.1 配置问题速查表把前面散落在各个章节的问题汇总成一张表方便遇到问题时按图索骥。现象可能原因解决思路插上 dongle 设备管理器无任何反应USB 枚举失败、dongle 处于 bootloader 状态换 USB 口、重新插拔、用 Programmer 烧录固件设备管理器显示未知设备或黄叹号驱动未正确安装右键更新驱动指定 usbser.sys 或重装 Nordic USB 驱动Wireshark 接口列表没有 nRF Sniffer 入口插件没装对、extcap 目录不对、Wireshark 未完全重启检查 extcap 目录重装插件确认进程完全退出后重开能看到接口但双击没数据固件没跑起来、信道没选对、串口被占用重烧固件切换广播信道关闭其他占用串口的软件抓到的包全是坏包或 CRC 错误信号干扰、距离太远、USB 3.0 干扰靠近设备、换 USB 口、排除 2.4G 干扰源连接数据抓不全单信道抓包限制使用 Follow 模式、双 dongle 协作、结合设备端日志配对后的数据全是密文缺少 LTK 解密从协议栈获取 LTK填入 Wireshark BLE 协议解密配置Wireshark 打开后卡住或崩溃插件版本与 Wireshark 版本不兼容按版本匹配表更换插件版本或 Wireshark 版本5.2 我个人的几条经验心得最后说几条难以归类的个人心得都是实战中逐渐养成的习惯。第一养成抓包前先确认环境的习惯不要等抓了半天发现是 dongle 固件掉了。我现在每次开始正式抓包前会先在 Wireshark 里看一眼有没有持续滚动的时间戳再用手机发一个广播包确认链路整个检查不超过 30 秒但能省下后面一小时的排查时间。第二多利用 nRF Connect for Desktop 里的 Programmer 工具不要只把它当成烧录工具。它能直接查看 dongle 的固件版本、芯片信息还能在设备出问题时一键恢复。我常用的流程是烧录 → 验证固件版本 → 拔插 → Wireshark 抓包每一步都有明确反馈出问题能立刻定位。第三分析连接问题时不要把 Sniffer 当成唯一依据。单信道抓包天然有缺陷有时候抓到的是不完整的数据容易得出错误结论。比如一次排查从机断连问题Sniffer 显示对端主动发起了 DISCONNECT但实际是因为我们的从机长时间没回包主机超时断开。只看 Sniffer 数据很容易被误导一对照从机端日志才发现真相。所以我的习惯是射频层数据 协议栈日志 应用层日志三份资料一起看才能还原完整现场。第四固件版本记得随手记录。nRF Sniffer 固件更新比较频繁有时候你从官网下载的安装包和 Wireshark 插件的版本对不上导致 extcap 报错。我每次下载安装包后会在解压目录里放一个 README记录版本号、安装日期、配套的 Wireshark 版本。过几个月再出问题翻一下这个文件就能快速定位是不是升级导致的不兼容。5.3 环境搭建完成后的验证清单最后给一个我每次搭好环境都会快速跑一遍的验证清单等同于“开机自检”设备管理器里能看到一个正常的 COM 口nRF Connect for Desktop 的 Programmer 能识别到 dongleWireshark 接口列表里显示 nRF Sniffer for BLE同一办公室里另一台手机发 BLE 广播Wireshark 能刷出 btle 包且无 CRC 错误与自己的开发板建立连接Wireshark 能抓到 CONNECT_IND 以及至少几个数据信道上的包。这五条全部通过说明这套环境已经处于“健康可用”状态。后面再遇到奇葩问题至少可以排除环境因素把精力集中在协议本身的分析上。说实话Wireshark nRF52 dongle 这套环境虽然配置过程有点磨人但用顺手之后它的性价比和实用性真的没话说。尤其当你通过抓包解决了一个隐蔽的断连原因或者定位到一个手机上频繁发起连接参数更新的问题时那种“原来如此”的感觉就是所有折腾最好的回报。希望这篇文章能帮大家少走一些弯路早点进入真正有意思的协议分析阶段。