With:
https://code.wireshark.org/review/9508/
https://code.wireshark.org/review/9610/
(and already submitted https://code.wireshark.org/review/9602/)
I consider this "feature complete enough for now". If Qt wants to provide a
better "user interface" for "heuristics in general", it certainly has some
flexibility to do so. Unless there are major issues/comments, I'll submit in a
few days (presuming all pass Petri-Dish)
-----Original Message-----
From: mmann78 <[email protected]>
To: wireshark-dev <[email protected]>
Sent: Fri, Jul 10, 2015 8:45 pm
Subject: Re: [Wireshark-dev] Enabling/disabling ANY heuristic dissector
Some more thoughts about enabling/disabling heuristic dissectors based on some
of the comments in the Gerrit review as well as this thread.
1. I'm now leaning more towards heuristic dissectors having their own name so
something "more intelligible" can be presented to the user. Right now we have
heuristic dissector tables that just link a dissection function with a protocol
(and that's put in a named table). The "protocol name" is not enough to easily
identify the heuristic to a user (but is enough for our current "internals").
With some of the "popular" protocols (Ethernet, IP, TCP, UDP), it is fairly
easy to figure out what's going on by concatenating "protocol name" and "table
name" (ex ADwin-Config/udp can be understood to be "ADwin-Config over UDP"),
but some dissectors are not really protocols and it just ends up looking ugly
in the list (ex RPCoRDMA/infinitiband.mad.cm.private). The same can be said
for some "dissectors" (that really aren't "protocols") that ended up on the
other "Enabled Protocols" tab. This can happen when "identifier based
dissectors" aren't really protocols but fit nicely into the provided internal
architecture.
2. I'm currently using the GTK GUI because work was already partially done
towards the goal of a tabbed dialog that enabled/disabled heuristic dissectors.
However, I'm more interested in setting up the "epan code" to ensure the
pieces are in place so any (Qt) GUI is capable of presenting something to the
user that isn't just the "raw internals". Some of the suggestions that have
been made sound good, but the pieces aren't currently in place to connect the
dots (and some look to require A LOT of work in the "epan code"). I'm okay
with the GTK GUI version being "barebones" and mostly mimicking the current
"Enabled Protocols" tab. Qt can find a way to "pretty it up", but we can have
the functionality in the mean time. I'm mostly looking to finalize the
"disabled_heuristics" file format so that doesn't have to be reworked (which
could be a PITA if someone started using it, even if its between nightly
builds)
3. Not sure how to integrate "all" heuristics together. Ideally preferences,
Decode As, the heuristic tables and even "identifier based" tables would all
factor into the Big Switch, but right now each serves it own purpose and can
provide specific granularity to certain use cases (usually allowing a user to
override a "default (dissection/dissector) behavior" Wireshark provides). The
current Gerrit patch is just a small step in the right direction.
-----Original Message-----
From: Guy Harris <[email protected]>
To: Developer support list for Wireshark <[email protected]>
Sent: Mon, Jul 6, 2015 3:12 am
Subject: Re: [Wireshark-dev] Enabling/disabling ANY heuristic dissector
On Jul 5, 2015, at 9:33 PM, Hadriel Kaplan <[email protected]> wrote:
> My
2 cents:
>
>> On Jul 5, 2015, at 11:32 PM, Guy Harris <[email protected]>
wrote:
>>
>> "Heuristic Protocol" or "Heuristic Dissector”?
>
> While
“Dissector” makes more sense to me personally, do most users/IT-folks understand
what a “Dissector” is?
That's why I prefer "Protocol". Let's not let too
much of the internals show through.
> I think a single table will be more
confusing since several protocols have heuristic dissectors for more than one
underlying transport/protocol type. Of course we could just enable/disable a
protocol’s heuristics for all underlying transports as all-onf/off... but I’m
just sure someone will have some reasonable use case for enabling heuristics for
some protocol over TCP but not UDP or vice-versa, and then we’d be back to
creating a preference for that protocol to do so.
So what exactly is the use
case for disabling "identifier-based" protocols?
Avoiding buggy
dissectors?
Disabling a level of protocol in which you're uninterested, so
that, for example, the Info column reflects the highest protocol level in which
you *are* interested?
For both of those cases, that's a use case for a Big
Switch for the protocol that switches off *all* dissectors for the protocol,
"identifier-based" and heuristic, no matter what protocol it's running
atop.
The use case for some but not other underlying protocols would appear
to be "traffic atop protocol X is rarely if ever mis-identified as being for
protocol Z, so leave the heuristic on, but traffic atop protocol Y is often
mis-identified as being for protocol Z, so turn the heuristic off". Would that
be better handled by, for example, a UI to allow the user to specify the order
in which heuristic checks are done, or something such as that (and a
command-line option to do the same, so that this same functionality is available
in
TShark)?
___________________________________________________________________________
Sent
via: Wireshark-dev mailing list <[email protected]>
Archives:
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent
via: Wireshark-dev mailing list <[email protected]>
Archives:
https://www.wireshark.org/lists/wireshark-dev
Unsubscribe:
https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <[email protected]>
Archives: https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:[email protected]?subject=unsubscribe
