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

[Tomasz Moń via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Tomasz Moń <desowin () gmail com>
>
> Date: Mon, 09 May 2022 21:31:30 +0200
>
> On Mon, 2022-05-09 at 11:52 -0700, Guy Harris wrote:
> > On May 9, 2022, at 1:58 AM, Tomasz Moń <desowin () gmail com> wrote:
> >
> > > On Mon, May 9, 2022 at 9:17 AM Guy Harris <gharris () sonic net>
> > > wrote:
> > > > 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 link will run at low speed.
> >
> > So what kind of bus is that link?  High-speed, full/low-speed, or
> > low-speed?
>
> The reason for "full/low-speed" bus is because the original USB 1.0 and
> 1.1 only supported full and low speed. The hub was really operating
> like a network hub, and the slight speed difference between full and
> low speed (8x) was handled by the PRE packets and blocking of
> downstream ports.
>
> With the USB 2.0 release, the high-speed bus was added. There the hub
> is operating more like a network switch. The downstream ports no longer
> receive full or low speed data - the host selects only one port that
> the full/low-speed traffic should be relayed to.
>
> There is no such thing as "low-speed bus" because low-speed is only
> allowed for non-hub devices. USB hosts and hubs *must* support atleast
> full and high speed. USB devices are allowed to be low-speed (such
> devices can operate *only* at low speed).
>
> The high-speed device can operate as full-speed or high-speed devices
> depending on host/hub the device is connected to. High-speed or Full-
> speed device cannot ever operate at low-speed (the full-speed hub
> related traffic, e.g. control transfers to hub, are always full-speed).
>
> It is important that the analysis engine know whether the packets were
> full or low-speed as there are slightly different rules. There is not
> so clear distinction between layers as USB does not really use ISO/OSI
> model.
>
> So I think it definitely makes sense to have separate link types for
> full-speed and low-speed.
>
> > > > 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?
> > >
> > > Yes. You either get solely high-speed traffic or full/low-speed
> > > traffic.
> >
> > OK, so it makes sense to have a separate link-layer type for high-
> > speed traffic, rather than a single link-layer type for "USB link-
> > layer with metadata header, with the per-packet metadata header
> > indicating the speed".
> >
> > But, if, as you said earlier:
> >
> > > 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.
> >
> > can there be separate link-layer types for full-speed and low-speed
> > traffic, or does there need to be a single type for full/low-speed
> > traffic, with a per-packet metadata header indicating the speed"?
>
> I am definitely in favour of the separate link-layer types for full-
> speed and low-speed traffic.
>
> The mixed full-speed and low-speed on single cable (when there is full-
> speed hub involved) is there for backwards compatibility and you have
> to actually try hard to trigger it these days. But even if you do
> trigger, there is simple workaround:
>   * if you are interested in full-speed traffic, simply set sniffer
> capture speed to full-speed and *ignore* the invalid packets reported
> after PRE packets
>   * if you are interested in low-speed traffic, set sniffer capture
> speed to low-speed and *connect* the cable between hub downstream port
> and the low-speed device (this cable only ever sees low-speed traffic)
>
> If the user is debugging issues related to handling PRE packets by
> full-speed hub, then oscilloscope (or logic analyzer) is much better
> option than packet-level capture like OpenVizsla.
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers