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@xxxxxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
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@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().
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <
wireshark-dev@xxxxxxxxxxxxx>
Archives:
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
