Re: Enabling/disabling ANY heuristic dissector

[Anders Broman <a.broman58 () gmail com>]

Den 6 jul 2015 09:12 skrev "Guy Harris" <guy () alum mit edu>:
> 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)?

Another use case might be "I'm not interested in any(or few ) heuristics
and don't want the performance hit of checking for them." I think quite a
few heuristics are for some of the more isoteric protocols.
Regards
Anders

>
___________________________________________________________________________
> 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