简介：Nordic 官方推出的蓝牙低功耗抓包器固件 nRF Sniffer for Bluetooth LE 3.1.0，面向 BLE 协议开发、嵌入式调试与无线协议分析人员，配合 Wireshark 可实时抓取并解析 BLE 广播、扫描及连接数据包。该版本相比 3.0.0 主要增加了对 nRF52840 Dongle 的支持，同时保留 nRF51/nRF52 系列开发板与 dongle 的 hex 固件，适用硬件范围更广。压缩包共 33 个文件，大小约 999KB，其中 5 个 hex 固件对应不同 Nordic 平台，19 个 py 文件组成抓包 API、SnifferCollector 与 extcap 插件，另有 PDF 接口指南、xlsx 串口协议说明、Windows/Linux 一键启动脚本及配置文件，目录结构清晰，便于快速部署和二次开发。已有 1090 人学习下载。资源附带官方英文改造教程链接与示例脚本，按说明将开发板刷入对应固件即可变身 Sniffer，特别适合需要搭建 BLE 抓包环境、分析空中报文和验证协议栈行为的开发者与学习者。 做蓝牙开发这几年，我最大的感触就是：调试BLE协议栈，手里没有一套抓包工具，很多问题真的只能靠猜。nrf_sniffer_for_bluetooth_le_3.1.0_7cc811f是Nordic官方发布的抓包器固件，它能把手头的nRF52系列开发板变成一台BLE协议分析仪，配合Wireshark就能实时看到空中的每一个蓝牙数据包。这篇文章我会从固件烧录讲到实际抓包，把整个流程里容易踩的坑一并说清楚。
适合谁看？正在做BLE外设或中心设备开发、想排查连接参数更新失败、断连异常、广播数据不对等问题的同学，这篇都值得收藏。就算你之前没接触过nRF Sniffer，跟着操作一遍也能上手。
1. 为什么要折腾一个BLE抓包器
1.1 没有抓包器，BLE调试就是盲人摸象
BLE调试和串口调试完全是两回事。串口调试时，所有数据都在你自己的代码里跑，逻辑不对看log就行。但BLE通信是无线空口传输，数据包一旦发出去，中间经过射频、协议栈状态机、对端设备处理，任何一环出问题都会导致连接异常。比如最常见的"设备连不上"、"连接几秒就断开"、"配对总是失败"这类问题，如果手里只有log，你只能看到自己这端的协议栈返回了错误码，但完全看不到对端到底回了什么包。这时候就需要抓包器在空中把数据包截下来。
nRF Sniffer固件解决的就是这个问题。它把Nordic官方开发板变成一个被动监听设备，不参与通信，只负责在BLE的三个广播信道（37/38/39）上轮询监听，把捕获到的链路层数据包通过USB串口发送到PC，Wireshark再解析成可读的协议信息。整个过程对你正在调试的两台设备完全透明，不会干扰通信，这一点在排查"玄学问题"时特别重要。
1.2 为什么选Nordic官方方案
市面上做BLE抓包的方案其实不少。有贵价的专业协议分析仪，比如Teledyne LeCroy、Frontline的设备，功能很强但价格感人，个人开发者基本不会碰。也有软件方案，比如用Android手机配合BLE嗅探app，但这类方案受限于手机射频前端，能看到的包有限，很多私有信道和底层细节看不到。Nordic官方抓包器固件的优势在于：硬件成本低（一块nRF52840 DK开发板就能用），固件和驱动都是官方维护的，配合Wireshark这个免费工具，基本就是个人开发者和小团队最合适的抓包组合。
我当时手头正好有nRF52840 DK，烧一个固件就多了一台抓包器，不用额外买设备。如果你手头是nRF52832 DK或者nRF51系列开发板，同样可以烧对应版本的固件，只是支持的蓝牙版本特性上略有差别。
这里补充一个细节：nRF Sniffer虽然名字叫sniffer，但它不是一个独立的软件，它的工作方式是把开发板的USB口模拟成一个串口设备，通过Nordic自定义的串口协议把捕获的帧封装上传。Wireshark端需要配套的解析插件才能识别这个串口协议。新版本的Wireshark（3.0以上）已经内置了Nordic BLE Sniffer的解析支持，如果你用的是比较老的Wireshark，需要手动安装Nordic提供的插件脚本。
2. 固件细节与板卡适配
2.1 3.1.0版本带来了什么
nrf_sniffer_for_bluetooth_le_3.1.0_7cc811f这个版本，从版本号和commit标识看，是Nordic在3.1.0主线上的一个正式发布版本。相比早期版本，3.1.0主要在蓝牙5.0特性的支持上做了完善。具体来说：
- 支持广播扩展（Advertising Extensions），也就是常说的次级广播通道，这是蓝牙5.0引入的重要特性。早期固件版本对扩展广播的解析不完整，3.x版本才开始稳定支持。
- 支持2M PHY和Coded PHY的抓包解析。长距离模式（Coded PHY）下数据包速率低但穿透强，工业场景用得很多。
- 对Wireshark解析插件的适配做了更新，配合新版Wireshark使用体验更流畅。
需要说明的是，具体更新内容以官方Release Note为准，我这里是根据这个版本实际表现和使用体验做的总结。如果你在项目里遇到某些蓝牙5.0特有的包解析不了，升级到3.1.0再试试，大概率能解决。
2.2 设备支持列表怎么选
固件包下载下来是一个zip压缩包，解压后里面有多个hex文件，分别对应不同的开发板。以3.1.0版本为例，主要支持：
- nRF52840 DK（PCA10056）
- nRF52840 Dongle（PCA10059）
- nRF52832 DK（PCA10040）
- nRF52810 DK
- nRF51系列DK
我个人的建议是：能选nRF52840就选nRF52840。原因很简单，nRF52840支持蓝牙5的全部特性，抓包时能看到2M PHY和Coded PHY的包，nRF52832虽然也支持蓝牙5.0的部分特性，但射频前端不支持2M PHY，抓包能力有上限。如果你手头只有nRF52832 DK，也不用纠结，日常调试1M PHY的BLE通信完全够用。
Dongle和DK的选择也值得说一句。nRF52840 Dongle体积小、价格便宜，插上电脑就是一台抓包器，功耗低，适合长期挂机抓包。DK开发板自带调试器，功能更多，但如果你专门为了抓包去买一个DK，性价比就不如Dongle了。我自己是DK和Dongle都有，日常调试用DK，需要长时间抓包的时候就换上Dongle，省一个桌面位置。
2.3 烧录前的准备工作
烧录固件本身不复杂，但准备工作做不好会出现各种奇怪问题。首先，你需要一个烧录工具。Nordic生态里有两种常用方式：一种是图形化的nRF Connect for Desktop里面的Programmer模块，另一种是命令行工具nrfjprog。
驱动程序方面，nRF52840 DK自带J-Link调试器，插上USB就能被识别。nRF52840 Dongle则需要注意：Dongle本身不带调试器，官方烧录方式是先进入DFU模式（按住reset键再插USB，或者通过引脚触发），然后用nRF Connect for Desktop的Programmer直接烧录。如果系统不识别Dongle，大概率是驱动没装好，需要检查是否有串口设备出现。
固件文件选择上，拿到hex文件后不要急着烧，先确认文件名里的板卡型号和你的开发板一致。烧错了型号虽然大概率不会损坏设备，但固件起不来，又要重新清理flash再烧，浪费时间。另外我一直坚持一个习惯：只从Nordic官网或GitHub官方仓库下载固件，不使用来路不明的hex文件。抓包器固件本身不存储敏感数据，但如果设备固件被植入恶意代码，抓到的数据就可能被偷偷转发，这种风险在调试阶段不觉得，到了量产阶段就是大问题。
3. 烧录实操：从下载到跑起来
3.1 用nRF Connect for Desktop一把梭
新手我最推荐走图形化路线。步骤很简单：
- 去Nordic官网下载nRF Connect for Desktop，安装后打开。
- 在左侧找到Programmer模块，打开它。
- 把开发板通过USB连到电脑，Programmer界面左上角会出现设备列表，选择你的设备。
- 点击"Add HEX file"，选择解压出来的对应hex固件。
- 点击"Write"按钮，等进度条走完就烧录成功了。
这里有个容易忽略的细节：如果你的开发板之前烧过其他固件，且这个固件还在运行（比如烧了某个应用固件），Programmer写入时会先自动擦除整个flash，这没问题。但如果你的芯片开启了访问端口保护（比如nRF52840的UICR里配置了access port protection），Programmer写入会失败，界面上会直接报错。解决方法是先执行"Erase all"操作，把整个flash擦干净，再写入新固件。
3.2 老司机路线：命令行+nrfjprog
命令行操作在批量烧录、CI集成场景下更高效。用nrfjprog烧录nRF Sniffer固件的命令如下：
# 烧录前先擦除整片flash（强烈建议） nrfjprog --eraseall # 写入固件（注意选择对应板卡型号的hex文件） nrfjprog --program nrf_sniffer_for_bluetooth_le_3.1.0_7cc811f_nrf52840dk.hex --verify # 复位设备 nrfjprog --reset--verify参数会在写入后自动校验flash内容，强烈建议加上。如果你电脑上同时连着多块Nordic开发板，烧录时还得加--snr参数指定设备序列号，否则nrfjprog会因为设备不唯一直接拒绝执行。烧录完成后，开发板会在USB口上枚举出一个串口设备。在Linux下通常是/dev/ttyACM0，Windows下是COMx，macOS下是/dev/tty.usbmodem*。看到这个串口设备出现，说明固件已经跑起来了。
nrfjprog工具本身是Nordic提供的命令行工具包，支持Windows/Linux/macOS三个平台。Linux和macOS下安装时需要注意权限问题，串口访问权限不够会让你在Wireshark里看到设备但打不开。解决办法是把当前用户加入dialout组（Ubuntu/Debian系），或者用chmod给串口设备加临时权限。
3.3 烧录后怎么验证固件正常工作
固件烧录成功不等于抓包器就绪，建议上电后先做个快速验证。最简单的方式是打开Wireshark，看接口列表里是否出现了Nordic的抓包接口。在Wireshark的接口列表或者捕获选项里，如果能看到一个名为"nRF Sniffer"的接口，说明驱动和固件都正常。
如果没有看到，可以从两个方向排查：一是确认串口设备枚举正常，在系统设备管理器或者ls /dev/tty*里能看到对应的串口；二是检查Wireshark是否加载了Nordic的解析插件，在Wireshark的"关于"页面看编译选项中是否启用了相关支持。新版Wireshark默认支持Nordic BLE Sniffer，所以多半是驱动或者固件烧录的问题。
另外提一个Windows下的常见坑：第一次插上开发板，系统可能把串口识别成了USB串行设备，但Wireshark就是看不到。这种情况十有八九是串口驱动被其他软件占用了，比如串口助手、IDE的调试器。关掉占用程序，重新插拔开发板基本就能解决。
4. Wireshark配合抓包：真正发挥威力
4.1 构建抓包环境
抓包器固件跑起来只是第一步，真正干活的是Wireshark。建议使用3.4以上的版本，对nRF Sniffer支持比较完善。nRF Sniffer接口依靠Wireshark的extcap机制读取串口数据，Windows下需要确保开发板的USB串口驱动正确安装，Linux下需要串口权限，macOS相对省心，一般插上就能用。
启动Wireshark后，在启动界面的捕获接口列表里找到nRF Sniffer接口，双击就能开始抓包。抓包时Wireshark会自动启用Nordic的解析逻辑，把串口协议解包成BLE链路层的帧。在Wireshark的过滤器栏输入btle就能筛选出所有BLE数据包，输入btle.advertising_address可以按广播地址过滤，这些是抓包时的基本操作。
4.2 实战抓包流程
一次完整的抓包流程大致是这样：
- 确定抓包目标。比如你要调试一个蓝牙外设的广播行为，那就只开这个设备，让它在空中广播。
- 在Wireshark里选择nRF Sniffer接口，开始抓包。
- 设备上电，触发广播，Wireshark里应该能看到周期性的ADV_IND包。
- 用手机或者中心设备去连接这个外设，观察连接建立的包交换过程。
- 停止抓包，分析数据。
这里有一个非常实用的技巧：nRF Sniffer支持射频通道追踪功能。在Wireshark的nRF Sniffer接口选项里，可以开启channel map显示，这样你能看到每个数据包是在哪个射频通道（37/38/39或者数据通道）上抓到的。排查干扰问题的时候，这个功能能帮你快速定位是不是某个信道被Wi-Fi或者其他2.4G信号占据了。
另一个技巧是结合nRF Connect APP使用。手机上的nRF Connect可以发起扫描和连接，同时触发你需要复现的行为；电脑上的Wireshark同步抓包。两边配合起来，既能知道手机端看到了什么，又能知道空口实际发生了什么，排查问题效率翻倍。
4.3 抓包数据怎么分析
拿到抓包文件后，分析的重点根据场景不同而不同。我举三个最常见的场景：
- 排查广播不到：看广播包的类型（ADV_IND/ADV_NONCONN_IND等）、广播间隔、是否携带扫描响应。如果广播包正常发出但手机搜不到，优先看广播功率和PHY。
- 排查断连问题：连接建立后会看到周期性的空包（Empty PDU），这些是保活机制。如果一段时间后握手包消失，紧接着出现LL_TERMINATE_IND，说明是双方协商断开。如果在断开前出现大量重传包，大概率是信号弱或者干扰。
- 排查连接参数更新失败：连接参数更新请求（LL_CONNECTION_UPDATE_IND）会在空中交换，抓包能看到是哪一方拒绝、拒绝原因是什么，比翻协议栈log直观得多。
Wireshark的过滤器和着色规则也有辅助作用。比如自定义规则把所有LL_TERMINATE_IND标红，这样在长时间抓包文件里快速定位所有的断连事件，效率会提高很多。我第一次排查一个半小时断一次的问题时，就是用着色规则在两万多个包里把断连点全标了出来，很快找出了是设备进入休眠导致的问题。
5. 常见问题与避坑记录
5.1 问题速查表
| 现象 | 可能原因 | 解决办法 |
|---|---|---|
| Wireshark看不到nRF Sniffer接口 | 驱动问题/固件没跑起来 | 检查串口枚举，重插设备，确认固件烧录成功 |
| 接口能看到但打开后无数据 | 串口被其他程序占用 | 关闭串口工具，重新插拔 |
| 只能看到广播包，看不到连接包 | 抓包器通道扫描太慢，漏掉了跳频 | 使用nRF Sniffer的"跟随"模式（配合中心设备） |
| Windows下烧录失败 | flash保护或驱动不匹配 | 先执行Erase all，更新J-Link驱动 |
| Wireshark显示"unknown"帧 | Wireshark版本过旧，解析插件不兼容 | 升级Wireshark到3.4+ |
| 抓包时设备连接断断续续 | 2.4G频段拥塞/位置不佳 | 调整抓包位置，使用屏蔽线连接设备 |
| Linux下无法打开串口 | 无权限访问/dev/ttyACM0 | 将用户加入dialout组 |
5.2 个人踩坑记录
最后说几个我实际遇到过的坑，这些都是文档里不一定写的。
第一个坑：nRF Sniffer抓包时，它本身也会向空中发送探测请求，用于主动扫描（主动扫描时设备会发SCAN_REQ）。在一些对扫描请求敏感的设备上，这可能会触发设备行为改变，比如设备看到扫描请求会改变广播内容。如果你发现抓到的包和实际设备行为不一致，可以尝试在Wireshark里关闭nRF Sniffer的主动扫描功能，或者确认设备是否对扫描请求有特殊逻辑。
第二个坑：长距离BLE（Coded PHY）抓包。nRF Sniffer虽然支持Coded PHY，但实际抓包时如果设备距离过远或者信号弱，很容易出现漏包。因为Coded PHY本身速率低，包在空中时间更长，抓包器在此期间不能切换到其他通道，漏掉数据信道的包很正常。这种情况下建议把抓包器放在两个通信设备的中间位置，尽量保证信号强度。
第三个坑：Wireshark的过滤器和nRF Sniffer的配合。有些网上教程里写的过滤器是老版本的，比如btle.advertising_address在新版本里可能已经改名了。遇到过滤器报错时，可以在Wireshark的协议树里右键字段，选择"作为过滤器应用"，让Wireshark自动生成正确的过滤器语法，比自己手敲可靠得多。
第四个坑：抓包文件太大导致Wireshark卡顿。长时间抓包时，如果业务流量大，文件很容易上百MB。建议抓包之前先在捕获选项里设置ring buffer（环形缓冲区），按文件大小和时间自动切割，这样既能持续抓包，又不会把内存和磁盘撑爆。
本文还有配套的精品资源，点击获取
