Hello Guy,
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 ?
Kind Regards
Ariel Burbaickij
> On Aug 31, 2021, at 10:37 PM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
>
> Hello Christopher, all,
> as I wrote "... to write Lua dissector...", so instructions what and how to do on command line do not apply in this case. Meanwhile, I figured out by myself how this is supposed to work:
>
> local udlt = DissectorTable.get("wtap_encap")
> udlt:add(wtap.USER1, ypp)
>
> why not to stick to one naming convention of user_dlt
An explanation of various link-layer type indicators:
Wireshark can read several file formats; they do not all use the same numerical values for any given link-layer type.
pcap and pcapng files use the LINKTYPEs specified on
https://www.tcpdump.org/linktypes.html
The numerical values in that file appear in the headers of pcap files and the Interface Description Blocks of pcapng files.
libpcap uses DLTs in its APIs. DLTs are *not* guaranteed to have the same numerical values on all platforms; historically, various OSes have given some DLTs different values on different OSes, so no program should depend on the numerical value; libpcap preserves that, for binary compatibility.
The LINKTYPEs were created to provide values that *would* be guaranteed to be the same, no matter what platform the file is written on; libpcap maps between LINKTYPEs and DLTs.
No current libpcap API uses LINKTYPEs.
Wireshark reads more than just pcap and pcapng files, and some of the files it reads have link-layer types for which there is no corresponding LINKTYPE_ value. Therefore, it has its *own* set of link-layer types - those are the WTAP_ENCAPs.
There is no guarantee that a WTAP_ENCAP that corresponds to a given LINKTYPE has the same numerical value, and there never will be such a guarantee - we don't even guarantee that the numerical values of WTAP_ENCAPs will remain the same from one Wireshark major release to another.
The APIs Wireshark offers to plugins, whether they're for C or Lua plugins, use WTAP_ENCAPs, not LINKTYPEs. There is, therefore, no guarantee that 148 will work as a way to refer to WTAP_ENCAP_USER1, even though the numerical value of LINKTYPE_USER1 is 148. The same applies for all other USERn values from USER0 to USER15 - use WTAP_ENCAP_USERn, not the numerical value for LINKTYPE_USERn, in libwiretap and libwireshark APIs.
The naming convention we use is that, when registering in the "wtap_encap" dissector table with the Wireshark encapsulation value WTAP_ENCAP_xxx, you use WTAP_ENCAP_xxx in C code and wtap.xxx in Lua code.
___________________________________________________________________________
Sent via: Wireshark-users mailing list <wireshark-users@xxxxxxxxxxxxx>
Archives: https://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
