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).
