Allow specifying preferred GO band in addition to frequency. If a band
is specified, the first two scans will be limited to only non-DFS
channels to shorten scan times, and the next two will scan the entire
band.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Add support to consider EHT rates while calculating the estimated
throughput for scan results.
- The estimated EHT throughput uses the HE 0.8 usec GI rates from the
relevant EHT-MCS tables from IEEE P802.11be/D2.0, 36.5.
- The minimum SNR values for EHT rates (4096-QAM) are derived by adding
the existing minimum SNR values of 1024-QAM rates from HE tables and
the difference between the values of minimum sensitivity levels of
1024-QAM rates and 4096-QAM rates defined in Table 36-67 (Receiver
minimum input level sensitivity) in IEEE P802.11be/D2.0.
Signed-off-by: Ayala Beker <ayala.beker@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
When WPS is running simultaneously on multiple per-band radios (e.g., a
separate 2.4 GHz and 5 GHz band radios in an AP device), handle
synchronization of scan results, detect PBC session overlap, and cancel
WPS for enrollees on both interface, if the UUID of the registrars on
different bands differ.
Signed-off-by: Sai Pratyusha Magam <quic_smagam@quicinc.com>
As P2P GOs are not expected to be collocated, i.e., they are not
expected to be announced in the RNR element of other APs, they can
operate only on preferred scanning channels (PSCs).
When performing a full scan for P2P discovery, include only the 6 GHz
PSCs (if supported) to avoid scanning channels on which P2P GOs are not
expected to reside.
While at it also fix couple of places that missed including 60 GHz
channels in P2P full scan.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
When scanning for a new connection, we currently optimize by scanning
all frequencies only when our MCC capabilities will allow an additional
operating frequency, and scan only the existing operating frequencies
otherwise. This is problematic when there the current operating
frequency singularly accounts for one of the shared radio frequencies
because we should be able to switch operating frequencies without adding
to the channel count. Fix this.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Add a helper function to get Multi-Link element of a specified type from
scan result Probe Response frame or Beacon frame elements.
Signed-off-by: Shivani Baranwal <quic_shivbara@quicinc.com>
If 6 GHz is supported by the device but 6 GHz P2P is disabled, P2P
invitation would fail if the GO select an operating channel which is not
the preferred channel. The root cause is that the 5 GHz and 6 GHz bands
are both HOSTAPD_MODE_IEEE80211A so the 5 GHz channels would be added
twice for the P2P Client's following scanning frequency list. This will
cause scanning to fail with -EINVAL. Fix this by adding the 5 GHz
channels only once.
Signed-off-by: Hector Jiang <jianghaitao@zeku.com>
Add a parameter (non_coloc_6ghz=1) to the manual scan command to disable
6 GHz collocated scanning.
This option can be used to disable 6 GHz collocated scan logic. Note
that due to limitations on Probe Request frame transmissions on the 6
GHz band mandated in IEEE Std 802.11ax-2021 it is very likely that
non-PSC channels would be scanned passively and this can take a
significant amount of time.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Set NL80211_SCAN_FLAG_COLOCATED_6GHZ in the scan parameters to enable
scanning for co-located APs discovered based on neighbor reports from
the 2.4/5 GHz bands when not scanning passively. Do so only when
collocated scanning is not disabled by higher layer logic.
Signed-off-by: Tova Mussai <tova.mussai@intel.com>
Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com>
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
wpa_add_scan_freqs_list() was updated to use bool for the is_6ghz
argument, but these callers were missed when updating the values from
0/1 to false/true.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The channels included for the scan to connect to a P2P GO are optimized
such that the P2P GO preferred channel and the common channels are
included for the first few scans followed by a full scan in which all
the channels supported by the local device are included. This results in
P2P client including the 6 GHz channels for the full scan after GO
Negotiation even when 6 GHz channels are not used for the P2P
connection.
Exclude the 6 GHz channels from the full scan if 6 GHz channels are
supported but are not used for P2P connection.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Previously, the 6 GHz channels were disabled for P2P operations.
Introduce a new include_6ghz parameter for the P2P_FIND command to
configure P2P discovery on the 6 GHz channels.
However, the p2p_6ghz_disable parameter in the configuration takes a
higher priority. If the p2p_6ghz_disable parameter is not set in the
configuration, include_6ghz parameter can be used to enable or disable
the discovery operation in the 6 GHz channels for the P2P_FIND command.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
APs in 6 GHz operating with LPI/VLP rules will have significantly lower
SNR values compared to 2.4/5 GHz band APs. Earlier, the estimated
throughputs were used for comparison only when the delta of SNRs between
both the APs was not greater than 7 and as a result for comparing 6 GHz
APs with 2.4/5 GHz APs, estimated throughputs were not getting used.
The estimated throughput calculations takes SNR value also into
consideration, hence remove RSSI delta check if any of the APs are from
the 6 GHz band. This change is limited to the 6 GHz band only in order
to avoid possible regressions with 2.4/5 GHz APs.
Signed-off-by: Vamsi Krishna <vamsin@codeaurora.org>
Prefer 6 GHz APs when estimated throughputs are equal with APs from the
2.4/5 GHz bands while selecting APs for connection. Also add a 6 GHz
specific noise floor default value for the 6 GHz band (with the same
value as was used for 5 GHz previously) to make this step clearer.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add support to consider HE rates while estimating throughputs for the
scan results from HE enabled APs. HE 0.8 usec GI rates are used in all
tables. The minimum SNR values for HE rates (1024-QAM) are derived by
adding the existing minimum SNR values of 256-QAM rates from VHT tables
and the difference between the values of minimum sensitivity levels of
256-QAM rates and 1024-QAM rates defined in Table 27-51 (Receiver
minimum input level sensitivity) in IEEE P802.11ax/D8.0.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add support to calculate estimated throughputs for APs which support the
160 MHz (including 80+80 MHz) mode in VHT. The minimum SNR values for
VHT 160 MHz mode are derived from minimum SNR values used for VHT 80 MHz
mode + 3 dBm. The min-SNR values are derived relatively based on the
information that the minimum sensitivity levels defined in Table 21-25
(Receiver minimum input level sensitivity) in IEEE Std 802.11-2020 for
the 160 MHz mode are higher by 3 dBm compared to the values of the 80
MHz mode for each rate.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add checks for features supported by the specific hardware mode of the
local device that has the channel for which the throughput is being
estimated instead of assuming the local device supports all optional
features. This is more accurate for cases where the local capabilities
might differ based on the band. In addition, this is in preparation for
extending rate estimates to cover optional VHT and HE features.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Add user configured vendor IEs for Probe Request frames to default scan
IEs so that these IEs will be included in the Probe Request frames for
the scans issued also by components other than wpa_supplicant.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Replace the implicit boolean checks that used int variables with use of
a more explicit bool variable type.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Support possible band combinations of 2.4 GHz, 5 GHz, and 6 GHz with
QCA_WLAN_VENDOR_ATTR_SETBAND_MASK attribute. Ensure backwards
compatibility with old drivers that are using
QCA_WLAN_VENDOR_ATTR_SETBAND_VALUE attribute and supporting only 2.4 GHz
and 5 GHz bands.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
This functionality was repeated for couple of times. Use a shared helper
function to avoid code duplication.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Add initial_freq_list to wpa_supplicant configuration. This option
allows wpa_supplicant to scan a smaller list of frequencies when it
starts. This in turn allows for a faster connection to an already known
network. This limit applies only for the initial scan operation and does
not restrict other channels from being used in consecutive scans.
Tests have shown this to reduce the amount of time for connecting to a
network from roughly 3 seconds to roughly 0.1 second.
Signed-off-by: Frederik Juul <frederik.juul@3shape.com>
Use the common IE parsing routine in hope of trying to make the length
checks easier for static analyzers. In addition, try to make the
*_vendor_ie_multi() cases easier to analyze as well even though they
cannot use for_each_element_id().
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
When using NetworkManager to set up an access point, there seems to be a
race condition which can lead to a new log message every second.
The following message appears in AP mode:
CTRL-EVENT-SCAN-FAILED ret=-95 retry=1
Normally, this log message only appears once. But then (and only then)
the race is triggered and they appear every second, the following log
messages are also present:
Reject scan trigger since one is already pending
Failed to initiate AP scan
This patch just disables the retry for requests where the operation is
not supported anyway.
Signed-off-by: Georg Müller <georgmueller@gmx.net>
There is no real use case for the scan to be requested on more than 100
channels individually. To avoid excessively long lists with invalid
configuration, use 100 entry limit for the list before dropping to the
fallback scan-all-channels option.
Signed-off-by: Jouni Malinen <j@w1.fi>
While int and unsigned int are not going overflow in practice as 32-bit
values, these could at least in theory hit an integer overflow with
16-bit int. Use size_t to avoid such potential issue cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Make max_*_rate() functions and rate calculation at the beginning of
wpas_get_est_tpt() more continuous. In wpa_supplicant_need_to_roam(), we
compare these values to make a roaming decision. However, at certain
SNRs, we see unrealistically large jumps in estimated throughput
according to these functions, leading us to make incorrect roaming
decisions. Perform linear interpolation where applicable to more
accurately reflect actual throughput.
Example:
wlan0: Current BSS: 88:3d:24:b4:95:d2 freq=2412 level=-69 snr=20 est_throughput=54000
wlan0: Selected BSS: 88:3d:24:b4:89:9e freq=2417 level=-67 snr=22 est_throughput=63500
wlan0: Using signal poll values for the current BSS: level=-69 snr=20 est_throughput=54000
wlan0: Allow reassociation - selected BSS has better estimated throughput
2 dB increase in RSSI likely isn't responsible for a 17% increase in
throughput.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Specific BSSID scan was replacing wildcard SSID with the known SSID if
any BSS with the specified BSSID is available in the known BSSes list.
Add control interface support to force use of a wildcard SSID in a
specific BSSID scan by user with the new "wildcard_ssid=1" argument to
the SCAN command.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Local variable should be used. This fixes an issue where IEs are
available only from a Beacon frame.
Fixes: ad06ac0b0 ("Move throughput estimation into a helper function")
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
The 5 GHz channels are stored in one hw_features set with mode
HOSTAPD_MODE_IEEE80211A while the 6 GHz channels will need to be stored
in a separate hw_features set (but with same mode
HOSTAPD_MODE_IEEE80211A) due to possibility of different HT/VHT/HE
capabilities being available between the 5 GHz and 6 GHz bands.
Iterate through all hw_features sets and check and match the band of
channel supported by the hw_features set while getting the hw_features
set in get_mode(). This allows both the 5 GHz and 6 GHz channels to be
found and correct capabilities to be used in cases where the driver
reports different capability values between 5 and 6 GHz channels.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
This is a step towards allowing this functionality to update the scan
result -based values with the values from a signal poll for the current
BSS.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
wpas_dbus_handler_scan() constructs a set of 'params' each time, but it
doesn't acknowledge the existing randomization settings when doing so.
That means that any D-Bus initiated scans weren't going to follow the
configured settings.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
Add D-Bus property:
* MACAddressRandomizationMask: a{say}
which configure random MAC address functionality in the Wi-Fi
driver via netlink.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
This array can be freed either from the scan parameters or from
clearing the MAC address randomization parameters from the
wpa_supplicant struct. To make this ownership more clear, we have
each struct own its own copy of the parameters.
Signed-off-by: Eric Caruso <ejcaruso@chromium.org>
wpa_scan_result_compar() would return wb->est_throughput -
wa->est_throughput in case the comparison is done based on the
throughput estimates. While the return value from this function is a
signed integer, these est_throughput values are unsigned integers and
need to be explicitly typecast to avoid an UBSan warning.
scan.c:1996:30: runtime error: unsigned integer overflow: 54000 - 135000 cannot be represented in type 'unsigned int'
Signed-off-by: Jouni Malinen <j@w1.fi>
When setting scan with randomized MAC, check the requested scan type
against supported types, to ensure callers will not set an unsupported
type, since this can cause scan/connect failures later. It is better to
do this in wpas_mac_addr_rand_scan_set() instead of control interface
specific code to apply the constraint on all possible interfaces using
this setting.
Signed-off-by: Lior David <liord@codeaurora.org>
The HS 2.0 Indication element can be up to 9 octets in length, so add
two more octets to the minimum extra_ie buffer size for scanning.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Hotspot 2.0 tech spec mandates mobile device to not indicate a release
number that is greater than the release number advertised by the AP. Add
this constraint to the HS 2.0 Indication element when adding this into
(Re)Association Request frame. The element in the Probe Request frame
continues to show the station's latest supported release number.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
An OWE AP device that supports transition mode does not transmit the
SSID of the OWE AP in its Beacon frames and in addition the OWE AP does
not reply to broadcast Probe Request frames. Thus, the scan results
matching relies only on Beacon frames from the OWE open AP which can be
missed in case the AP's frequency is actively scanned.
To improve the discovery of transition mode APs, include their SSID in
the scan command to perform an active scan for the SSIDs learned from
the open mode BSSs.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
If the device supports OCE features and OCE is enabled, set the relevant
scan parameters and FILS Request Parameters element with Max Channel
Time.
Signed-off-by: Roee Zamir <roee.zamir@intel.com>
Add a flag to scan parameters that enables OCE scan features. If this
flag is set the device should enable the following features as defined
in the Optimized Connectivity Experience Technical Specification v1.0:
- Overwrite FILS request Max Channel Time with actual value (clause 3.8)
- Send Probe Request frame in high rate (at least 5.5 Mbps) (clause 3.12)
- Probe Request frame Transmission Deferral and Suppression (clause 3.5)
- Accept broadcast Probe Response frame (clause 3.6)
Signed-off-by: Roee Zamir <roee.zamir@intel.com>
When failing to trigger scan for beacon report (e.g., when the
requested duration is not supported by the driver), send a
Radio Measurement response with the mode set to refused and don't
retry the scan.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
