Bus Scope (总线猎手) logo Bus Scope (总线猎手) USB 协议分析

2026-06-02

Wireshark USB 过滤器：USBPcap、usbmon 与 Bus Scope 下如何定位目标设备

在 USBPcap 或 usbmon 抓包流量过大时，按设备、端点、传输类型、Setup Packet、接口、时序过滤定位目标 USB 设备。

Wireshark USB 过滤器, USBPcap, usbmon, USB 抓包, USB 诊断, Display Filter

USB 抓包一开起来就可能变得很吓人。一台机器上可能同时挂着键盘、鼠标、摄像头、蓝牙适配器、存储设备、串口适配器、安全令牌、内部 Hub。当用户搜 "Wireshark USB filter"、"USBPcap filter device"、"usbmon filter endpoint"、"how to find my USB device in capture" 的时候，他们的问题通常是同一个：抓包流量太多、结构太少。

Bus Scope 的设计目标是让 USB 检查更直接，但理解"过滤"这件事本身仍然有用。不管抓包来自 Windows 上的 USBPcap、Linux 上的 usbmon 还是其他 USB 抓包源，关键都是：先定位设备，再按地址、端点、传输类型、控制请求收窄 trace。

从枚举开始

定位 USB 设备最简单的方式是从插入那一刻开始抓。枚举过程里包含命名设备的描述符、Vendor ID、Product ID、Configuration、Interface、Endpoint、Class 相关细节。

要看的：

  • Vendor ID
  • Product ID
  • Device Descriptor
  • Configuration Descriptor
  • Interface Descriptor
  • Endpoint Descriptor
  • String Descriptor
  • SET_ADDRESS
  • SET_CONFIGURATION

如果你抓包的时候设备已经跑起来了，可能只剩端点流量，没有描述符上下文——这时候过滤会很难，因为只有端点号是不够的。

设备地址会变

USB 设备地址是主机在枚举时分的。如果设备断连后重连，地址可能变。一开始过滤能用的地址，重连之后就抓不到了。

排查 Reset 循环的时候这个细节尤其重要。一台设备反复重新枚举，你可能需要在一份抓包里跟踪多个地址。产品 / Vendor 描述符能告诉你这些地址其实是同一台物理设备。

Bus Scope 能让这种关系一直可见，不用你手动把地址变化缝起来。

按端点过滤

配置完成后，绝大多数数据流量都走端点。Endpoint 0 是 Control，其他端点可能是 Bulk、Interrupt、Isochronous。

常见的端点含义：

  • 0x00：端点 0 的 Control OUT
  • 0x80：端点 0 的 Control IN
  • 0x81：端点 1 IN
  • 0x01：端点 1 OUT
  • 0x82：端点 2 IN
  • 0x02：端点 2 OUT

方向位很关键。0x81 和 0x01 不是同一个方向的端点。一个串口适配器可能用一个 Bulk OUT 走主机到设备的数据，一个 Bulk IN 走设备到主机的数据。

按端点过滤的用处，发生在你已经知道要看哪条端点之后。

按传输类型过滤

不同的 USB 问题活在不同的传输类型里：

  • Control Transfer：描述符、配置、类请求、厂商命令
  • Bulk Transfer：存储、串口数据、厂商数据、很多采集设备
  • Interrupt Transfer：HID 输入、状态通知、低延迟报告
  • Isochronous Transfer：音频、视频、时敏流媒体

USB 串口设备打开了但不出数据，先查 Control Transfer 里的 Line Coding 和控制线状态，再看 Bulk 端点的 payload。摄像头开了但视频花屏，看 Isochronous Transfer 和 Alternate Setting。HID 设备行为异常，看 Interrupt Transfer 和 Report Descriptor。

按传输类型过滤能在保留相关证据的同时减少噪音。

按 Setup Packet 过滤

Control Transfer 包含 Setup Packet。Setup Packet 极其有用，它标明了请求的方向、类型、Recipient、Request Code、Value、Index、Length。

重要的例子：

  • GET_DESCRIPTOR
  • SET_ADDRESS
  • SET_CONFIGURATION
  • SET_INTERFACE
  • CLEAR_FEATURE
  • HID GET_REPORT
  • HID SET_REPORT
  • CDC SET_LINE_CODING
  • CDC SET_CONTROL_LINE_STATE
  • 厂商自定义命令

设备在 setup 阶段失败的时候，Setup Packet 通常能直接告诉你哪条请求触发了问题。

Windows 上 USBPcap 抓包选哪个

Windows 上，USBPcap 是从 USB 主控制器抓包的。如果一台机器有多个控制器，选错了控制器可能整份抓包都没有目标设备的流量。

实用的工作流：

  1. 拔掉目标设备
  2. 在最可能的控制器上启动抓包
  3. 插入设备
  4. 找枚举描述符
  5. 如果什么都没出现，换一个控制器抓
  6. 找到设备之后，把这份抓包留作参考

Bus Scope 的价值是让这条工作流更直接：目标就是 USB 设备的对话，不是一份庞大的包列表。

Linux 上 usbmon 抓包

Linux 上，usbmon 暴露 USB 总线流量。总线号很关键。一台 lsusb 列成 Bus 003 Device 012 的设备属于 3 号总线那一刻。重连之后，设备号可能变。

最有用的抓包是在插入之前就开始——因为枚举揭示了设备身份。如果权限挡住了抓包，先解决权限，不然可能只看到应用层失败，永远看不到 USB 证据。

常见的过滤误区

避开这些坑：

  • 失败之后才开始过滤，错过了枚举
  • 假设设备地址在重连之间稳定
  • 把端点方向搞混
  • 忽略端点 0 的 Control 流量
  • 只看 payload 包，错过类请求
  • 把所有厂商请求当噪音
  • 太早把 Reset 和错误过滤掉
  • 忽略 Hub 和端口上下文

一个干净的过滤只有保留了故障才有意义。

一份可共享的调查抓包要保留什么

一份可以发给固件、驱动、QA 团队的报告，应该保留：

  • 最初的枚举
  • 目标设备的描述符
  • 主机选中的 Configuration 和 Interface
  • 失败前后的类或厂商请求
  • 失败相关的端点流量
  • Reset、STALL、超时或断连事件
  • 足够的时序上下文，看清楚故障是立刻、空闲后、还是负载下出现

这些证据比一张"设备没识别"的截图强得多。

最终诊断

USB 过滤不是单纯地藏噪音——它要保留的是"能解释故障的那段包序列"。从枚举出发，识别设备，跟踪地址变化，按端点和传输类型收窄，把 Control Request 保持在视野里。

Bus Scope 就是要支持这条工作流：快速找到真正的 USB 对话，然后看清设备为什么工作、STALL、Reset 或消失。

相关工作流