Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

From: Michael Mann <mmann78@xxxxxxxxxxxx>
Date: Fri, 5 Feb 2016 11:38:30 -0500
Glad to get some positive feedback before going down that rabbit hole.  It shouldn't take that long to figure out how to convert the prefs into Decode As format, it's just there are probably about 200 port preferences (rough estimate from grepping prefs_register_uint_preference which returned about 300 results)
-----Original Message-----
From: Alexis La Goutte <alexis.lagoutte@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Fri, Feb 5, 2016 11:26 am
Subject: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

On Sun, Jan 31, 2016 at 6:11 PM, Michael Mann <mmann78@xxxxxxxxxxxx> wrote:
I've ran across a bunch of dissectors lately that don't have an IANA registered port, so they add a port preference.  This is done is one of two ways:
1. Assigning their "randomly picked" port number to the preference, possibly requiring a user to change (set to 0) if it interferes with their traffic.  Since these are usually niche protocols, I can understand someone being annoyed by the "interference".
2. Defaulting port preference to 0, then making sure it's non-zero when registering with the (TCP/UDP) dissector table.  If not careful, sometimes the dissector isn't registered at all, so Decode As can't be used.
Since Decode As can also be persistent, wouldn't that be a better way to (force users to) go?  To me it has similar logic/justification as when I removed the "subdissector preferences" in favor of Decode As.  While it would be nice to have users go to a single place to decide a "heuristic hierarchy" (a subject that is touched on from time to time), having port preferences seems to spread it out more than necessary.
I'm hesitant because of the number of backwards compatibility issues it could introduce, but if we converted the preferences into the Decode As structure (if found), wouldn't that alleviate a lot of it? 
I'm more okay with keeping "range" preferences for protocols (at least for now) as that seems a more tedious task to do with Decode As.
Hi Michael,

I can be a good idea... because Preference and Decode as is redundancy... but yes need have option to "convert" actual pref ! 

Sent via:    Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>

Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>