如果你正在调试 BLE 设备一定经历过这种时刻固件里明明写了 notify 上报手机 App 却永远等不到数据两个设备能连上但打不开服务日志里也看不出哪一步错了。遇到这种情况与其继续改代码猜问题不如把空口上的每一帧都原原本本抓下来看一眼。用 nRF52840 Dongle 配 Wireshark 抓取 BLE 数据包是我目前在项目调试中最常用的方案没有之一。这套组合便宜、即插即用能完整看到广播、连接请求、链路层握手、GATT 读写和 SMP 加密流程适合嵌入式工程师、测试工程师、在校学生以及任何想搞懂 BLE 内部到底在传什么的开发者。下面我把从硬件准备、固件烧录到第一次抓包的全过程拆开讲最后把新手最容易踩的坑也一并整理出来。1. 抓 BLE 数据包这件事为什么绕不开这套组合1.1 你写好了固件手机却什么都收不到很多做 BLE 产品的开发者第一年基本都在和看不见摸不着的问题作斗争。MCU 跑着跑着从 log 口吐出一堆调试信息但射频那边到底发生了什么单靠串口日志是看不到的。比如外设广播间隔设置不合理导致手机扫描不到或者连接参数更新流程被系统拒绝又或者 GATT 服务声明顺序不对导致iOS 端只读到部分特征值——这些问题的共同点就是问题发生在空中而不是代码里。我自己的经历是某次蓝牙耳机项目设备能连上但音频传输极其不稳定抓了半小时数据包才发现是连接事件里的 CRC 错误率飙升根因是天线走线附近有一根 I2C 时钟线干扰。如果不是抓包这种问题靠逻辑分析仪几乎没法定位。1.2 主流抓 BLE 方案的横向对比在 nRF52840 Dongle 之前圈内常用的抓包手段五花八门但各有各的别扭。抓包方案能看到什么主要限制手机 AppnRF Connect 等扫描列表、广播内容、GATT 服务/特征值看不到链路层状态机、加密过程、连接事件时序TI CC2540 USB Dongle经典 BLE 4.0 抓包不支持 BLE 5.0 的 2M PHY/Coded PHY驱动配置繁琐Ubertooth One开源自定义扩展强上手成本高软件链复杂非新手友好专业蓝牙协议分析仪Ellisys/Frontline几乎一切多信道同步价格感人动辄几万起步nRF52840 Dongle Wireshark广播、连接事件、L2CAP/ATT/GATT、SMP 加密流程单信道被动抓包无法同时抓取所有物理信道手机 App 适合快速看广播和 GATT 结构但你要想确认设备到底有没有发出连接更新请求这种链路层问题App 永远给不了答案。TI CC2540 是老前辈抓 BLE 4.0 没问题但现在的产品基本都跑 BLE 5.0CC2540 就有点跟不上了。Ubertooth 更适合无线电爱好者折腾不是调试工具的首选。专业分析仪很好但多数团队预算不批。nRF52840 Dongle 的定位恰好卡在中间官方评估板型号叫 PCA10059板载 Cortex-M4F 主控支持 Bluetooth 5、802.15.4、Thread、Zigbee、NFC-A刷上 Nordic 的 Sniffer 固件后就能通过 USB 直接给 Wireshark 喂 pcap 数据流。价格在百元级别比专业分析仪低了几个数量级。1.3 这块 Dongle 厉害在哪nRF52840 Dongle 用的是 nRF52840 SoC1MB Flash、256KB RAM射频前端覆盖全频段。作为抓包工具它最大的优势是支持 BLE 5.0 的 2M PHY 和 Coded PHY125kbps/500kbps 长距离模式这是 CC2540 做不到的。另外同一块 Dongle换个固件还能去抓 802.15.4 的 Thread/Zigbee 包相当于一个硬件干了几种分析仪的活。还有一个很关键的细节Nordic 做了完善的 Wireshark 插件extcap抓包工具链是官方维护的不是某个开发者用爱发电的玩具。这意味着 Wireshark 升级后插件会跟着适配基础字段解析也比较靠谱。我在 Linux 和 Windows 上都跑过这套方案稳定性比想象中好。2. 动手前把三件事整明白硬件、固件和 Wireshark2.1 确认你的 Dongle 没买成山寨货先说一个容易忽略的问题nRF52840 Dongle 因为市面上太火有一些仿制板或二手刷过其他固件的板子流通。正品 Dongle 在 Nordic 官方渠道或授权分销商买外壳有北欧半导体 Logo丝印清晰插上电脑后设备管理器里显示 nRF52840 Dongle同时会枚举出一个虚拟串口 COM 口。如果是二手板风险在于出厂引导程序被擦除过USB DFU 功能不可用后续刷固件会很麻烦内部晶振或射频匹配电路的元件被换过导致抓包灵敏度下降怎么验证是不是正品最简单的办法是用 nRF Connect for Desktop 的 Programmer 应用它如果能在 DFU 模式下正确识别芯片型号基本就没问题。绕过这个没问题的办法就是尽量买北美、欧洲或者国内正规代理商渠道的货。放开手在二手平台赌运气浪费的时间远比省下的钱值钱。2.2 刷 Sniffer 固件的两条路线出厂状态下nRF52840 Dongle 预装的是 Open Bootloader并不能直接抓包需要先刷入 Nordic 官方的 nRF Sniffer for Bluetooth LE 固件。推荐用图形化工具刷这也是最符合保姆级定位的路线。从 Nordic 官网下载并安装 nRF Connect for Desktop 桌面应用打开应用在Apps面板中安装两个工具Programmer 和 Bluetooth Low Energy Sniffer把 Dongle 插到电脑 USB 口尽量插 USB 2.0 口原因后面讲打开 Programmer点击Select device选择识别到的 nRF52840 Dongle从 Nordic 官网下载 nRF Sniffer for Bluetooth LE 固件压缩包zip 格式把它拖进 Programmer 界面点击Write按钮等待进度条走完整个刷写过程通常在十几秒内完成期间不要拔 USB。刷完之后 Programmer 会提示擦除或自动跳转到应用模式。如果你习惯命令行也可以装 Python 版的 nrfutil 直接烧nrfutil dfu serial -pkg nRF_Sniffer_for_Bluetooth_LE_5.1.0.zip -p COM5注意 COM5 替换成你机器上实际枚举出的串口号。这条路适合需要批量刷机或做自动化流水线的场景单次使用没必要折腾。2.3 Wireshark 安装与 Nordic 插件挂载Wireshark 建议直接装最新的 4.x 稳定版nRF Sniffer 5.1 固件要求 Wireshark 3.2 及以上4.x 兼容性反而更稳。安装时保持默认选项即可Npcap 会一并装好。装完 Wireshark 后打开 nRF Connect for Desktop 里的 Bluetooth Low Energy Sniffer 应用它会要求你选择 Wireshark 可执行文件的路径。这一步不只是告诉应用 Wireshark 在哪它会自动把 Nordic 的 extcap 插件部署到 Wireshark 的 extcap 目录里。完成这一步之后Wireshark 的接口列表里才会出现 nRF Sniffer 相关的抓包接口。如果是手动部署 extcap方法也简单从 nRF Sniffer 固件包或 GitHub 仓库中拿到对应操作系统的 extcap 插件文件放到 Wireshark 安装目录的extcap子目录下重启 Wireshark 即可。Windows 下通常会看到nRF_Sniffer_BLE.bat或类似的可执行脚本Wireshark 启动时会自动探测。2.4 Windows 驱动与接口识别的确认插上 Dongle 后Windows 一般不需要手动装驱动系统会用内置的 USB CDC ACM 驱动把它识别成一个虚拟 COM 口。如果你的机器曾经给 nRF52840 装过其他驱动比如刷过 CircuitPython 或 Adafruit UF2 引导程序可能会出现设备管理器里显示感叹号或者识别成未知 USB 设备。遇到这种情况先去设备管理器确认 Dongle 到底处于什么状态看到 Ports (COM LPT) 下的 nRF52840 Dongle 或 COM 号说明 CDC 驱动正常看到 Universal Serial Bus devices 下的 nRF52840 且没有 COM 口说明被 WinUSB/其他驱动接管了如果是后者最简单的处理是用 Zadig 工具把驱动切回 UsbSer.sysUSB Serial Device或使用 Nordic 官方提供的驱动安装包。装完重新插拔确认 COM 口出现。macOS 和 Linux 上也有对应注意事项macOS 首次插入需要到系统设置 - 隐私与安全性允许 USB 配件连接Linux 一般需要给/dev/ttyACM*配置 udev 规则或直接用 sudo 运行 Wireshark。不过接下来的实操步骤以 Windows 为主其他平台类似。3. 第一次实操从广播包一路看到 GATT 交互3.1 选择 nRF Sniffer 接口并开始抓包确认 Dongle 刷好固件、Wireshark 插件挂载完成后打开 Wireshark在主界面的接口列表里会看到一个名称类似 nRF Sniffer for Bluetooth LE 的接口可能标注了对应的 COM 口。双击这个接口Wireshark 就会开始实时抓包。这时打开你的手机、开发板或者其他任何正在广播的 BLE 设备没一会儿就能看到大量广播包涌进来。有一点需要提前了解BLE 空口有 40 个 2MHz 信道其中 37、38、39 是广播信道。Dongle 在广播阶段是在这三个信道上轮流监听而不是同时听三个信道。所以就算你的设备一直在发广播Wireshark 里也是每隔一段时间蹦出几条的节奏这是正常现象不是丢包。广播包在 Wireshark 里会标记为ADV_IND、ADV_SCAN_IND、ADV_NONCONN_IND等类型。每一种代表外设的广播模式ADV_IND可连接、可扫描的通用广播ADV_DIRECT_IND定向广播只发给特定主机ADV_NONCONN_IND不可连接的广播常用于信标ADV_SCAN_IND可扫描但不可连接的广播如果你只想看某台设备的广播最直接的过滤方法是看链路层地址btle.advertising_address aa:bb:cc:dd:ee:ff把aa:bb:cc:dd:ee:ff换成目标设备的蓝牙地址。如果你的设备地址是随机的Random Static Address这个地址在每次重启后会变需要重新识别。3.2 广播包结构拆解字段不是白给的选中一个广播包展开协议树你会看到如下结构Preamble1 字节前导码用于接收机时钟同步Access Address广播包固定为0x8E89BED6连接后变成随机值PDU Header包含 PDU 类型、发送地址类型TxAdd、接收地址类型RxAdd和长度PDU Payload广播数据CRC24 位校验广播 Payload 里最重要的其实是 Advertising Data 部分Wireshark 会帮你解出里面的 Service UUID、Local Name、Manufacturer Specific Data、Tx Power Level 等。你可以在 Packet Details 面板里看到类似 Advertisement Data 的分层展开那里就是设备的自我介绍。比如你看到一个Frame Check Sequence: Bad的标记说明这一帧的 CRC 校验不过要么是干扰要么是距离太远。偶尔出现几条可以忽略如果比例超过 10%先怀疑环境和天线。3.3 锁定目标设备并跟随连接广播看够了接下来做一次完整的连接抓包。最常用的方式是让手机当主机去连目标设备Dongle 在旁边被动监听。Wireshark 的界面上方在安装了 Nordic 插件后会出现一个 nRF Sniffer 工具栏里面有一个实时更新的设备列表显示扫描到的设备地址、RSSI、广播名称等。在这个列表里选中你要跟踪的设备通常可以通过点击对应行或点一个 Select 按钮锁定。一旦选中Sniffer 的状态会变成 Following 或者显示目标设备的 Access Address。此刻你再用手机去连接那台设备Dongle 就会在三个广播信道上守候 CONNECT_REQ 包拿到连接参数后自动切换到数据信道跟随跳频。从这一刻开始Wireshark 里看到的就不再是广播包而是完整的连接事件流。这个过程中最关键的一帧是CONNECT_REQ它里面包含了连接后的 Access Address、CRC 种子、跳频算法需要的 Channel Map 和 Hop、连接间隔、从机延迟、超时时间等参数。Dongle 就是靠解析这一帧才能后续一路跟随。如果你发现 Dongle 一直停在 Scanning 状态连接建立后 Wireshark 也没有数据流大概率是设备广播用的白名单或定向广播策略导致 CONNECT_REQ 没被 Dongle 捕获到。这时候换个普通的可连接广播方式再试。3.4 连接事件与 ATT/GATT 层解读连接建立后Wireshark 里会出现大量链路层数据包其中第一个数据包往往是一个空包Empty PDU这是主机用来同步时序的。后面的数据包则按通道、序列号SN、下一期望序列号NESN组织起确认/重传关系。在链路层之上你会看到 L2CAP、ATT、GATT、SMP 等协议层L2CAP逻辑链路控制承载上层数据CID 为 0x0004 表示 ATT 通道ATT属性协议负责读写服务属性GATT在 ATT 之上定义服务、特征值、描述符的组织规则SMP安全管理协议负责配对和密钥分发调试 GATT 问题时最常用的过滤器是btatt || btgatt这会过滤出所有 ATT/GATT 交互包。你看一次手机端读取特征值的操作就能看到 Read Request、Read Response、Write Request、Notification 等操作码配合 Handle 和 UUID几乎能把上层协议栈的每一步动作都还原出来。如果遇到设备连上后 App 卡住不动逐帧去看 ATT Write Request 和 Response 的对应关系基本能定位是主机没收到响应、句柄错误还是权限不足。这种时候抓包给出的信息量是串口日志完全比不了的。4. 常见错误排雷踩过的坑按类别整理4.1 Wireshark 接口列表里找不到 nRF Sniffer这个坑几乎所有人都遇到过原因通常有三类。第一类是 Nordic extcap 插件没有真正装成功。最常见的是直接用 Wireshark 打开但从未在 nRF Connect for Desktop 的 Sniffer 应用中指定过 Wireshark 路径extcap 文件没有部署到 Wireshark 目录。解决办法是回到 Bluetooth Low Energy Sniffer 应用重新选择 Wireshark 可执行文件让它再自动部署一次。第二类是 Wireshark 以普通权限运行读不到 USB 设备。Windows 下偶尔会出现这种问题右键 Wireshark 图标选以管理员身份运行试试。Linux 下则是 udev 权限问题给/dev/ttyACM*加上 dialout 组权限或者临时 sudo 启动 Wireshark 都能解决。第三类是 Dongle 被其他进程占用。如果你开着串口助手、nRF Connect 的 Programmer、或者任何占用了 COM 口的软件Wireshark 的 extcap 就没办法访问串口设备。关掉这些程序再刷新接口列表即可。另外提醒一下Wireshark 的接口列表需要点一下那个刷新图标或者完全重启 Wireshark 才能识别新加入的 extcap 接口有时候看起来没找到其实只是没刷新。4.2 能抓广播但抓不到连接包现象是广播包哗哗地来但用手机去连设备的时候Wireshark 里始终没出现 CONNECT_REQ更别说后续的连接事件。大部分情况是目标设备没有在自己的广播里声明我可以被连接。如果设备广播类型是ADV_NONCONN_IND或ADV_SCAN_IND主机根本不会对它发送连接请求。反过来如果设备用了定向广播ADV_DIRECT_IND只有指定的主机能连Dongle 即便听到了 CONNECT_REQ也可能因为过滤条件或者时序错过。还有一种是白名单策略。设备把主机加入白名单后才接受连接广播内容里不会直接展示这一点但抓包时表现为其他设备都能连唯独这台连不上。这种情况先看广播包里的 AdvA 和 InitA 字段CONNECT_REQ 里会明确写出发起者的地址。如果 CONNECT_REQ 确实出现在 Wireshark 里但 Dongle 没有跟随成功状态栏会显示类似 No connection found 的信息。手动刷新设备列表重新选择一次目标通常能解决。4.3 CRC 坏包过多的环境因素抓包时如果看到大量 Bad FCS 或者 CRC 错误标记先别急着怀疑 Dongle 坏了大概率是环境射频干扰或天线位置问题。我在办公区做过一次测试Dongle 插在电脑机箱后面的 USB 3.0 口上结果抓包丢包率接近 30%。原因不复杂USB 3.0 的高速数据线在 5Gbps 速率下产生的谐波会落在 2.4GHz 频段附近对 BLE 接收造成明显干扰。这个干扰是真实存在的不是你操作的问题。解决办法非常简单把 Dongle 插到 USB 2.0 接口黑色内芯的那种或者使用 USB 延长线/USB Hub让 Dongle 离 USB 3.0 接口和主板远一点抓包时把 Dongle 和目标设备放在同一个桌面上距离控制在 12 米内如果办公室 WiFi 2.4GHz 信号很多可以尝试把目标设备和 Dongle 移到相对远离 WiFi 天线的位置另外要注意手握 Dongle 的方式。nRF52840 Dongle 用的是 PCB 板载天线如果手正好握住天线附近的区域或者把它贴着金属桌面放灵敏度会有肉眼可见的下降。最好让 Dongle 保持竖直或者用支架架空。4.4 加密数据包解析不了的问题BLE 配对后链路层会启用加密Wireshark 里会出现大量无法解析上层协议的数据包只显示Encrypted Data。这不是抓包失败而是你没有给 Wireshark 提供解密所需的密钥材料。对于 LE Legacy 配对Dongle 在被动监听模式下如果抓到 SMP 配对过程Wireshark 有可能自动解密一部分数据前提是配对方式为 Just Works因为临时密钥 TK 固定为 000000。用 Passkey Entry 或 OOB 方式配对时被动 Sniffer 拿不到 TK后续数据就解不开了。对于 LE Secure Connections被动模式基本无法解密。工程上的建议是分两步走先在固件里关掉加密把协议功能跑通确认 GATT 逻辑没问题再打开加密验证安全性。这样定位问题非常高效。如果确实需要看加密后的内容可以在 Wireshark 的 Edit - Preferences - Protocols - BTLE 里找到解密相关的配置填入你知道的 LTK 或 IRK。注意不同版本 Wireshark 的配置项名称略有不同有耐心翻一翻就能找到。4.5 驱动冲突和 COM 口识别问题这块已经在 2.4 小节提过一部分。常见的现象是 Dongle 插入后设备管理器里既看不到 COM 口也看不到nRF52840 Dongle只有一行黄色感叹号。遇到这种情况先把 Dongle 拔下来换个 USB 口试一次。排除 USB 口本身问题后用 Zadig 查看 USB 设备的当前驱动如果显示的是 WinUSB你需要把它重新安装成 UsbSer.sys 或直接选择 Nordic 官方驱动。注意操作前先备份原驱动避免把系统 USB 驱动弄乱。如果 Dongle 之前被刷过其他固件比如 Adafruit 的 UF2 BootloaderWindows 可能识别成 Adafruit nRF52840 之类的名字并且只有一个 USB 磁盘而没有 COM 口。这时候需要通过按键复位进入 DFU 模式具体操作是按住 Dongle 侧面的按钮插入 USB等 1 秒后松开然后用 nRF Connect Desktop 的 Programmer 重新烧录 Sniffer 固件。4.6 BLE 5.0 的 2M PHY 与 Coded PHY 问题如果你的设备用了 BLE 5.0 的 2M PHY 或者 Coded PHY但 Dongle 刷的固件是旧版 4.x Sniffer它可能只能看到广播包连接后直接抓瞎。要用完整的 BLE 5.0 抓包能力固件必须刷到 nRF Sniffer for Bluetooth LE 5.x 及以上版本。扩展广播也要注意。BLE 5.0 的扩展广播Extended Advertising会将广播数据放在辅助广播信道AUX_ADV_IND上发送Sniffer 固件 5.x 支持这类包的解析但 Wireshark 的显示和传统广播不太一样你会看到主广播和辅助广播分在两个位置。如果只是简单过滤btle.advertising_address可能只看到主广播辅助广播的地址字段在另一个位置需要展开看。我踩过的一个坑是设备用了 Coded PHY 做长距离广播Dongle 放在 3 米外结果 Wireshark 几乎收不到包。后来把 Dongle 挪近到 1 米内才恢复正常。Coded PHY 虽然能传得更远但 Dongle 的接收灵敏度有限抓包环境还是要保证近距离。5. 让分析效率翻倍的几个习惯5.1 常用的过滤器收藏Wireshark 的显示过滤器是日常高频操作我把自己常用的几条整理在这里新手可以直接抄# 只看某个广播地址的所有包 btle.advertising_address aa:bb:cc:dd:ee:ff # 只看某个连接的包连接后使用 Access Address btle.access_address 0x12345678 # 只看 ATT/GATT 层交互 btatt || btgatt # 只看配对相关包 btsmp # 隐藏纯空包链路层空包不代表没意义但刷屏很严重 frame.len 10frame.len 10的过滤依据是一个空包在空口上大约是 1 字节前导码 4 字节 Access Address 2 字节 PDU Header 3 字节 CRC合计正好 10 字节。所以用frame.len 10可以滤掉几乎所有的纯空包。想保留空包分析连接时序时把这个条件去掉即可。过滤器不用死记字段名。看到感兴趣的字段直接在 Packet Details 面板右键选 Apply as FilterWireshark 会自动生成正确的过滤器表达式这个习惯能省不少事。5.2 解密配置怎么填Wireshark 的 BTLE 协议偏好设置里有解密相关选项一般在 Edit - Preferences - Protocols - BTLE 页面。这里能输入的信息包括临时密钥 TK原始配对密钥长期密钥 LTK身份解析密钥 IRK对于调试阶段我的建议是先用非加密模式跑通所有功能然后单独做一次配对过程抓包把 SMP 交互里的每一个包都看清楚。重点看 STK 生成、密钥分发、DHKey Check 这几个步骤确认哪一步出了问题。真正理解 SMP 流程之后你会发现很多加密兼容性问题的根因并不是加密算法本身而是参数不匹配或配对功能不支持某一种方式。5.3 RSSI 和距离的配合使用抓包过程中Wireshark 的包详情里有 RSSI 字段这是判断射频链路质量的直观指标。广播包的 RSSI 通常来自 Dongle 接收到的实际信号强度数值越小比如 -30 dBm代表信号越强-90 dBm 基本快到极限了。调 RFID 和调 BLE 的现场经验有些相通如果 RSSI 波动超过 20 dBm说明周围环境存在较强的多径效应或干扰源。这种情况下抓包数据会有间歇性丢包分析上层协议时容易误判为设备逻辑问题。5.4 顺手利用同一块 Dongle 干更多事这块 Dongle 不只能抓 BLE。Nordic 有对应 802.15.4 的 Sniffer 固件刷上去之后 Wireshark 就能抓 Thread 和 Zigbee 的包。对同时做多种无线协议产品的团队来说出差调试时只需要带一块 Dongle 就能覆盖 BLE、Thread、Zigbee 三种生态这是很划算的投入。换固件的方法和刷 Sniffer 固件完全一样用 nRF Connect for Desktop 的 Programmer选择对应固件包写入即可。唯一要注意的是同一个时间点只能在一个协议下工作不可能同时抓 BLE 和 Zigbee。这套方案我用了很长时间最大的体会是抓包这件事真正改变了调试思路。过去遇到 BLE 兼容性问题第一反应是改参数试来试去现在则是先抓包把广播、连接、加密三个阶段各抓一次很多问题的答案在 Wireshark 里是直接摆在那里的。尤其是第一次完整看到 CONNECT_REQ 里的 Access Address 和跳频参数时你会有种原来空中协议长这样的豁然开朗。最后提醒一句常识抓包只能针对你自己开发、或者有明确授权调试的设备。未经许可抓取他人的蓝牙通信涉及隐私和法律问题这一点在工程实践里需要牢牢记住。