Wireshark mailing list archives
Re: Duplicate protocols in dissector tables
From: Michael Mann <mmann78 () netscape net>
Date: Wed, 4 Nov 2015 07:33:35 -0500
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 () tieto com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> 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 () netscape net> 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 () 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 -- 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 () 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
Current thread:
- Re: Duplicate protocols in dissector tables Michal Labedzki (Nov 04)
- Re: Duplicate protocols in dissector tables Michael Mann (Nov 04)