Wireshark · Wireshark-dev: Re: [Wireshark-dev] Duplicate protocols in dissector tables

[Michael Mann <mmann78@xxxxxxxxxxxx>]

The original intent was of the patch was targeting a protocol that had multiple dissectors because of slight differences in dissection, but a common entry point (like ethertype or TCP/UDP port) so it was confusing to users when presented with the Decode As dialog.  I wouldn't necessarily expect custom/vendor extensions like that to show up in the officially released version of Wireshark, but yes, you are now forced to make changes like you outlined below if the situation arises.

Your example seems more legitimate than some of the cases I ran into.  For some, there are just "placeholder" protocol names (as noted by the comments in those dissectors)

 

 

 

-----Original Message-----
From: Michal Labedzki <michal.labedzki@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Wed, Nov 4, 2015 4:31 am
Subject: Re: [Wireshark-dev] Duplicate protocols in dissector tables

Hello,

If I understand correctly it is ok to have custom/vendor for example
XXX
dissector, but it name must be different then original dissector.
For example IP
dissector. Wireshark has:
> proto_register_protocol("Internet Protocol Version
4", "IPv4", "ip")

So I think about create my custom IP dissector, so all I need
to do is:
> proto_register_protocol(" My Internet Protocol Version 4", "My
IPv4", "ip")
or better:
> proto_register_protocol(" My Internet Protocol Version
4", "My IPv4", "my_ip")

Then I can use Decode as to choose between builtin "ip"
and "my_ip"
dissectors, right?
For example:
  dissector_add_uint("ethertype",
ETHERTYPE_IP, ipv4_handle);
  dissector_add_uint("ethertype", ETHERTYPE_IP,
my_ip_handle);

If so, I am ok with this change.

On 29 October 2015 at 17:01,
Michael Mann <mmann78@xxxxxxxxxxxx> wrote:
> I wrote a patch
(https://code.wireshark.org/review/1405/) that may require
> discussion, so I
thought I'd do it with a broader audience (because it
> impacts many dissectors
whose individual authorship doesn't need to be added
> to a single Gerrit
review)
>
> The patch fixes bug 3949
>
(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3949) by enforcing that
>
dissector tables that are used by Decode As can't have the same "protocol"
>
(name) in multiple entries (exception - FT_STRING because the string value
> is
used in the Decode As dialog, not the protocol name).  I've made a few
> patches
in the past that fixed some of the duplicates by visual inspection,
> but this
patch allows the code to do the work to ensure nothing was missed.
>
> The part
I felt was more "up for debate" was that I "defaulted" dissector
> tables to not
allow duplicates.  As a test, I made all dissector tables not
> allow
duplicates, then used printf and TShark to see how many duplicates
> there were.
If the dissector table wasn't used for Decode As, I would
> switch it to
allowing duplicates.  Is that the way to go?  Should I
> "default" FT_STRING
dissector tables to always allow duplicates?
>
> The problem is that I'm limited
to the dissector source in Wireshark and if
> there are dissector tables with
known/intentional third-party dissectors
> with duplicate protocol registration,
they will end up getting flagged.  I'd
> like to limit the number of follow-up
commits with dissectors being
> corrected for allowing duplicates.  If you have
specific dissector tables
> that you think should allow duplicates (or didn't
like my "duplicate
> replacement"), please post in the review or email me
privately.  The dialog
> I'm going for in the mailing list is for more general
approaches (like all
> ASN.1 dissector tables should allow duplicates or you
think the "default"
> should be to allow duplicates for all dissector
tables)
>
> I also plan to backport this to 2.0 (because I want the API change
in there
> before it can't be changed).  Opinions on that welcome as
well.
>
>
>
>
___________________________________________________________________________
>
Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
>
Archives:    https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
>             
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe



--


Pozdrawiam / Best
regards
-------------------------------------------------------------------------------------------------------------
Michał
Łabędzki, Software Engineer
Tieto Corporation

Product Development
Services

http://www.tieto.com / http://www.tieto.pl
---
ASCII: Michal
Labedzki
location: Swobodna 1 Street, 50-088 Wrocław, Poland
room: 5.01 (desk
next to 5.08)
---
Please note: The information contained in this message may be
legally
privileged and confidential and protected from disclosure. If the
reader
of this message is not the intended recipient, you are hereby
notified that any
unauthorised use, distribution or copying of this
communication is strictly
prohibited. If you have received this
communication in error, please notify us
immediately by replying to
the message and deleting it from your computer. Thank
You.
---
Please consider the environment before printing this e-mail.
---
Tieto
Poland spółka z ograniczoną odpowiedzialnością z siedzibą w
Szczecinie, ul.
Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym
Szczecin-Centrum w
Szczecinie, XIII Wydział Gospodarczy Krajowego
Rejestru Sądowego pod numerem
0000124858. NIP: 8542085557. REGON:
812023656. Kapitał zakładowy: 4 271500
PLN
___________________________________________________________________________
Sent
via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives:   
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
            
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe