HX Wireless BLE Sniffer v1.5.10 自动抓包完整指南

# HX Wireless BLE Sniffer v1.5.10 自动抓包完整指南

本指南适用于 HX 专用抓包硬件。无需配置内部节点、传输总线、信道或 PHY：用户只需在 Wireshark 选择目标设备并按需加入已知密钥；设备固件自动调度接收资源，完成发现、目标聚焦、跟踪、融合和去重。

> **适用版本：** Host 发布包 v1.5.10；无线节点固件 v1.5.0。

## 阅读导航

| 你现在要做什么 | 建议阅读 |
|---|---|
| 第一次使用、安装环境或确认界面 | [1. 快速开始](#quick-start) · [2. 界面与控件](#interface) · [15. 开始前检查](#limits) |
| 抓广播、连接、Mesh 或等时数据 | [4. 广播任务](#advertising) · [5. 连接任务](#connection) · [6. 密钥](#keys) · [7. EAD / Mesh](#ead-mesh) · [8. CTE / ISO](#iso) |
| 理解一包数据、检查抓包状态 | [9. 阅读数据包](#analysis) · [10. Status](#status) · [11. Read Stats](#stats) |
| 保存结果、升级或解决问题 | [12. 保存与交付](#save) · [13. 检查与安装更新](#updates) · [14. 故障排查](#troubleshooting) |
| 了解自动跟踪方式与能力边界 | [3. 自动跟踪原理](#automatic-follow) · [15. 能力边界](#limits) |

---

## 1. 五分钟快速开始

### 1.1 Windows 首次安装

1. **完整解压发布包。** 不要只把安装脚本单独拖出来。
2. 双击 `Install_HX_Wireless_BLE_Sniffer.cmd`。安装器会检测并安装 Wireshark、私有 Python 运行环境、PyUSB/libusb、HX Extcap 与 Lua 插件。
3. 连接已经烧录配套固件的 HX Wireless BLE Sniffer。Windows 首次接入时按安装器提示为接口 0 绑定 WinUSB。
4. 完全退出并重新打开 Wireshark。
5. 在欢迎页双击唯一的 **HX Wireless BLE Sniffer** 抓包入口。

### 1.2 每次抓包

1. 确认发射设备正在广播，先使用 `Device = All advertising devices`。
2. 不需要选信道：当前自动发现覆盖 LE 1M 的三个主广播信道，并按需调度辅助发现。
3. 开始抓包，观察左侧是否持续出现广播。
4. 要跟踪连接时，先在 `Device` 选中目标，再让手机或中心设备连接它。
5. 选中任意一包，在右侧展开 **HX BLE Analysis**。

### 1.3 macOS 首次安装

1. 先安装 Wireshark for macOS 和 Python 3.11 或更高版本。
2. 完整解压 `_macOS.zip`，双击 `Install_HX_Wireless_BLE_Sniffer.command`。首次运行被 Gatekeeper 阻止时，把安装包移到桌面，在 Finder 中右键安装器并选择“打开”。
3. 安装器把程序和私有运行环境安装到当前用户的 Application Support 目录，并部署 Extcap 与 Lua 插件。macOS 不使用 WinUSB/Zadig。
4. 连接设备，完整退出并重新打开 Wireshark，再选择 HX 抓包入口；使用指南可通过抓包工具栏的 `Help` 打开。

### 1.4 版本与更新

Host、无线节点和控制器固件的版本彼此独立；请以更新窗口显示的组件版本为准。检查更新本身不会开始安装。发现新版本后，更新器会先显示版本变化和 Release Notes，只有选择“立即更新”才会继续。详细操作见第 13 节。

---

## 2. 界面与所有控件

### 2.1 开始抓包前的选项

在 Wireshark 欢迎页打开 HX 接口的抓包选项。抓取加密 BIG 时建议在开始前填写 Broadcast Code，以覆盖完整同步过程；抓包期间也可在工具栏修改。内部接收资源与无线参数不暴露给客户。

| 选项 | 何时修改 | 推荐值与作用 |
|---|---|---|
| `BIG Broadcast Code` | 抓取加密 BIS | 输入 16 字节、32 个十六进制字符；未加密 BIG 留空。建议开始前填写；较晚加入不能补回此前缺失的包。 |

### 2.2 抓包中的工具栏

![Wireshark 工具栏左侧控件](https://docdisk.wireless-tech.cn/img/2026/11/02/wireshark_hx_toolbar_start_20261102010348356491.png)

*图 2a：Interface、Device、Key Type 与密钥输入区域。*

**目标与密钥**

| 控件 | 怎么用 | 注意事项 |
|---|---|---|
| `Device` | All 时自动发现广播设备；选择名称/MAC 后，全部接收资源都聚焦该目标。 | All 不跟踪连接。选中后覆盖目标的 AUX、Periodic、PAwR、PAST、ACL、CIS 与 BIS；其他设备不再占用跟踪资源。 |
| `Key Type` | 选择 Passkey、OOB、LTK、SC LTK、IRK、Mesh Key 或 EAD 资料。 | 它只说明 Key Value 的格式，不改变抓取的协议范围。 |
| `Key Value` | 输入当前 Key Type 对应的资料。 | 加入成功后字段会清空；密钥不会写入抓包文件。 |
| `IV Index` | 输入 BLE Mesh IV Index，可用十进制或 `0x` 十六进制。 | 可与 Mesh Key 一起加入，也可单独输入后按 Add Key。 |
| `Add Key` | 验证格式并把资料加入本次抓包会话。 | 查看 Status 确认成功；错误格式会明确提示。 |
| `BIG Broadcast Code` | 在抓包期间设置或更改已知的 16 字节广播码。 | 输入 32 个十六进制字符；清空输入会通知设备清除广播码。 |
| `Clear Keys` | 立即清除 Host 密钥、IV Index、设备链路密钥和 BIG Broadcast Code，并清空相关输入。 | 停止抓包或开始新会话也会清理相应资料；密钥不会写入 PCAPNG。 |

![Wireshark HX 工具栏右侧操作控件](https://docdisk.wireless-tech.cn/img/2026/11/02/wireshark_hx_toolbar_actions_20261102072419436526.png)

*图 2b：工具栏右侧控件的实际界面截图，依次为 IV、BIG Code、Add Key、Clear Keys、Status、Read Stats、Help、Reset。截图处于空闲状态，部分按钮呈不可用状态。*

**状态与常用操作**

| 控件 | 怎么用 | 注意事项 |
|---|---|---|
| `Status` | 打开自动识别、跟踪、密钥和 MIC 的事件日志。 | 协议事件通常只提示一次，避免日志刷屏。 |
| `Read Stats` | 弹出设备记录计数、内部校验/传输及目标调度统计。 | 结合 uptime、rx、crc、transport 和 gap 判断设备与数据通路状态。 |
| `Help` | 打开这份离线完整指南。 | 抓包期间可直接使用。 |
| `Reset` | 恢复 Device=All、No key，并清空输入和内部跟踪上下文。 | 连接结束后系统默认继续等待同一目标重连；只有 Reset 或手动选 All 才返回全设备发现。 |

### 2.3 包列表与右侧属性树

![HX 抓包器的实际 Wireshark 抓包界面，设备地址已隐藏](https://docdisk.wireless-tech.cn/img/2026/11/02/fb2da6f9092844c5bcea61b28b93d15d5379.png)

*图 3：HX 抓包器的实际 Wireshark 抓包截图。左侧显示 BLE 包列表，右侧展开 HX BLE Analysis；示例仅显示 CRC 有效包，设备地址已隐藏。*

---

## 3. 自动跟踪原理：为什么不需要手工切换协议

![图1](https://docdisk.wireless-tech.cn/img/2026/11/01/eac8b805194a47e1a0cc883bfbd7a4b45269.png)

*图 1：自动跟踪流程示意，展示从全设备发现、选择目标到自动调度与融合去重的过程。*

> **发现范围：** 当前 Wireshark 自动发现使用 LE 1M Primary。无线节点具备 Coded 接收及配置命令，但当前自动发现没有配置 Coded Primary；仅在 Coded Primary 发出的扩展广播不能据此保证被发现。已抓到 AuxPtr 后的辅助信道/PHY 跟随是另一项能力。

> **连接跟踪：** 必须先选中目标 Device，再让中心设备发出 `CONNECT_IND` 或 `AUX_CONNECT_REQ`。如果目标已经连上，请先断开，再重新开始一次连接。

> **最低条件：** 设备已连接、USB 访问正常（Windows 使用 WinUSB）、Wireshark 选择了 HX Wireless BLE Sniffer 接口，且发射源正在广播。客户无需选择当前使用的主广播信道。

| 自动流程 | 设备完成的工作 |
|---|---|
| 1. All 自动发现 | 自动覆盖主广播与辅助发现 |
| 2. 选择 Device | 唯一目标上下文图 |
| 3. 目标事件日历 | ACL / AUX / Periodic / ISO |
| 4. 动态角色分配 | 主跟踪 / 保护 / 恢复 |
| 5. 融合去重 | SYNC 时间基准 + 统计 |

微秒级射频动作由无线节点本地执行，设备固件维护目标上下文和事件日历，独立 USB 数据面负责 AGG1；Windows 负责选择目标、接收 PCAP 流和展示。因此短 AuxPtr、首个连接锚点和跳频不会依赖 PC 实时响应。

> **动态分配规则：** 不同的同时上下文优先使用独立接收资源；空闲资源才做冗余。只有 ACL 时分为主跟踪、提前保护、延后保护和热备恢复；ACL 与 Periodic/AUX/PAwR 并存时按下一事件重新分配。并发任务超出硬件能力会累计 scheduling conflict，不会静默丢弃。

### 3.1 自动识别

从 PDU 类型和控制字段判断 Legacy、Extended、Periodic、ACL、PAST、PAwR、Mesh、EAD 与 ISO。

### 3.2 自动跟踪

从 AuxPtr、SyncInfo、CONNECT、LL 控制过程和 BIGInfo 获取后续信道、锚点、PHY 与参数。

### 3.3 自动验证

CRC、MIC、CMAC 和密钥结果明确区分；认证失败不会被显示成可信明文。

> **Sniffer 只接收：** 正式抓包固件不会对外广播、不会接受连接、不会主动连接目标，也不会发送扫描请求或响应。连接始终发生在被测中心设备与目标设备之间。

---

## 4. 广播任务：普通、扩展、周期、PAST 与 PAwR

### 4.1 抓普通 Legacy Advertising

1. Device 保持 **All advertising devices**。
2. 开始抓包；抓包硬件已自动覆盖主广播信道。
3. 让设备发送 ADV_IND、ADV_NONCONN_IND、ADV_SCAN_IND 或 SCAN_RSP。
4. 在左侧选择广播包，右侧展开 Advertising Data 查看 Flags、名称、UUID、TX Power、Company ID 等。
5. 若没有数据，确认设备确实在广播、距离合适并查看 Read Stats。

> **成功现象：** Status 出现 `Legacy advertising detected`；包列表持续出现广播，Device 下拉框出现名称或 MAC。

### 4.2 抓 Extended Advertising 与 AUX_CHAIN

1. Device 可保持 All；抓包硬件自动发现 Primary PHY 和 `ADV_EXT_IND`。
2. 若只分析一台设备，先从 Device 选中它，全部接收资源随后只为该设备服务。
3. 抓包器读取 AuxPtr，自动转到指定辅助信道与 PHY 接收 `AUX_ADV_IND`、`AUX_CHAIN_IND`。
4. 在右侧 Link Layer、RF Channel 和 Timing 中核对 PHY、辅助信道和偏移。

> **成功现象：** Status 依次出现 `Extended Advertising detected — following AuxPtr automatically` 与 `Extended advertising auxiliary packet captured`。

### 4.3 抓 Periodic Advertising

1. 先抓到携带 SyncInfo 的扩展广播链。
2. 抓包器自动读取周期 Access Address、CRC Init、事件计数、信道图、间隔和 PHY。
3. 随后自动接收 `AUX_SYNC_IND` 与后续周期事件，无需手工输入数据信道。
4. 周期广播短时丢包时会扩大接收窗口；连续超时后进入失锁恢复并继续等待同一目标。

> **成功现象：** Status 出现 `Periodic Advertising sync established — AUX_SYNC_IND captured`，包列表可见连续事件。

> **回到扫描后界面仍可能不滚动：** 抓包器不会生成虚拟数据。原设备若仍保持连接，通常不会重新广播；此时等待设备恢复广播，或停止后重新开始抓包。

### 4.4 抓 PAST 与 PAwR

1. 先按“连接跟踪”步骤选目标并建立 ACL。
2. 保持抓包覆盖 `LL_PERIODIC_SYNC_IND` 或 `LL_PERIODIC_SYNC_WR_IND`。
3. 抓包器从 ACL 控制包读取转移的 Periodic 参数，自动切换到对应周期上下文。
4. PAwR 场景继续自动跟随 Subevent Indication 与 Response Slot，包括独立 RspAA。

> **成功现象：** Status 出现 `PAST received`、`PAwR sync transfer received`、`AUX_SYNC_SUBEVENT_IND captured` 或 response slot 提示。

> **并行调度：** PAST/PAwR 不再要求整个系统放弃 ACL。设备会把 ACL、Periodic/PAwR 和 AUX 作为不同上下文分配给可用接收资源；资源冲突会在 Read Stats 中显示。

---

## 5. 连接与链路任务

![图4](https://docdisk.wireless-tech.cn/img/2026/11/01/f88f685a9f424079bdb29c3af70667463251.png)

*图 4：Sniffer 不参与连接，只旁听连接请求并据此安排后续接收。*

### 5.1 跟踪 Legacy 或 Extended Connection

1. 先用 All 开始抓包，等待目标名称或 MAC 出现在 Device。
2. 在 **连接发生之前** 选择目标 Device。
3. 让手机、测试仪或中心设备发起连接。
4. Legacy 会从 `CONNECT_IND` 进入 ACL；Extended 会从 `AUX_CONNECT_REQ/RSP` 进入 ACL。
5. 抓包器自动处理 CSA#1/CSA#2、Connection Update、Channel Map Update、PHY Update、DLE、Subrating 与 Terminate。

> **成功现象：** Status 显示连接请求针对所选目标，并出现 `ACL follow started automatically`、`Connected BLE ACL traffic detected`。

> **没有选目标时：** All 只会显示连接请求本身，不会离开主广播扫描，也不会跟踪周边任意设备的 ACL。

### 5.2 查看 Link Layer、L2CAP、ATT、SMP 与 EATT

1. 完整抓到连接请求和后续 ACL；加密连接还要按第 6 节加入正确密钥。
2. 在右侧展开 Wireshark 标准 **Bluetooth Low Energy Link Layer**。
3. LL Control 可查看 Connection/PHY/Channel Map/DLE/Power Control/Channel Classification/Subrating 等过程。
4. L2CAP 分片会按方向和 CID 自动重组；固定 ATT 使用 CID 0x0004。
5. EATT 建立 Enhanced Credit Based bearer 后，会跟踪动态 CID，并跨 credit-based frame 重组 ATT SDU。

> **成功现象：** Status 可提示 `EATT Enhanced Credit Based bearer established`；右侧出现 L2CAP、ATT、SMP 或 EATT 字段。

### 5.3 自动解析的现代连接能力

| 能力 | 需要用户做什么 | 查看位置 |
|---|---|---|
| Connection / Channel Map / PHY Update | 从连接建立前开始抓包 | LL Control 与 HX Timing / Link Layer |
| LE 1M / 2M / Coded S=8/S=2 | 无需选择；Sniffer 从空口上下文自动跟随 PHY 与 coding scheme | PHY、Coding Scheme、包列表 PHY 列 |
| DLE 长包 | 无需额外设置 | Payload Length、L2CAP 重组 |
| LE Power Control | 无需额外设置 | LL_POWER_CONTROL_REQ/RSP、LL_POWER_CHANGE_IND |
| Channel Classification | 无需额外设置 | LL_CHANNEL_REPORTING_IND、LL_CHANNEL_STATUS_IND |
| Connection Subrating | 必须从控制过程之前持续抓包 | LL_SUBRATE_REQ/IND 与事件时序 |
| Terminate | 保持抓包直到断开 | LL_TERMINATE_IND；随后继续等待同一目标重连 |

---

## 6. 密钥、加密连接与隐私地址

> **先说结论：** Sniffer 不破解未知密钥。必须提供已经知道的密钥或完整抓到可验证的 Legacy 配对过程；只有 MIC/CMAC 通过的数据才会标为可信明文。

| 要分析什么 | Key Type | Key Value 格式 |
|---|---|---|
| 已知加密 ACL | `LE Long Term Key` / `Secure Connections LTK` | 32 个十六进制字符 |
| Legacy Passkey 配对 | `Legacy Passkey` | 6 位十进制，例如 `123456` |
| Legacy OOB / Just Works | `Legacy OOB TK` | 32 hex；Just Works 的 TK 为全 0 |
| 目标使用 RPA | `IRK / Private Address` | 32 hex；先选择当前 RPA |
| Mesh 网络层 | `Mesh NetKey` | 32 hex，并提供 IV Index |
| Mesh 应用层 | `Mesh AppKey` | 32 hex |
| Mesh 设备消息 | `Mesh DevKey` | `SRC=KEY`，例如 `0x1201=32hex` |
| Encrypted Advertising Data | `EAD Key Material` | `32hexSessionKey:16hexIV` |
| 加密 BIS | `BIG Broadcast Code` | 32 hex |

### 6.1 使用已知 LTK / SC LTK 解密 ACL

1. 先选目标 Device。
2. Key Type 选择 `LE Long Term Key` 或 `Secure Connections LTK`。
3. Key Value 输入 16 字节密钥，按 `Add Key`。
4. 最好在 `LL_ENC_REQ` 之前加入，并从连接建立前开始抓包。
5. 观察 Status 的加密建立、解密和 MIC 结果。

> **可信成功条件：** `Encrypted ACL decrypted with a RAM-only link key; MIC is valid`。仅仅看到十六进制明文候选不算成功。

### 6.2 使用 Legacy Passkey 或 OOB TK

1. 在 Pairing Request 之前输入 Passkey 或 OOB TK 并 Add Key。
2. 保持抓包覆盖双方 Pairing Confirm 与 Pairing Random。
3. Host 使用 Bluetooth c1 验证双方 Confirm；只有都通过才使用 s1 派生 STK。
4. 派生 STK 自动下发到设备 RAM，用于后续加密 ACL 的 MIC 验证。

> **Secure Connections 限制：** 显示的 Passkey 或 Numeric Comparison 数字不能让被动抓包器恢复 ECDH 派生 LTK。此时必须提供已知 SC LTK。

### 6.3 跟踪 Resolvable Private Address 轮换

1. 让目标以当前 RPA 广播，并在 Device 中选中这个地址。
2. Key Type 选择 `IRK / Private Address`，输入 32 hex IRK。
3. 按 Add Key。系统会先验证该 IRK 能否解析当前所选 RPA；验证失败不会绑定。
4. 绑定成功后，后续出现同一身份的新 RPA 会继续作为目标。

> **成功现象：** Status 显示 IRK 已绑定当前地址，并提示未来匹配的 RPA 保持定向。

> **密钥生命周期：** LTK、STK、IRK、EAD、NetKey、AppKey、DevKey 与 Broadcast Code 只保存在当前进程或设备 RAM。Clear Keys、停止抓包或开始新会话会清理相应资料。

---

## 7. EAD 与 BLE Mesh

### 7.1 解析 Encrypted Advertising Data（EAD）

1. Key Type 选择 `EAD Key Material (SessionKey:IV)`。
2. 输入 `32hexSessionKey:16hexIV`，例如 `0011…EEFF:0102030405060708`。
3. 按 Add Key，然后抓包含 AD Type 0x31 的广播。
4. Host 使用 5-byte Randomizer、8-byte IV、AAD 0xEA 和 4-byte MIC 做 AES-CCM 认证。
5. 选中包，展开 **HX Encrypted Advertising Data** 查看认证、Randomizer、明文 AD Structures 与内部类型。

> **成功现象：** `Encrypted Advertising Data authenticated and decrypted`，且 `hxead.authenticated == 1`。

没有资料或 MIC 失败时，EAD 仍以 `Raw Data Length` 和 `Raw Data` 显示，不会伪造字段含义。

### 7.2 抓 BLE Mesh Advertising Bearer

1. Device 保持 All；设备自动覆盖主广播信道，Wireshark 不需要配置信道或 PHY。
2. 只看公开 Bearer 时无需密钥，可识别 AD Type 0x29、0x2A、0x2B、PB-ADV 与 Beacon。
3. 解密网络层：选择 Mesh NetKey，输入 32 hex；填写 IV Index；按 Add Key。
4. 解密应用层：再添加 Mesh AppKey。
5. 解密使用设备密钥的消息：选择 Mesh DevKey，输入 `0x源地址=32hex`。
6. 分段 Access、乱序与重复片段会自动重组；在右侧展开 **HX BLE Mesh Decryption**。

> **成功现象：** 可见 Network Decrypted、Access Decrypted、SRC、DST、TTL、SEQ、Opcode 与 Parameters；Secure Network Beacon 只有 CMAC 正确才算认证通过。

> **常见原因：** 只有 NetKey 没有 IV Index，网络层无法开始；只有 NetKey 没有 AppKey/DevKey，可能只能看到 Network Decrypted，无法看到 Access 明文。

---

## 8. CTE、CIS、BIS、BIG 与 ISOAL

### 8.1 查看 CTE PDU 与 CTEInfo

1. 按连接任务抓到带 CTE 的 ACL；无需额外开关。
2. 在 Wireshark 中展开 Link Layer，检查 CTEInfo、CTE 类型、时长和相关空口字段。
3. 可用 `hxble` 及标准 Bluetooth LE 过滤字段定位相应 PDU。
4. 当前无线硬件不输出原始 I/Q 采样值，因此不会出现 **HX CTE IQ Samples** 记录。

> **硬件边界：** 当前版本支持抓取 CTE PDU/CTEInfo，不支持原始 IQ Sampling，也不能据此执行 AoA/AoD 测角。

### 8.2 跟踪 CIS 与重组 ISOAL

1. 先选目标并从 ACL 建立之前开始抓包。
2. 保持抓包覆盖 CIS 建立相关 LL 控制过程；加密 ACL 时先加入正确 LTK。
3. 抓包器从 ACL 上下文建立 CIS 调度，按方向跟踪 Payload Number。
4. Wireshark 将 CIS 标成正确的 BTLE RF CIS 方向，不再当作普通 ACL。
5. 跨多个 CIS PDU 的 framed ISOAL SDU 会自动重组。

> **成功现象：** 包列表出现 CIS 数据，右侧可见 CIS 方向；完整 SDU 在重组完成后出现。

### 8.3 跟踪 BIG / BIS 与加密广播音频

1. 先按 Periodic Advertising 步骤建立周期同步并抓到 BIGInfo。
2. 未加密 BIG 无需密钥；加密 BIG 建议在开始前填写 BIG Broadcast Code；抓包期间也可通过工具栏加入或修改。
3. 抓包器从 BIGInfo 派生 BIS Access Address、CRC Init、信道、锚点及 BN/NSE/IRC/PTO。
4. 自动识别预传输、重传与重复 Payload Number；BIG Control 的 Channel Map/Terminate 只有 MIC 通过后才应用。
5. Wireshark 将 BIS 标成 BTLE RF BIS；framed ISOAL 按 BIS 流重组 SDU。

> **成功现象：** 可见 BIGInfo、一个或多个 BIS、MIC valid、BIG Control 与 ISOAL SDU。错误 Broadcast Code 只会得到 MIC failure，不会输出可信音频明文。

> **单上下文限制：** 当前一块抓包器一次跟踪一个 ACL/CIS 或一个 BIG/Periodic 上下文，不能同时跟踪多个独立连接与多个 BIG。

---

## 9. 像协议分析仪一样阅读每个包

### 9.1 先看左侧八个关键列

| 列         | 回答的问题           | 例子                            |
|---|---|---|
| Packet     | 这是什么包？         | ADV_IND、AUX_ADV、ACL、CIS、BIS |
| Status     | 接收与认证是否可靠？ | CRC valid、MIC valid / failed   |
| Start Time | 包从什么时候开始？   | 相对抓包开始时间                |
| Delta      | 与上一包间隔多少？   | 检查 T_IFS、连接间隔、周期间隔  |
| Length     | 空口或负载长度多少？ | 识别 DLE 长包、广播数据大小     |
| Channel    | 在哪个 BLE 信道？    | 37/38/39 或 0–36 数据信道       |
| PHY        | 使用哪个 PHY？       | LE 1M、LE 2M、Coded S=8/S=2     |
| RSSI       | 接收信号多强？       | -45 dBm 通常强于 -90 dBm        |

### 9.2 再展开右侧 HX BLE Analysis

| 分组 | 主要字段 | 用途 |
|---|---|---|
| 顶部概览 | Item、Operation / Interpretation、Communication、Payload Summary、Status | 先快速知道包是什么、在做什么、谁发给谁及结果 |
| Communication Details | Originator、Transmitter、Receiver、地址类型 | 识别通信双方与角色 |
| Protocol Layers | PDU 类型、长度、Advertising Data | 查看 HX 提供的分层语义摘要 |
| Integrity | CRC、MIC、接收质量 | 判断包校验和认证状态 |
| Capture Context | Channel、PHY、RSSI、时序、Access Address | 查看本次接收的射频与时间上下文 |

这是借鉴 Ellisys Overview 的事件概览方式，不是逐字段解码器。展开同一包下的 Wireshark 原生 **Bluetooth Low Energy Link Layer**，可查看原生协议字段和对应字节位置；不确定的厂商私有载荷仍需厂商协议规格。

### 9.3 无法可靠解析时的 Raw Data 规则

全局 Packet Bytes 窗格默认隐藏，但未解析的局部内容不会消失。以下数据会在所属解析项显示准确的 `Raw Data Length` 与十六进制 `Raw Data`：

- Manufacturer Specific Data 中 Company ID 之后的厂商私有载荷；
- Service Data 中已解析 UUID 之后的私有载荷；
- 没有正确密钥的 EAD；
- 未知 AD Type 或暂未支持的字段。

```text
Manufacturer Specific Data
  Company Identifier: 0x1234
  Raw Data Length: 15
  Raw Data: 01 35 36 30 31 31 43 45 32 46 41 32 33 37 32
```

已解析的 Company ID 或 Service UUID 不会在 Raw Data 中重复。没有厂商协议规格时，工具不会猜测剩余字节含义。

### 9.4 常用显示过滤器

| 目的 | 过滤器 |
|---|---|
| 只看 HX 已分析的 BLE 包 | `hxble` |
| 只看信道 37 | `hxble.channel == 37` |
| 只看扩展辅助包 | `hxble.pdu_type contains "AUX"` |
| 只看 CIS/BIS | `hxble.pdu_type contains "CIS" \|\| hxble.pdu_type contains "BIS"` |
| 只看有未解析局部数据的包 | `hxble.raw_data` |
| 只看已认证 EAD | `hxead.authenticated == 1` |
| 只看已解密 Mesh 网络包 | `hxmesh.network_decrypted == 1` |
| 只看 ATT 或 L2CAP | `btatt \|\| btl2cap` |

---

## 10. 如何阅读 Status

`Status` 是当前抓包会话的事件日志。`HX:` 表示正常信息；`ERROR:` 表示输入无效、缺少资料、认证失败或数据通路异常。大多数协议事件只提示一次，因此没有重复日志不代表后续数据没有继续抓取。

### 10.1 启动摘要

```text
Device=All: automatic primary and auxiliary discovery is active
Focused on C0:DE:09:50:00:01: capture resources now follow this device's ACL, AUX, periodic, PAwR and ISO event contexts
```

以上分别示例自动发现和选中目标后的提示。`Device=All` 表示只发现广播；`Focused on` 后的地址表示当前跟踪目标。当前状态不会用单一 `Primary Ch` 代表所有接收资源；密钥加入或校验结果通过各自的事件提示确认。

### 10.2 协议与安全术语

| 术语 / 消息 | 是什么意思 | 用户下一步 |
|---|---|---|
| `Device found` | 发现 CRC 正确的广播设备并加入 Device | 要跟踪连接时先选中它 |
| `Legacy advertising` | 收到普通广播 | 右侧查看 Advertising Data |
| `Extended Advertising / AuxPtr` | 收到扩展主包并安排辅助接收 | 等待 AUX_ADV/AUX_CHAIN |
| `Periodic Advertising sync` | 已经建立周期同步 | 查看 AUX_SYNC_IND 连续性 |
| `CONNECT_IND / AUX_CONNECT_REQ` | 收到传统/扩展连接请求 | 只有目标匹配才进入 ACL |
| `ACL` | 收到连接数据信道包 | 展开 LL、L2CAP、ATT、SMP |
| `PAST` | ACL 转移了周期同步信息 | 预期从 ACL 切换到 Periodic |
| `PAwR` | 周期广播包含 Subevent 与响应时隙 | 检查 Indication/Response 是否成对 |
| `Pairing / LL_ENC_REQ/RSP` | 发现配对或加密建立 | 确认密钥已在关键过程前加入 |
| `MIC valid` | 密钥和计数匹配，明文可信 | 可以继续分析上层 |
| `MIC failure` | 密钥、计数或抓包起点不匹配 | 核对密钥并从连接前重抓 |
| `EATT bearer established` | 动态 L2CAP 信道已建立 | 查看动态 CID 上的 ATT |
| `PB-ADV / Mesh Beacon / Network PDU` | Mesh 配网、Beacon 或网络包 | 按需加入 Net/App/DevKey 与 IV |
| `EAD authenticated` | EAD MIC 通过并得到内部 AD | 展开 HX EAD 字段 |
| `CIS / BIS / BIG / ISOAL` | 连接型或广播型等时流及重组 | 加密 BIG 核对 Broadcast Code |

### 10.3 典型序列

```text
HX: Device found: Sensor (C0:DE:09:50:00:01)
HX: CONNECT_IND captured for C0:DE:09:50:00:01 — ACL follow started automatically
HX: Connected BLE ACL traffic detected
HX: BLE link-layer encryption setup detected (LL_ENC_REQ/RSP)
HX: Encrypted ACL decrypted with a RAM-only link key; MIC is valid
```

```text
HX: PAST received — following the transferred periodic sync
HX: Periodic Advertising sync established — AUX_SYNC_IND captured
```

---

## 11. Read Stats 字段

点击 `Read Stats` 会弹出统计窗口，并把相同内容写入 Status：

```text
device uptime=453.3s sync=10ms | rx=17629 crc=0 transport=0 gap=0 | mode=All contexts=0x00 roleChanges=4 conflicts=0 dedup=0 recoveries=0
```

| 字段 | 含义 | 健康判断 |
|---|---|---|
| `uptime / sync` | 设备运行时间和公共同步周期 | uptime 持续增加表示主控仍在运行 |
| `rx` | 设备累计收到的记录数 | 活动广播存在时应持续增加 |
| `crc / transport / gap` | 内部校验、传输错误和序号缺口 | 稳定抓取时应为 0 |
| `mode / contexts` | All/Focus 和当前上下文位图 | 选择 Device 后 mode 应变为 Focus |
| `roleChanges` | 动态角色重分配次数 | 上下文变化时增加是正常现象 |
| `conflicts` | 并发任务超出可用接收资源的冲突累计 | 应尽量为 0；非零必须结合空口负载评估 |
| `dedup` | 冗余接收资源重复抓到并被固件去重的记录 | 非零说明冗余生效，不代表丢包 |
| `recoveries` | 分配热备/恢复角色的次数 | 频繁增加时检查信号、时钟和事件窗口 |

这些统计是设备记录、内部数据通路与调度计数，当前窗口不显示射频接收尝试次数、射频 CRC 成功率或 Ring 占用率。`rx` 不是全部空口包数，`crc` 是内部帧校验错误数；不能据此计算空口丢包率。

> **界面暂时不滚动，但 Read Stats 有响应且 uptime 持续增加：** 设备与控制通路仍在工作。结合目标是否仍广播、当前 mode/contexts 以及 rx 的变化判断，不能仅凭 rx 不变认定设备停止。

> **crc、transport 或 gap 持续增加：** 内部校验、传输或记录连续性存在异常；检查电源、USB 连接和主机负载，并保留前后统计。conflicts 增加表示并发调度受限，需要结合目标业务评估缺口。

---

## 12. 保存、过滤与交付抓包

1. 完成后点击 Wireshark 停止按钮，等待接口释放。
2. 使用 **File → Save As** 保存为 PCAPNG；PCAPNG 保留射频伪头、时间戳、方向和注释。
3. 用第 9.4 节过滤器缩小范围；需要交付全部证据时保存未裁剪原始文件，再另存过滤后的副本。
4. 同时记录目标地址、开始时间、是否添加 LTK/Broadcast Code，以及 Status/Read Stats 摘要；客户无需记录内部资源、信道或 PHY 配置。
5. 分享前确认业务载荷是否包含隐私数据。密钥本身不会写入 PCAPNG，但成功解密的明文可能属于敏感内容。

> **建议命名：** `产品_场景_信道_PHY_日期时间.pcapng`，例如 `Sensor_Periodic_Ch37_2M_20260917_1430.pcapng`。

---

## 13. 检查与安装更新

![Wireshark HX 接口选项中的 Updates 标签](https://docdisk.wireless-tech.cn/img/2026/11/02/exec-2ab1ddd6-b698-426d-a275-0033b6c59a9c_20261102071853645714.png)

*图 5：Updates 标签入口。点击后可查看更新状态和打开更新器。当前检查结果显示 Host/Lua 与无线固件均为 1.5.11，高于更新源版本，因此阻止降级；本次没有可安装的新版。*

更新器会在打开 Wireshark 或刷新接口列表、发现 HX 接口时，检查已配置的签名更新源。发现更新时，会显示组件、当前版本、目标版本及可用的 Release Notes；选择“稍后”不会安装，选择“立即更新”后才会下载和处理。

### 13.1 手动检查

1. 在 Wireshark 欢迎页找到 HX Wireless BLE Sniffer，打开接口选项。
2. 在 `Updates` 分组查看 `Update Status`；点击状态旁的刷新按钮（Reload）可重新检查。
3. 若更新窗口已关闭，在同一分组选择 `Install Updates` / `Open update window`，重新查看说明并确认。

### 13.2 安装与重启

1. 阅读组件版本变化和更新说明后再确认。更新器会验证签名清单和下载文件。
2. 涉及设备固件时，先停止抓包并等待设备释放；升级期间保持 USB 连接和供电，等待完成提示，不要拔线或关闭设备。
3. 更新器读取设备实际版本，只升级确认需要更新的无线节点；Host/Lua 文件在设备更新后安装。版本无法读取时会阻止相应固件更新，不会猜测或盲目烧录。
4. Host/Lua 更新后，完全退出并重新打开 Wireshark。
5. 如果窗口提示下载完整客户包，按提示打开下载位置，完整解压 ZIP 并运行对应系统的安装器，再重启 Wireshark。

### 13.3 Host/Lua 更新示例

下图示例显示 Wireshark 插件/Lua 从 1.5.10 更新到 1.5.11。点击“是”后，更新器会自动下载、校验并安装；请先停止抓包，并保持 USB 和供电连接。

![Host/Lua 更新提示（1.5.10 → 1.5.11）](https://docdisk.wireless-tech.cn/img/2026/11/02/766e8cdff6bd4d99bf6d19cc2dc37c947109.png)

下图示例显示更新完成后的 host 1.5.11。按提示重新打开 Wireshark 后，Host/Lua 更新才会生效。

![Host 更新完成提示（host 1.5.11）](https://docdisk.wireless-tech.cn/img/2026/11/02/ea4e425a820d494fb44f578f3dcc83972277.png)

### 13.4 检查或安装失败

确认电脑能访问更新源、设备已连接且抓包已停止，再从 `Updates` 刷新状态。保留窗口中的完整错误提示；若签名、下载或版本读取错误仍持续，请联系 HX 技术支持，不要自行选择固件文件。

---

## 14. 故障排查：按现象一步一步检查

### 14.1 Wireshark 看不到 HX Wireless BLE Sniffer

1. 确认设备已供电且 USB 可以被系统识别；Windows 查看设备管理器并检查 WinUSB，macOS 查看系统信息中的 USB 设备。
2. 完全退出 Wireshark，包括后台抓包进程，再重新打开。
3. 重新运行对应平台的安装脚本；客户无需填写 COM 口。
4. 仍然没有时，重新插拔设备并检查 USB 数据线。

### 14.2 能够开始抓包，但一包都没有

1. Device 先设为 All；确认设备已正常上电并且 Read Stats 可读。
2. 确认发射设备当前确实广播，而不是已经保持连接；当前自动发现覆盖 LE 1M Primary，尚未配置 Coded Primary。
3. 检查 Read Stats 中 rx 是否变化；扩展广播只有先抓到 AuxPtr，才会安排辅助信道和 PHY 跟随。
4. 若 uptime 增加但 rx 不变，检查发射源、天线、距离和配套固件；rx 不变本身不能证明设备停止。
5. 若 Read Stats 也无响应，检查 USB 访问及是否有其他抓包/升级进程占用设备。

### 14.3 能看到广播或连接请求，但没有后续 ACL

1. 确认连接前已经从 Device 选中正确目标；All 不跟踪 ACL。
2. 目标如果已经连接，先断开再重新连接。
3. 确认抓包覆盖完整 CONNECT_IND 或 AUX_CONNECT_REQ/RSP。
4. 扩展连接查看 Status 是否抓到 ADV_EXT_IND、AuxPtr 与 AUX_CONNECT_REQ/RSP。
5. 查看 Status 是否明确提示目标不匹配或未进入 Follow。

### 14.4 抓到一半界面不再滚动

1. 点击 Read Stats。若弹窗有响应且 uptime 持续增加，设备与控制通路仍在工作；同时比较 rx、crc、transport 和 gap。
2. Periodic 失锁会扩大窗口并启用恢复资源；没有空口包时界面本身不会生成虚拟包。
3. 连接结束后系统继续等待同一目标重连，不会自动切回 All。
4. 等待发射源重新广播，或停止后重新开始一次抓包。
5. 若 Read Stats 也无响应，再检查 USB 访问（Windows 为 WinUSB）、USB 连接和是否有另一个抓包/升级进程占用设备。

### 14.5 加密 ACL、EAD、Mesh 或 BIS 解不出来

1. 先区分是“未提供资料”还是“MIC/CMAC failure”。
2. 核对 Key Type、长度、字节顺序、目标设备和 IV Index。
3. ACL 必须从连接/加密建立前开始；Legacy Passkey/OOB 必须覆盖 Confirm/Random。
4. EAD 使用 SessionKey:IV；Mesh 至少需要 NetKey + IV Index；Access 再需要 AppKey/DevKey。
5. 加密 BIS 应尽早加入正确的 Broadcast Code；较晚加入不能补回此前缺失的包。
6. Secure Connections 的显示数字不能替代 SC LTK。

### 14.6 右侧没有字段，或只看到 Raw Data

1. 先点击左侧的一条包记录，再展开 HX BLE Analysis。
2. 完全重启 Wireshark，确保新插件已经加载。
3. 标准字段可继续展开 Bluetooth Low Energy Link Layer。
4. 厂商私有载荷没有协议规格时，只显示 Raw Data Length + Raw Data 是正确结果。
5. 若整个 HX BLE Analysis 都不存在，重新运行安装脚本。

### 14.7 Status、Help、Read Stats 或工具栏显示异常

1. 确认 Host/Extcap 来自 v1.5.10 发布包，并完全重启 Wireshark；无线节点固件版本独立为 v1.5.0。
2. 最大化窗口；关键顺序应为 Status → Read Stats → Help → Reset。
3. Help 应打开本地指南；Read Stats 应弹窗并同步写入 Status。
4. Reset 需要先停止抓包。
5. 旧标签或旧顺序说明仍加载了旧 Host，重新运行对应平台的 v1.5.10 安装脚本。

---

## 15. 能力边界与开始前检查清单

### 15.1 当前实现的能力

- LE 1M Primary 37/38/39 自动发现 Legacy / Extended Advertising。
- 抓到 AuxPtr 后跟随 Extended Advertising 1M/2M/Coded 辅助链及多级 AUX_CHAIN。
- Periodic Advertising、16 位事件计数回卷、失锁恢复。
- CONNECT_IND、AUX_CONNECT_REQ/RSP、CSA#1/#2、双向 ACL。
- Connection/Channel Map/PHY/DLE/Power Control/Classification/Subrating。
- 已知 LTK/SC LTK、Legacy Passkey/OOB、IRK/RPA、EAD。
- L2CAP 分片、ATT/SMP、EATT credit-based 重组。
- BLE Mesh Bearer、Network/App/DevKey、分段、Beacon、PB-ADV。
- PAST、PAwR Subevent/Response。
- CTE PDU/CTEInfo、CIS、BIS、BIG Control、Broadcast Code、framed ISOAL。

> **当前验证边界：** 以上描述当前固件和 Host 的实现范围。最终 PCB 上的长期 USB/射频压力、PHY/时钟偏差、复杂 PAwR/CIS/BIS 组合、无线节点升级及掉电恢复仍待实板验证；macOS 实机安装与 USB 抓包也尚未完成验证，当前交付不能据此标为量产验证版。

### 15.2 当前不做

| 边界 | 实际含义 |
|---|---|
| 多连接并行 | 当前只选择一个目标并跟踪一条连接；内部并行资源不代表多条独立连接。 |
| 融合去重 | 同一台设备内使用公共时间基准、事件字段和 PDU 指纹去重；不合并多台设备。 |
| 设备/USB 数据链 | 内部高速数据面汇聚到 USB；Wireshark 只看到一个标准 BLE 链路入口。 |
| 未知密钥破解 | 不会猜测或破解密钥；认证失败不输出可信明文。 |
| 原始 IQ 与测角 | 可抓取 CTE PDU/CTEInfo，但当前无线硬件不输出原始 IQ，也不执行 AoA/AoD 测角。 |
| 主动发射 | Sniffer 不广播、不连接、不响应，只被动接收。 |

### 15.3 每次开始前的 10 项检查

1. Host 来自 v1.5.10 发布包，配套无线节点固件为 v1.5.0；两者版本分别确认。
2. Wireshark 已在安装后完整重启。
3. 选择的是唯一的 HX Wireless BLE Sniffer 接口。
4. 目标可通过当前 LE 1M Primary 自动发现，或已具备所需跟随上下文。
5. 客户没有配置任何内部节点、传输总线、信道或 PHY。
6. 要跟踪连接时，Device 已在连接请求前选中。
7. 需要解密时，资料已按正确格式加入。
8. 加密 BIS 的 Broadcast Code 已尽早填写。
9. Status 没有未处理的 ERROR。
10. Read Stats 的 crc、transport 和 gap 没有持续新增异常，并结合 conflicts 评估并发缺口。

> **最可靠的客户操作顺序：** All 扫描找到目标 → 选 Device → 加入所需资料 → 让被测系统开始连接或同步 → 用 Status 确认状态 → 用右侧语义树分析 → 用 Read Stats 确认抓包健康 → 保存 PCAPNG。

---

*HX Wireless BLE Sniffer · Host v1.5.10 / 无线节点固件 v1.5.0 · 客户使用指南*