Wireshark-dev: Re: [Wireshark-dev] Duplicate dissectors error
From: Guy Harris <[email protected]>
Date: Mon, 29 Aug 2016 19:43:06 -0700
On Aug 29, 2016, at 7:05 PM, Guy Harris <[email protected]> wrote:

> On Aug 29, 2016, at 6:09 PM, Michael Mann <[email protected]> wrote:
> 
>> Yes, that's the main side effect, and if all the registering is with proprietary dissectors, it's your users that have to deal with it.
>> Solutions are:
>> 1. Change dissector table to allow duplicates.
>> 2. Create "placeholder" protocols (you'll see a few examples in native Wireshark dissectors) so that each can show up differently in Decode As.
> 
> Or
> 
> 3. In dissector_add_for_decode_as(), if you find an entry in the list of "for decode as" handles for the same handle it was asked to add, just silent ignore the request to add it.
> 
> That way, if the same handle is added multiple times - for example, if that handle is used for multiple different keys in a dissector table, so that dissector_add_for_decode_as() is called multiple times for that handle and that dissector table - there's never any output.
> 
> If that means we can get rid of the allow_dup_proto flag, great!

Actually, it's uglier than that.

For example, the GTPv2 dissector module registers a bunch of dissectors for particular Diameter AVPs with the GTPv2 protocol, even though they're not actually dissecting GTPv2 packets.  Those are, I suspect, unlikely to be of any use with "Decode As" - they don't correspond to "decode this AVP's value as a GTPv2" dissectors - and they don't deserve protocols of their own.

That causes some "duplicate" registrations, none of which really need to be done - not even the first of them!

So we probably either 1) need to have a way of marking dissector tables as "doesn't need Decode As" or 2) marking a registration in a dissector table as "this isn't useful for Decode As".