--- Begin Message ---
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 <ghar...@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
