Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...
On Mon, Oct 16, 2017 at 7:09 AM, Richard Sharpewrote: > On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-dev > wrote: >> >> >> >> -Original Message- >> From: Richard Sharpe >> To: Developer support list for Wireshark >> 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 Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...
On Sun, Oct 15, 2017 at 7:36 PM, Michael Mann via Wireshark-devwrote: > > > > -Original Message- > From: Richard Sharpe > To: Developer support list for Wireshark > 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 (何以解憂?唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Reusing the code for various things in ieee802.11 in other dissectors ...
-Original Message- From: Richard SharpeTo: Developer support list for Wireshark 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 > (何以解憂?唯有杜康。--曹操) ___Sent via:Wireshark-dev mailing list Archives: https://www.wireshark.org/lists/wireshark-devUnsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[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. 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.) 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. 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? -- Regards, Richard Sharpe (何以解憂?唯有杜康。--曹操) ___ Sent via:Wireshark-dev mailing listArchives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe