ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

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

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 5 Feb 2016 12:04:12 -0800
On Jan 31, 2016, at 9:11 AM, 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,

Including at the UI level; we're now getting "OK, I could change this setting in 1.12, but that setting disappeared in 2.0, how do I do that in 2.0?" questions, such as

and, as I remember, others.

Perhaps there needs to be a UI for changing persistent Decode As settings that makes it easier to point people to them - something that lets you see the settings for a particular protocol in the same way that the Preference dialog does.

BTW, at least some use cases of Decode As are really "decode *this particular conversation in this particular capture* as XXX"; it might be useful to have a UI for *that*, which *doesn't* affect any persistent settings, but just sets the dissector with conversation_set_dissector().