Re: Do we really need port preferences for dissectors?

[Guy Harris <guy () alum mit edu>]

On Jan 31, 2016, at 9:11 AM, Michael Mann <mmann78 () netscape net> 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().
___________________________________________________________________________
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