On Sep 1, 2021, at 12:27 AM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
> thank you for your detailed answer, I figured the practical part, i.e. not the part related to the design rationale of it myself, as you have seen, was not too complicated, either. And now your answer explained the design rationale too. Would be good, maybe, to have this answer, together with some examples, included in the guide or some tutorial, as I see it, as this, maybe somewhat obscure, to the general audience at least, topic, is underrepresented there, no ?
I'd say the LINKTYPE/DLT stuff doesn't really belong in Wireshark documentation other than 1) "don't use them to register in the wtap_encap table" and "if you're adding support for a newly-assigned LINKTYPE value, here's how you do it". The pcap-linktype man page says:
For a live capture or ``savefile'', libpcap supplies, as the return
value of the pcap_datalink(3PCAP) routine, a value that indicates the
type of link-layer header at the beginning of the packets it provides.
This is not necessarily the type of link-layer header that the packets
being captured have on the network from which they're being captured;
for example, packets from an IEEE 802.11 network might be provided by
libpcap with Ethernet headers that the network adapter or the network
adapter driver generates from the 802.11 headers. The names for those
values begin with DLT_, so they are sometimes called "DLT_ values".
The values stored in the link-layer header type field in the savefile
header are, in most but not all cases, the same as the values returned
by pcap_datalink(). The names for those values begin with LINKTYPE_.
The link-layer header types supported by libpcap are described at
https://www.tcpdump.org/linktypes.html .
which indicates where LINKTYPE values are used and where DLT values are used, and that they're not always the same.
(It doesn't indicate *why* they're not always the same, but most people probably don't want to waste their times reading me explaining - and complaining! - that DLT_RAW being 14 in OpenBSD and 12 everywhere else, and that this means that *neither* value should be used in capture files to indicate "raw IP" packets, because both values are used for purposes other than "raw IP" on some platforms, meaning *neither* of them can be relied on to indicate "raw IP" without either ugly heuristics or the user having to indicate what the link type means, so I'm not sure that needs to be indicated. :-))
The Wireshark Developer's Guide doesn't have anything on how, in a C dissector, to register a dissector for a given link-layer type; it does have documentation on how to do that in a Lua dissector in section 10.3 "Example: Dissector written in Lua", but it doesn't give more details on the namespace for wtap.* values.