On Sep 1, 2021, at 1:49 AM, Ariel Burbaickij <ariel.burbaic...@gmail.com> 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.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@wireshark.org>
Archives: https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-requ...@wireshark.org?subject=unsubscribe
