Number of deployed 80 MHz capable VHT stations that do not support 80+80
and 160 MHz bandwidths seem to misbehave when trying to connect to an AP
that advertises 80+80 or 160 MHz channel bandwidth in the VHT Operation
element. To avoid such issues with deployed devices, modify the design
based on newly proposed IEEE 802.11 standard changes.
This allows poorly implemented VHT 80 MHz stations to connect with the
AP in 80 MHz mode. 80+80 and 160 MHz capable stations need to support
the new workaround mechanism to allow full bandwidth to be used.
However, there are more or less no impacted station with 80+80/160
capability deployed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Fix the order of CSA, eCSA, Secondary Channel Offset, and Wide Bandwidth
Channel Switch Wrapper elements in Beacon and Probe Response frames.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
When switching to a VHT channel with width greater than 20 MHz, add Wide
Bandwidth Channel Switch element. This element is added in Beacon and
Probe Response frames inside Channel Switch Wrapper element.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Check the element length in the parser and remove the length field from
struct ieee802_11_elems since the element is of fixed length.
Signed-off-by: Jouni Malinen <j@w1.fi>
Disable VHT caps for STAs for which there is not even a single
allowed MCS in any supported number of streams. i.e STA is
advertising 3 (not supported) as VHT MCS rates for all supported
streams.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
Commit e7d0e97bdb ('hostapd: Add vendor
specific VHT extension for the 2.4 GHz band') resulted in a compiler
warning regarding comparison between signed and unsigned integers at
least for 32-bit builds.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This allows vendor specific information element to be used to advertise
support for VHT on 2.4 GHz band. In practice, this is used to enable use
of 256 QAM rates (VHT-MCS 8 and 9) on 2.4 GHz band.
This functionality is disabled by default, but can be enabled with
vendor_vht=1 parameter in hostapd.conf if the driver advertises support
for VHT on either 2.4 or 5 GHz bands.
Signed-off-by: Yanbo Li <yanbol@qti.qualcomm.com>
This was added by commit 8a45811638
('hostapd: Add Operating Mode Notification support'), but the validation
steps cannot be true either for the channel width (which is a two-bit
subfield that cannot encode more than the list four values) or Rx NSS
(which cannot encode a value larger 7). Furthermore, the VHT_CHANWIDTH_*
defines do not match the definition of the Channel Width subfield
values.
Since this check cannot ever match, it is better to remove it to make
the code easier to understand and to avoid getting complaints about dead
code from static analyzers.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows use of structs (and not only pointers) defined in drivers.h.
Remove also some not needed forward declarations and redundant includes.
Signed-hostap: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Mask the remote VHT capabilities with our own capabilities, similarly
to what is done for HT capabilities.
Signed-hostap: Eliad Peller <eliadx.peller@intel.com>
The VHT IE struct just has an opaque 8-byte array for the MCS
set, make it more expressive by explicitly naming the pieces.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Add the configuration option vht_oper_centr_freq_seg1_idx
for the second segment of an 80+80 MHz channel and use it
when building the VHT operation IE.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
