On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev
<wireshark-dev@xxxxxxxxxxxxx> wrote:
>
>
>
> -----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.
The problem with this is likely to be point 3 below because the
structure as used by IEEE1905 is not tagged (although it does contain
TLVs ...)
>>
>> 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.
It will be coming as a patch soon ... :-)
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)
