Hello Guy, yes, exactly for the following two reasons from your post: " you're adding support for a newly-assigned LINKTYPE value, here's how you do it" and "... it doesn't give more details on the namespace for wtap.* values..." I suggest maybe expanding the documentation to cover them. As for OpenBSD, so what, is there really some #ifdef for this special case buried somewhere in the code or how is it handled?
Kind Regards Ariel Burbaickij On Wed, Sep 1, 2021 at 9:50 AM Guy Harris <ghar...@sonic.net> wrote: > On Sep 1, 2021, at 12:27 AM, Ariel Burbaickij <ariel.burbaic...@gmail.com> > 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. > ___________________________________________________________________________ > 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 >
___________________________________________________________________________ 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
