Add support for new channels 173 and 177 in the operating classes 125 to
130 as defined in draft IEEE P802.11ax/D8.0.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Replace the implicit boolean checks that used int variables with use of
a more explicit bool variable type.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it easier to change the internal struct wpa_bss design for
storing the variable length IE buffers.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add support for missing 6 GHz operating classes as defined in
IEEE P802.11ax/D7.0.
This is needed to avoid OCV failures on the 6 GHz band when the channel
width is larger than 20 MHz.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Instead, log a diagnostic so that noise to the user is reduced. This is
expected behavior with driver interfaces that do not report supported
operating modes/classes.
Signed-off-by: Roy Marples <roy@marples.name>
The channel numbering/center frequencies was changed in IEEE
P802.11ax/D6.1. The center frequencies of the channels were shifted by
10 MHz. Also, a new operating class 136 was defined with a single
channel 2. Add required support to change the channelization as per IEEE
P802.11ax/D6.1.
Signed-off-by: Wu Gao<wugao@codeaurora.org>
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
The previous implementation was assuming a fixed 20 MHz channel
bandwidth when determining which operating class value to indicate as
the Current Operating Class in the Supported Operating Classes element.
This is not accurate for many HT/VHT cases.
Fix this by determining the current operating class (i.e., the operating
class used for the requested association) based on the HT/VHT operation
elements from scan results.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The 5 GHz channels are stored in one hw_features set with mode
HOSTAPD_MODE_IEEE80211A while the 6 GHz channels will need to be stored
in a separate hw_features set (but with same mode
HOSTAPD_MODE_IEEE80211A) due to possibility of different HT/VHT/HE
capabilities being available between the 5 GHz and 6 GHz bands.
Iterate through all hw_features sets and check and match the band of
channel supported by the hw_features set while getting the hw_features
set in get_mode(). This allows both the 5 GHz and 6 GHz channels to be
found and correct capabilities to be used in cases where the driver
reports different capability values between 5 and 6 GHz channels.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is needed to allow the 6 GHz operating classes to be compared
against the driver support channels since the channel numbers are not
really unique identifiers of a channel even within a single band.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The bandwidth values are shared between VHT and HE mode so remove the
VHT specific prefix.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
If a station is configured to allow only a subset of frequencies for an
association, the supported operating classes may need to be more limited
than what the hardware supports.
Signed-off-by: Ben Greear <greearb@candelatech.com>
If user has disabled HT or VHT, those related operating classes
should not be advertised as supported.
Signed-off-by: Ben Greear <greearb@candelatech.com>
Extend verify_channel() to return whether IR is allowed on the channel
or not, and make it a global function so it can be used in other files,
too. This makes this function useful for checking not only if a channel
is supported but also if it is allowed for active and passive scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Supported Operating Classes element and its use is define in the IEEE
802.11 standard and can be sent even when MBO is disabled in the build.
As such, move this functionality out from the CONFIG_MBO=y only mbo.c.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
