我正在尝试破译由产生的 USB I/O 流量的痕迹，usbmon并且在解决字节序时遇到了一些问题。例如，以下是我正在使用的跟踪中的两行：
ffff8800650e7000 433121059 S Ci:2:000:0 s 80 06 0100 0000 0040 64 <
ffff8800650e7000 433121661 C Ci:2:000:0 0 18 = 12010002 00000040 da0b8781 00010102 0301
我最初在跟踪中除了大端顺序之外没有任何怀疑，但后来我da0b8781在第二行中看到，它对应于我正在跟踪的 USB 设备的身份，其供应商 ID0x0bda和产品 ID 为0x8187（注意跟踪中字节顺序的反转）。
所以在这一点上，我认为可能在usbmon跟踪的给定字段中，字节总是以相反的字节顺序进行的，应该这样解释。但相反，让我们检查靠近第一条迹线末端的一小部分，... 0040 64
0040是一个十六进制字段，表示接受的最大响应大小。 64是一个十进制字段，应该代表完全相同的事物。 0x0040=64十进制，无需将字节顺序切换为! 0x4000=64十进制。usbmon所以在这一点上，我开始对跟踪不同部分的字节顺序有点不确定。
接下来我想，也许只是usbmon跟踪的数据部分是反向字节顺序的。所以我想也许我真的应该读书
...12010002 00000040 da0b8781 00010102 0301
作为
1030 20101000 1878b0ad 04000000 20001021...
不，这似乎也不对。USB 规范声明供应商 ID（0x0bda在我的例子中）应该是这个特定字符串的字节偏移量 8。如果我们将上面的字符串保持原来的顺序，那么供应商 ID 确实从字节偏移 8 开始（12010002 00000040 消耗前 8 个字节），但是如果我们像上面那样反转它，那么它从字节偏移 6 开始（1030 20101000只消耗前 6 个字节）。
所以我现在最好的猜测是usbmon显示所有大端，接受它在每个 4 字节字内切换到反向字节顺序，但仅用于数据。任何人都可以澄清这是否正确，或者是否还有其他我遗漏的东西？