--- Begin Message ---
On Mon, May 9, 2022 at 10:17 PM Guy Harris <ghar...@sonic.net> wrote:
> On May 9, 2022, at 12:31 PM, Tomasz Moń <deso...@gmail.com> wrote:
> > 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).
>
> So what is the term used for a cable between a low-speed-only device and 
> either a host or a hub?

Universal Serial Bus Specification Revision 2.0:
    6.6 Cable Mechanical Con figuration and Material Requirements does specify:
    High-/full-speed and low-speed cables differ in data conductor
arrangement and shielding.
and then it specifies:
    7.1.1.2 Low-speed (1.5 Mb/s) Driver Characteristics
    A low-speed device must have a captive cable with the Series A
connector on the plug end.

So the term is "low-speed cable" and that cable is not removable
(captive cable is attached to the circuit board).

> The USB 2.0 spec appears to use "bus" for an "edge", in the graph-theory 
> sense:
>
>         https://en.wikipedia.org/wiki/Glossary_of_graph_theory#edge
>
> rather than for the entire tree.

In USB 1.x the "bus" did stand for the entire tree. Then it diverged
in subsequent revisions :-)

> What *is* the correct term to use for a single cable, the traffic on which 
> one might be sniffing?

"Low-speed cable" and "High-/full-speed cable" (hopefully this
discussion does not cover later revisions where the cabling is way
more complicated).

> > 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.
>
> It makes sense to indicate whether packets are full-speed or low-speed; 
> nobody is arguing otherwise.
>
> The question is whether the right way to do that is to have separate link 
> types, so that you can't have a mix of full-speed and low-speed packets in a 
> single pcap capture or on a single interface in a pcapng capture, or to have 
> a single link-layer type with a per-packet full-speed/low-speed indicator.

I think the separate link types are the way to go.

The full to low speed transition is not technically a packet, but
rather a "Preamble". While the transceivers, e.g. the one used in
OpenVizsla, have special mode to send that preamble together with
low-speed packet, they do not have a mode to capture low-speed
transactions. The handling logic has to be bundled in specialized hub
chip (and only there, the non-hub full speed devices will happily
discard what they see as garbage).

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

Reply via email to