1. There is already some code in place to have the heuristic dissector tables displayed in a separate tab in the Enable Protocols dialog. Looks like a WIP that was defed out (presumably until it was ready). grep HEUR_DISSECTOR_LIST
2. Because #1, I don't think the architecture is that far off.
3. A suggestion to help with backwards compatibility - We have some code that handles obsolete/removed/changed preferences, part of set_pref() in prefs.c. Perhaps that can be used to read the soon-to-be obsoleted heuristic enable/disable preferences and convert them to whatever "global" structure ends up being created.
-----Original Message-----
From: Hadriel Kaplan <hadrielk@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Cc: mmann78 <mmann78@xxxxxxxxxxxx>
Sent: Sat, Jul 4, 2015 2:38 pm
Subject: Enabling/disabling ANY heuristic dissector
Howdy,
as part of the discussion for several recent bugs and gerrit changes to
add preference settings for various protocols to enable/disable heuristic
dissection, Michael Mann suggested we just provide a way to enabled/disable
*any* heuristic dissector (i.e., for all of them, automagically in code).
For
example, by providing a similar thing as currently available for Protocols with
the 'Analyze->Enabled Protocols' dialog. (well... available in Wireshark-GTK,
not Qt yet)
That seems like a really good idea to me.
The only issue with
it, other than having to inspect and possibly change ~200 files, is whether to
remove the existing heuristic enable/disable preference settings for those
protocols that provide one already. Doing so would break backwards-compatibility
of existing preference files if the user had changed the default for a
heuristic, and break any user script that starts Wireshark/tshark with the '-o’
command-line option to set a heuristic preference, and of course it would likely
change the C-code dynamic plugin API (though that changes all the time).
On
the other hand, we’d be doing this for version 2.0 so such changes are
defendable. And keeping them would be very confusing. And we have removed
preference settings in the past, though probably not in such a large number (~40
preference settings).
Does anyone object to such a change? Or have a
different idea?
-hadriel
