Wireshark mailing list archives
Re: The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way
From: Michael Mann via Wireshark-dev <wireshark-dev () wireshark org>
Date: Tue, 8 Jan 2019 01:33:35 +0000 (UTC)
There are a number of dissector tables used, so I thought the TAGs and Extended TAGs could be moved around. You would just have to move thedissector_add_uint("wlan.tag.number", … along with the function. If enums/value_strings need to be shared for breaking the dissector up into multiple files, those could go in a header file. We just don't like to create header files for the sake of storing things that will just be used by a single .c module. Currently dissector tables just work with "the last value set to it". Within dissector_add_uint, there is the dissector_add_uint_sanity_check(), but it's #if 0ed out. I think that's very intentional, but I can see the need to make it conditionally defined out (like we have for some of the hf_ checks). -----Original Message----- From: Richard Sharpe <realrichardsharpe () gmail com> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Sent: Thu, Jan 3, 2019 12:07 pm Subject: [Wireshark-dev] The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way Hi folks, I am sure that most people who work on the ieee80211 dissector will agree that it is a monster that needs taming. It is currently more than 37,000 lines long and a number of things that have been done in it make it hard to split it in rational ways. Perhaps the way that the Wi-Fi community does standards also makes things difficult, but some of the issues I see are: 1. TAGs and Extended TAGs (for IEs) have to be defined in packet-ieee80211.c and thus are hard to split out to other files. It would be nice if there was some way to register new tags and extended tags with errors if you are registering an already registered value. 2. The IE handling code handles placing the TAG and length into the tree, also forcing the handling of IEs into packet-ieee80211.c. It would be better if there was a function to handle the header, that could perhaps be passed a function pointer to handle the body so we can spit things out. 3. It is damn hard to find fixed fields that have been implemented ... And so on. I am sure that others can think of further deficiencies. It would be useful to compile a list so we can look at reworking the Wi-Fi suite of dissectors to make them more maintainable over time. Please respond with your thoughts. -- Regards, Richard Sharpe (何以解憂?唯有杜康。--曹操)(传说杜康是酒的发明者) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way Richard Sharpe (Jan 03)
- Re: The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way Guy Harris (Jan 03)
- Re: The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way Alexis La Goutte (Jan 07)
- Message not available
- Re: The 802.11 dissector is a big hairy ball of wax that needs to be refactored in some way Michael Mann via Wireshark-dev (Jan 07)