Re: any examples of how to hook up Lua dissector to user_dlt tree?

[Ariel Burbaickij <ariel.burbaickij () gmail com>]

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 Wed, Sep 1, 2021 at 8:48 AM Guy Harris <gharris () sonic net> wrote:

> > On Aug 31, 2021, at 10:37 PM, Ariel Burbaickij <
> ariel.burbaickij () gmail com> 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 () wireshark org>
> Archives:    https://www.wireshark.org/lists/wireshark-users
> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-users
>              mailto:wireshark-users-request () 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-request () wireshark org?subject=unsubscribe