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.
