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, 13 Jun 2022 21:33:18 +0200
>
> On Tue, 2022-05-10 at 21:31 +0200, Tomasz Moń wrote:
> > On Tue, 2022-05-10 at 07:28 +0200, Tomasz Moń wrote:
> > > On Mon, May 9, 2022 at 10:17 PM Guy Harris <gharris () sonic net> wrote:
> > > > 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).
> >
> > It should be noted that when (and if) low-speed traffic is received on
> > full-speed device differential pair (D+/D-), it is never intended for
> > the full-speed device and the full-speed device never acts upon it
> > (full-speed hub simply forwards low-speed traffic, non-hub devices
> > simply ignore it).
> >
> > When user does full-speed only capture using hardware sniffer, the user
> > intends to see full-speed packets. If the resulting capture includes
> > PRE token, it is clear that there was some low-speed traffic. And it is
> > clear that the low-speed traffic was not in any way related to any
> > full-speed function.
> >
> > When low-speed capture is performed, it has to be performed at the leaf
> > (in graph-theory sense) connection. Full-speed traffic never make it to
> > the low-speed cables, so the capture will contain only low-speed
> > packets.
>
> Is there anything still to discuss here? I have opened the pull
> requests [1] [2] few weeks ago. I have also prepared Wireshark [3]
> change that I would like to merge before Wireshark 4.0 release.
>
> I think I have summed up whole discussion in the libpcap commit
> message. High-speed and Low-speed are pretty much clear, as these links
> never observe other speed packets. Full-speed is the only disputable
> one, but I believe the PRE packets are really a corner case that is not
> worth per-packet speed encoding. If the user has obsolete setup to
> trigger the corner case in the first place, then such user will
> definitely know to just capture at the downstream link for low-speed
> traffic.
>
> > From packet level analysis point of view, it is simply enough to know
> that there was some low-speed transaction that is not included in the
> capture as the full-speed devices ignore the low-speed transactions
> anyway. This is what the PRE packet (just one byte) in full-speed
> capture means.
>
> If there is something wrong with the PRE packet handling in full-speed
> hub, then packet analyzer is not really the right tool. The right tool
> would be 4 channel oscilloscope with 2 channels connected to upstream
> D+/D- and 2 channels to downstream D+/D-.
>
> [1] https://github.com/the-tcpdump-group/libpcap/pull/1109
> [2] https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/29
> [3] https://gitlab.com/wireshark/wireshark/-/merge_requests/7045
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers