Comment # 7
on bug 11351
from Guy Harris
So, given the flurry of 802.11-related activity lately, I've got 3 PDF windows
open, with 802.11-2012, 802.11ac-2013, and 802.11ad-2013, so I could just go to
the first window and look for "HT Control" and find:
8.2.4.6 HT Control field
The HT Control field is always present in a Control Wrapper frame and is
present in QoS Data and management frames as determined by the Order bit of the
Frame Control field as defined in 8.2.4.1.10.
and 8.2.4.1.10 "Order field" says:
The Order field is 1 bit in length. It is used for two purposes:
— It is set to 1 in a non-QoS data frame transmitted by a non-QoS STA to
indicate that the frame contains an MSDU, or fragment thereof, that is being
transferred using the StrictlyOrdered service class.
— It is set to 1 in a QoS data or management frame transmitted with a
value of HT_GF or HT_MF for the FORMAT parameter of the TXVECTOR to indicate
that the frame contains an HT Control field.
Otherwise, the Order field is set to 0.
It's a QoS data frame, and the Order field is set:
1... .... = Order flag: Strictly ordered
Perhaps the correct interpretation of what 8.2.4.1.10 "Order field" says is
that, for QoS data or management frames, the order bit should be set to 1 if
and only if the frame contains an HT Control field, and that non-HT non-VHT QoS
data and management frames should never have an HT Control field, and thus they
should never have Order set to 1, so all we have to check is the Order field -
we needn't bother checking what PHY was used, as, for QoS data and management
fields, Order *should not ever be set* if the PHY wasn't HT or VHT.
So we should probably update the comments to reflect that, and fix the
dissector not to care about the PHY in that case, in both the trunk and 1.12
branch.
You are receiving this mail because:
- You are watching all bug changes.