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 <g...@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 <g...@alum.mit.edu> wrote: > On Aug 29, 2016, at 6:09 PM, Michael Mann <mman...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
