--- Begin Message ---On May 9, 2022, at 7:41 AM, Tomasz Moń <deso...@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
