The list just keeps growing, and some of these protocols just don't exist in a network anymore. Do we really expect a Token Ring network? IPX? Is there any thought on how dissectors will get removed. It just seems to bloat up WireShark.
I am not sure every token-ring network is dead.
Most of us don't need 90% to 99% of the protocols that are included. Untill the day you find yourself in a decades old environment
Who is crazy enough to still use a 16Mbps 35 year old technology when many networks are over 10,000 Mbps today in the Enterprise. Yes they did come out with a 100Mbps standard that most people didn't adopt. That means the Token Ring network takes 100 seconds to do something that takes 1 second today assuming you were budgeted enough to get the 100Mbps. If you had the more common 4Mbps or 16Mbps That is 1 hour to do something that takes 6 seconds today. It would be hard to even find the bulky Token Ring connectors today let alone any other equipment that is still functioning. I think it would be hard to even locate a bank vault that had any Token Ring equipment in there. There just are no advantages to using it with todays protocols. I can barely get support for software that is over ...
Consider the two extremes no protocols ensbled vs all protocols enabled. In the first case you would have to have enogh knowledge to turn on the protocols needed as we progress trough the protocol stack for each packet.
In the second case wireshark will do its best to dissect each packet to show you the content.
Judging what us obsolete is difficult. What if you want to look at a 20 years old trace as part of education?
What is the gain of removing dissectors?
Whose use case to prioritise?
Having a smaller number of dissectors I believe would prioritize which dissectors would get priority on verification. I am guessing that the dissectors are not verified outside of the original author and if there are no authors, there is no updating of the dissector as the protocol specs update -- outside of bug fix reports. There are bugs in the dissectors and incomplete dissector. I looked through and verified 10s of dissectors as much as I could, but 2000+ is too many to go through all and had no interest in filing bugs for dissectors that are not maintained. I've filed numerous bugs for other projects, and there have been some that just sit there for years not getting fixed. You could implement something like a running annual vote as to which protocols to keep and update the list annually. A dissector could timeout after 5 years. If there have ...
Define bloat, installer, memory or cpu? Looking at the installer for win64 sizes as a proxy for "bloat" I see:
3.2 looks to be a bit of an outlier, 3.2.1 was back down to 57M. The increase from 2.0 to 2.6 was the switch from the GTK to Qt UI and the addition of the extcap interface support. 3.4 gains the new Packet diagram features. All versions have added or improved protocol dissection and added functionality.
To see the increase in "bloat" for dissectors you would have to look at the size of libwireshark (formerly libepan) in installed versions, I'll leave that as an exercise for the interested reader.
The purpose of Wireshark is to allow users to see what's on their network, removing protocol dissectors from the software runs counter to that mission.
A dissector that is not "called" due to no traffic of that protocol being present requires a small amount of memory and no cpu after initial loading. Heuristic dissectors, by their very nature, require some cpu time to determine if their protocol is present when called but can usually be disabled on a per-dissector preference. All dissectors can be optionally disabled via the existing "Enabled Protocols" dialog. These preferences can be saved in a Wireshark "profile".
There are development discussions about a UI and an API to disable dissectors at run-time using some form of grouping but I don't know if that goes as far as stopping the dissectors from registering, they will still be present in the binaries.
You can also build your own custom version including just those protocols you want. Please abide by the Wireshark licence when distributing your own build.
By Bloat, I mean there are over 2000 protocols. I've worked in Networks for 30 years and I have never seen most of these protocols in any network. Why not have the ability to download additional protocols, but the core protocols that come with the default install would only include the protocols used today in most networks.
Because the management of such and the user complaints of "why isn't this working" would be immense. IIRC Microsoft Message Analyser had such a scheme of being able to download extra protocols, but that has now been discontinued. Better to have all the "batteries included".
Feel free to raise an issue at the Wireshark GitLab site detailing how the removal of protocols that you don't use will make Wireshark better for everyone.
Thank you for the feedback. The reason to remove outdated protocols was not for my personal enjoyment. I looked through many WIreShark protocols over the last month on what I could find pcap files for. I found many tiny errors, such as incorrect size, missing fields, incorrect endian, out of order (this could be considered subjective, but definitely not consistent), and one protocol just incomplete. Half the protocol seemed to be there, but then the other half was blanket details left out unlike the other half of the protocol like they didn't finish the dissector. I did not have a sense of what is no longer developed, which ones were actively used, and which ones were too new in active development and known to be incomplete instead of unknown as incomplete. Maybe another idea that would have helped is if the protocols were tagged something like Legacy, Stable, and ...
Asked: 2020-10-30 09:25:39 +0000
Seen: 257 times
Last updated: Oct 30 '20
Copyright Wireshark Foundation, 2017-2023 Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.
