Re: Duplicate dissectors (anonymous) and (anonymous) for protocol xxx

[Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>]

If you create separate dissector handles with a protocol, how is a user using "Decode As" functionality supposed to 
know which dissection function will be picked?  That's why the check was added.
You can have the same protocol ID between TCP and UDP, but you can't have the same one twice in TCP.

To me there are 2 solutions
1. Create "placeholder" protocols with proto_register_protocol().  The "protocol lD" returned can be used to 
differentiate the different dissector function handles
2. Create a "pino" (protocol in name only) with proto_register_protocol_in_name_only.  This allows you to create 
"helper" protocols, with most of the "control" still with the "parent" protocol created with proto_register_protocol.
 
I believe #2 is the "preferred" solution.
 
 
 
-----Original Message-----
From: John Dill <John.Dill () greenfieldeng com>
To: wireshark-dev <wireshark-dev () wireshark org>
Sent: Wed, Oct 25, 2017 4:44 pm
Subject: [Wireshark-dev] Duplicate dissectors (anonymous) and (anonymous) for protocol xxx



I just happened to turn on console printing to troubleshoot a different problem and I'm getting a couple of interesting 
messages when I change my protocol preferences.
 
Duplicate dissectors (anonymous) and (anonymous) for protocol xxx in dissector table tcp.port
Protocol <Protocol Description> is already registered in "udp" table.
 
I have a proto_reg_handoff_xxx that creates a couple of TCP port dissector handles using 
'dissector_add_uint("tcp.port", MY_TCP_PORT, tcp_handle)', and a UDP heuristic dissector 'heur_dissector_add("udp", 
dissect_xxx_udp_heur, "<Protocol Description>", "xxx", proto_xxx, HEURISTIC_ENABLE)'.
 
My question is whether I'm doing something not recommended.  The protocol uses both TCP and UDP packets to send data, 
and I've lumped it under one "xxx" protocol.  For the most part, it hasn't been an issue operationally, but I'm 
wondering if there's a better way to do it so I don't have these messages.  I haven't looked at the console output in 
detail before, so I've missed this up till now.
 
Is there any advice about dissecting a protocol that appears on both TCP and UDP streams and using the same name, or 
what I'm doing specifically that's causing it?  The messages have the same format, but the packaging in the TCP vs the 
UDP streams is slightly different.
 
Best regards,
John D.
 

___________________________________________________________________________Sent via:    Wireshark-dev mailing list 
<wireshark-dev () wireshark org>Archives:    https://www.wireshark.org/lists/wireshark-devUnsubscribe: 
https://www.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://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe