On Aug 29, 2016, at 7:05 PM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
> On Aug 29, 2016, at 6:09 PM, Michael Mann <mmann78@xxxxxxxxxxxx> 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".
