[tcpdump-workers] Speed specific Link-Layer Header Types for USB 2.0
desowin at gmail.com
Sun Jun 19 16:10:15 EDT 2022
On Tue, 2022-06-14 at 10:49 -0400, Michael Richardson wrote:
> Tomasz Moń via tcpdump-workers wrote:
> > 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.
> I think that Guy and I thought that you'll be better off with a single
> LINKTYPE with a subtype header, but if you want to go with three, I don't
I don't see any value (and according to information theory there is no
information) in per packet subtype header that would be set to exactly
the same value for *every single packet* captured on Low- or High-speed
It would also be the same value for every single packet captured on
Full-speed link with either OpenVizsla or LambdaConcept USB2Sniffer as
it is impossible for these sniffers to capture both Full- and Low-
speed packets during single capture session.
If, for whatever reason, the user wants to merge multiple captures,
then pcapng format should be used as pcapng can preserve the
information that the packets came from different sources (pcap format
cannot do that).
I have updated ovextcap draft pull request  to present low-speed-
only, full-speed-only and high-speed-only capture options when run with
Wireshark version that supports the speed specific linktypes. This
matches the "don't support full/low-speed traffic capture, just support
full-speed-only and low-speed-only traffic capture" reasonable choice
mentioned in Guy Harris email sent on 9 May 2022.
More information about the tcpdump-workers