On Fri, Sep 7, 2012 at 5:47 PM, Maynard, Chris
<Christopher.Maynard@xxxxxxxxx> 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