tcpdump mailing list archives

What bit order should be used for the pcapng Enhanced Packet Block flags field?


From: Guy Harris <gharris () sonic net>
Date: Tue, 12 Feb 2019 22:03:26 -0800

The pcapng spec, as I read it, says that bit 0 of the Enhanced Packet Block flags field is the high-order bit of the 
word.

However, several implementations of pcapng, including those in:

        Wireshark's pcapng reading code (sorry about that);

        macOS's libpcap and tcpdump;

        Wireshark's text2pcap;

and possibly the one that generated the capture in bug 11665:

        https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=11665

treat bit 0 as the *low-order* bit in the word.

I don't know if they all made the same slip that I did independently, or got the idea from reading the pcapng reading 
code.  The other implementations fill in and process the direction field, and the bug 11665 one appears to fill in the 
"reception type" as "promiscuous"; neither of them appear to process the FCS length, and my implementation only fetched 
the FCS length, so we all *might* have failed to notice the "bit 0 is the high-order bit" part of the pcapng spec and 
just went with the bit numbering in the {x86, ARM, SPARC, MIPS, Alpha, Itanium, 68k} documenation rather than the one 
used in the {PowerPC/Power ISA, System/3x0-and-z/Architecture, PA-RISC} documentation.

I've filed an issue about this on the GitHub page for the pcapng specification:

        https://github.com/pcapng/pcapng/issues/57

Continue discussion there (rather than here).
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Current thread: