On Mon, Oct 16, 2017 at 7:09 AM, Richard Sharpe
<realrichardsharpe@xxxxxxxxx> wrote:
> 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 ...)
It's worse than I thought :-) The structure I am interested in is
dissected as part of the function ieee80211_tag_measure_rep in the
802.11 dissector ...
I guess I could break it out and make another dissector table.
However, there is also the issue of filter fields as well ...
>>>
>>> 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
> (何以解憂？唯有杜康。--曹操)
--
Regards,
Richard Sharpe
(何以解憂？唯有杜康。--曹操)