Hello Guy,
>
People adding *dissector* support for a new WTAP_ENCAP do not need to
know about it, other than "don't use the LINKTYPE numerical value when
registering in the >wtap_encap dissector table".
this type of issue is IMHO better solved through having a link to a more in-depth explanation if somebody cares/wants/has to read it rather than deciding for them beforehand what they need to know and what they don't. In my example as dissector writer I do not care too much obviously why it happened once I hooked up properly to wtap_encap but in retrospect it was interesting to understand why I spent some half a day in vain trying to utilize "user_dlt" ;-).
Kind Regards
Ariel Burbaickij
On Sep 1, 2021, at 1:33 PM, Ariel Burbaickij <ariel.burbaickij@xxxxxxxxx> wrote:
> thank you very much for your detailed explanations. RIght now OpenBSD is nowhere in the chain but there are some scenarios plausible where it might become part of it. So, if somebody is going to update the Developers' Guide with how user_dlt/wtap_encap for dissector purposes is handled, then why part of it should include the explanations you provided, I reckon.
The only Wireshark developers who have to know or care about LINKTYPEs are:
people adding support for a new LINKTYPE value in the pcap and pcapng reading/writing code;
people adding support for that new value in the pcap and pcapng file dissectors and in dissectors for protocols that send LINKTYPES over the wire, such as the recap protocol.
People adding *dissector* support for a new WTAP_ENCAP do not need to know about it, other than "don't use the LINKTYPE numerical value when registering in the wtap_encap dissector table".
None of those people need to know the history of why there are separate LINKTYPEs and DLTs.
___________________________________________________________________________
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