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>
NL80211_ATTR_CENTER_FREQ1 is defined to be used for anything but 20 MHz
bandwidth, so it could be unset for 20 MHz channels. Do not use it to
override center frequency from NL80211_ATTR_WIPHY_FREQ (if available)
for 20 MHz channels to avoid clearing frequency.
Signed-hostap: Jouni Malinen <j@w1.fi>
DFS operations are specific to the interface (radio/wiphy), not BSS
(netdev/vif), so hostapd_iface is the appropriate element to use in
them.
Signed-hostap: Jouni Malinen <j@w1.fi>
If radar was detected single BSS is notified about it. This caused only
that single BSS to be stopped and restarted. However, due to nl80211
interface combinations the BSS was not started on a new channel and
other BSSes remained operating on the old channel.
The downside is that hostapd_disable_iface() causes deauth frames to be
sent. This is undesired but on the other hand it doesn't make sense to
create workarounds that imitate CSA's 'block tx'. For proper Tx
quiescing CSA should be properly implemented.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Decouple HT/VHT offset/center-freq calculations from channel lookup.
This will be necessary for further improvements on the DFS codebase.
Signed-hostap: Michal Kazior <michal.kazior@tieto.com>
When we have CAC active and receive a radar event, we should ignore
CAC_ABORT event and handle channel switch in the radar event handler.
Signed-hostap: Janusz Dziedzic <janusz.dziedzic@tieto.com>
This fixes a problem when operating on non-DFS channel and receiving a
radar event for that channel. Previously, we would have decided to
switch channels.
Signed-hostap: Janusz Dziedzic <janusz.dziedzic@tieto.com>
Add a table of available VHT80 channels. This table contains the first
available channel. We will also choose this first channel as the control
one.
Signed-hostap: Janusz Dziedzic <janusz.dziedzic@tieto.com>
The VHT_CHANWIDTH_160MHZ case fell through to the default case and
printed out a debug message that was not supposed to be shown here.
Signed-hostap: Jouni Malinen <j@w1.fi>
