ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-dev: Re: [Wireshark-dev] Why some Dissectors are registered and others not ?

From: Anders Broman <a.broman@xxxxxxxxx>
Date: Wed, 12 Jan 2011 20:13:58 +0100
Sandwood Sandwood skrev 2011-01-12 19:49:
A good example is "es-is" and "is-is" protocol.

packet-esis.c  line 436  : register_dissector("esis", dissect_esis, proto_esis)

=> In LUA, we can retreive and use the ESIS Dissector
(Dissector.get("esis)  succeed)

packet-isis.c : the register_dissector("isis",dissect_isis, proto_isis)  is NOT called.

=> In LUA, we can not retreive and use the ISIS Dissector

Everthing is ready to call the register_dissector function, and still this call is not made.


Is there a performance issue  ?

Yes :-)
Or is this just an inconsistancy ?
Yes :-))

Seriously; of course the bigger the table over dissector names are the longer it will take to find something
in it, but as a hash table is used I'm not sure how much of an performance hit it is.

The main reason is probably that if the dissector writer or others saw no need to be able to find its handle.
So that function call newer got implemented.
Perhaps we should consider to change proto_register_protocol()
to also register by name using "PFNAME" perhaps.  In the mean time you could write a bug report listing the dissectors you need to be registered by name or submit a patch.

Regards
Anders

The same conclusion can be tracked on a lot of dissectors.

It is very frustrating and confusing when  writting LUA scripts because until opening the wireshark code,
 it is impossible to understand why the Dissector.get function failed on an existing dissector.

Thanks,
Fabien


___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe