Wireshark · Wireshark-dev: Re: [Wireshark-dev] Bug in Wireshark Display filter engine caused by optimization of proto tree duri

[Guy Harris <guy@xxxxxxxxxxxx>]

On Aug 21, 2015, at 7:34 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> 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.