[tcpdump-workers] Link-Layer Header Type request: USB 2.0
gharris at sonic.net
Mon Jul 22 21:59:09 EDT 2019
On Jul 21, 2019, at 9:22 PM, Tomasz Moń <desowin at gmail.com> wrote:
> On Sun, Jul 21, 2019 at 10:47 PM Guy Harris <gharris at sonic.net> wrote:
>> It looks as if USB 3.1's packets are different from USB 2.0's packets, so this would be 2.0-specific.
> USB 3 operates on different hardware signals. USB 3 hubs do contain
> USB 3 and USB 2.0 hubs inside them.
> The USB 2.0 data is sent on the D+/D- differential pair, while the USB
> 3 data uses dedicated Superspeed
> differential pairs for RX and TX.
The issue isn't the hardware signals.
Maybe I'm reading the wrong sections of the specs, but:
section 8 of the 2.0 spec speaks of packets beginning with a SYNC field, which is followed by a PID - section 8.4 describes the format of what follows the SYNC field for various packet types;
section 8.3 of the 3.1 spec speaks of various packet types, none of which obviously look like the packets described in section 8.4 of the 3.0 spec.
1) I'm missing something, and 2.0 packet look like 3.1 packets, so there could be a way to store 1.x, 2.x, and 3.x packets in the same capture, without an indication of whether the packets are 1.x/2.x or 3.x
2) without a per-packet indication of whether a packet are 1.x/2.x or 3.x, there would be no way to dissect packets if there was a mixture of 1.x/2.x and 3.x packets.
> Valid USB 1.0 and 1.1 packets can be dissected as USB 2.0. However,
> this is not always true the other way round.
> For example USB 1.1 device won't understand SPLIT packet. Fortunately
> compliant USB 2.0 Host won't ever send SPLIT
> to the USB 1.1 device as this PID can only be sent on High Speed link
> (which was introduced in USB 2.0).
If we're talking tools to *dissect* packets, that's not an issue - the tool would presumably support all of USB 2.0, so it can handle all of USB 1.x as well.
More information about the tcpdump-workers