path: root/src/ap/ieee802_11_ht.c
Commit message (Collapse)AuthorAgeFilesLines
* Fix CSA related IEs orderAndrei Otcheretianski2015-10-031-1/+2
| | | | | | | 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>
* Move HT CSA related IE functionAndrei Otcheretianski2015-10-031-0/+22
| | | | | | Move Secondary Channel element function to ieee802_11_ht.c. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
* Simplify HT Capabilities element parsingJouni Malinen2015-04-221-2/+1
| | | | | | | 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>
* Rename HT 20/40 coex variable to be more descriptiveJouni Malinen2015-03-301-7/+7
| | | | | | | | 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>
* AP: Unset HT capabilities for an HT association request without WMMIlan Peer2015-03-251-2/+6
| | | | | | | 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>
* Fix 20/40 MHz co-ex report processing with obss_interval=0Jouni Malinen2015-02-031-1/+2
| | | | | | | | | | | | | | | 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>
* HT: More robust 20/40 coex Action frame parsingJouni Malinen2014-12-221-12/+36
| | | | | | | | | | | | | | | | | | | | Commit 587d60d2b74190d58ddeb6a30ab338352af1186a ('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>
* HT: Fix 20/40 coex Action frame parsingJouni Malinen2014-12-221-1/+1
| | | | | | | | | Commit 5ce3ae4c8f2a07c28e0bbae1b68e5524ee034387 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>
* HT: Use cleaner way of generating pointer to a field (CID 68097)Jouni Malinen2014-06-121-4/+2
| | | | | | | | 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>
* Add AP mode support for HT 20/40 co-ex Action framePeng Xu2014-04-291-0/+111
| | | | | | | | | | 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>
* hostapd: Extend support for HT 20/40 coexistence featurePeng Xu2014-04-291-0/+63
| | | | | | | | | | | | | 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>
* Document and rename HT Capability/Operation fieldsJouni Malinen2014-04-071-20/+17
| | | | | | | | 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>
* hostapd: Supply default parameters for OBSS scanPaul Stewart2014-03-141-1/+14
| | | | | | | | | 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>
* Remove unnecessary variable initializationJouni Malinen2014-03-021-1/+0
| | | | | | | | 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>
* Remove obsolete license notificationsJouni Malinen2013-12-241-8/+2
| | | | | | | | 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>
* Include driver.h in hostapd.hAndrei Otcheretianski2013-12-241-1/+0
| | | | | | | 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>
* hostapd: Add option to send OBSS scan paramsPaul Stewart2013-11-071-0/+16
| | | | | | | | | | 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>
* hostapd: Do not change HT40 capability due to OBSS scanJohannes Berg2013-02-091-2/+1
| | | | | | | | | | | | | | | 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>
* hostapd: Don't mask out non-symmetric STA HT capsHelmut Schaa2011-06-231-2/+8
| | | | | | | | | | | | | | | 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>
* hostapd: Don't force HT Mixed Mode for non-GF STAsHelmut Schaa2011-03-161-7/+1
| | | | | | | | | | | | | 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>
* hostapd: Allow coexistance of HT BSSes with WEP/TKIP BSSesHelmut Schaa2011-02-211-5/+8
| | | | | | | | | | | | | | | | | | | 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>
* Fix segfault in hostapd_eid_ht_capabilities() with some driversJouni Malinen2010-09-051-1/+1
| | | | | | | 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: enable STBC only for STBC capable STAsHelmut Schaa2010-08-281-2/+10
| | | | | | | | | | | | | 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>
* Include header files explicitly in *.c, not via header filesJouni Malinen2009-12-251-0/+1
* Rename some src/ap files to avoid duplicate file namesJouni Malinen2009-12-251-3/+3
| | | | | | 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.
* Move generic AP functionality implementation into src/apJouni Malinen2009-12-241-0/+261
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.