This makes it easier to understand what is happening when a new channel
needs to be selected based on a radar detection event.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Upon radar detection we used to search channels with the same bandwidth.
This way we might not find any other channels. If there are no channels
available with that bandwidth the AP service will be stopped. To avoid
this problem, also search a suitable channel by downgrading the
bandwidth. This scenario is applicable during CAC as well.
Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
In the normal case hostapd_disable_iface() and hostapd_enable_iface()
will be done while switching to another DFS channel upon radar
detection. In certain scenarios radar detected event can come while
hostapd_disable_iface() is in progress and iface->current_mode will be
NULL in that scenario. Previously, we did not check for this scenario
and proceeded with the radar detection logic which can trigger a
segmentation fault. To fix this, avoid proceeding the radar detection
event if iface->current_mode is NULL.
Signed-off-by: Seevalamuthu Mariappan <seevalam@codeaurora.org>
Skip DFS checks and CAC operation for 6 GHz channels. AFC checks
will be added for 6 GHz channels later.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Update center frequency and center frequency2's DFS channel status in
VHT80+80 mode. Otherwise it will cause AP failed to start on a DFS
channel.
Tested: qca9984 with firmware ver 10.4-3.10-00047
Signed-off-by: Rick Wu <rwu@codeaurora.org>
Signed-off-by: Lei Wang <leiwa@codeaurora.org>
With DFS offloaded to the driver, hostapd state and CAC info was not
updated in DFS-CAC-START event, so STATUS output showed wrong info. Fix
this by updating the CAC related state when processing the driver event.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The HE capabilities are no longer per PHY but per iftype on this
specific PHY. It is therefore no longer enough to just parse the AP
capabilities.
The he_capabilities are now duplicated to store all information for
IEEE80211_MODE_* which hostap cares about. The nl80211 driver fills in
this information when the iftype supports HE. The rest of the code still
only uses the IEEE80211_HE_AP portion but can be extended later to also
use other HE capabilities.
Signed-off-by: Sven Eckelmann <seckelmann@datto.com>
These are used for both VHT and HE, so remove the misleading prefix.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
The bandwidth values are shared between VHT and HE mode so remove the
VHT specific prefix.
Signed-off-by: Shashidhar Lakkavalli <slakkavalli@datto.com>
Signed-off-by: John Crispin <john@phrozen.org>
While selecting a new channel as a reaction to radar event we need to
take into account supported bandwidth for each channel provided via
nl80211. Without this modification hostapd might select an unsupported
channel that would fail during AP startup.
Signed-off-by: Dmitry Lebed <dlebed@quantenna.com>
Mark a channel as required DFS based on regulatory information received
from the driver/kernel rather than deciding based on hardcoded
boundaries on the frequency. Previously few channels were being marked
as requiring DFS even though they were non-DFS in a particular country.
If the driver does not provide channel list information, fall back to
the previously used frequency-based determination.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is to comply with uniform spreading requirement for ETSI domain
(section 4.7.2.7 in EN 301 893 - V1.8.1). ETSI uniform spreading
requires equal probability for the usable channels. The previous channel
selection logic after a radar detection did not fully comply with the
uniform spreading requirement for the domain by ignoring DFS channels.
Consider DFS channels also during channel selection when the current DFS
domain is ETSI.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
As FCC DFS requirement does not explicitly mention about the validity of
the (pre-)CAC when channel is switched, it is safe to assume that the
pre-CAC result will not be valid once the CAC completed channel is
switched or radar detection is not active on the (CAC completed) channel
within a time period which is allowed (10 seconds - channel switch time)
as per FCC DFS requirement.
Use the new driver event to allow the driver to notify expiry of the CAC
result on a channel. Move the DFS state of the channel to 'usable' when
processing pre-CAC expired event. This means any future operation on
that channel will require a new CAC to be completed. This event is
applicable only when DFS is not offloaded to the kernel driver.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
When DFS channel state is shared across multiple radios on the system it
is possible that a CAC completion event is propagated from other radio
to us. When in enabled state, do not proceed with setup completion upon
processing CAC completion event with devices where DFS is not offloaded,
when in state other than enabled make sure the configured DFS channel is
in available state before start the AP.
Signed-off-by: Vasanthakumar Thiagarajan <vthiagar@qti.qualcomm.com>
In scenarios where only DFS channels are available (e.g., outdoor,
special country codes), hostapd must be able to handle situations
where all are unavailable.
The two possibilities to get there are
1) while operating on the last available DFS channel a radar is
detected
2) hostapd is started while all channels are unavailable
In both cases, hostapd instead of terminating should better
wait for the NOPs to pass and re-try operation after the CAC.
This patch provides that feature by using the condition
(iface->state == HAPD_IFACE_DFS && !iface->cac_started)
as NOP mode signature to retry operation from within
hostapd_dfs_nop_finished().
Signed-off-by: Zefir Kurtisi <zefir.kurtisi@neratec.com>
Remove the fallback dependency on os_random() from the code that gets a
valid DFS channel. This is exceptionally unlikely to ever be called as
the call to os_get_random() is unlikely to fail. The intention is to
facilitate future removal of os_random() as it uses a low quality PRNG.
Signed-off-by: Nick Lowe <nick.lowe@lugatech.com>
Update ACS driver offload feature for VHT configuration. In addition,
this allows the chanlist parameter to be used to specify which channels
are included as options for the offloaded ACS case.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
There's off-by-one in the range availability check - the case of
first_chan_idx + num_chans == num_channels should be allowed (e.g., 0 +
1 == 1, for the case of a single 20 MHz channel).
Signed-off-by: Maital Hahn <maitalm@ti.com>
Signed-off-by: Eliad Peller <eliad@wizery.com>
When looking for a new operating channel, consider the case of
non-contiguous channels when checking all the needed channels (e.g., the
driver might support channels 36, 38, 40, so look for channels 36+40
explicitly, instead of failing when encountering channel 38).
Signed-off-by: Eliad Peller <eliad@wizery.com>
Add handling logic for DFS offloaded case, and add a helper function
that takes the frequency (MHz) as a param and returns 1 if given channel
requires DFS, or 0 otherwise.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If DFS is offloaded to the driver, hostapd should not be performing
these operations. Send the relevant control interface events to provide
information to upper layer software that may use such events to track
DFS/CAC state. This makes the offloaded DFS implementation more
consistent with the DFS-in-hostapd behavior.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If DFS implementation was built in, some configurations with drivers
that do not provide mode information could end up dereferencing a NULL
pointer. Fix this by skipping DFS operations in such cases since not
having information about modes and channels means that hostapd could not
perform DFS anyway (i.e., either this is not a wireless driver or the
driver takes care of DFS internally).
Signed-off-by: Jouni Malinen <j@w1.fi>
This use does not really need a strong random number, so fall back to
os_random() if a theoretical error case occurs. (CID 72682)
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows cases where neither 80 MHz segment requires DFS to be
configured. DFS CAC operation itself does not yet support 80+80, though,
so if either segment requires DFS, the AP cannot be brought up.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
set_dfs_state() return value is not currently checked anywhere, so
remove the dead assignment to avoid static analyzer complaints.
Signed-off-by: Jouni Malinen <j@w1.fi>
Currently hostapd data structures aren't ready for multi-channel BSSes,
so make DFS work now at least with single-channel multi-BSS channel
switching.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Sometimes function hostapd_is_dfs_required() returns -1 which indicates
that it was not possible to check if DFS was required. This happens for
channels from the 2.4 GHz band where DFS checking should not happen.
This can be fixed by returning DFS-not-required for mode different from
IEEE80211A and when DFS support is not available (ieee80211h not set).
Signed-off-by: Marek Puzyniak <marek.puzyniak@tieto.com>
If channels are "available", change to "usable" DFS channels as a
fallback, too. This requires CAC, but it is still better to do that
instead of stopping service completely.
Signed-hostap: Simon Wunderlich <sw@simonwunderlich.de>
If DFS channels are marked as "available", an AP can switch to them
immediately without performing CAC. Therefore, the channel selection
function should consider these channels even though these are radar
channels.
Signed-hostap: Simon Wunderlich <sw@simonwunderlich.de>
Different channels allow different transmission power, at least in ETSI
countries. Also, ETSI requires a "channel plan" for DFS operation, and
channels should be randomly choosen from these channels.
Add a channel list configuration option for users to add channels
hostapd may pick from.
Signed-hostap: Simon Wunderlich <sw@simonwunderlich.de>
Previously, we printed this message as a debug one, which was confusing
in case verbose debug messages were disabled. User could think CAC
started but never ended. Add more parameterss to DFS_EVENT_CAC_START, so
external programs can more easily check what was wrong in case of
errors.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
This seemed to be fine on most code paths, but the code was complex
enough to make the analysis difficult (and a bit too much for static
analyzers). There is no harm in forcing these parameters to be
initialized, so do that to make sure they cannot be left uninitialized.
Signed-off-by: Jouni Malinen <j@w1.fi>
Allow mixed DFS and non-DFS channels, e.g., VHT160 on channels 36-64.
This is useful for testing VHT160 with mac80211_hwsim.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Add configuration of Spectrum Management subfield in the Capability
Information of Beacon, Probe Response, and Association Response frames.
Spectrum Management bit is set when directly requested by new
configuration option spectrum_mgmt_required=1 or when AP is running on
DFS channels. In the future, also TPC shall require this bit to be set.
Signed-hostap: Srinivasan <srinivasanb@posedge.com>
Signed-hostap: Chaitanya T K <chaitanyatk@posedge.com>
Signed-hostap: Marek Puzyniak <marek.puzyniak@tieto.com>
Initialize variables explicitly to avoid [-Wmaybeuninitialized] compiler
warning in hostapd_handle_dfs() and
hostapd_dfs_start_channel_switch_cac() functions.
Signed-hostap: Max Stepanov <Max.Stepanov@intel.com>
Until now DFS was simply restarting the AP when radar was detected. Now
CSA is used to perform smooth switch to the new channel. Stations not
supporting CSA will behave as before.
Signed-hostap: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Signed-hostap: Michal Kazior <michal.kazior@tieto.com>
This is needed for AP CSA. Since CSA must happen immediately after radar
is detected there's no time to perform CAC. Thus, radar channels must be
disabled when looking for a new channel to escape to after a radar is
detected.
Signed-hostap: Michal Kazior <michal.kazior@tieto.com>
