The problem as I see it is that even if we have good heurustic detection. Worst case we might try every heurustic against every packet in the trace and make no match. But if you have traces with say trift or suspected trift you can enable the trift heuristic. Now worst case is trying one heuristic for every packet.
Downside is you will have to know which heuristics to enable, otoh you can always enable all again. Best regards Anders Den ons 19 nov. 2025 20:49Triton Circonflexe <[email protected]> skrev: > Hi, > > Personal opinion here: also default off but with the possibility of > exceptions for heuristic known to have a low rate of false positive (value > of low to be defined, of course). > > The example I have in mind is (of course) Thrift where it is documented in > the code to be very conservative in heuristic mode and tries much harder > when forced with Decode As. > I think that the difficulty with this approach is to define the > “acceptable” rate of false positive (which may very well exclude Thrift > anyway). > > The more magic/fixed bits and bytes the protocol has, mostly in a header, > the less false positive it will generate. > > My 2 cents, > > Triton. > > Le mer. 19 nov. 2025 à 14:53, Anders Broman <[email protected]> a > écrit : > >> Hi, >> Should heuristic (udp/tcp) be default off to speed up dissection of >> larger files? Or >> should we just disable the more unusual ones? >> >> I'm Leaning towards default off and users would have to learn to enable >> relevant ones. >> Or is that too much to ask from inexperienced users? On the other hand it >> can be hard to >> know if a heuristic detection is a false positive. >> Best regards >> Anders >> _______________________________________________ >> Wireshark-dev mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Wireshark-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
