Ok, I definitely did not want it to be received like that. I agree that we should adapt and improve the program. That being said, I fought tooth and nails with my former colleagues to get them to understand and use Wireshark. My fear is just, if they cannot do this out of the box, Wireshark will be labeled as "useless" by such people. I agree with you in the sense that we should check if there are really dissectors that need to be always enabled and run, but it is a slippery slope. And I also agree, that we already have the possibility to configure the program, but the majority of users - blissfully or due to ignorance - does not know about that.
cheers Roland Am Do., 20. Nov. 2025 um 22:57 Uhr schrieb Anders Broman < [email protected]>: > >Wireshark should behave like it always did > > So we're done nothinhg to be added to the program. ;-) > > We have preferences to to tune wireshark to individual needs. The default > should be someting resonable. I thought I found "rare" protocols very few > people would find in their traces and the ones that would, would find them > missing and enable the heuristic. > > But it seems the majority dissagrees. > > > > Den tors 20 nov. 2025 22:35Roland Knall <[email protected]> skrev: > >> Bad example, that protocol is actually quite in use in games and some >> industrial applications ;-) >> >> Am Do., 20. Nov. 2025 um 20:48 Uhr schrieb John Thacker < >> [email protected]>: >> >>> Another group is "obsolete." I think even people skeptical about the >>> idea in general are easily on board with the idea of disabling the Yahoo >>> Messenger protocol that hasn't been a commercial protocol in well over a >>> decade. >>> >>> On Thu, Nov 20, 2025, 2:46 PM Triton Circonflexe < >>> [email protected]> wrote: >>> >>>> The profile-based presets looks like a good approach. >>>> How would these profiles get generated? >>>> - Hard-coded lists? >>>> - “Tags” in the dissectors indicating to which categories they belong? >>>> >>>> In any case, we can start with a few obvious sets like the “safe” one >>>> proposed by John and most of the ones proposed by Anders (also not sure >>>> about Bittorrent as a category, seems too specific). >>>> I may suggest the "Web" category including the dissectors for the >>>> content of the data since there’s not much heuristics between frame and >>>> HTTP. >>>> >>>> >>>> Le mer. 19 nov. 2025 à 21:46, Anders Broman <[email protected]> a >>>> écrit : >>>> >>>>> Protocol groups might help. Should be at least x(10?) dissectors or >>>>> large ones. >>>>> Group Ideas: >>>>> Telco ( Better name? POTS, 2G, 3g etc) >>>>> File Storage ( DCE-RPC etc) >>>>> Car industry (ITS, CAN? ... >>>>> HomeAutomation ( Zigbee? ... >>>>> Bittorrent? >>>>> Games >>>>> ... >>>>> Best regards >>>>> Anders >>>>> >>>>> >>>>> Den ons 19 nov. 2025 kl 22:04 skrev John Thacker < >>>>> [email protected]>: >>>>> >>>>>> On Wed, Nov 19, 2025 at 3:59 PM Anders Broman <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> 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. >>>>>>> >>>>>> >>>>>> There's a "No Reassembly" profile that is automatically generated by >>>>>> a Python scripts in the tools directory that disables all the reassembly >>>>>> related preferences. I think it would be helpful to have extra default >>>>>> profiles that target different levels of enabled heuristic dissectors. (A >>>>>> profile optimized for speed with very few enabled, only reliable ones, >>>>>> only >>>>>> ones you might see on the public Internet but not industrial protocols, >>>>>> etc.) I think that both inexperienced and experienced users alike might >>>>>> want to quickly switch between large numbers of heuristics enabled and >>>>>> disabled without having to do it individually. If I am trying to >>>>>> characterize a completely unknown capture where I don't know what is >>>>>> there >>>>>> I have a different use case than a network where I already have a good >>>>>> idea >>>>>> what to expect. >>>>>> >>>>>> Cheers, >>>>>> John >>>>>> _______________________________________________ >>>>>> 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] >>>> >>> _______________________________________________ >>> 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] >
_______________________________________________ Wireshark-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
