On Sep 1, 2021, at 1:49 AM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
> As for OpenBSD, so what, is there really some #ifdef for this special case buried somewhere in the code or how is it handled?
If you're capturing with a program built with, and using, a version of libpcap based on release 1.0 or later of libpcap from tcpdump.org, then:
The public header files for those versions of libpcap provide their own definitions of DLT_ values, using #ifdefs to define the "not the same on all platforms" DLT_ values, such as DLT_RAW, so that, on platforms using BPF as the capture mechanism, the definition matches what the definition in the platform's net/bpf.h or net/dlt.h header. For example, DLT_RAW is defined as 14 on OpenBSD and 12 on all other platforms (including platforms *not* using BPF as the capture mechanism).
If you're using the code in that version of libpcap to read the capture file, the open-offline routines to open a capture file for reading will see the LINKTYPE_RAW value of 101 in the pcap header or in a pcapng IDB and will map it to DLT_RAW when returning the linktype from pcap_datalink(), so 14 would be returned on OpenBSD and 12 would be returned on all other platforms.
If you're using the code in that version of libpcap to write the capture file, the dump-open routine to open a pcap file for writing will map DLT_RAW, whatever value it might have, to LINKTYPE_RAW, and thus write out 101 as the link-layer type value in the pcap header.
*Most* platforms, these days, provide a libpcap that's based on libpcap from tcpdump.org, and only *very* old OS versions provide a libpcap based on something prior to 1.0. In addition, the final release of WinPcap and all releases of Npcap include a libpcap based on tcpdump.org libpcap 1.0 or later.
OpenBSD is an exception. Unfortunately, at least as of OpenBSD 6.6, its libpcap did not pick up the LINKTYPE <-> DLT mapping, so it still writes out "raw IP" files with 14, rather than 101, in the file header, and can't handle "raw IP" files with 12 or 101 as the link-layer type; it treats files with 12 as being DLT_LOOP (BSD loopback, but with the AF_ value in the header being in network byte order rather than host byte order) and doesn't support files with 101.
Wireshark has its own code to read and write pcap and pcapng files; there's code in libwiretap and separate code used by dumpcap (to keep dumpcap simpler, as it may run with enhanced privileges).
The libwiretap code maps the LINKTYPE values in pcap file headers and pcapng IDBs to WTAP_ENCAP values. It always maps 101 to WTAP_ENCAP_RAW_IP.
In addition:
It maps 14 to WTAP_ENCAP_RAW_IP on all platforms - to quote the comment in wiretap/pcap-common.c:
* 14 is DLT_PPP_BSDOS on FreeBSD and NetBSD, but those OSes
* don't actually generate it. I infer that BSD/OS translates
* DLT_PPP from the kernel BPF code to DLT_PPP_BSDOS in
* libpcap, as the BSD/OS link-layer header is different;
* however, in BSD/OS, DLT_PPP_BSDOS is 16.
*
* From this, I infer that there's no point in handling 14
* as DLT_PPP_BSDOS.
*
* 14 is DLT_RAW on BSD/OS and OpenBSD.
If compiled on OpenBSD, it maps 12 to WTAP_ENCAP_LOOP, otherwise it maps it to WTAP_ENCAP_RAW_IP.
It always writes out "raw IP" with 101 as the pcap file header value and the pcapng IDB value.
The dumpcap code currently doesn't do LINKTYPE mapping, so, if you're capturing from a raw IP device, it'll write out 12 to an IDB or pcap header on everything but OpenBSD and will write out 14 on OpenBSD. It probably should do its own mapping.