OK, so even with all that omissions of topics far and close to Wireshark
and whatever differences in tastes/approaches, can we take a look at the
first draft of the additions to the documentation, if any?
Kind Regards
Ariel Burbaickij
On Thu, Sep 2, 2021 at 10:13 AM Guy Harris wrote:
> On Sep
On Sep 2, 2021, at 12:05 AM, Ariel Burbaickij
wrote:
> 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.
*ANY*
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
On Sep 1, 2021, at 1:33 PM, Ariel Burbaickij 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
Hello Guy,
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,
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
On Sep 1, 2021, at 12:27 AM, Ariel Burbaickij
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
>
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,
> On Aug 31, 2021, at 10:37 PM, Ariel Burbaickij
> 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
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
> From: Wireshark-users On Behalf Of
> Ariel Burbaickij
> Sent: Monday, August 30, 2021 4:20 AM
> To: Community support list for Wireshark
> Subject: [Wireshark-users] any examples of how to hook up Lua dissector to
> user_dlt tree?
>
> Hello community,
> I would like to write Lua dissector
Hello community,
I would like to write Lua dissector for a binary, i.e. not text,
proprietary protocol on top of user_dlt. Are there any examples available,
which roughly show how this is done ? Could you point me to them as I have
not found much interesting yet.
In particular, how actual hooking
12 matches
Mail list logo