> On Jul 6, 2015, at 3:12 AM, Guy Harris <guy@xxxxxxxxxxxx> wrote:
>
> 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)?
I had actually been thinking that someday we might indeed offer the ability to control the ordering of heuristic dissectors. I don’t think we need it now, as people seem ok with just disabling a heuristic and there aren’t that many.
There is, I think, a reasonable use-case for disabling a heuristic but keeping the main protocol enabled.
One example is RTP, which is extremely "correct" for its "main" protocol because it’s setup by SIP/H.323/etc., but is often "incorrect" when enabled as a heuristic, either over raw UDP or in TURN messages. (it matches too frequently) Another example is TFTP, which is reasonably correct when its main dissector hooks into port 69, but is badly inaccurate when its heuristic is used over TURN.
I mention those two because at my previous job I had to deal with captures of them, and the gerrit changes 9489 and 9490 to add a preference to disable the TFTP heuristic, and disable RTP over TURN, were what triggered Michael suggesting we make the enabling/disabling of heuristics a general feature.
-hadriel
