USBPcap 抓包完全指南：Windows 下 USB 流量捕获与 Wireshark 联动

做 USB 诊断，第一步往往是平台问题：到底是在 Linux 上抓，还是在 Windows 上抓？这个答案很关键，因为抓包路径完全不同。Linux 上常见的是 usbmon，Windows 上常见的是 USBPcap。两条路径都能撑起日常现场诊断，但前提条件、权限模型、驱动行为、典型失败模式都不一样。

先说结论：Bug 只在 Windows 上复现——用 USBPcap。你手头有 Linux 实验机、需要 CI 自动化、嵌入式验证环境——用 usbmon。Windows 和 Linux 表现不一致——两条都抓，它们之间的差异本身就是证据。

第一包不要急着过滤

固件层面的 USB 工作，开局不要把过滤条件收得太紧。第一包至少要把"枚举 + 配置后的第一条应用层传输"完整覆盖进来。如果你抓包时设备已经配置完毕，可能正好错过那个能解释故障的关键描述符或类请求。

最小证据集：

• 连接 / 复位 / 重连的时间线
• 设备、配置、接口、端点、BOS、HID、CDC、MSC 或厂商描述符
• 控制传输的 SETUP 包字段
• 端点地址、方向、传输类型
• 状态 / STALL / 超时 / 短包标记
• 失败传输的原始 payload 字节
• 主机平台与驱动绑定上下文

重点不是哪个平台"更好"，而是这份抓包能不能保留足够的证据，把设备行为解释清楚。

一份合格的 USB 抓包应该保留什么

固件和硬件调试场景下，有用的抓包至少要保留：

• 总线与设备上下文
• 端点地址与方向
• 传输类型
• SETUP 包字段
• 描述符响应
• 状态与错误标志
• 原始 payload
• 时序
• 足够把包关联回设备自身的元数据

这些结构缺一项，抓包就会沦落为"一堆字节"，在支持工单里根本站不住脚。

Linux usbmon

在 Linux 上，usbmon 把 USB 流量从内核暴露出来。它对固件团队特别友好，因为 Linux 在实验室、CI 平台、嵌入式验证环境里都很常见。而且当目标是观察枚举和传输行为时，Linux 也省去了很多 Windows 上驱动绑定的麻烦。

基本的可用性检查：

sudo modprobe usbmon
ls /sys/kernel/debug/usb/usbmon

如果抓包工具看不到 usbmon，先检查 debugfs 是否挂载、当前用户是否有读 monitor 节点的权限。不要把权限失败直接等同于"USB 没流量"——它只能说明主机没把这套抓包源暴露出来。

Linux 抓包常见问题清单：

• 当前用户是否有抓包权限？
• 设备挂在哪条总线上？
• 枚举是在配置之前就停了？
• 类特定请求有没有到达？
• 配置完成后端点有没有在传输？

如果 Linux 上枚举和传输都干净、Windows 上失败，下一个嫌疑对象就该转向 Windows 驱动绑定、INF 配置、USBPcap 安装、类兼容性。

Windows USBPcap

在 Windows 上，USBPcap 是最常见的 USB 流量捕获驱动路径。它的价值在于：很多客户的设备问题只在 Windows 上才能复现。如果你的产品是固件设备，忽视 Windows 证据就可能错过现场真正的失败模式。

Windows 上的特有风险是抓包范围。USBPcap 只从某个选定的 Root Hub 上抓。如果你的设备挂在另一个控制器或 Hub 上，抓包文件可能完全是空的，而设备却在那里活蹦乱跳——下结论前，先确认 Root Hub。

Windows 抓包常见问题清单：

• USBPcap 是否已安装并启用？
• 应该抓哪个 Root Hub？
• 设备是否绑定到了预期的驱动？
• 应用程序打开设备前，枚举是否已经完成？
• 绑定之后有没有类请求或 Bulk / Interrupt 传输？

当问题只在特定驱动栈或应用环境下出现时，Windows 抓包的价值会格外突出。

两边的抓包要对比，不要互相覆盖

如果同一个 USB 设备在 Linux 和 Windows 上行为不一样，这个差异本身就是证据。不要把它简化成"USB 太玄学"。要对比的是：

• 描述符请求
• 选中的配置
• 类特定请求
• 配置完成后的端点流量
• 错误状态
• 复位与重连时序

对比下来往往能说明：固件对平台敏感、某台主机拒收了一个描述符但另一台能容忍、或者 USB 配置已经成功只是应用层又把它搞挂了。

Bus Scope 在这个场景里做什么

Bus Scope 是一款围绕"证据"构建的 USB 抓包与检查工作台。它不是通用的网络分析工具，也没想把所有协议都吃下来。它的工作就是：让 USB 抓包更容易看、更容易过滤、更容易保存、更容易讲清楚。

对 usbmon / USBPcap 这两条工作流，Bus Scope 能帮团队：

• 识别抓包适配器和设备上下文
• 检查 SETUP 包和描述符
• 在支持的范围内解码类相关证据
• 把原始字节和解析后的字段绑在一起
• 保存为 .bscope 会话以便回放和交接

现场报告写着"设备在 Windows 上失败，Linux 上正常"的时候，下一步不该是猜，而是摆出两份抓包对比。