Re: Do we really need port preferences for dissectors?

[Michael Mann <mmann78 () netscape net>]

I'm not surprised we're getting those questions, but for me I'd like to work towards the goal of providing an overall 
solution for heuristics and get away from dissector specific ones.  I'm not sure how to get there (reasonably) without 
taking dissector specific decisions away (because it lessens the logic/complexity needed).
Right now the functionality I'm talking about fits into our existing Decode As, so that's why I'm suggesting putting it 
there.  Long term (probably post 2.2 release) I'd like to see Decode As, enable/disable protocols, enable/disable 
heuristic dissectors, "conversation Decode As" (and maybe other items I'm forgetting) all somehow merged into a single 
UI data representation.  But I'm looking at it from the bottom up and questioning whether we have the underlying data 
structures to do such a representation now.  I'm also trying to figure out how to minimize impact to the code required 
in a dissector.  It would be nice if the dissector could be completely ignorant/unchanged and just have all of these 
heuristics done in dissector_try_uint_new (and similar) functions.
 
 
-----Original Message-----
From: Guy Harris <guy () alum mit edu>
To: Developer support list for Wireshark <wireshark-dev () wireshark org>
Sent: Fri, Feb 5, 2016 3:04 pm
Subject: Re: [Wireshark-dev] Do we really need port preferences for dissectors?

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




___________________________________________________________________________
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