On Jul 21, 2019, at 9:22 PM, Tomasz Moń <deso...@gmail.com> wrote:
> On Sun, Jul 21, 2019 at 10:47 PM Guy Harris <ghar...@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.
So either
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
or
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.
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
