Previously, a channel with even a single scan/survey result missing
information was skipped in ACS. This may not be desirable in cases when
multiple scan iterations are used (which is the case by default in
hostapd). Instead, use all channels that provided at least one complete
set of results. Calculate the average interference factor as an average
of the iterations that did provide complete values.
This seems to help with some cases, e.g., when ath9k may not be able to
report the noise floor for all channels from the first scan iteration
immediately after the driver has been loaded, but then returns it for
all other scan iterations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new acs_chan_bias configuration parameter is a space-separated list
of <channel>:<bias> pairs. It can be used to increase (or decrease) the
likelihood of a specific channel to be selected by the ACS algorithm.
The total interference factor for each channel gets multiplied by the
specified bias value before finding the channel with the lowest value.
In other words, values between 0.0 and 1.0 can be used to make a channel
more likely to be picked while values larger than 1.0 make the specified
channel less likely to be picked. This can be used, e.g., to prefer the
commonly used 2.4 GHz band channels 1, 6, and 11 (which is the default
behavior on 2.4 GHz band if no acs_chan_bias parameter is specified).
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The interference factors for adjacent 2.4 GHz channels were summed
together without doing any kind of weighted average on them. This
resulted in the channels at the band edges getting undue preference due
to only including interference factors from three channels vs. five for
the channels in the middle of the band.
While it is somewhat unclear whether the design here was supposed to
count overlapping channels together in this way or whether that is
already covered in channel survey results, it is clear that this summing
of three to five values together and then comparing the sum rather than
average of some kind gives too much preference to the channels at the
edges of the band by assuming that there is no interference whatsoever
outside the band.
Use weighted average of the interference factors rather than a sum from
different number of values. For now, the adjacent 2.4 GHz channels get
weight of 0.85 (1.0 for the main channel itself) and the neighboring
channels to those adjacent ones get 0.55 weight. Band-edge channels are
handled in a way that takes average over the channels that were actually
considered instead of assuming zero interference from neighboring bands.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add the possibility to define a subset of channels used by the ACS
engine when not operating on DFS channels.
Signed-off-by: Adrien Decostre <ad.decostre@gmail.com>
Using QCA vendor command, allow ACS function to be offloaded to the
driver. Once channels are selected, hostapd is notified to perform OBSS
operation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Especially when multiple BSSes are used with ACS, number of the error
paths were not cleaning up driver initialization properly. This could
result in using freed memory and crashing the process if ACS failed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The center segment0 calculation for VHT20 ACS was incorrect. This caused
ACS to fail with: "Could not set channel for kernel driver".
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
In case of Automatic Channel Selection (ACS) failure, we do not have a
real fallback path. Interface still remains in ACS state. To reflect we
did not succeed with ACS, simply disable the interface and indicate this
to user/upper layer entity so that a suitable recovery or error
notification can be performed.
Signed-off-by: Pawel Kulakowski <pawel.kulakowski@tieto.com>
For example, the previous implementation considered [44, 48, 52, 56] to
be a valid VHT80 channel -- which it is not. This resulted in, e.g.,
failure to start CAC when channels on overlapped segments included DFS
channels.
Add a check similar to the HT40 one to prevent that. The check is
performed this way as the ACS implementation assumes the primary channel
to be the first channel in a given segment.
Signed-off-by: Michal Kazior <michal.kazior@tieto.com>
Return control flow to hostapd by calling hostapd_acs_completed()
if requesting a scan from the underlying device fails.
Signed-hostapd: Helmut Schaa <helmut.schaa@googlemail.com>
Previously ACS required valid survey data on all available channels.
This can however not be guaranteed. Instead of just failing, fall back
to the subset of channels that have valid ACS data.
Signed-hostap: Helmut Schaa <helmut.schaa@googlemail.com>
Otherwise hostapd might hang doing nothing anymore. Propagate ACS
errors so we can fail gracefully.
Signed-hostap: Helmut Schaa <helmut.schaa@googlemail.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>