BLE 抓包这件事，说难不难，说简单也真能卡住人。我见过太多人买了 nRF52840 Dongle，插上电脑发现设备管理器里是个未知设备，或者 Wireshark 里根本找不到 nRF Sniffer 接口，折腾一晚上连个广播包都没抓到。这篇就把从固件烧录到 Wireshark 出包的全流程拆开讲，重点放在那些教程里通常一笔带过、但实际最容易翻车的环节。不管你是刚接触 BLE 协议栈的新手，还是想排查主从连接时序、广播间隔、连接参数协商的老手，这套组合都能给你一个成本极低但极其好用的空口观测手段。
1. 为什么选 nRF52840 Dongle 做 BLE 空口抓包
1.1 抓包方案的三条路线对比
搞 BLE 抓包，市面上能走的路其实就三条。第一条是专用协议分析仪，比如 Ellisys 或 Frontline 那类设备，功能确实强，能解到应用层甚至给出时序评分，但价格基本是五位数起步，个人开发者和小团队很难承受。第二条是用手机 App 配合 HCI 日志，比如 Android 的 btsnoop，这条路免费但只能看到本机协议栈视角的数据，空口上其他设备之间的交互完全看不到，遇到主从切换、广播冲突这类问题就抓瞎了。第三条就是 nRF52840 Dongle 刷上 Nordic 官方的 Sniffer 固件，配合 Wireshark 做空口监听。
第三条路的核心优势在于：它工作在广播/数据通道的物理层之上，能同时看到周围所有 BLE 设备的广播包和连接后的数据包，而且价格只要一百多块。对于调试 BLE 通信协议、分析连接建立时序、验证广播参数这些场景，性价比没有对手。
1.2 nRF52840 Dongle 的硬件底子
这块小 Dongle 用的是 Nordic 自家的 nRF52840 SoC，Cortex-M4F 内核，带 1MB Flash 和 256KB RAM，支持 BLE 5.0 的全部特性，包括 2Mbps 高速模式和长距离编码 PHY。做 Sniffer 的时候，它其实是在跑一个特殊的固件，把射频前端收到的 BLE 包通过 USB CDC 转发给上位机。这里有个关键点很多人不知道：Sniffer 固件本身不解析协议，它只负责把空口抓到的原始包加上时间戳和 RSSI 等信息打包上传，真正的协议解析是 Wireshark 里的 Nordic 插件完成的。所以 Wireshark 版本和插件版本必须匹配，否则会出现能抓到包但解析不出来的情况。
1.3 它能抓到什么、抓不到什么
先说能抓的：BLE 广播包（ADV_IND、ADV_NONCONN_IND、ADV_SCAN_IND 等全部类型）、扫描请求和扫描响应、连接请求、连接后的数据通道 PDU、LL 层的控制包（比如连接参数更新请求、PHY 更新请求）。这些足够你分析绝大多数 BLE 通信问题了。
抓不到的也要说清楚：加密连接建立之后的数据载荷，如果没拿到 LTK 是解不开的，Wireshark 里只能看到加密后的密文。另外它同一时刻只能跟踪一个连接，如果周围有多个 BLE 连接同时进行，你需要指定跟踪哪一个。还有一点，Sniffer 的射频是半双工的，理论上会漏包，尤其是在广播密集的环境里，所以看到丢包不要慌，先确认是不是环境太拥挤。
2. 固件烧录：从裸片到 Sniffer 的完整链路
2.1 烧录前的环境准备
nRF52840 Dongle 出厂时是不带 Sniffer 固件的，你拿到手它可能是个空白片，也可能带了个别的示例程序。烧录需要用到 Nordic 的 nRF Connect for Desktop 工具，里面有个 Programmer 应用。去 Nordic 官网下载 nRF Connect for Desktop，安装的时候会连带装上一堆依赖，建议全程保持网络畅通，因为部分组件是运行时下载的。
装好之后打开 nRF Connect，在应用列表里找到 Programmer 并安装。这时候把 Dongle 插到 USB 口上，注意尽量插在主板直出的 USB 口，不要用前面板延长线或者劣质 Hub，供电不稳会导致烧录中途失败。设备管理器里应该能看到一个名为 "nRF52840 Dongle" 的 USB 设备，如果显示未知设备，先装 nRF Connect 自带的 USB 驱动。
2.2 进入 Bootloader 模式的正确姿势
这是第一个大坑。nRF52840 Dongle 上有一个很小的白色按钮，旁边有个更小的复位孔。要进入 bootloader 模式，正确操作是：先按住白色按钮不放，然后短按一下复位孔里的复位键，再松开白色按钮。这时候 Dongle 上的 LED 会开始呼吸闪烁，表示已经进入 bootloader。
很多人失败的原因是只按了复位键，或者按按钮的时机不对。记住顺序是"按住按钮→点复位→松按钮"，不是同时按。另外，如果 Dongle 之前烧录过其他固件并且正在运行，直接插上电脑是不会进 bootloader 的，必须手动触发。
2.3 用 Programmer 烧录 Sniffer 固件
进入 bootloader 后，在 nRF Connect 的 Programmer 界面里，左上角设备选择处应该能看到 "nRF52840 Dongle" 的 bootloader 设备。点击 "Add file"，选择你下载好的 Sniffer 固件 hex 文件。这个固件在 Nordic 官网的 nRF Sniffer for Bluetooth LE 页面可以下载，注意要选对应版本的 hex，通常文件名里带 "sniffer" 和版本号。
加载文件后，Programmer 会显示固件的地址范围，确认无误后点 "Erase & write"。烧录过程大概十几秒，完成后 Dongle 会自动重启，LED 会变成常亮或者慢闪，具体取决于固件版本。这时候在设备管理器里，原来的 bootloader 设备会消失，取而代之的是一个 USB 串行设备，这就是 Sniffer 的工作接口。
注意：如果烧录过程中报错 "Could not open device" 或者进度条卡住，大概率是 USB 供电问题。换一个 USB 口重试，最好用 USB 2.0 口，部分 USB 3.0 口在 bootloader 模式下会有兼容性问题。
2.4 烧录失败的几种典型表现与排查
第一种，Programmer 里根本看不到设备。先确认 Dongle 是否真的进了 bootloader（LED 呼吸闪烁），然后检查设备管理器里有没有 "nRF USB Device" 之类的条目。如果没有，换线换口，有些 USB 线只有充电功能没有数据线。
第二种，能看到设备但烧录报错。这种情况多半是固件文件选错了，比如选了 nRF52832 的固件或者选了不对的 SoftDevice 版本。Sniffer 固件是独立完整的，不需要额外烧 SoftDevice，直接烧 hex 就行。
第三种，烧录成功但 Wireshark 里找不到接口。这通常是驱动问题，需要手动安装 Nordic 的 USB CDC 驱动，或者用 Zadig 工具把接口驱动替换成 WinUSB。这个在下一节详细说。
3. Wireshark 侧配置：让 Sniffer 接口出现在捕获列表里
3.1 Wireshark 版本与插件安装
Wireshark 本身不带 BLE 解析能力，需要装 Nordic 提供的插件。插件包在 nRF Sniffer 的下载页面里一起提供，通常是一个 exe 安装程序或者一组 lua 脚本。推荐用官方安装程序，它会自动把插件放到 Wireshark 的插件目录并注册 Sniffer 接口。
Wireshark 版本建议用 3.6 以上的稳定版，太老的版本对 BLE 5.0 的解析支持不完整。安装 Wireshark 的时候会提示安装 Npcap 驱动，这个必须装，它是底层抓包的基础。如果你之前装过 WinPcap，建议先卸载，两者会冲突。
3.2 接口不出现的排查链路
装完插件后打开 Wireshark，在捕获接口列表里应该能看到一个叫 "nRF Sniffer for Bluetooth LE" 的接口。如果没看到，按这个顺序排查：
先确认 Dongle 是否被系统识别为串口设备。打开设备管理器，在"端口"分类下应该有一个 USB 串行设备，记下它的 COM 口号。然后检查 Wireshark 插件目录里有没有 Nordic 的 lua 脚本，通常在 Wireshark 安装目录的 "extcap" 文件夹下，应该有一个 nrf_sniffer_ble.bat 或者类似的可执行文件。
如果文件都在但接口还是不出现，打开 Wireshark 的"帮助→关于 Wireshark→插件"标签页，看看 Nordic 插件有没有被加载。没有加载的话，可能是 lua 脚本的路径不对，需要手动在 Wireshark 的偏好设置里指定插件路径。
3.3 用命令行验证 Sniffer 是否工作
在正式用 Wireshark 之前，可以先在命令行里验证一下 Sniffer 固件是否正常。打开 cmd，进入 Wireshark 的 extcap 目录，运行类似这样的命令：
nrf_sniffer_ble.bat --extcap-interfaces如果返回了接口信息，说明 Sniffer 固件和驱动都正常。再运行：
nrf_sniffer_ble.bat --extcap-interface /dev/ttyACM0 --extcap-capture这个命令会开始输出抓到的包，如果能看到滚动的数据，说明整条链路是通的。Windows 下把 /dev/ttyACM0 换成对应的 COM 口，比如 COM3。
4. 抓包实操：从广播包到连接建立的全过程
4.1 选择目标设备与信道跟踪
Wireshark 里选中 nRF Sniffer 接口后，点开始捕获。这时候你会看到大量广播包涌进来，因为周围所有 BLE 设备都在广播。为了聚焦目标设备，可以在 Wireshark 的捕获过滤器里设置，或者在 Nordic 插件的配置里指定目标 MAC 地址。
Nordic Sniffer 的工作方式是：它先扫描所有广播信道（37、38、39），发现目标设备后，跟随它进入数据信道。所以如果你要抓某个特定设备的连接过程，最好在它还没连接的时候就开始抓，这样 Sniffer 能捕获到连接请求，然后自动跟踪到数据信道。
4.2 读懂广播包的关键字段
抓到的广播包在 Wireshark 里会显示为 "Bluetooth Low Energy Link Layer" 协议。展开可以看到几个关键字段：
| 字段 | 含义 | 调试价值 |
|---|---|---|
| Access Address | 接入地址 | 广播包固定为 0x8E89BED6，数据包则随机 |
| PDU Type | 包类型 | ADV_IND 是可连接广播，ADV_NONCONN_IND 是不可连接广播 |
| AdvA | 广播地址 | 发送方的 MAC 地址 |
| AdvData | 广播数据 | 包含设备名、服务 UUID、厂商数据等 |
| RSSI | 信号强度 | 判断距离和信号质量 |
广播数据里的 AD Structure 是重点，每个 AD Structure 由长度、类型、数据三部分组成。类型 0x09 是完整设备名，0x03 是完整 16 位 UUID 列表，0xFF 是厂商自定义数据。分析这些能快速判断设备类型和广播意图。
4.3 连接建立时序的抓取与分析
BLE 连接建立的过程在空口上表现为：设备 A 发 ADV_IND，设备 B（发起方）收到后发送 CONNECT_IND，里面包含接入地址、CRC 初始值、窗口大小、窗口偏移、间隔、延迟、超时等参数。Sniffer 如果抓到了 CONNECT_IND，就会自动切换到数据信道跟踪这个连接。
在 Wireshark 里，CONNECT_IND 包展开后能看到 "Connection Request" 字段，里面的 Interval 就是连接间隔，单位是 1.25ms。比如显示 24，就是 30ms。Slave Latency 是从设备可以跳过的连接事件数，Timeout 是监督超时，单位 10ms。这几个参数直接决定了连接的功耗和响应速度，调试低功耗设备时必看。
连接建立后，第一个数据包通常是 LL_FEATURE_REQ 和 LL_FEATURE_RSP，双方交换支持的特性。然后是 LL_VERSION_IND，交换协议栈版本。再往后可能看到 LL_LENGTH_REQ、LL_PHY_REQ 等控制包。这些控制包的交互顺序和内容，是判断协议栈兼容性的重要依据。
4.4 加密连接的抓包限制与应对
如果连接建立后很快进入加密流程，你会看到 LL_ENC_REQ、LL_ENC_RSP、LL_START_ENC_REQ、LL_START_ENC_RSP 这几个包。加密完成后，数据通道上的包就变成密文了，Wireshark 里显示为 "Encrypted" 或者直接是乱码。
要解密的话，需要在 Wireshark 的偏好设置里配置 LTK（长期密钥）。如果你有设备的配对信息，可以把 LTK 填进去，Wireshark 就能自动解密。但大多数情况下拿不到 LTK，这时候就只能分析加密前的控制包和加密后的包长度、时序，无法看到应用层数据。
提示：调试自己的设备时，可以在固件里临时关闭加密，或者把 LTK 打印出来，这样抓包分析会方便很多。量产固件当然不能这么干，但开发阶段无所谓。
5. 常见抓包异常与实战避坑经验
5.1 抓不到包或包很少
最常见的原因是信道没对上。BLE 广播在 37、38、39 三个信道轮询，如果 Sniffer 只停在某一个信道，就会漏掉大部分广播。Nordic Sniffer 默认是轮询的，但如果目标设备广播间隔很长（比如 1 秒以上），而 Sniffer 的扫描窗口很短，就可能错过。
解决办法是在 Nordic 插件的配置里把扫描窗口调大，或者直接用命令行模式指定信道。另外，如果周围 BLE 设备太多，Sniffer 的射频前端会饱和，导致丢包严重。这种情况下可以先用捕获过滤器缩小范围，只抓目标 MAC 的包。
5.2 包解析异常或显示为 Malformed
这通常是 Wireshark 插件版本和 Sniffer 固件版本不匹配导致的。Nordic 的 Sniffer 固件和 Wireshark 插件是配套发布的，版本号要对上。比如 Sniffer 固件是 4.1.0，插件也必须是 4.1.0。混用版本会出现字段解析错位，甚至整个包显示为 Malformed。
另一个可能是抓包过程中出现了射频错误，比如 CRC 校验失败的包。这些包在空口上是真实存在的，但内容不可靠。Wireshark 里会标记为 "CRC Incorrect"，分析时可以过滤掉。
5.3 连接跟踪丢失
Sniffer 跟踪一个连接后，如果连接参数发生更新（比如主设备发起 LL_CONNECTION_UPDATE_REQ），Sniffer 需要重新同步。如果更新过程中丢包，Sniffer 可能会跟丢，之后的包就抓不到了。这时候需要停止捕获重新开始，让 Sniffer 重新扫描并跟踪。
还有一种情况是从设备发起了连接参数更新请求，但主设备拒绝了，这时候连接参数不变，Sniffer 不会跟丢。所以看到 LL_CONNECTION_UPDATE_REQ 后要关注后面的 LL_CONNECTION_UPDATE_RSP，看是接受还是拒绝。
5.4 USB 供电与干扰问题
nRF52840 Dongle 体积小，USB 接口的供电质量直接影响射频性能。如果插在 USB Hub 上，尤其是无源 Hub，供电纹波会很大，导致抓包丢包率飙升。实测下来，直接插在电脑主板后置 USB 口上，丢包率能低一个数量级。
另外，Dongle 旁边的 USB 3.0 设备会产生宽带噪声，干扰 2.4GHz 频段。如果抓包环境里有正在读写的高速 USB 存储设备，尽量把它们挪远一点。这个干扰在抓微弱信号时特别明显。
6. 从抓包数据反推协议行为的几个实用技巧
6.1 用 IO Graph 看广播间隔和连接事件
Wireshark 的 IO Graph 功能可以把抓到的包按时间轴画出来。选中 Sniffer 接口，在统计菜单里打开 IO Graph，设置 Y 轴为包数量，X 轴为时间。如果抓的是广播包，你会看到周期性的尖峰，尖峰之间的间隔就是广播间隔。如果抓的是连接后的数据，尖峰对应连接事件，可以直观看到连接间隔是否稳定。
这个技巧在调试低功耗设备时特别有用。比如你设置了广播间隔 100ms，但 IO Graph 显示实际间隔在 80ms 到 120ms 之间跳动，说明协议栈的调度有问题，或者射频环境太差导致重传。
6.2 过滤器的实战用法
Wireshark 的显示过滤器是分析 BLE 抓包的核心工具。几个常用的：
btle.advertising_address == aa:bb:cc:dd:ee:ff只看某个设备的广播包。
btle.advertising_header.pdu_type == 0x00只看 ADV_IND 类型的广播。
btle.control_opcode == 0x00只看 LL_CONNECTION_UPDATE_REQ 控制包。
btle.data_header.length > 0只看有载荷的数据包，过滤掉空包。
把这些过滤器组合起来，可以快速定位到你关心的交互片段。比如分析连接参数更新，可以用btle.control_opcode == 0x00 || btle.control_opcode == 0x01同时看请求和响应。
6.3 导出数据做离线分析
Wireshark 抓到的包可以导出为 pcap 或 pcapng 格式，方便后续用脚本处理。比如用 Python 的 pyshark 库读取 pcap，提取所有广播包的 MAC 地址和 RSSI，做信号覆盖分析。或者提取连接事件的间隔序列，做统计分布。
导出的时候注意选择 "Displayed" 而不是 "All packets"，这样只导出当前过滤器命中的包，文件会小很多。如果抓包时间很长，pcap 文件可能几个 GB，导出前先过滤。
7. 固件烧录与抓包环境的长期维护建议
7.1 固件版本的记录与回滚
Nordic 的 Sniffer 固件更新不算频繁，但每次 Wireshark 大版本更新后，插件通常也会跟着更新。建议在本地建一个文件夹，把每次用到的固件 hex 和对应插件安装包都存好，命名带上版本号。这样以后遇到兼容性问题，可以快速回滚到之前能用的组合。
我自己的习惯是：固件用 4.1.0 配 Wireshark 3.6.x，这个组合稳定跑了很久，没出过解析问题。新版本出来先不急着升，等社区反馈稳定了再动。
7.2 多 Dongle 并行抓包的可行性
如果你需要同时抓多个连接，可以买多个 Dongle，每个刷上 Sniffer 固件，分别跟踪不同的目标设备。Wireshark 支持同时打开多个捕获接口，每个接口独立配置目标 MAC。但要注意 USB 带宽和供电，多个 Dongle 插在同一个 Hub 上可能会互相干扰。
实测下来，两个 Dongle 并行抓包是可行的，三个以上就开始出现丢包和同步问题。如果确实需要抓多个连接，建议用带独立供电的 USB Hub，并且把 Dongle 分散插在不同的 Hub 上。
7.3 抓包数据的隐私与合规
BLE 抓包会捕获周围所有设备的广播数据，其中可能包含设备 MAC 地址、设备名等信息。这些数据仅用于技术调试，不要公开分享包含他人设备信息的抓包文件。如果要在社区发帖求助，记得先把 MAC 地址做匿名化处理，Wireshark 里有 "Anonymize" 功能可以批量替换地址。
另外，抓包行为本身不涉及破解加密，只是被动监听空口广播。但如果用于分析他人设备并试图提取隐私数据，那就越界了。技术工具的使用边界，自己心里要有数。
8. 几个容易被忽略的细节补充
8.1 Dongle 的 LED 状态含义
Sniffer 固件运行时，Dongle 上的 RGB LED 会指示状态。不同版本固件的 LED 含义略有差异，但大体上是：蓝色慢闪表示正在扫描广播，绿色常亮表示已锁定目标并跟踪连接，红色闪烁表示出错。抓包时瞄一眼 LED，能快速判断 Sniffer 是否在工作状态。
8.2 Wireshark 的 extcap 路径配置
如果 Wireshark 是从 Microsoft Store 安装的，extcap 目录的路径会和普通安装不一样，Nordic 插件可能找不到。这种情况建议卸载 Store 版本，从 Wireshark 官网下载 exe 安装包重新装。Store 版本的沙箱机制会限制 extcap 程序的执行权限，导致 Sniffer 接口无法启动。
8.3 抓包时的电脑电源管理设置
Windows 的 USB 选择性暂停功能会在空闲时切断 USB 设备供电，导致 Sniffer 中途掉线。抓包前建议在电源选项里把 "USB 设置→USB 选择性暂停设置" 改为已禁用。这个设置藏得比较深，但改完之后抓包稳定性会明显提升。
8.4 关于 BLE Mesh 的抓包
如果你抓的是 BLE Mesh 设备，广播包里的数据是 Mesh 的 AD 类型，Wireshark 的 Nordic 插件能解析一部分，但 Mesh 的完整解析需要额外的解密密钥。Mesh 的 provisioning 过程抓包可以看到配网流程，但配网完成后的网络层数据需要 NetKey 和 AppKey 才能解密。这部分内容展开又是一大篇，这里先不深入。
整套流程走下来，从烧录固件到稳定抓包，顺利的话半小时能搞定，不顺利的话可能卡在驱动或版本匹配上折腾半天。我的经验是：先把固件版本和 Wireshark 插件版本对齐，再把 USB 供电和驱动搞定，最后才是抓包技巧。前面两步扎实了，后面就是水到渠成的事。
