Use the 'no_ir' notation instead of the 'passive scan' and
'no_ibss' notations to match the earlier change in nl80211.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Add smps_modes field, and let the driver fill it with its supported SMPS
modes (static/dynamic). This will let us start an AP with specific SMPS
mode (e.g., dynamic) that will allow it to reduce its power usage.
Signed-off-by: Eliad Peller <eliad@wizery.com>
Before starting a 20/40 MHz BSS on the 2.4 GHz band, a 40-MHz-capable HT
AP is required by the rules defined in IEEE Std 802.11-2012 10.15.5 to
examine the channels of the current operational regulatory domain to
determine whether the operation of a 20/40 MHz BSS might unfairly
interfere with the operation of existing 20 MHz BSSs. The AP (or some of
its associated HT STAs) is required to scan all of the channels of the
current regulatory domain in order to ascertain the operating channels
of any existing 20 MHz BSSs and 20/40 MHz BSSs. (IEEE 802.11-2012 S.5.2
Establishing a 20/40 MHz BSS).
Add the check for an overlapping 20 MHz BSS to the initial AP scan for
the P == OT_i case in 10.15.3.2.
Signed-off-by: Rajkumar Manoharan <rmanohar@qti.qualcomm.com>
This makes the initial OBSS scans in AP mode before starting 40 MHz BSS
more robust. In addition, HT20 can be used as a backup option if none of
the scans succeed.
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>
This was used to fill in the "PSMP support" subfield that was defined
during P802.11n development. However, this subfield was marked reserved
in the published IEEE Std 802.11n-2009 and it is not supported by
current drivers that use hostapd for SME either. As such, there is not
much point in maintaining this field as ht_capab parameter within
hostapd either.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If the driver supports full offloading of DFS operations, do not disable
a channel marked for radar detection. The driver will handle the needed
operations for such channels.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Secondary channel was compared incorrectly (-4/4 vs. actual channel
number) which broke matching neighboring 40 MHz BSSes and only the
no-beacons-on-secondary-channel rule was applied in practice. Once
sec_chan was fixed, this triggered another issue in this function where
both rules to switch pri/sec channels could end up getting applied in a
way that effectively canceled the switch.
Signed-off-by: Jouni Malinen <j@w1.fi>
As per IEEE Std 802.11ac-2013, 'Maximum A-MPDU Length Exponent' field
value is in the range of 0 to 7. Previous implementation assumed EXP0 to
be the maximum length (bits 23, 24 and 25 set) what is incorrect.
This patch adds options to set it up within the 0 to 7 range.
Signed-off-by: Bartosz Markowski <bartosz.markowski@tieto.com>
The regulatory rules in Japan do not allow OFDM to be used on channel
14. While this was to some extend assumed to be enforced by drivers
(many of which apparently don't), it is safer to make hostapd enforce
this by disabling any OFDM-related functionality. This tries to avoid
backwards compatibility issues by downgrading the mode rather than
rejecting the invalid configuration.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
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>
Only scan the affected channels instead of all enabled channels when
determining whether the primary and secondary channel for HT40 needs to
be swapped. This speed up HT40 setup considerably on 5 GHz band.
Signed-hostap: Jouni Malinen <j@w1.fi>
Otherwise hostapd might hang doing nothing anymore. Propagate ACS
errors so we can fail gracefully.
Signed-hostap: Helmut Schaa <helmut.schaa@googlemail.com>
If ACS fails we still need to call hostapd_setup_interface_complete.
Otherwise hostapd will just hang doing nothing anymore. However, pass
an error to hostapd_setup_interface_complete to allow a graceful fail.
Signed-hostap: Helmut Schaa <helmut.schaa@googlemail.com>
Add DFS structures/events handlers, CAC handling, and radar detection.
By default, after radar is detected or the channel became unavailable, a
random channel will be chosen.
This patches are based on the original work by Boris Presman and
Victor Goldenshtein. Most of the DFS code is moved to a new dfs.c/dfs.h
files.
Cc: Boris Presman <boris.presman@ti.com>
Cc: Victor Goldenshtein <victorg@ti.com>
Signed-hostap: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
Signed-hostap: Janusz Dziedzic <janusz.dziedzic@tieto.com>
This adds ACS support to hostapd. Currently only survey-based
algorithm is available.
To use ACS you need to enable CONFIG_ACS=y in .config and use
channel=0 (or channel=acs_survey) in hostapd.conf.
For more details see wiki page [1] or comments in src/ap/acs.c.
[1]: http://wireless.kernel.org/en/users/Documentation/acs
Signed-hostap: Michal Kazior <michal.kazior@tieto.com>
This splits up the channel checking upon initialization into a few
helpers. This should make this a bit easier to follow. This also paves
the way for some initial ACS entry code.
Signed-hostap: Michal Kazior <michal.kazior@tieto.com>
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>
Basic support for the 60 GHz band. Neither P2P nor WPS are yet taken
care off. Allows to start AP with very simple config:
network={
ssid="test"
mode=2
frequency=60480
key_mgmt=NONE
}
Signed-off-by: Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com>
Commit e5693c4775 added a copy of the
determined basic rate set into struct hostapd_iface, but did not
actually copy the terminating -1 value. This could be problematic if
something were to actually try to use this list since would be no way to
know what is the last entry in the list. Fix this by copying the
terminating value.
Signed-hostap: Jouni Malinen <j@w1.fi>
When starting an AP with HT40 on 2.4 GHz, limit the set of channels
to scan for based on the affected frequency range to speed up the
AP setup.
Signed-hostap: Jouni Malinen <j@w1.fi>
We need to call this function after having completed the neighboring
channel scan to figure out whether HT40 can be used and if so, which
channel is the secondary channel.
ieee80211n_supported_ht_capab is called after ieee80211n_check_40mhz in
function hostapd_check_ht_capab. ieee80211n_check_40mhz can return 1 in
a valid scenario where the initialization is completed in a callback. In
this case ieee80211n_supported_ht_capab is skipped and hostapd does not
check the ht capabilities reported by the driver. Fix this issue making
sure ieee80211n_supported_ht_capab gets called.
Signed-off-by: Nishant Sarmukadam <nishants@marvell.com>
The previous implementation ended up incorrectly assuming that all
40 MHz use cases have secondary channel above the primary one. Fix this
by properly masking the secondary channel offset field and checking its
value.
