On radar detection on the main chain switch to the channel monitored
by the background chain if we have already performed the CAC there.
If a radar pattern is reported on the background chain, just select a
new random channel according to the regulations for monitoring.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Rely on hostapd_dfs_request_channel_switch() to enable CSA for
background radar detection switching back to the selected channel.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
This is a preliminary patch to add Channel Switch Announcement for
background radar detection.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Introduce the capability to perform radar/CAC detection on an offchannel
radar chain available on some hardware (e.g., mt7915). This feature
allows to avoid CAC downtime switching on a different channel during CAC
detection on the selected radar channel.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Add the capability to specify all 3 channel type possibilities in
dfs_downgrade_bandwidth(). This is a preliminary change to introduce
radar/CAC background detection support.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Introduce type parameter to dfs_get_valid_channel() routine to allow
selection of a radar-only channel where the CAC detection has not been
performed yet. This is a preliminary patch to enable background
radar/CAC detection.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
This is a preliminary change to introduce radar/CAC background detection
support.
Tested-by: Owen Peng <owen.peng@mediatek.com>
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
If min_tx_power is specified (default 0 dBm, i.e., no constraint), ACS
and DFS will not consider channels whose available max_tx_power is less
than the configured value.
This may be useful to exclude SRD (Short Range Device) channels which
may be limited to 13.9 dBm (25 mW) in some regulatory domains.
Signed-off-by: Alan Young <consult.awy@gmail.com>
hostapd_handle_dfs_offload() is the DFS handler for the offloaded case,
in which ieee80211_is_dfs() is used to check if the configured frequency
requires DFS or not.
When the configured channel width is not 20 (e.g., 160),
ieee80211_is_dfs() will not checked adjacent freqs, so it possibly makes
wrong conclusion for whether DFS is required.
hostapd_is_dfs_required() does similar thing with ieee80211_is_dfs()
except it supports checking whether the configured frequency and its
adjacent frequencies require DFS. So hostapd_is_dfs_required() is a more
robust and better option than ieee80211_is_dfs() to check DFS.
The issue is hostapd_is_dfs_required() is for non-offload case due to
the check of the configuration parameter ieee80211h. Add a check for
WPA_DRIVER_FLAGS_DFS_OFFLOAD to make it support the DFS offload case
(i.e., ieee80211h=0) as well.
For example, configuring the AP to start at freq=5240 with channel width
160:
- Existing hostapd checks freq=5240 is non-DFS, hence skip DFS CAC and
transition to AP-Enabled which volatiles DFS-RADAR detection.
LOG: "hostapd : hostapd_handle_dfs_offload: freq 5240 MHz does not
require DFS. Continue channel/AP setup"
- This commit checks freq=5240 and its adjacent freqs are DFS required,
hence remains in DFS state until DFS CAC completed.
LOG: "hostapd : hostapd_handle_dfs_offload: freq 5240 MHz requires
DFS for 4 chans"
Signed-off-by: Hu Wang <huw@codeaurora.org>
For EU, where preCAC is allowed, we should allow switch to DFS available
channels, instead of restarting BSS.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Add support for new channels 173 and 177 in the operating classes 125 to
130 as defined in draft IEEE P802.11ax/D8.0.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Previously hostapd would not stop transmitting when a DFS event was
detected and no available channel to switch to was available.
Disable and re-enable the interface to enter DFS state. This way, TX
does not happen until the kernel notifies hostapd about the NOP
expiring.
Signed-off-by: David Bauer <mail@david-bauer.net>
The hostapd DFS code deinitializes and initializes the AP interface, if
a clean channel switch is not possible. In this case the AP code paths
would deinit the driver, for example nl80211, without wpa_supplicant
code paths getting notice of this.
Therefore add callbacks for wpa_supplicant mesh methods, which are
called on init/deinit of the AP BSS. These callbacks are then used to
handle the reset in the mesh code.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
This is needed to cover the HE-specific conf->he_oper_chwidth value in
addition to conf->vht_oper_chwidth.
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Some places in the code base were not using the wrappers like
hostapd_set_oper_centr_freq_seg0_idx and friends. This could lead to
errors, for example when joining 80 MHz mesh networks. Fix this, by
enforcing usage of these wrappers.
wpa_supplicant_conf_ap_ht() now checks for HE capability before dealing
with VHT in order for these wrappers to work, as they first check HE
support in the config.
While doing these changes, I've noticed that the extra channel setup
code for mesh networks in wpa_supplicant/mesh.c should not be necessary
anymore and dropped it. wpa_supplicant_conf_ap_ht() should handle this
setup already.
Acked-by: John Crispin <john@phrozen.org>
Signed-off-by: Markus Theil <markus.theil@tu-ilmenau.de>
Add a new hostapd_is_dfs_overlap() helper function to DFS module. This
function tells whether the selected frequency range overlaps with DFS
channels in the current hostapd configuration. Selected frequency reange
is specified by its center frequency and bandwidth.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
Rename DFS helper hostapd_config_dfs_chan_available() to
hostapd_is_dfs_chan_available(). Enable access to this helper function
from other hostapd components.
Signed-off-by: Sergey Matyukevich <sergey.matyukevich.os@quantenna.com>
After a radar signal is detected, the AP should switch to another
channel, but in the case of 80+80 MHz, channel switch failed because
hostapd did not select the secondary channel in the process. Fix this by
selecting a secondary channel in the case of 80+80 MHz.
Signed-off-by: Xin Wang <xwangw@codeaurora.org>
Signed-off-by: Pravas Kumar Panda <kumarpan@codeaurora.org>
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>
