Re: Link-Layer Header Type request: USB 2.0

[Guy Harris <gharris () sonic net>]

On Jul 21, 2019, at 9:22 PM, Tomasz Moń <desowin () gmail com> wrote:

> On Sun, Jul 21, 2019 at 10:47 PM Guy Harris <gharris () 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