tcpdump mailing list archives

Re: Speed specific Link-Layer Header Types for USB 2.0


From: Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Mon, 9 May 2022 00:17:40 -0700

--- Begin Message --- From: Guy Harris <gharris () sonic net>
Date: Mon, 9 May 2022 00:17:40 -0700
On May 8, 2022, at 10:47 PM, Tomasz Moń <desowin () gmail com> wrote:

On Sun, May 8, 2022 at 8:53 PM Guy Harris <gharris () sonic net> wrote:
At least from a quick look at section 5.2.3 "Physical Bus Topology" of the USB 2.0 spec, a given bus can either be a 
high-speed bus or a full/low-speed bus.

The full/low-speed bus applies only to upstream link from full speed hub.

So what happens if you plug a low-speed keyboard or mouse into a host that supports USB 2.0?  Does that link not run at 
low speed?

The idea, then, is presumably that a capture tool is capturing on a single bus (single wire), so it's either 
capturing on a high-speed bus or a full/low-speed bus.

I assume that by single wire you meant "single wire pair"
(differential pair). USB 2.0 has only single differential pair, formed
by D+ and D- signal wires, so the high/full/low speed communication
always occurs on the same wire pair.

Sorry - that's "wire" in the sense of "cable", not in the literal sense.

It looks as if a high-speed bus will always run at 480 Mb/s, so that capture would be a LINKTYPE_USB_2_0_HIGH_SPEED 
capture.  Is that correct?

Yes. If you connect high-speed hub to high-speed host (or super-speed
host, but super-speed host essentially contains high-speed host, aka

dual-bus) the communication on the connecting wires will be at high
speed (480 Mb/s). Similarly if high-speed device is connected to
high-speed host (or hub) then the communication will be at high speed.

"super-speed" is USB 3.0, right?  No LINKTYPE_/DLT_ has been proposed for the 3.0 link layer, as far as I know.

But no full-speed or low-speed will go over that connection, either, so it's never the case that, in a capture on a USB 
cable, there will be both high-speed and full/low-speed traffic, right?

(And presumably this is for captures on a single USB cable; if you're capturing on more than one cable, that's with 
more than one capture interface, so that's a job for pcapng, with different interfaces having different link-layer 
types.)

For full/low-speed buses, will those also always run at full peed or low speed, so that there would never be a 
mixture of full-speed and low-speed transactions?

If you capture at the connection between low speed device and
host/hub, there will only ever be low speed packets. It would be a
LINKTYPE_USB_2_0_LOW_SPEED capture.

The problematic case (and the reason why full/low-speed bus is
mentioned) is the LINKTYPE_USB_2_0_FULL_SPEED. It is the case when you
capture at the connection between full speed hub and the host (and
possibly full speed device connected to a full speed hub if there are
low speed devices connected to the full speed hub). If there is low
speed device connected to downstream hub port, then when the host
wants to send packets to the low speed device, these will be sent at
low speed to the hub. However, there will be PRE packet (sent at full
speed) before every low speed transaction.

So, as per a few paragraphs above ("If you connect high-speed hub to high-speed host ... the communication on the 
connecting wires will be at high
speed (480 Mb/s)."), if you have a high-speed hub connected to a high-speed host, and the high-speed hub has full-speed 
or low-speed devices downstream, the packets from the host to the hub, ultimately intended for the full-speed or 
low-speed device, are sent as high-speed traffic, and only the downstream traffic from the host to the full-speed or 
low-speed device is full-speed or low-speed?

However, if you have a full-speed hub connected to a full-speed or high-speed host, and the full-speed hub has 
low-speed devices downstream, the packets from the host to the hub, ultimately intended for the low-speed device, are 
sent as a full-speed PRE packet followed by a transaction sent as low-speed traffic?

--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Current thread: