企业官网建设流程全解析

做BLE开发，最怕的就是出问题时眼前一抹黑。代码跑得好好的，一连接就断、一配对就失败、数据明明发了对端却没收到，你手头有没有一份“空中报文”当证据？我跟很多人一样，之前遇到这类问题全是靠猜，直到入了Nordic nRF Sniffer这套工具链，才真正体会到什么叫“把蓝牙空空口的每一bit都摊开给你看”。

这篇文章的主体内容，就是围绕nRF Sniffer来写：从硬件选型、固件烧录、Wireshark配置，到加密报文的密钥导入和解密，再到我最想重点讲的LESC配对调试技巧，都会一步一步拆开讲清楚。涉及的工具和命令都是这两年在我自己项目里验证过的，不是照着文档念。无论你是刚接触BLE的嵌入式新手，还是被配对和加密报文折磨的“老油条”，这篇都值得先收藏再细看。

1. 方案选型：为什么是Nordic nRF Sniffer，而不是手机抓包或逻辑分析仪

很多新手第一次想“抓包”，第一反应是拿手机配合App去抓，或者买个十几块钱的逻辑分析仪去扒引脚。这两个路线我前期都试过，说实话，都有点“隔靴搔痒”。手机抓包只能在系统层拿到HCI日志，很多低层事件被协议栈过滤掉了，看不到空口上的广播冲突和重传细节；逻辑分析仪则只能分析UART、SPI这类有线协议，对2.4GHz无线信号完全没招。

1.1 各路线对比：手机抓包、HCI日志、专用Sniffer

先说手机抓包。Android端可以开Bluetooth HCI snoop log，iOS也有办法导日志，但这种日志本质上是蓝牙协议栈对HCI命令和事件的记录，它反映的是“主机视角”，并不是“空中视角”。比如两个设备在空口上因为干扰反复重传、连接参数更新失败、广播包被别的设备冲掉，这些信息在HCI日志里要么看不到，要么严重滞后。调试连接稳定性的时候，这种盲区非常致命。

HCI日志还有一个问题，就是它只覆盖自己设备参与的那条链路。如果产品是Central加多个Peripheral，你只能看到自己手机或者板子和外设之间的交互，外设之间发生了什么完全没有感知。这就好比你在房间里装了个摄像头，只对着自己书桌上的区域，隔壁房间打架了你根本看不到。

专用Sniffer走的路线完全不同。它把一颗支持BLE的芯片刷成嗅探固件，让芯片进入一种特殊的“监听模式”，在2.4GHz频段上专门去听空口数据包。它不需要和任何设备建立连接，完全是被动监听。所以它能捕捉到周围所有BLE广播、扫描请求、连接请求、数据包、配对交互，视角是整个空间，而不是某个设备。

1.2 硬件选择：nRF52840 Dongle、开发板、还是自制方案

Nordic官方生态里，最适合当Sniffer的硬件是nRF52840 Dongle（PCA10059），一个U盘大小的板子，上面有颗nRF52840芯片，支持蓝牙5.0（后来固件也支持5.3的包格式），USB直插，Windows/Linux/macOS通吃，烧个Sniffer固件就能用，功耗也低，插在电脑上就能当嗅探器使。

如果你手头正好有nRF52840 DK开发板，也可以刷成Sniffer用，效果一样。不过DK板子尺寸大，插在电脑边上线缆一多就容易乱，而且价格比Dongle贵不少。我的建议是，如果没有现成DK，直接买Dongle，省心。顺便提一嘴，nRF52833也可以跑Sniffer固件，但市面上不太好买成品模块，性价比不高。

自制方案其实也有，原理就是用一颗支持BLE的MCU，自己写射频监听代码，然后通过USB转串口把抓到的包发到电脑。但这件事的坑非常多，BLE的跳频同步、白化处理、CRC校验、微小时序窗口，任何一个没处理好，抓到的包就是残缺不全的。我见过有人用ESP32自己拼包，抓几个广播包可以，一连上以后就开始疯狂丢包，根本没法用。专业的事交给专业的工具，省下那个时间去调业务代码，不香吗？

1.3 软件生态梳理：nRF Connect for Desktop、Wireshark、pcap文件

硬件只是耳朵，软件才是大脑。Nordic这套Sniffer方案的软件栈分三层：

第一层是烧录工具。Nordic官方提供nRF Connect for Desktop，里面的Programmer应用可以图形化烧录hex固件，对新手非常友好。也可以用命令行工具nrfutil或者nrfjprog，适合批量生产和CI环境。

第二层是Sniffer插件。nRF Connect for Desktop里有专门的“nRF Sniffer for BLE”应用，它会加载Sniffer固件，把Dongle收到的数据包通过USB送上来，并且自动拉起Wireshark来解析和展示。

第三层是Wireshark。Wireshark本质上是一个通用的协议分析器，它内置了对BLE协议栈的解析，包括广播包、LL层、L2CAP层、ATT层、SMP层，而且支持解密。Sniffer插件会把数据包封装成pcap格式，喂给Wireshark做可视化分析。

这个方案最舒服的一点，是Wireshark本身功能足够强大，过滤表达式、着色规则、协议树、导出对象一应俱全。你抓到的信息落盘以后是一个标准pcap文件，可以发给同事，也可以保存下来做回归对比。

2. 环境搭建：从烧录固件到跑通第一次抓包

整个环境搭建过程其实非常简单，如果按照下面的流程走，从零到看到第一个包，5分钟完全够。我见过很多人在这一步卡住，多半是驱动没装对或者固件版本不匹配，下面我会把关键点都标出来。

2.1 烧录Sniffer固件：图形化烧录与命令行烧录

先准备Dongle，插到电脑USB口。Windows下第一次插上，系统可能会装错驱动，导致设备显示为一个无法识别的设备。这时候不要慌，打开nRF Connect for Desktop，进入Programmer应用，如果Dongle正常，它会出现在设备列表里。

烧录固件有两种方式：

1. 图形化方式：打开nRF Connect for Desktop -> 安装并打开Programmer -> 连接设备 -> 点击“Browse”找到Sniffer固件hex文件 -> 烧录。固件文件在Sniffer插件安装目录下，路径大概是C:\Users\你的用户名\AppData\Local\nrfconnect\apps\pc-nrfconnect-sniffer\firmware\下面，找到sniffer_nrf52840dongle_4.1.0.hex这类文件即可。

2. 命令行方式：用nrfutil刷写，适合脚本化操作。命令大致是：

nrfutil dfu usb-serial -pkg app_sniffer_pca10059.zip -p COM5

或者用nrfjprog：

nrfjprog --program sniffer_nrf52840dongle_4.1.0.hex --chiperase --reset

烧录完成后，如果Programmer里还能识别到设备，说明固件烧写成功了。这里有个小技巧，烧完Sniffer固件后，Dongle的USB设备描述符会变成“nRF Sniffer”，你可以在系统设备管理器里确认一下。

2.2 配置Wireshark并启动Sniffer插件

烧完固件以后，回到nRF Connect for Desktop，安装并打开“nRF Sniffer for BLE”插件。第一次打开会让选择设备，选中你的Dongle，然后点击“Start”按钮。插件会自动拉起Wireshark。

这里有个比较常见的坑：Wireshark没有装，或者安装了但是路径不在系统PATH里。Sniffer插件启动Wireshark是直接调用系统命令的，如果找不到Wireshark可执行文件，就会报错。解决办法很简单，重新安装Wireshark，安装时勾选“Add Wireshark to the system PATH for everyone”这个选项。

装完并启动后，你会看到Wireshark里多了一个类似“nRF Sniffer for BLE”的抓包接口，点一下“Start Capturing”或者直接按蓝色鲨鱼鳍图标，就开始实时抓包了。屏幕上跳出来的乱七八糟的广播包、扫描包会像瀑布一样往下刷。

2.3 5分钟快速抓包流程实录

这里给你一个标准的快速验证流程，确认整套工具链OK：

1. 确认Dongle已经刷入Sniffer固件，插在电脑上。

2. 打开nRF Connect for Desktop -> nRF Sniffer，Start。等Wireshark弹出并开始抓包。

3. 用手机开一个BLE广播（比如用nRF Connect手机App，里面可以创建广播），或者打开你的开发板，让它在广播状态。

4. 在Wireshark的过滤栏输入btle.advertising_address == 设备的MAC地址，过滤出目标设备的广播包。

5. 观察广播包里的AD Type字段（Flags、Complete Local Name、Tx Power等），确认抓包链路已经通了。

这个流程走完，一切正常的话，你就能看到完整的一个广播事件。注意广播地址的大小写和冒号分隔符格式，Wireshark过滤器里统一使用小写加冒号，比如aa:bb:cc:dd:ee:ff。

2.4 看懂Wireshark核心字段：ADV、SCAN_REQ、LL层与L2CAP层

刚接触Wireshark的时候，看到满屏的协议树很容易懵。这里给你快速划几个重点：

广播包（ADV）里，最常看的是Advertising Address（发送方地址）和AD Structure（广播数据）。连接请求（CONNECT_IND）是个关键包，里面包含了发起方的地址、接入地址（AA）、跳频表、CRC初始值、超时参数等信息，Sniffer成功进入连接跟踪状态，才会出现后续的LL Data包。

数据信道包（LL Data）里，最关键的是LLID字段，它区分这个包是LL Control，还是空包，还是带L2CAP数据的包。LL Control PDU是我们调试加密、连接参数更新的主战场，比如LL_ENC_REQ、LL_ENC_RSP、LL_CONN_UPDATE_REQ都在这一层。L2CAP层则是各种协议数据的承载层，ATT、SMP这些你关心的业务数据都从这里进进出出。

刚开始不用每个字段都看懂，先建立“这个包是谁发的、发给谁、里面带了什么数据”的整体概念，再往下钻细节，效率会高很多。

3. 加密报文抓包与解密

BLE的链路加密是很多开发者绕不过去的坎。Sniffer抓包最爽的地方在于，它能把加密链路建立前后的所有报文都录下来，只要你手里有密钥，就能把密文还原成明文。这一节我讲清楚底层原理和具体配置方法。

3.1 BLE链路层加密核心原理：LL_ENC_REQ、LTK、EDIV、Rand

BLE的加密发生在链路层，用的是AES-CCM加密算法。每个连接建立后，双方协商一个Session Key（由LTK加上随机数生成），然后在Link Layer对所有后续数据包加密。正常的流程是：加密之前，设备双方先完成Pairing（配对），配合出LTK（Long Term Key）；然后Central发起LL_ENC_REQ，带上两个参数——EDIV和Rand；Peripheral回复LL_ENC_RSP，确认加密启动。

这里有个容易混淆的点：LTK本身并不是通过LL_ENC_REQ明文发送的。在Legacy配对中，双方用PIN码（TK）计算出STK，然后用STK加密LTK，LTK在加密信道中传一次；在LESC配对中，LTK是双方通过ECDH P-256算法协商出来的，空口上根本不会直接传LTK。所以哪怕你抓到了全部空口报文，也拿不到LTK本身，必须从设备侧导出。

EDIV和Rand的作用是“给LTK加个临时编号”。每个连接重新加密时，EdIV和Rand会变化，接收方用它们来索引自己保存的LTK。调试的时候，这两个值在Wireshark里都能直观看到，它们也是后面配置解密密钥时的重要字段。

3.2 怎么把LTK喂给Wireshark：解密密钥配置详解

解密的第一步是拿到LTK。实际项目中，最简单的方式是在设备固件里把LTK打印出来。比如Nordic nRF Connect SDK，在配对回调里可以读到配对后的LTK信息，通过RTT或者UART打印到串口终端。拿到LTK后，我们需要把它配置给Wireshark。

在Wireshark里，点击菜单栏的Preferences（偏好设置）-> Protocols -> Bluetooth（老版本叫BTLE）-> Decryption页面，找到Decryption Keys列表，点击加号添加。不同版本的Wireshark路径可能略有差异，但关键词就是“Decryption Keys”。

添加密钥的字段格式如下：

注意几个格式细节：

第一，MAC地址的冒号分隔符必须写对，大小写不敏感，但建议统一用大写。

第二，EDIV和RAND可以通过Wireshark抓到的LL_ENC_REQ包直接复制，里面有明确的字段值。实在没有的情况下，可以填成0，只要LTK正确，Wireshark也能匹配上。

第三，LTK是16字节、128位，十六进制字符串一共32个字符。很多芯片打印LTK时是十六进制数组，中间有空格或者逗号，粘贴前记得清理干净。

配置好密钥之后，不需要重新抓包，Wireshark会基于原始pcap自动重新解析，原本显示为加密数据（Encrypted Data）的包，会变成可读的ATT或L2CAP明文。

3.3 实战：从加密连接中还原出一笔ATT Write

我举个例子，假设我手上有个nRF52840 Peripheral，和一个手机App做配对和通信。我按下面步骤操作：

1. Peripheral固件里在配对完成后，用日志打印出LTK、EDIV、RAND。

2. Dongle正在抓包，手机App发起连接并配对，之后App向Peripheral发送一个特征值写请求，内容是0x01 0x02 0x03。

3. 抓包结束后，我打开Wireshark，在Preferences里添加对端地址对应的LTK。

4. 回到主界面，原本显示的Encrypted Data字段，现在变成了可展开的Attribute Protocol层，里面能清楚看到Opcode是Write Request（0x12），Handle是0x000F，Value是01 02 03。

这个还原过程非常直观，也很有成就感。一旦解密链路通了，你就能在Wireshark里看到完整的GATT交互，配合时间戳，定位问题就是一目了然的事。

3.4 解密失败排查：密钥错误、大小端、EDIV/RAND不匹配

解密失败的常见原因，我按实际遇到频率排个序：

1. LTK抄错了。芯片打印出来的LTK是每字节一个十六进制对，如果原样拼接少了一个字符或者多了一个空格，Wireshark都不认。建议直接复制，不要手敲。

2. 大端小端搞反。BLE协议里，多字节字段默认是小端（Little Endian）先传低字节。LTK本身是按字节数组用的，但有些芯片打印时是倒序的，你得确认打印格式是不是和Wireshark一致。不确定的话，抓一次已知明文（不加密的GATT交互）来验证链路，再对比加密后的行为。

3. EDIV/RAND不匹配。如果LTK是全局唯一的，可以只填地址和LTK，但有些SDK会在每次重新配对时生成新的EDIV/RAND，旧密钥就失效了。遇到“解密后还是乱码”，优先去抓包文件里看最后一次LL_ENC_REQ的EDIV/RAND，把最新值填进去。

4. 忘记选“Decryption Enabled”。Wireshark解密功能默认不开启，必须在Preferences里勾选“Try to decrypt Bluetooth Low Energy traffic”之类的选项，才算真正启用。

4. LESC配对调试技巧：这一节直接帮你脱坑

标题里特意提到LESC，因为这是很多BLE开发者的噩梦。Legacy配对模式下逻辑比较直观，就是输入PIN码或者Just Works，配对失败最多是PIN错。到了LESC，引入了椭圆曲线密钥交换、确认值比较、DHKey Check等一堆概念，光看协议栈日志根本转不过来。

4.1 LESC和Legacy配对在空口上的本质区别

传统Legacy配对，密钥生成依赖的是PIN码（TK），TK通常只有6位数字，甚至直接为0（Just Works）。它的安全性说白了很弱，暴力猜解成本极低。LESC则改用公钥加密体制——双方各自生成一对ECDH P-256密钥对，然后把公钥明文发给对方，结合自己的私钥算出共享密钥，再派生出后续的LTK、CSRK等。

在抓包界面里，判断当前配对是哪一种很简单：看Pairing Request或Pairing Response报文中的AuthReq字段。AuthReq的第3位（bit 3）是Secure Connections标志位，置1表示支持LESC。如果双方都支持LESC，配对流程里就会出现“Pairing Public Key”包；如果只有一方支持，或者双方安全参数有一项不匹配，就会回退到Legacy。

还有一个明显区别：Legacy配对的Authentication Stage 1是用TK加密一个Confirm值，然后交换Random；LESC则是先交换公钥，再进入不同的认证方式——Numeric Comparison、Passkey Entry、Just Works或OOB。

4.2 Numeric Comparison、Passkey Entry、Just Works如何判定

很多人在代码里设置了配对方式，但实际跑起来发现和预期不一样，这就是没有搞懂LESC的“认证方式选择规则”。LESC的认证方式不是简单地由某一边说了算，而是由双方的IO Capability共同决定。

以一个实际例子说明。如果两端都支持显示和确认（比如手机屏幕 + 确认按钮），那么系统会选择Numeric Comparison：两端各生成一个6位数字，界面各自显示，用户比对一致后确认。这种模式下，抓包能看到两个关键包：Confirmation和Random，Random包里带的就是那6位数字的“佐证”。用户确认这个动作不会直接出现在空口上，但它影响后续的DHKey Check结果。

如果其中一端只有键盘输入能力，另一端有显示能力，系统会选择Passkey Entry。这里有个大坑：LESC的Passkey Entry虽然也是6位数字，但它在空口上的交互方式和Legacy完全不同，是按位（bit by bit）确认的，一次确认一个bit，20位bit总共20轮交互。这也是为什么你会看到抓包中Passkey Entry阶段的消息特别多。如果你按Legacy思路只做一次6位数字校验，配对必然失败。

如果两边有一方是NoInputNoOutput（比如一个温度传感器），那就只能用Just Works。Just Works没有用户确认环节，安全性最弱，同样可以看到公钥交换、Confirm、Random和DHKey Check，但用户界面完全无感知。

4.3 用Sniffer定位LESC配对失败的关键方法

LESC配对失败的现场，在抓包里非常“有仪式感”。流程走完公钥交换之后，会进入Confirmation和Random包的交换，然后另一方会发送DHKey Check。如果双方算出来的DHKey不一致，在空口上通常表现为一方发出DHKey Check后，另一方直接发送Pairing Failed，Reason字段一般是0x06（Confirm value failed）。

我调试过一个很典型的案例：设备端屏幕显示一个6位数字，手机上显示的是另一个，用户点确认后，两边都认为对方不对，最终配对失败。抓包看，Confirmation包都正常发出去了，DHKey Check包也没有问题，问题其实出在用户确认环节的实现——其中一端在用户没确认时就提前发送了确认消息，导致双方的认证流程不同步。

另一个高频失败原因是IO Capability配置不当。比如产品要求必须支持MITM防护，但代码里把IO Capability设成了NoInputNoOutput，这样系统直接强制使用Just Works，根本不给用户确认的机会。你在抓包里看Pairing Request的AuthReq字段，如果MITM位是0，就说明配对没有开启MITM保护，功能上就是降级了。

4.4 实测案例：DHKey Check失败到底怎么查

有一次我帮同事排查一个问题：两个nRF52840设备之间用LESC配对，其中Peripheral是手机App模拟的Central，App端一直报“配对失败”，但设备端日志没有任何异常。

我用Sniffer抓包，发现整个Pairing过程走到了Authentication Stage 2——双方都发出了DHKey Check。但Peripheral发出DHKey Check后，Central立刻回了Pairing Failed，Reason是0x06。

这个现象基本锁定了问题出在共享密钥的计算上。同样的私钥、同样的公钥，两边算出的共享密钥不应该不一致。后来进一步排查发现，问题出在Peripheral端实现LibSign算法的随机数生成器上——设备端某些环境下获取真随机数失败，导致临时私钥被复用，共享密钥被预测。换成硬件TRNG方案后，问题彻底消失。

这个案例说明，遇到DHKey Check失败，不要急着怀疑另一端“不配合”，先确认两端临时密钥是否随机、公钥交换是否被篡改、随机数是否重复，往往更能找到根因。

5. 常见问题与排查技巧实录

这个章节是纯经验分享，把我这几年用nRF Sniffer踩过的坑和常见的疑问集中梳理一下。

5.1 抓不到包、设备不识别、USB驱动问题

最常遇到的是Windows下设备识别异常。nRF52840 Dongle在主控端有一个USB CDC接口和一个USB MSC接口，第一次插上时如果系统自动装了不匹配的驱动，设备会显示为一个无法识别或者有黄色感叹号的设备。

解决方案是到设备管理器里找到对应设备，手动更新驱动，选择“从计算机的驱动程序列表中选择”，然后选“USB 串行设备”类目下的“USB Serial Device”。这招对绝大多数USB CDC设备都管用。

Linux环境下相对省心，插上就能看到/dev/ttyACMx设备。macOS也是即插即用。如果Linux下设备识别了但权限不足，需要把当前用户加入dialout组，或者是给串口设备添加udev规则。

还有一个很隐蔽的问题：Sniffer Dongle的固件版本和Wireshark解析版本不匹配。旧固件抓到的新类型包（比如BLE 5.0的扩展广播包）可能在Wireshark里解析成Error包。我建议直接把Sniffer插件更新到最新版，固件和Wireshark都保持一致。

5.2 解密失败的各种姿势和排查速查表

解密失败是最容易让人抓狂的，我把常见情况整理成一张表，对照排查效率很高：

一个非常实用的技巧：解密之前先把加密包前后的LL_ENC_REQ和LL_ENC_RSP截个图，对比一下EDIV和RAND有没有变化，如果变了，说明连接重新协商了密钥，旧的解密配置自然失效。

5.3 多连接场景下的抓包策略与过滤技巧

nRF Sniffer最明显的短板是它同一时间只能跟踪一个连接。如果你的Central设备同时连接了好几个Peripheral，抓包时必须在Sniffer插件界面里手动选择“Follow”哪一个连接。列表里会显示当前空口上所有广播和连接的信息，跟着黄色小箭头走就对了。

多连接场景下，我的做法是抓包前先确认目标的连接参数（比如连接间隔、跳频种子），然后在Wireshark里用btle.access_address过滤器过滤出特定连接的数据包。因为每个连接的接入地址（Access Address）是独立的随机数，这个过滤条件是稳定且精确的。

另外，如果多个Peripheral设备都在同一个信道上广播，广播包之间的碰撞很容易被淹没，这时候可以优先观察广播信道的时序。Wireshark里有广播事件的视图，可以快速发现信道利用率过高的异常。

5.4 性能与存储：长时间抓包的注意事项

长时间抓包（比如半小时以上）文件会变得巨大，Wireshark操作会明显卡顿。我习惯在抓包前就设定捕获过滤条件，只记录目标设备的广播和连接包。具体在Wireshark的Capture Options里设置Capture Filter，填入类似btle.advertising_address == aa:bb:cc:dd:ee:ff的表达式，无用的包直接不进缓冲区。

如果担心电脑性能不足，可以在Sniffer插件里降低上报速率，或者在Wireshark的Display Filter里临时隐藏不关心的协议层。实测发现，应对持续几百MB的抓包文件，Wireshark的响应速度主要卡在显示过滤上，抓包本身反而没那么吃性能。

6. 个人实操体会与扩展玩法

按照惯例，最后分享一点我自己的私货和扩展方向。

6.1 我实际用下来的“土办法”

抓包和解密并不是万能的，我在正式项目里总结出了几个靠谱的组合拳：

第一，Sniffer只能看到“结果”，看不到“原因”。比如一个连接突然断了，Sniffer能看到最后一个包是LL_TERMINATE_IND，但为什么断、是超时还是对方主动踢掉，还需要结合两端设备的日志来看。我现在的习惯是：Sniffer负责拿空口证据，设备日志负责拿本地状态，两边一对齐，问题基本就能水落石出。

第二，调试LESC配对时，强烈建议在设备端开启加密的调试选项。nRF Connect SDK里可以设置固定公钥或者固定LTK，这样每次配对用的密钥都是一样的，抓包分析时不用频繁重新导入密钥，调试效率翻倍。不过要明白这只是开发期用的，量产固件绝对不能带这种配置。

第三，关于“5分钟搞定”这件事的真相——工具链熟了之后，从插上Dongle到看到解密后的ATT明文，5分钟是真实可行的。前提是密钥已经拿到手上。最耗时的从来不是抓包本身，而是让设备把LTK打印出来这个过程。

6.2 相关扩展：BLE Mesh Remote Provisioning与多协议抓包

如果你做完BLE点对点调试后想更进一步，可以尝试BLE Mesh Remote Provisioning（Mesh 1.1的特性）。简单说，就是通过已经入网的一个节点，给一个新设备远程执行Provisioning流程，不需要用户跑到设备跟前去。调试这种流程，Sniffer同样有用——不过要注意，Mesh网络的报文除了链路层加密之外，还有Network Layer加密和Application Layer加密，需要配置NetKey和AppKey才能看到明文。

同一颗nRF52840 Dongle，除了刷BLE Sniffer固件，Nordic还提供了802.15.4协议（Zigbee/Thread）的Sniffer固件，想玩多协议抓包的话，备用一颗Dongle刷成802.15.4 Sniffer就能同时覆盖BLE和Thread场景，对智能家居类项目的开发非常有帮助。

6.3 最后分享一个排查小技巧

在Wireshark里准备一个“常用过滤表达式”收藏夹，会大幅提升日常调试效率。我个人的常用清单大概是：

btle.access_address btle.advertising_address btatt.opcode btl2cap.cid == 0x0004 btsmp.pairing_failed.reason

尤其是btsmp.pairing_failed.reason，一次配对失败，点开这个字段就能看到失败原因代码，协议栈日志里报的错反而没有它直接。

工具是死的，思路是活的。nRF Sniffer这套组合拳，核心价值就是让你在BLE调试中从“猜谜模式”切换到“看案卷模式”。按照本文的流程走一遍，从烧录固件到解密ATT明文，再带着LESC的认知去看空口交互，你很快会发现，以前那些玄学一样的连接失败、配对失败、数据吞包问题，其实都有明确的答案。