Wireshark-dev: Re: [Wireshark-dev] Do we really need port preferences for dissectors?
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
https://ask.wireshark.org/questions/49893/decode-as-rpc_netlogon-in-wireshark-201
https://ask.wireshark.org/questions/49688/problem-with-ethernet-traffic-encapsulated-within-mpls
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().
