On Mon, Oct 16, 2017 at 7:09 AM, Richard Sharpe <[email protected]> wrote: > On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev > <[email protected]> wrote: >> >> >> >> -----Original Message----- >> From: Richard Sharpe <[email protected]> >> To: Developer support list for Wireshark <[email protected]> >> 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 (何以解憂？唯有杜康。--曹操) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
