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
