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: Sun, 19 Jun 2022 22:10:15 +0200
>
> 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
> > object.
>
> 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
> link.
>
> 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 [1] 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.
>
> [1] https://github.com/matwey/libopenvizsla/pull/26
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers