Wireshark mailing list archives
Re: Disabling a dissector doesn't seem to quite work.
From: Evan Huus <eapache () gmail com>
Date: Fri, 7 Sep 2012 18:09:09 -0400
On Fri, Sep 7, 2012 at 5:47 PM, Maynard, Chris <Christopher.Maynard () gtech com> wrote:
Recently another old proprietary protocol (I’ll call it FOO) was brought to my attention, and I was asked to write a dissector for it. In doing so, I discovered a conflict with another dissector, namely SNA. Initially I thought that simply disabling SNA when analyzing FOO would be good enough for our purposes; however, even after disabling SNA, the FOO dissector was never called. The conflict arises because both dissectors, SNA and FOO, register as follows: dissector_add_uint("llc.dsap", SAP_SNA2, [sna|foo]_handle); I found that even with SNA disabled, I had to comment out the above line of code from the packet-sna.c source file before LLC would successfully hand off dissection to FOO. To illustrate this, I’ve attached a very stripped down and slightly modified version of packet-foo.c, along with a simple foo24.pcap file in case anyone would care to take a look at it. I have since found an alternate solution, but I was surprised that disabling a protocol does not seem to have the completely desired effect. While the packet does not get dissected as SNA, other dissectors are apparently not given the opportunity to dissect the packet even when the SNA dissector is disabled. But beyond LLC and SNA, I was thinking/wondering that maybe this is a general problem affecting all dissectors and that some general solution might be needed?
A couple of problems here: - When two protocols register with the same uint value in a table, the second one just overwrites the first. - When two protocols register with the same uint value in a table, we leak memory. It's visible in valgrind, as there are already a couple in the default build. Just run "libtool --mode=execute valgrind --leak-check=full ./tshark" and grep for "dissector_add_uint". - Even disabled protocols are registered, and thus are added to the appropriate table. This can overwrite enabled protocols, depending on registration order. I've got somewhere to be right now, but I'll try and do further analysis this weekend. Evan ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Disabling a dissector doesn't seem to quite work. Maynard, Chris (Sep 07)
- Re: Disabling a dissector doesn't seem to quite work. Evan Huus (Sep 07)
- Re: Disabling a dissector doesn't seem to quite work. Evan Huus (Sep 08)
- Re: [Wireshark-dev] Disabling a dissector doesn't seem to quite work. Christopher Maynard (Sep 15)
- Re: Disabling a dissector doesn't seem to quite work. Guy Harris (Sep 15)
- Re: Disabling a dissector doesn't seem to quite work. Joerg Mayer (Sep 16)
- Re: Disabling a dissector doesn't seem to quite work. Guy Harris (Sep 16)
- Re: Disabling a dissector doesn't seem to quite work. Joerg Mayer (Sep 17)
- Re: Disabling a dissector doesn't seem to quite work. Evan Huus (Sep 08)
- Re: Disabling a dissector doesn't seem to quite work. Evan Huus (Sep 07)
- Re: [Wireshark-dev] Disabling a dissector doesn't seem to quite work. Christopher Maynard (Sep 15)
- Re: Disabling a dissector doesn't seem to quite work. Evan Huus (Sep 15)
- Re: Disabling a dissector doesn't seem to quite work. Bill Meier (Sep 15)
- Re: Disabling a dissector doesn't seem to quite work. Jeff Morriss (Sep 17)