Re: Duplicate dissectors error

[Michael Mann <mmann78 () netscape net>]

I'm pretty sure that when the "decode as structure" is registered by a dissector that the dissector table used in that 
is *required* to have allow_dup_proto flag set to FALSE.  Otherwise it could be ignored.
However, when the allow_dup_proto flag was added, I tried to be as strict as possible in case more dissector tables 
started using Decode As (and the issue would have to be addressed then).  When developing, I initially set all 
dissector table registrations to have allow_dup_proto flag = FALSE, and then ran Wireshark/TShark to see how many 
"complaints" I got.  The "justified" ones  (i.e.  those not using Decode As) were changed to "duplicates allowed".  
Subsequent patches have been submitted for cases like GTPv2 that don't use Decode As (and where proprietary dissectors 
triggered the assert), so the dissector table can be "duplicates allowed".
 
 
 
-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Mon, Aug 29, 2016 10:43 pm
Subject: Re: [Wireshark-dev] Duplicate dissectors error

On Aug 29, 2016, at 7:05 PM, Guy Harris <guy () alum mit edu> wrote:

> On Aug 29, 2016, at 6:09 PM, Michael Mann <mmann78 () netscape net> 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".
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

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