nRF52840 Dongle + Wireshark：BLE抓包实战方案全解析

1. 抓包方案选型为什么是nRF52840 Dongle Wireshark搞BLE开发的人迟早会碰到同一个痛点明明设备连上了、数据也发了但就是不知道协议栈里到底发生了什么。广播报文对不对、连接参数有没有生效、GATT服务发现是否正常、断开连接的reason是什么——这些问题靠串口打印很难定位尤其当你手上只有一颗从机芯片、没有逻辑分析仪、又不想为几百块钱的商用抓包工具买单的时候。我最早是用小米蓝牙调试助手凑合看广播数据的后来用手机上的nRF Connect扫描、看Service UUID再往后调低功耗参数时发现光看手机端根本不够用。手机看到的只是已经建立连接之后的“结果”但连接是怎么建立的、连接间隔是怎么协商的、链路上有没有重传这些关键信息全部藏在空中的数据包里。这时候就需要一个真正能“听”BLE信道的东西。nRF52840 Dongle加Wireshark这套组合本质上是用一片支持BLE 5的射频芯片当嗅探器配合PC上的Wireshark做协议解析和可视化。整套硬成本大约在100块上下如果你买Nordic原厂的Dongle会贵一点国内兼容板很便宜软件全部开源免费。效果上它能抓广播、抓连接握手、抓GATT交互、抓加密后的空包、甚至能看跳频序列和信道占用情况。对大部分BLE开发调试场景来说这套方案在性价比上可以说是没有对手。适合谁来用如果你是做BLE外设固件的、做Android/iOS App蓝牙功能的、做智能家居设备联调的或者只是拿ESP32写了个BLE Beacon想确认广播包内容对不对这套抓包组合都能派上用场。它不需要你有射频背景不需要动硬件刷个固件、装个驱动、点几个菜单就能开始工作。需要提前说明的是这篇文章不是照抄Nordic官方文档的翻译而是我实际用了大半年、踩了不少坑之后整理出来的流程。从固件烧录到过滤表达式再到那些一搜一大把但都不解决实际问题的报错我都会按自己的实操路线讲清楚。2. 环境搭建与基础原理2.1 硬件与软件清单在动手之前先把工具备齐我按“必备”和“可选”分开列一下项目名称说明必备nRF52840 Dongle兼容板即可USB接口板载PCB天线必备Wireshark建议3.4以上版本4.x更好必备nRF Connect for Desktop用于烧录Sniffer固件可选第二块nRF52840 DK如果你的Dongle被刷坏了可以救砖可选USB延长线减少PC机箱蓝牙/WiFi天线干扰Dongle本身出厂自带的是BLE 5.0的“passive sniffing”相关固件吗实际上不是。原厂Dongle默认烧的是“Open Bootloader”加一个示例固件可以当串口透传用。要做抓包必须先把Nordic官方的Sniffer固件刷进去。这个固件会把Dongle变成一个专用的BLE嗅探器PC端通过串口读取数据并转发给Wireshark的扩展插件解析。这里有个容易搞混的概念我必须先说清楚Sniffer固件模式下Dongle和PC之间走的不是蓝牙而是USB串口。也就是说Wireshark里看到的“nRF Sniffer”是一个虚拟串口接口数据从Dongle的射频前端捕获后经USB传输到PC再由Wireshark的nRF Sniffer插件翻译成BLE协议。所以如果你的电脑识别不到串口后面的所有步骤都白搭。2.2 为什么这套系统能“看到”蓝牙数据包无线数据在空气中是以2.4GHz频段上的射频信号传播的。BLE把80MHz带宽划分为40个信道其中37/38/39号信道是广播信道0到36号是数据信道。普通蓝牙设备只在自己工作的时间窗口内打开接收机所以一个手机配对一个手环它俩只知道彼此的时序但不知道周围还有谁在发数据。Sniffer的原理不一样它的射频前端会在某个指定信道上长时间监听把所有能解调出来的数据包都收下来。后续Dongle的固件和Wireshark插件进一步处理这些原始包如果是广播包就直接显示如果是连接相关的包插件会跟踪连接事件的时间、跳频图样、接入地址等信息随着连接建立而自动跟随跳频把整个连接过程的空口数据完整还原出来。这正是抓包能抓到“连接间隔协商”“密钥交换”“属性读写”这些高层行为的物理基础。理解这一点有助于排查一个常见误区抓包工具不是全信道同时收的。在一个时刻它只能监听一个信道上的数据但因为连接事件是按已知跳频序列轮转的插件可以联动跟随所以连接状态下的抓取是完整的。而广播状态则一般会轮询37/38/39三个信道所以广播包不会漏。2.3 安装驱动与Wireshark插件安装Wireshark建议直接去官网下载最新的稳定版安装包。Windows下装完Wireshark会顺带安装Npcap这是抓包所必需的底层驱动安装时建议勾选“Install Npcap in WinPcap API-compatible Mode”虽然新版大多默认兼容但这个勾选在某些老工具链中能省去不少麻烦。然后安装nRF Connect for Desktop。装完后打开它在左侧应用列表里找到“Programmer”应用它会自动检测已连接的J-Link或Dongle设备。把Dongle插入USB口按住上面的复位按钮再插上会进入Bootloader模式此时PC会枚举出一个新的USB设备Programmer里就能看到“nRF52840 Dongle”了。接下来把从Nordic官网下载的Sniffer固件hex文件烧进去。固件文件名通常是nrf_sniffer_for_ble_版本号_nrf52840_dongle_xx.hex下载时注意版本匹配。烧录完成之后Dongle会重新枚举成一个串口设备设备管理器里能看到一个USB串口COM口这就代表成功了。接下来是Wireshark插件部分。Nordic的Sniffer包是一个压缩包解开后里面除了固件还有Wireshark插件目录和extcap工具。不同版本Wireshark的插件目录不太一样官方文档推荐的方式是把nrf_sniffer_for_ble下的extcap文件夹里所有内容拷贝到Wireshark的extcap目录同时把tools目录下的nRF_Sniffer_For_BLE脚本放到plugins/Wireshark版本号/目录。如果你用的Wireshark版本比较新有些目录需要手动创建。装好插件后重新打开Wireshark首页的接口列表里就会出现“nRF Sniffer”开头的接口实际名称可能是“nRF Sniffer for BLE COMx”。如果看不到接口多半是插件路径不对或Python环境缺失这个我在后面常见问题里会详细展开。3. 抓包实操从接入到过滤3.1 启动Sniffer接口打开Wireshark在接口列表里找到带“nRF Sniffer”字样的接口双击它。第一次启动时Wireshark右下角可能会提示“需要安装Python”或“找不到Python解释器”这时候要注意Wireshark的extcap脚本依赖于PythonWindows下建议装Python 3.8到3.11之间的版本不要装最新版因为某些extcap脚本和Python 3.12的兼容性有问题。启动之后Wireshark的抓包界面会开始滚动数据。这个时候如果周围有蓝牙设备你应该能看到大量的广播包Advertising packets。如果你看到的是满屏的LL_TYPE_ADV_NONCONN_IND之类的包说明抓包已经正常工作了。但这里有个非常关键的细节Wireshark打开Sniffer接口后默认显示的是“全部信道轮询”模式。在这个模式下Dongle会在37/38/39三个广播信道上快速切换所以能看到所有广播包。但如果你要跟一个特定的设备建立连接、抓连接后的数据就必须要先设置“锁定目标设备”让Dongle只追踪这个设备的广播和连接事件。在Wireshark的nRF Sniffer界面里每一行包都有一个Advertising Address字段。鼠标右键点击目标设备的广播包选择“Copy as Filter”复制为过滤器然后新建一个显示过滤器把这个地址过滤出来。这样界面上就只会显示这个设备的广播了。3.2 锁定连接、跟随跳频锁定目标的另一条路径是使用nRF Sniffer的“设备追踪”功能。Wireshark的nRF Sniffer接口信息里有一个“Active Device”区域或者通过菜单栏“Capture - Options”里找到该接口的配置项。在这里可以输入目标设备的BD AddressSniffer就会只跟随这个设备的广播。一旦这个设备和其他中心设备建立了连接Sniffer会自动切换到数据信道开始按连接事件抓包。这个过程是自动的但前提是你的Sniffer必须完整听到连接请求包CONNECT_IND。如果Dongle在广播扫描的那个瞬间正好在听另一个信道漏掉了CONNECT_IND那么后续即使看到了数据包也无法正确解码。这是被动嗅探的天然局限。实操经验是不要直接把Dongle插在PC主机背后尽量用USB延长线把它拉到设备附近。Dongle板载的PCB天线增益有限隔一堵墙或距离两米以外就很容易漏包。如果条件允许把Dongle固定在目标设备和手机之间、尽量靠近连接发起的那个设备一般是手机或开发板这样听到CONNECT_IND的概率会高很多。成功跟随连接后Wireshark里能看到完整的连接事件序列包括LL_DATA_PDU、LL_EMPTY_PDU、LL_ENC_REQ、LL_ENC_RSP这些链路层包以及上层的ATT、GATT读写响应等。此时你会非常直观地理解什么叫“连接参数协商”。3.3 Wireshark过滤表达式速查很多人第一步能抓到满屏数据下一步就懵了——包太多了根本看不过来。这时候Wireshark的显示过滤器就是核心效率工具。我把自己常用的表达式整理成一张表直接抄就行抓包目的显示过滤器只看广播包btle.advertising_address ! 00:00:00:00:00:00锁定某个MAC的广播btle.advertising_address xx:xx:xx:xx:xx:xx只看连接包btle.connection_ll_data 1只看某个连接上的所有包btle.access_address 0x8e89bed6该值会被Wireshark自动填充到Packet Details里只看GATT写入请求btatt.opcode 0x12只看GATT通知btatt.opcode 0x1b看所有LL控制包btle.length btle.ll_control 1看空包连接保持包btle.ll_empty_pdu 1看加密相关的包btle.ll_control.opcode 0x05平时我用得最多的是btatt.opcode系过滤。比如你怀疑你的从机在某个服务上发通知的频率不对设置btatt.handle过滤或者btatt.opcode 0x1b就能看到所有Notification的时间戳和内容。Wireshark的BLE过滤字段前缀是btle和btatt如果你不确定某个字段名直接在“Packet Details”面板里点开一个数据包看左侧字段右键可以“Apply as Filter - Selected”Wireshark会自动生成对应的过滤表达式。这个方法比死记硬背字段名高效得多。3.4 抓取连接失败场景的实操记录我调试的一个典型例子一颗自研从机模块和手机相连连接总是十几秒后就断开。用串口日志只能看到“Connection terminated, reason 0x08”完全不知道是手机断的还是从机断的。用nRF Sniffer抓完一整个连接周期后Wireshark里清清楚楚显示手机端每隔30ms发一个空包从机应该在收到空包后的150ms内回复但某些时刻从机的包延迟了超过300ms随后链路层检测到连接超时主动发出LL_TERMINATE_INDreason code是0x08Connection Timeout。这个排查过程前后只花了半小时而如果用串口日志去复现、去猜可能一天都定位不到。有了完整的空口数据哪些包丢了、哪些包重传了、延时多少全部一目了然。4. 常见错误与排查技巧实录4.1 “打不开nRF Sniffer接口”或“extcap报错”这个错误在Windows上非常常见。Wireshark的extcap插件是通过命令行调用外部程序来捕获数据的nRF Sniffer插件的脚本是Python脚本所以它依赖Python环境。报错信息通常在Wireshark“Capture”下拉菜单里出现一个红色的错误提示或者在“接口列表”中根本没有nRF Sniffer接口。排查顺序先确认在Wireshark的“接口列表”里能看到nRF Sniffer接口。如果看不到先看Dongle的设备管理器状态确认板子被识别成COM口。如果设备管理器里是未知设备检查驱动安装Zadig把驱动换成USB串口CDC驱动。再看Wireshark插件目录确认extcap可执行文件路径正确。如果接口能看到但双击启动时报Python相关错误打开命令行手动执行nrf_sniffer_for_ble.py --extcap-interfaces看输出内容。通常错误是找不到pyshark或numpy模块用pip install pyshark numpy就能解决。注意Wireshark插件的extcap路径区分架构64位Wireshark要装64位Python。别混装32位和64位环境否则也会出现“找不到模块”的迷惑报错。4.2 能抓到广播但连接后没有数据这个问题说到底是Dongle没有正确锁定目标。Sniffer固件在没有锁定目标时会以信道轮询模式工作能抓到广播包但一旦目标设备建立连接它切换到了数据信道而Sniffer还在3个广播信道上转自然就抓不到连接数据包了。解决方案在Wireshark的“nRF Sniffer”配置里指定你要追踪的设备地址。如果目标设备是随机地址每次上电可能变化先通过广播数据里的Address字段确认地址再手动填入。或者借助“Active Device”功能选中目标设备。另一个坑是如果手机或电脑端已经和从机建立了连接你再启动Sniffer它是跟不上的因为连接参数已经交换完毕Sniffer没有听到最初的CONNECT_IND就无法同步时序。所以正确流程是启动抓包Sniffer在听广播→ 确认目标设备出现在广播中 → 再让手机发起连接 → Sniffer自动跟随。顺序反了就只能重新连一次。4.3 “No interface captured”或数据包完全不刷新这种情况多半是Dongle固件没有真正刷进去。注意Dongle有Bootloader模式和运行模式的区别运行模式下插上USB设备管理器里出现的设备名通常是“OpenDFU Bootloader”或“nRF52840 Dongle”之类的USB设备但它不是一个串口。此时nRF Connect的Programmer是能识别的但Wireshark的Sniffer接口没有注册。正确刷写步骤我再说一遍按住Dongle的复位按钮不要松手插入USB等电脑识别出Bootloader设备后再松开复位。然后在nRF Connect Programmer里选择hex文件烧录。烧录成功后会重新枚举成串口设备MAC地址前缀的设备比如Nordic Semiconductor ASA nRF52840 Dongle这时候再打开Wireshark才有接口。4.4 抓包时丢包严重 / 时序不连贯丢包排查顺序距离太远Dongle天线增益很小和设备保持在1米以内。信道冲突2.4GHz频段WiFi和蓝牙共用如果你的开发环境WiFi信道恰好挨着BLE信道会有干扰。条件允许的话关掉大功率WiFi或有线连接电脑。抓包机USB供电不足老台式机前置USB口可能电流不够试试后置USB口或带供电的Hub。Sniffer固件版本和Wireshark插件版本不匹配如果抓包时大量出现CRC错误、Unsolicited Packet之类的内容建议全部升级到Nordic官网最新版。丢包最直观的特征是Wireshark里连接事件的序号不连续。比如看到Connection Event: 10后面直接跳到Connection Event: 12中间缺的那个事件就是丢了。轻度的丢包不影响分析GATT交互但如果要做时序分析比如测量连接间隔的实际抖动建议在无干扰环境下重抓。4.5 Wireshark版本兼容问题Wireshark的更新节奏很快每隔几个月就出一个新版本。nRF Sniffer插件的更新则慢得多。实测下来Wireshark 3.6到4.0这个区间和nRF Sniffer 4.1.0以上的插件搭配比较稳定。用太新的Wireshark比如4.2配合旧版Sniffer插件可能出现“无法解析BLE协议”或者BTLE字段消失的情况。如果你已经装好了Wireshark不想为了Sniffer重装可以下载旧版的“PortableApps”版Wireshark单独解压一份专门用来跑电台抓包这样不影响日常网络抓包。5. 进阶玩法BLE抓包的更多应用场景很多人以为BLE抓包只用来排查连接问题其实它的用途远不止这些。看广播数据是最基础的应用。比如你做一个Beacon广播的产品想确认厂商自定义字段在空口里的实际字节序和封装方式用Sniffer抓一下比翻代码快多了。Wireshark里可以看到完整的AD Structure列表Event Type、AD Type、Payload一目了然还能直接对比手机端扫描到的数据。另一个高频场景是调试“配对绑定”流程。BLE配对涉及SMP层的密钥交换、确认值计算出错时从设备日志里只能看到“Pairing failed”这种笼统信息。抓包后你可以看到SMP层的命令序列确认哪一步超时、哪一步返回了错误代码甚至能看到双方的IO能力是否匹配从而定位是不是配对方式配置不一致导致的失败。还有现在的BLE Mesh、低功耗音频LE Audio、带响应的周期性广播PAwR这些新特性都依赖空口数据做调试。Sniffer固件虽然核心还是监听链路层但Wireshark插件对这些新协议的解析能力一直在增强。如果你做Mesh设备抓包能看到Subnet、TTL、Seq等网络层字段排障效率比厂商工具高不少。再往前一步你甚至可以用nRF52840 Dongle做一点“逆向”工作比如抓取某个商业设备的OTA升级流程分析它的数据传输规范和加密方式。这属于合法调试范畴还是违规操作取决于设备是否归你所有、是否用于学习自用我不展开建议但技术路线上是完全可行的——只要不涉及破解、绕过授权这类违法违规行为。对我个人而言这套东西最大的价值是它让BLE开发变得“可见”了。在没有抓包工具之前调试蓝牙协议栈的感觉就像在黑暗里走路能听到回声但看不见路。现在等于多了一个手电筒能看到每一块砖缝里的内容。无论是排查连接参数问题、GATT通信异常还是研究别人的协议设计都变得非常直观。6. 我踩过最深的坑与最后的建议如果说整个流程里最容易劝退新手的一道坎绝对是驱动和插件安装。这不是因为你笨而是Nordic的工具链对Windows环境的要求比较“娇气”Python版本不能太新、Wireshark版本不能太旧、插件路径不能放错。我见过有人在群里卡了三天最后发现只是Python装成了最新版导致extcap脚本崩溃。所以如果你卡在环境搭建这一步别怀疑硬件也别怀疑自己先对照我前面列的环境版本要求检查一遍。第二道坎是很多新手的通病在连接建立之后才打开抓包。我总是强调抓连接数据包一定要让Sniffer全程听着从广播开始到CONNECT_IND到数据交互一气呵成。漏了CONNECT_IND后面的包全都不完整。实际操作中如果发现Wireshark里只有广播没有连接数据别急着调这调那直接把设备重新复位、重新广播、重新连接再抓一轮往往就好了。第三点经验是在Wireshark里善用“导出特定包”功能。当你需要把某一小段抓包结果发给同事时不要整包导出。用显示过滤器把目标设备的通信过滤出来然后File - Export Specified Packets勾选“Selected packets only”保存成pcapng发出去。对方打开后波形干净不浪费彼此时间。最后说一下如何把这套方案的价值最大化抓包不是独立的一步工作它要和你的设备日志、手机端日志配合起来看。抓包告诉你空口发生了什么设备日志告诉你固件内部认为发生了什么两者一对照很多伪随机问题马上现原形。比如你在日志里看到应用层发了Write Request但Wireshark里根本没有对应的ATT包那说明数据在协议栈的某个缓存层被扣住了问题大概率出在固件的发送时机或缓冲区管理上而不是射频链路。有机会写后续的话我还想单独聊聊怎么用Wireshark分析“Link Layer控制过程”和“连接参数更新发起方异常”这类进阶主题。如果你已经在用这套方案干活或者刚把环境跑通欢迎分享你自己的抓包经验——尤其是那些Wireshark显示但IntelliJ不显示的细节往往才是最有意思的部分。