Re: Speed specific Link-Layer Header Types for USB 2.0

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Mon, 9 May 2022 12:02:20 -0700
>
> On May 9, 2022, at 7:41 AM, Tomasz Moń <desowin () gmail com> wrote:
>
> > That would require defining pseudoheader that would have to be included
> > in every packet.
>
> Is that really a great burden?
>
> > And it would only solve the corner case that the
> > currently available open-source friendly sniffers do not presently
> > handle.
>
> The point isn't to just handle what currently available open-source friendly sniffers handle.  I'd prefer to leave room 
> for future sniffers that *do* handle it.
>
> > I think it is fine to assume that any tool that would create full-speed
> > captures that contain both full-speed and low-speed data should be able
> > to write pcapng file (or simply create two separate pcap files).
>
> I think that, if you're capturing on a link between a full/low-speed host and a full/low-speed hub, with low-speed 
> devices plugged into that hub, it would not make sense to treat that link as two interfaces, with one interface 
> handling full-speed packets and one interface handling low-speed packets; I see that as an ugly workaround.
>
> So I see either
>
>         1) a link-layer type for full/low-speed traffic, with a per-packet pseudo-header
>
> or
>
>         2) don't support full/low-speed traffic capture, just support full-speed-only and low-speed-only traffic capture
>
> as the reasonable choices.
>
> (Note that both tcpdump and Wireshark still have their Token Ring dissection code; heck, Wireshark has even had 3MB 
> Xerox PARC Ethernet dissection code for a while now!)
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers