This element is not used in Beacon or Probe Response frames (which is
the reason why the standard does not indicate where exactly it would be
in those frames..); HT Operation element has this information and so
does Extended CSA element.
In practice, this reverts the functionality added in commit 76aab0305c
("Add secondary channel IE for CSA").
Signed-off-by: Jouni Malinen <j@w1.fi>
When operating on the 6 GHz band, add 6 GHz Operation Information inside
the HE Operation element and don't publish HT/VHT IEs.
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
- Replace HOSTAPD_MODE_IEEE80211AX mode checks with is_6ghz_op_class()
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
When processing 20/40 BSS Coexistence Management frames that do not
explicitly require 40 MHz to be disabled, check whether the reported
channels in 20/40 BSS Intolerant Channel Report element match the
current primary channel. If so, allow 40 MHz operation to continue. This
makes the during-operation updates for 20/40 Operation Permitted more
consistent with the scans during initial BSS startup.
The received 20/40 BSS Intolerant Channel Report channels are to be used
in the OT set in the during-operation determination and the P == OT_i
exception was ignored in the previous implementation which could result
in the AP first starting with 40 MHz and then dropping to 20 MHz on
first received 20/40 BSS Coexistence Management frame even though there
was no change in the neighboring BSSs.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This extends 20/40 BSS Coexistence Management frame processing to
iterate over all the included 20/40 BSS Intolerant Channel Report
elements instead of using only the first one.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The 20 MHz BSS Width Request field is set to 1 only for intra-BSS
reports. As such, ignore the frame if such a claim is made by a
transmitter that is not currently associated with the AP.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This makes it easier to understand what kind of information a STA is
reporting about 20/40 MHz coexistence requirements.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Let mesh STA A be a STA which has config disable_ht=1.
Let mesh STA B be a STA which has config disable_ht=0.
The mesh STA A and B was connected.
Previously, the mesh STA A sent frame with HT rate even though its HT
was disabled. This commit fixes the issue by checking the local BSS HT
configuration.
Signed-off-by: Masashi Honma <masashi.honma@gmail.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>
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>
is_ht_allowed is a confusing name since this variable is used to track
whether 40 MHz channel bandwidth is allowed instead of whether HT is
allowed in general.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
HT requires QoS/WMM, so unset HT capabilities for a station
whose association request does not include a valid WMM IE.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
If OBSS scan interval is not set, the AP must not schedule a timeout to
restore 40 MHz operation immediately after having moved to a 20 MHz
channel based on an unsolicited co-ex report. Fix this by scheduling the
timeout only if obss_interval is non-zero.
Since we do not currently support AP doing OBSS scans after the initial
BSS setup, this means practically that 40-to-20 MHz transition is
allowed, but 20-to-40 MHz is not with obss_interval=0. The latter gets
enabled if obss_interval is set to a non-zero value so that associated
STAs can take care of OBSS scanning.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Commit 587d60d2b7 ('Add AP mode support
for HT 20/40 co-ex Action frame') added processing of co-ex report, but
did not include proper bounds checking or IE type checking for the
payload. Furthermore, this was not ready for the possible extensibility
of the 20/40 BSS Coexistence element.
Fix these by checking IE ids for both elements and doing more
apprioriate bounds checking for the element lengths to avoid potentially
reading beyond the frame buffer. Though, the event receive buffer in
both libnl and driver_nl80211_monitor.c is sufficiently large to make it
very unlikely that the maximum read of about 260 bytes beyond the end of
the Action frame would really have any chances of hitting the end of the
memory buffer, so the practical effect of missing bounds checking would
have been possibly accepting an invalid report frame and moving to 20
MHz channel unnecessarily.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 5ce3ae4c8f tried to clean up
fetching a pointer to the action code field, but it forgot to add
IEEE80211_HDRLEN to the pointer. This resulted in the coex report
elements being read from too early in the frame.
Signed-off-by: Jouni Malinen <j@w1.fi>
The Action code field is in a fixed location, so the IEEE80211_HDRLEN
can be used here to clean up bounds checking to avoid false reports from
static analyzer.
Signed-off-by: Jouni Malinen <j@w1.fi>
If a 2.4 GHz band AP receives a 20/40 Coexistence management frame from
a connected station with 20/40 BSS Intolerant Channel Report element
containing the channel list in which any legacy AP are detected or AP
with 40 MHz intolerant bit set in HT Cap IE is detected in the affected
range of the BSS, the BSS will be moved from 40 to 20 MHz channel width.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Extend the minimal HT 20/40 co-ex support to include dynamic changes
during the lifetime of the BSS. If any STA connects to a 2.4 GHz AP with
40 MHz intolerant bit set then the AP will switch to 20 MHz operating
mode.
If for a period of time specified by OBSS delay factor and OBSS scan
interval AP does not have any information about 40 MHz intolerant STAs,
the BSS is switched from HT20 to HT40 mode.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This makes the definitions match the terminology used in IEEE Std
802.11-2012 and makes it easier to understand how the HT Operation
element subfields are used.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
For some client OBSS implementations that are performed in
firmware, all OBSS parameters need to be set to valid values.
Do this, as well as supplying the "20/40 Coex Mgmt Support"
flag in the extended capabilities IE.
Signed-hostap: Paul Stewart <pstew@chromium.org>
The following if statements set the new_op_mode value in all cases,
so there is no need to initialize this to 0 first. This removes a
static analyzer warning.
Signed-off-by: Jouni Malinen <j@w1.fi>
These files have been distributed only under the BSD license option
since February 2012. Clarify the license statements in the files to
match that to avoid confusion.
Signed-hostap: 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>
Add a parameter to send the overlapping BSS scan parameter
information element. This will require clients to perform
background scans to check for neigbors overlapping this
HT40 BSS. Since the implementation is incomplete it should
only be used for testing.
Signed-hostap: Paul Stewart <pstew@chromium.org>
The capability itself isn't really affected by an OBSS
scan, only the HT operation must then be restricted to
20 MHz. Change this, and therefore use the secondary
channel configuration to determine the setting of the
OP_MODE_20MHZ_HT_STA_ASSOCED flag.
This shouldn't really change anything functionally,
it just makes the code a little less confusing and
is also needed to implement more dynamic bandwidth
changes if ever desired.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
Previously hostapd just masked the STAs HT caps with its own. However,
some HT caps are not symmetric and as such need to be handled
different.
hostapd shouldn't overwrite the STAs SMPS mode as otherwise the driver
cannot know it has to use RTS/CTS to wake the receiver from dynamic
SMPS for MCS rates > 7.
hostapd shouldn't mask the RX and TX STBC caps with it's own. They are
already handled in a special case below.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Currently hostapd will force HT Mixed Mode if at least one non-GF STA is
associated. This will force _all_ HT transmissions to be protected.
802.11n-2009 doesn't require HT Mixed Mode to be used in case of non-GF
STAs but instead the HT information element contains a flag if non-GF
STAs are present. All STAs are required to protect GF transmissions in
that case. Hence, setting HT Mixed mode if non-GF STAs are present is
superfluous.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
In multi BSS setups it wasn't possible to set up an HT BSS in
conjunction with a WEP/TKIP BSS. HT needed to be turned off entirely
to allow WEP/TKIP BSSes to be used.
In order to allow HT BSSes to coexist with non-HT WEP/TKIP BSSes add a
new BSS conf attribute "disable_11n" which disables HT capabilities on a
single BSS by suppressing HT IEs in the beacon and probe response
frames. Furthermore, mark all STAs associated to a WEP/TKIP BSS as
non-HT STAs. The disable_11n parameter is used internally; no new entry
is parsed from hostapd.conf.
This allows a non-HT WEP/TKIP BSS to coexist with a HT BSS without
having to disable HT mode entirely. Nevertheless, all STAs associated to
the WEP/TKIP BSS will only be served as if they were non-HT STAs.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
This function is not really needed in case of drivers that build the
HT IEs internally. However, since this can get called if ieee80211n=1
is set in hostapd.conf, we better not segfault even if the driver
does not provide hw info (hapd->iface->current_mode == NULL).
hostapd simply used its own STBC configuration in the STA's HT caps. This
resulted in TX STBC being used for STAs not supporting RX STBC, which in
turn resulted in the STA not receiving anything.
Fix this by handling the STBC flags in the same way mac80211 does. Mask
out RX STBC if we don't support TX STBC and vice versa.
Tested only with the nl80211 driver and a STBC incapable STA.
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Doxygen and some build tools may get a bit confused about same file
name being used in different directories. Clean this up a bit by
renaming some of the duplicated file names in src/ap.
This code can be shared by both hostapd and wpa_supplicant and this
is an initial step in getting the generic code moved to be under the
src directories. Couple of generic files still remain under the
hostapd directory due to direct dependencies to files there. Once the
dependencies have been removed, they will also be moved to the src/ap
directory to allow wpa_supplicant to be built without requiring anything
from the hostapd directory.
Jouni Malinen
Andrei Otcheretianski
Jouni Malinen
Masashi Honma
Jouni Malinen
Ilan Peer
Peng Xu
Paul Stewart
Johannes Berg
Helmut Schaa