企业官网建设流程全解析

1. 先搞清楚一件事：为什么抓BLE必须有硬件嗅探器

做蓝牙低功耗开发的同学迟早会碰到这种时刻：协议栈上报连接已经建立，外设也说自己发了数据，但手机App端就是收不到，或者收到一堆毫无规律的数据。代码看了一遍又一遍，逻辑上找不到问题，最后只能怀疑“空中到底发生了什么”。想搞清楚这个问题，就只能把空气里的BLE包“抓”出来看。

不少人第一反应是：电脑上装个软件、开个蓝牙不就能抓了？Windows自带的蓝牙、笔记本里的蓝牙适配器，确实能用Wireshark抓HCI层的数据，但那仅仅是你这一台设备协议栈发给蓝牙控制器（Controller）的命令和事件，以及从Controller上报给Host的收发结果。它看不到其他设备之间的通信。对于两个设备之间实际收发的链路层分组，比如对方有没有重传、跳频跳到了哪个信道、空中的连接间隔实际是多少，软件抓包根本无能为力。

这就引入了捕获BLE空中包的标准做法：用一块专用的接收器，把所有在2.4GHz频段上的BLE广播和连接事件通通接收下来。最常见的方案就是Nordic的Sniffer Dongle，它本质上是一个跑着特殊嗅探固件的nRF52832或者nRF52840芯片，配合PC上的Wireshark，通过USB把捕获到的数据段实时送给Wireshark解析。

Nordic官方为这个场景提供了完整的工具链：nRF Sniffer for BLE。固件本身是一个特定的hex文件，刷进nRF52开发板或现成的USB Dongle之后，它在Wireshark里会注册成一个可用的“外部捕获接口”（extcap），Wireshark可以直接从这块设备上接收链路层数据包。

所以，环境配置这件事的核心其实就三块：硬件烧好嗅探固件、PC端驱动识别正常、Wireshark插件安装正确。而这中间任何一个环节出了问题，都会让你在抓包时遇到各种莫名其妙的状况。

这篇文章就是针对这三块，把我在多个Windows和macOS环境里配这个工具链时踩过的坑总结一遍。无论你是刚接触BLE调试的新手，还是已经在用这块Dongle但被某些报错卡住的开发者，应该都能找到对应的解决办法。

2. 硬件准备与固件烧录：这个阶段的坑大多与选型有关

2.1 nRF52832还是nRF52840，选错等于白折腾

很多人看Nordic官网文档，看到nRF52832也能做Sniffer，就直接拿手头的52832开发板开刷。实际上，“能不能”和“好不好用”是两回事。

nRF52832是一颗非常经典的BLE SoC，它本身是可以跑嗅探固件的，但注意：nRF52832只有一个射频前端，跑嗅探固件后，它同时只能监听一条广播信道或者一条已连接的数据信道。BLE广播有三个信道（37、38、39），一个正在进行的连接会在数据信道上按跳频图谱跳来跳去。nRF52832的嗅探固件对广播包的处理是逐个信道轮询，实际抓包体验是能看到广播包，但在连接事件里丢包率会比较高，因为它在跳频信道上很难跟上连接双方的跳频节奏。

nRF52840的Sniffer固件则不同。Nordic在nRF52840上实现了多个射频前端的并行监听（严格来说是时分复用加更快的跳频跟踪），单颗芯片可以同时跟踪广播和已建立连接的所有数据信道，抓连接事件的完整性比52832好得多。所以如果你打算长期做BLE调试，直接买nRF52840 Dongle，不要心疼那几十块钱差价。

这里顺便说清楚硬件形态：Nordic官方的nRF52840 Dongle是一个USB棒子形态的板子，自带一个J-Link OB调试器和一个串口桥（CDC UART）。串口桥在这个场景里不用管，但USB功能会影响整机的驱动识别和Wireshark的接口命名，后面会提到。

2.2 固件烧写：别把Keil工程和hex烧写混为一谈

拿到Dongle之后，第一步是把嗅探固件烧进去。Nordic官方提供的nRF Sniffer for BLE固件，是一个编译好的hex文件，不需要你自己打开Keil或者Segger Embedded Studio去编译。

你需要下载的是下面两个东西：

• nRF Sniffer for BLE固件包（里面包含ble_sniffer_nrf52840dongle_nrf52840_xxaa_x.x.x.hex）
• nRF Connect for Desktop，并用里面的Programmer应用来烧录

很多人会在这里踩第一脚坑：用老的nRFgo Studio或者直接拿J-Flash烧hex。不是说烧不进去，而是新版固件包里的hex文件格式和烧写工具的兼容性各有差异，用回Nordic官方推荐的Programmer最省心。

烧录步骤就是典型的嵌入式操作：

1. 把Dongle插入电脑USB口，Dongle背面的LED会亮起（通常是红色常亮，表示处于Bootloader模式或者等待程序运行）。
2. 打开nRF Connect for Desktop，进入Programmer应用。
3. Programmer会自动识别Dongle上的J-Link OB调试器。
4. 选择Browse，定位到烧录固件文件（xxx.hex）。
5. 点击Write，等待进度条走完即可。

这里有一个特别重要的细节：新版nRF52固件烧录前，最好先做一次Erase all（全片擦除）。如果Dongle之前烧过其他应用固件，比如某个基于SoftDevice的蓝牙外设例程，你不擦除全片直接写hex，会导致固件运行时出现奇怪的异常（最常见的就是USB不被识别，或者烧录成功但Wireshark里看不到接口）。这不是玄学，是因为旧固件里某些NVM配置或UICR寄存器设置会影响新固件的运行环境。全片擦除后再写入，能避开绝大多数此类问题。

还有一个容易被忽视的问题：固件包也可能自带SoftDevice，直接写hex是没问题的。但如果你手痒去选了一个带SoftDevice的烧录方式（点选Add SoftDevice），那就要注意SoftDevice的版本必须和协议栈版本匹配，否则固件起来就死在异常向量里。正常按Nordic官网的操作路径走，完全不需要手动加SoftDevice。

2.3 烧录后的驱动识别：看起来连上了但Wireshark不认

烧录完成后，Dongle重新上电，程序运行起来，它在系统里会以两个USB设备的形式出现：一个是J-Link调试器，另一个是CDC串口桥。Wireshark的extcap插件通过访问CDC串口来获取数据流。

所以，驱动层面的关键点在于：CDC串口桥是否被系统识别为一个可用的COM串口（Windows）或者cu.usbmodem设备（macOS）。

Windows下极易遇到的问题是：串口驱动装了，但设备管理器里显示的是一个带黄色感叹号的设备，因为系统压根没识别到它用的是什么USB驱动。这通常是老的CDC ACM驱动缓存导致的。处理方法：

1. 拔下Dongle。
2. 打开设备管理器，查看“端口（COM和LPT）”下是否有未知设备。
3. 卸载掉显示异常的USB复合设备或者J-Link驱动。
4. 重新插上Dongle，让系统重新枚举一次。

如果设备管理器里一直显示“无法识别USB设备”，大概率是USB供电或硬件本身的问题，可以换个USB口试试，尤其是台式机前置USB口经常因为供电不足导致这类问题。

macOS端的驱动一般不需要额外安装，插上后在/dev/tty.usbmodem*就能看到设备，但要注意权限。如果你在Wireshark的接口列表里能看到nRF Sniffer接口但无法打开（权限报错），多半是当前用户没有该串口设备的读写权限，执行一下：

sudo chmod 666 /dev/tty.usbmodem*

不过更好的办法是把当前用户加入dialout组（macOS上对应的是access_bpf组，但nRF Sniffer的串口通常对应的是staff或者dialout），这样每次插拔都不用手动改权限。

3. Wireshark端安装与插件匹配：新旧版本的坑完全不同

3.1 正确下载对应版本的Wireshark

nRF Sniffer for BLE的插件和Wireshark之间存在严格的版本对应关系。这是整个环境配置里最容易出现问题、同时最不被人意识到的地方。

举个例子：nRF Sniffer for BLE 4.0的插件包，只支持Wireshark 4.0和4.2的特定小版本，如果你装的是Wireshark 4.4，插件加载会直接失败。反过来说，如果你装的是Wireshark 3.6，那就要用nRF Sniffer for BLE 3.1.1这类的旧插件包。

这个问题在北欧半导体官方文档里写得很清楚，但架不住大家下载时追求“最新版”，顺手就装了最新的Wireshark，结果插件manager一打开就是一片红叉。

我的建议是：先决定用哪个版本的Wireshark，再下载对应的Sniffer插件包，不要盲目追新。目前比较稳妥的组合是Wireshark 4.2.x + nRF Sniffer for BLE 4.1.x，或者Wireshark 4.0.x + nRF Sniffer for BLE 4.0.x，具体以Nordic官网Sniffer下载页面的说明为准。

这个版本匹配不光影响功能，还会影响你是不是能看到正确的解析字段。比如BLE 5.0的扩展广播（Extended Advertising）只能在较新版本的插件里解析，老插件会把扩展广播当普通广播来解，导致你看到一堆不认识或错乱的信息。

3.2 extcap插件的安装路径

Wireshark的抓包接口（尤其这种外部硬件接口）是靠着“extcap”机制注册的。nRF Sniffer的安装包里包含一个nrf_sniffer_ble.bat（Windows）或nrf_sniffer_ble.sh（macOS/Linux）脚本，Wireshark在启动时会扫描特定目录下的extcap插件，并运行这些脚本来枚举可用的接口。

安装路径这个坑非常经典。很多人下载了插件包，把内容解压到了Wireshark安装目录下的extcap文件夹里，以为就完事了。实际上，现代Wireshark（3.0以后）的extcap目录并不是固定的，它首先会扫描用户配置目录下的extcap（Windows下位于%APPDATA%\Wireshark\extcap），其次才会扫描安装目录下的extcap。

最保险的做法是：

1. 在Wireshark里打开：帮助 → 关于 → 文件夹。
2. 找到“Extcap”这一栏显示的绝对路径。
3. 把整个nRF Sniffer插件目录（包括nrf_sniffer_ble.bat、nrf_sniffer_ble.py等文件）复制到这个路径下面。

这个路径在不同操作系统上不一样：

如果你把插件解压到了一个奇奇怪怪的位置，Wireshark根本不会去扫描它，接口列表里自然什么都不显示。

3.3 验证接口是否注册成功

插件放对位置后，重启Wireshark。

注意：必须完全关闭Wireshark再重新打开，光在打开的界面里刷新接口列表是不行的，因为extcap枚举只在启动时执行。

重启后在主界面点击“捕获选项”（Capture Options），或者直接看主窗口顶部的接口列表下拉框，正常情况下会看到类似下面的条目：

nRF Sniffer for BLE COMxx

如果在“接口列表”里看到这个条目，说明插件加载成功。如果看到了但接口名显示为灰色，多半是串口设备被占用（比如另一个Wireshark实例或者串口调试工具还开着），关掉占用程序再试。

如果连这个条目都没有，说明插件加载失败了。这时可以手动验证一下脚本能否运行。在Windows的cmd里，切到插件目录执行：

nrf_sniffer_ble.bat --extcap-interfaces

正常会输出类似：

extcap {version=4.1.0}{display=nRF Sniffer for BLE}

如果执行报错，通常要么是缺少Python依赖（该插件依赖Python 3.x的某些标准库，一般系统自带Python就够了），要么是路径中包含中文或者空格导致脚本解析出错。遇到后者，直接把插件目录挪到纯英文路径下，问题即可解决。

4. 实测抓包：从广播包到连接事件的完整链路

4.1 抓包的第一步：选择正确的启动方式

在Wireshark里看到nRF Sniffer for BLE接口后，双击它就能开始抓包。但这里有个操作习惯问题：如果你直接双击接口，Wireshark会默认使用“无过滤”方式把所有硬件上报的数据全收进来，数据量一大，界面会卡到让你怀疑人生。

正确的启动方式是点击接口旁边的“齿轮”图标，进入捕获选项界面。这里有几个关键的设置：

1. 接口：确认选择的是nRF Sniffer for BLE，而不是Microsoft Wi-Fi Direct Virtual Adapter之类的东西。
2. 显示过滤器：建议一开始就填上btle，这个过滤表达式只保留BLE链路层数据包，其他无关的802.11包（如果Dongle在混杂模式）会被过滤掉。
3. 自动滚动：如果希望实时观察，保留自动滚动；如果数据量大，建议取消，否则界面渲染会吃CPU。

设置好后点击“开始捕获”，Dongle上的LED状态会发生变化。

nRF52840 Dongle在嗅探固件下，每个信道都会轮流扫描一小段时间（通常每个信道停留约10ms），所以能看到37/38/39三个广播信道上的所有广播包。如果你在Wireshark主窗口看到大批量的Adv包，说明抓包链路已经通了。

4.2 广播阶段：验证设备地址和广播数据

最常见的验证方法就是看你自己的设备有没有在广播。

比如你用手机打开一个BLE调试App（nRF Connect或者LightBlue），手机本身作为一个Central在扫描和发起连接，但手机不是广播者，Dongle抓不到手机的“扫描请求”很正常，除非手机发起了连接或者扫描回复。而你的外设如果是一个BLE广播设备，它的广播包在Dongle里能直接看到。

在Wireshark里，BLE广播包的特征是：

• 源地址是广播者的设备地址（Random或Public类型）
• 包类型是ADV_IND / ADV_NONCONN_IND / ADV_SCAN_IND等
• 直接在“Bluetooth Low Energy Link Layer”这一层就能看到完整的广播数据和AdvA地址

我建议你第一件事就是确认自己的设备地址——把Wireshark里看到的AdvA地址和你代码里设置的地址、或者nRF Connect里看到的设备地址对一下，能快速验证整条链路没问题。

这里有一个值得注意的点：如果你的设备开启了随机地址（Random Address），你会看到地址每次连接不一定相同（如果是可解析随机地址，还会周期性变化）。不要慌，这很正常，不是抓包错了。

4.3 连接建立：看CONNECT_IND和Channel Map

当你用手机或另一个Central设备去连接你的外设时，空中会出现一个非常重要的包：CONNECT_IND（连接指示包）。这个包由Central发起，里面包含了连接参数的初始值——连接间隔、从机延迟、超时时间、跳频图谱、CRC初始值等。

Dongle的嗅探固件正是通过侦听这个CONNECT_IND包来初始化连接跟踪的。一旦嗅探器看到了CONNECT_IND并解密出跳频图谱，它就能跟着跳，抓后续的数据信道包。

在实际调试中，CONNECT_IND是很有用的诊断信息：

• 连接间隔是否符合预期（比如你设置7.5ms，这里就显示7.5ms）
• 跳频图谱是否包含所有37个数据信道
• CRC初始值是否正常

还有一些细节，比如如果你的设备使用白名单过滤（Whitelist），Dongle必须提前知道连接双方的地址才能正确跟跳。Nordic的插件在抓包界面上有一个“主动扫描/被动扫描”的选项，如果你发现连接后的数据包抓不全，可以尝试调整这个选项。

4.4 连接事件：跟跳成功后的数据包解析

连接建立后，Dongle会切换到跟踪已建立连接的模式（此时LED状态通常变化，可参考Nordic文档中的LED状态说明）。这时你可以在Wireshark里看到连接事件中所有数据信道包，它们会被标记为Data Channel PDU。

在连接事件里，你可以看到LL层的数据分片，以及L2CAP和更高层的ATT报文。如果你抓的是GATT操作，会看到ATT层的Read、Write、Notification等操作类型；如果连接双方有加密，ATT层的数据载荷会是加密后的密文，这时就需要配置解密密钥，后面专门讲。

这里是抓包调试的核心环节，很多调试结论都从这一步得出。比如：

• 你发现外设实际发出的Notification频率和预期不符，连接间隔被对端偷偷改了。
• 你发现某条ATT Write请求一直没收到对端响应，说明对端协议栈没有正确处理。
• 你发现数据包里有大量的重传（Retransmission）标记，说明空中信号质量或者连接参数可能有问题。

这些信号比你在代码里打断点要直观得多，因为打断点只能看到本机协议栈的行为，而抓包看到的是双方交互的真实结果。

5. 加密连接与解密配置：看不到明文时的关键一步

5.1 为什么要单独讨论加密连接

现代BLE设备出于安全考虑，绝大多数连接都会启用加密（Encryption）。Wireshark抓到的密文和密钥交换过程没有解密能力的情况下，只能看到空中的密文乱码和一堆LL_ENC_REQ、LL_ENC_RSP之类的加密协议包。

如果连接双方使用的是LE Legacy配对（Just Works或Passkey方式），并且在配对过程中使用了密钥分发（Key Distribution），那么Wireshark可以在特定的条件下解出链路层加密的密钥，从而解密后续的数据包。

但实际情况往往不是这样顺利：

• 如果配对方式是LE Secure Connections（LESC），配对过程中的长期密钥（LTK）是通过双方的ECDH密钥协商动态生成的，嗅探器无法实时解出LTK，除非你把这些密钥信息手动配置给Wireshark。
• 如果设备使用了已有的长期密钥（Bonding），没有执行新的配对过程，那么嗅探器看不到密钥协商过程，同样无法直接解密。

所以，想要在Wireshark里看到应用层的明文GATT数据，核心思路是：把你设备协议栈里已知的LTK（或者CSRK等密钥）手动填入Wireshark的密钥配置里，Wireshark才能对连接进行解密。

5.2 如何拿到LTK

获取LTK的几种常见方式：

1. 从代码里获得：如果你是自己开发的BLE设备，且使用固定密钥或存储在Flash中的长期密钥，直接读代码就能拿到LTK。
2. 从协议栈日志获得：Nordic SoftDevice在配对过程中会通过调试日志输出生成的密钥，拿到日志后可以直接提取。
3. 从Central端获得：如果你使用的是手机App，配完对后可以在系统蓝牙设置里找到设备，导出配对信息（但需要系统权限，Android和iOS的具体操作方式略有不同）。

最省事的方式其实是第一种，但实际项目中往往做不到纯固定密钥。这时你可以临时修改代码，在配对完成后通过串口把LTK打印出来，再进行抓包分析。这类临时调试手段在开发阶段是完全合法的常规操作。

5.3 Wireshark中的密钥配置位置

在Wireshark中配置BLE解密密钥，入口路径如下：

1. 编辑 → 首选项 → Protocols → 找到“BTLE”或“Bluetooth Low Energy”协议（不同版本位置略有差异）。
2. 在解密相关的选项中，找到“Decryption Keys”设置，点击“Edit...”。
3. 在弹窗中点击“New”，输入LTK（通常是16字节十六进制）。
4. 确认后，已经抓取的包需要重新打开或刷新才能应用解密。

如果你的连接双方还配置了IRK（身份解析密钥），同样可以在这里输入，Wireshark才能把可解析随机地址解析成真实身份地址。

一个容易出错的地方：Wireshark里BTLE的解密是基于连接双方的地址来做匹配的。如果你的连接使用的是随机地址，并且开启了地址解析，那这里就要特别注意，输入的密钥要和实际使用的连接绑定起来。否则Wireshark会提示解密失败或者完全不解密。

5.4 解密失败时的自查顺序

解密失败是最容易让人崩溃的环节，因为报错信息往往不明确。按照下面的顺序排查，通常能解决九成问题：

1. 确认输入的LTK字节序是否正确。BLE的密钥是多字节小端序存储的，如果你从日志里面复制的十六进制是Big-Endian展示的，需要反转字节序再填入。
2. 确认Wireshark是否识别到了正确的连接匹配。可以先用显示过滤器btle看一下连接双方地址是否和包里的地址一致。
3. 确认抓包过程中的配对事件是否完整。如果你在连接过程开始前才启动Wireshark，可能会丢失配对阶段的某些包，导致无法获取相关信息。
4. 确认是否使用了Secure Connections。如果使用了LE Secure Connections，链路层加密密钥的推导机制和Legacy不同，Wireshark不一定能从LL_ENC_REQ里直接解出，需要额外的密钥输入参数。

我自己碰到最多的其实就是字节序问题，十次有八次都是小端序没转对，导致一堆包解不开，感觉Wireshark有问题，结果是自己看错了字节顺序。

6. 抓包失败与异常现象的完整排查链路

6.1 现象A：Wireshark能看到接口，但抓不到任何包

这个现象我判断是“接口通了但硬件没数据”，排查链路如下。

第一步，检查Dongle的LED状态。如果LED常亮且没有闪烁，说明固件可能没有进入扫描状态，先检查是否烧录正确版本固件。

第二步，确认抓包通道。如果使用nRF52832 Sniffer，它的监听带宽是有限的（板载天线或者射频前端问题会导致灵敏度下降），也许换了nRF52840 Dongle问题就消失了。对于nRF52840 Dongle，如果PC的USB口供电不足（比如用了扩展坞），也会出现射频灵敏度极低、几乎抓不到包的情况。直接插主板USB口试试。

第三步，检查环境射频干扰。蓝牙工作在2.4GHz频段，和Wi-Fi的2.4G重合。如果你的办公室Wi-Fi信号很强，或者有很多电子设备在附近，信道37/38/39上的干扰会大大影响捕获成功率。此时可以把Dongle尽量靠近被测设备（距离最好在1米以内），并避免中间隔着金属物体。

第四步，检查被测设备是否真的在广播。最简单的办法是用手机上一个蓝牙调试App（nRF Connect/lightBlue）扫描看能否看到设备，如果手机都看不到，那不是抓包工具的锅，是设备端广播配置有问题。

6.2 现象B：广播包能抓到，但连接后Dongle就“丢”了

这是nRF52832时代最常见的抱怨。原因我在前面提过：nRF52832的嗅探固件是基于时分轮询的，实质上就是在37/38/39/数据信道之间快速切换。连接过程中跳频太快时，它无法保证完整跟上连接事件。

解决方案只有一个，换nRF52840 Dongle。nRF52840的嗅探固件对连接的跟随能力要好得多。

但如果你现在手头只有52832，也可以通过调整抓包方式来提高成功率：把设备双方之间的距离拉近，降低连接间隔（从7.5ms调大到15ms以上能明显提升单信道的驻留时间），以及尽量保证环境里没有强干扰源。

6.3 现象C：数据包解析出来全是LL层，看不到L2CAP和ATT

抓到包是很开心，但打开一看全是LL层空包或者LL_UNKNOWN，L2CAP和ATT协议层空荡荡的，这可能是因为抓包时未正确解密，或者抓到了某个连接但该连接未执行加密。

另一种情况是：你在抓包期间捕获到了多个设备的广播和连接（比如办公室周围有其他设备在活动），Wireshark会先把所有设备的空中包都收进来，你需要用显示过滤器锁定目标设备。一个很实用的过滤器组合：

btle && (btle.src == XX:XX:XX:XX:XX:XX || btle.dst == XX:XX:XX:XX:XX:XX)

或者用地址过滤直接看：

btatt || btl2cap || btle

如果过滤后依然全是LL层，再看一下抓包过程中是否已经出现CONNECT_IND。如果没有发现CONNECT_IND，说明你的嗅探器错过了连接建立过程，连接建立后Dongle不知道跳频图谱，自然无法解出完整连接事件。

解决方法是：重新连接一次，并且确保Dongle在Central发起连接之前已经开始监听广播信道。

6.4 现象D：Wireshark提示Python路径错误或extcap启动失败

现代Wireshark的extcap机制依赖Python 3.x，Nordic的sniffer脚本是Python写的。如果你的系统里正好装了多个Python版本（比如装了Anaconda、并发过Python 3.7和3.11），Windows的Python启动器（py）可能会把脚本引导到错误版本。

这种情况下，报错信息往往杂乱，推荐的处理方法：

1. 打开cmd，手动执行抓包脚本，看具体的报错内容。
2. 如果报错指向某个Python模块不存在，可以考虑用pip给对应的Python版本安装依赖（一般就是crcmod、构造库、pyserial等）。
3. 修改nrf_sniffer_ble.bat，让它显式指向正确的python路径：

@echo off C:\Python39\python.exe "%~dp0nrf_sniffer_ble.py" %*

这样可以绕过系统里Python版本混乱的问题。

6.5 现象E：长距离或穿墙后乱报错，但靠得近就正常

这个现象通常与抓包硬件无关，而是射频环境的问题。nRF Sniffer Dongle本身是一个接收器，它只能接收它能解调到的信号。如果信号太弱，CRC校验会频繁失败，Wireshark里的包会显示为Bad CRC或者直接丢失。

在实际调试中，把Dongle的天线端靠近被测设备（10cm到50cm是一个比较舒服的抓包距离），往往比调来调去配置参数更管用。特别是在调试一些天线尺寸很小的模块（比如智能灯、智能锁传感器）时，距离稍远一点就很难抓到完整的连接事件。

7. 几个能显著提高抓包效率的使用技巧

7.1 抓包时把Dongle放在“被动监听”模式

nRF Sniffer for BLE在Wireshark里可以配置工作模式。默认的“主动扫描（Active）”模式，嗅探器本身会发送SCAN_REQ探索广播者的扫描响应数据。这在某些场景下很有用（比如你要看设备的扫描响应包），但也会导致一些设备对你的嗅探器产生状态变化——比如某些设备会因为收到SCAN_REQ而进入某种状态，或者广播行为发生变化。

如果你只想巴适地看广播包，切到“被动模式（Passive）”，嗅探器就不发任何包，单纯接收空中的信息，对被调试设备的影响降到最低。

这个选项在Wireshark的接口配置里，名字一般叫“Scanning Mode”或类似的选项，默认是Active。

7.2 用着色规则加速定位关键包

Wireshark自带的着色规则在BLE领域的支持并不完整。如果你长期和BLE打交道，可以自定义几条着色规则：

• 所有CONNECT_IND包：红色
• ATT Write Request / Write Response：蓝色
• ATT Notification / Indication：绿色
• LL重传包：橙色

具体操作是：视图 → 着色规则，自己添加规则并指定颜色。

这样在数据量刷屏的时候，你一眼就能看到连接建立、数据交互和异常重传的位置。

7.3 导出特定连接段做离线分析

长时间抓包会生成巨大的pcapng文件。如果想让别人帮你分析问题，直接甩一个几百MB的文件过去显然不现实。

推荐做法是：用显示过滤器选中你关注的那个连接的全部数据包，然后使用“文件 → 导出特定分组”，只导出过滤后的部分。必要时再加上时间段限制，文件能缩减到几MB级别。

7.4 日志和抓包对照：定位协议栈内部问题的不二法门

纯看空中包，你只能看到最终结果，看不到设备协议栈内部的状态变化。所以我的习惯是同时打开两个视角：

• 一边用Wireshark抓空中包
• 另一边用串口抓设备协议栈日志（比如Nordic的RTT日志或者串口printf日志）

两者时间戳大致对齐后，你就能看到“协议栈说发了一个Notification”和“空中实际发出的这个Notification”之间的对应关系。解决问题的效率会翻倍。

8. 最后的经验总结：这套工具链值得花一下午配一次

如果有人问我，Wireshark + nRF Sniffer Dongle这套环境，到底值不值得花时间配？我的答案是：太值了。一旦配好，你以后调试所有BLE项目都会离不开它。

而且说到底，这套环境配置本身并不复杂，复杂的是中途遇到各种各样看起来莫名其妙的问题。归纳起来，大部分问题都集中在三个核心检查点上。

第一个是硬件层面。确认你买的是nRF52840 Dongle（或者至少是支持完整连接跟踪的版本），烧录时注意先全片擦除再写入，驱动识别正常。这一层通了，后续问题就少了一大半。

第二个是软件版本匹配。Wireshark、nRF Sniffer插件、固件三个东西的版本必须能对上。别追新，用官网写明兼容的组合。

第三个是密钥配置。加密连接的BLE调试，解密密钥配置和字节序处理是技术活，也是最能体现经验的地方。

如果你卡在某一环节过不去，可以按照本文的排查链路逐步检查，大概率能自己搞定。如果还不行，多半就是你遗漏了某个细节，比如USB供电、天线距离、或者Python版本这种看起来八竿子打不着但实际影响巨大的事情。

最后说一点亲身经验：不要等到要调试复杂的连接异常时才临时搭这套环境。平时做功能开发时，就偶尔接上Dongle顺手看看空中发生了什么。当你熟悉了“正常”的空中包长什么样，遇到“异常”时你才能一眼就看出来问题在哪。这种“网感”是调试效率的重要来源。