Wireshark-dev: Re: [Wireshark-dev] The 802.11 dissector is a big hairy ball of wax that needs t
From: Michael Mann <[email protected]>
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 the
dissector_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 <[email protected]>
To: Developer support list for Wireshark <[email protected]>
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

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.

Richard Sharpe
Sent via:    Wireshark-dev mailing list <[email protected]>
            mailto:[email protected]?subject=unsubscribe