Re: Enabling/disabling ANY heuristic dissector

[Pascal Quantin <pascal.quantin () gmail com>]

Le 13 juil. 2015 3:03 AM, <mmann78 () netscape net> a écrit :
> 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)

Hi Michael,

Sorry I come late in the discussion. I do not have access to a computer
right now so I cannot easily look at the patch (the latest Gerrit diff page
is rather smartphone unfriendly) but is there a way to activate heuristic
dissectors from tshark / wireshark command line? I use an external tool
launching both programs with the right command line and it would be a real
functionality loss if it could not be done anymore.
Note that I consider your overall goal as a good achievement (it was
frustrating not to be able to deactivate easily some weak heuristics) but I
would dislike losing the ability to activate on demand a given heuristic
that is deactivated by default for performance reasons.

Pascal.

> -----Original Message-----
> From: mmann78 <mmann78 () netscape net>
> To: wireshark-dev <wireshark-dev () wireshark org>
> 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 <guy () alum mit edu>
> To: Developer support list for Wireshark <wireshark-dev () wireshark org>
> 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 <hadrielk () yahoo com> wrote:
>
> > My
> 2 cents:
> > > On Jul 5, 2015, at 11:32 PM, Guy Harris <guy () alum mit edu>
> 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 <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
___________________________________________________________________________
> 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