On Fri, Aug 21, 2015 at 7:14 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Aug 21, 2015, at 7:34 AM, Jeff Morriss <jeff.morriss...@gmail.com> wrote: > >> It appears that the 802.11 dissector calls >> proto_tree_traverse_post_order()/is_80211ad() in order find the value of a >> field (hf) named "Channel frequency"; if the value is one of the AD >> frequencies then the dissector, well, treats it as AD. > > The only fields named "Channel frequency" are radiotap fields for Channel and > XChannel. > > However, the current trunk version of the radiotap dissector puts the channel > frequency into a struct ieee_802_11_phdr structure, and when it's done it > calls the "common 802.11 radio information" dissector and passes it a pointer > to that structure as the data argument; that dissector then calls the 802.11 > dissector and passes the struct ieee_802_11_phdr pointer on to the 802.11 > dissector. > > So if the 802.11 dissector in the trunk wants to know the frequency on which > the packet arrived, it should just check whether the > PHDR_802_11_HAS_FREQUENCY flag is set in the presence_flags member of the > struct ieee_802_11_phdr structure and, if so, use the frequency member of > that structure. > > Then again, the struct ieee_802_11_phdr structure *also* has a phy field, and > it can currently be one of: > > PHDR_802_11_PHY_UNKNOWN if the PHY for the packet is unknown; > > PHDR_802_11_PHY_11_FHSS if it's legacy 802.11 FHSS; > > PHDR_802_11_PHY_11_IR if it's legacy 802.11 infrared; > > PHDR_802_11_PHY_11_DSSS if it's legacy 802.11 DSSS; > > PHDR_802_11_PHY_11B if it's 11b; > > PHDR_802_11_PHY_11A if it's 11a; > > PHDR_802_11_PHY_11G if it's 11g; > > PHDR_802_11_PHY_11N if it's 11n; > > PHDR_802_11_PHY_11AC if it's 11ac; > > and we could add PHDR_802_11_PHY_11AD and have the "common 802.11 radio > information" dissector set the phy field to PHDR_802_11_PHY_11AD if the > frequency field is present and is in the 60 MHz band. > > Then the 802.11 dissector can just check for the phy being > PHDR_802_11_PHY_11AD. > >> Isn't this backwards from how Wireshark normally does things? Shouldn't we >> be storing the channel frequency somewhere (historically that would be in >> pinfo though there's been some effort to get stuff out of there) so later >> dissectors can (easily) get the value? > > Yes, and we even have a place to store it (and to store the PHY, while we're > at it.
Hmmm, I should have looked more carefully ... that looks like the best way to deal with the issue. OK, I agree we should define PHDR_802_11_PHY11AD and set that correctly based on the frequencies. I already have a macro for checking the 11AD frequencies. I will have to do a significant overhaul, however, to pass that down to various functions, so it might be easier to do a p_add_proto_data in the _common function to pass the phdr structure along ... -- Regards, Richard Sharpe (何以解憂？唯有杜康。--曹操) ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
