Wireshark-dev: Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other d
-----Original Message-----
From: Richard Sharpe <realrichardsharpe@xxxxxxxxx>
To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
Sent: Sat, Oct 14, 2017 1:47 pm
Subject: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...
> Hi folks,
>
> I am almost finished a dissector for the IEEE1905 Multi-AP technical
> specification draft from August 2017. The work was done for an
> organization in the industry. It is pretty complete and has undergone
> testing with real traffic.
>
> Unfortunately, they make references to elements in IEEE802.11 2016.
>
> One specific item is 9.4.2.22.7 Beacon Reports from IEEE802.11 2016.
> There is another such reference as well.
I'm not familiar enough with the protocols to know where exactly this is in the dissector. I recently created a dissector table for tagged fields ("wlan.tag.number"). I'm guessing this is where the beacon stuff is, so yes existing dissector tables should handle this.
>
> These raise problems:
>
> 1. I don't want to duplicate code
> 2. The code in the current packet-ieee80211.c dissector is incomplete
> WRT the 2016 version of the spec. (Eg, it does not handle Vendor
> specific or Wide Bandwidth Channel Switch optional sub-elements.)
I also created a few dissector tables in packet-ieee80211.c for vendor specific extensions. Most of the cases involved multiple vendors that were already in the dissector. I think a few more could probably be created. Most of the ones I left only had OUI_WFA as the only vendor, so I lost interest in the conversion to adding more dissector tables.
> 3. The references in IEE1905 are to the underlying structures not the
> tagged structures.
> 4. The code in packet-ieee80211.c is declared static so I can't call
> it if I wanted to.
Again, specifics about the code are more helpful to me.
>
> We have mechanisms for dealing with this. One is dissector tables.
> Another is to declare certain functions non-static and put the
> definitions in header files. There might be others.
>
> Are there any suggestions?
Without seeing the code, I would lean towards suggesting dissector tables as the solution for most of it. Removing "static" from functions and declaring them in header files should be more of a last resort.
You can put your patch up for review, even if it is just a WIP. Marking where you don't want to duplicate code or where you want to call (currently static) packet-ieee80211.c functions would be helpful.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
