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>
In ap_scan=2 mode, wpa_supplicant_assoc_try() did not check whether the
SSID is temporarily disabled before trying to associate and this may
result in an infinite connect/disconnect loop. If the association
succeeds while the SSID is temporarily disabled, wpa_supplicant will
request to deauthenticate and that in turn will cause the SSID to be
temporarily disabled again. Fix that by postponing the association until
the SSID is no longer temporarily disabled.
Signed-off-by: Shaul Triebitz <shaul.triebitz@intel.com>
The userspace may want to delay the the first scheduled scan.
This enhances sched_scan to add initial delay (in seconds) before
starting first scan cycle. The driver may optionally choose to
ignore this parameter and start immediately (or at any other time).
This uses NL80211_ATTR_SCHED_SCAN_DELAY to add this via user
global configurable option: sched_scan_start_delay.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This leads to cleaner code overall, and also reduces the size
of the hostapd and wpa_supplicant binaries (in hwsim test build
on x86_64) by about 2.5 and 3.5KiB respectively.
The mechanical conversions all over the code were done with
the following spatch:
@@
expression SIZE, SRC;
expression a;
@@
-a = os_malloc(SIZE);
+a = os_memdup(SRC, SIZE);
<...
if (!a) {...}
...>
-os_memcpy(a, SRC, SIZE);
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Previously it was possible for wpa_s->scan_res_handler to remain set to
its old value in case wpa_drv_scan() failed and no retry for the scan
trigger was scheduled (i.e., when last_scan_req == MANUAL_SCAN_REQ).
This could result in getting stuck with the next connection attempt
after a failed "SCAN TYPE=ONLY" operation when wpa_s->scan_res_handler
was set to scan_only_handler().
Fix this by clearing wpa_s->scan_res_handler if wpa_drv_scan() fails and
no retry is scheduled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This functionality was originally added in commit
204c9ac4ee ('Extend select_network command
with freq= to reduce scan time') re-using wpa_s->manual_scan_freqs and
MANUAL_SCAN_REQ. That got broken when commit
35d403096e ('Set NORMAL_SCAN_REQ on
SELECT_NETWORK/ENABLE_NETWORK') started overriding wpa_s->scan_req for
SELECT_NETWORK.
Fix this by adding a new scan frequency list specifically for
SELECT_NETWORK so that this does not need to depend on any specific
wpa_s->scan_req value.
Signed-off-by: Jouni Malinen <j@w1.fi>
Previously, the est_throughput comparison was done only when SNR
difference was less than 5 dB. Since the throughput estimation take into
account SNR, this can be done in more cases. For now, add a conservative
2 dB more to the difference so that any SNR difference below 7 dB
results in BSS selection based on throughput estimates.
In addition, the throughput estimates require SNR values to be
available, so separate this from the 5 GHz preference that can be done
based on either SNR or qual values.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows throughput estimates and 5 GHz preference over 2.4 GHz band
to be used in more cases. The previously used value of 30 was
significantly more conservative than the SNR limits used for the highest
rate in scan_est_throughput() and this resulted in cases where 5 GHz AP
was ignored while SNR with it would have been close to reaching the
maximum TX rate.
Signed-off-by: Jouni Malinen <j@w1.fi>
Add support to set sched scan relative RSSI parameters so that the
drivers can report BSSs after relative comparision with the current
connected BSS. This feature is applicable only when in connected mode.
The below commands can be used to configure relative RSSI parameters
SET relative_rssi <disable|rssi_value>
disable - to disable the feature
rssi_value - amount of relative RSSI in dB
SET relative_band_adjust <band:adjust_value>
band - "2G" or "5G" for 2.4 GHz or 5 GHz respectively
adjust_value - amount of RSSI to be adjusted in dB
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Sched scan is supported by the kernel also in the connected state, so
allow PNO scan to be issued in the connected state from wpa_supplicant
as well.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add the following parameters to scan request:
1. Dwell time on each channel.
2. Whether the specified dwell time is mandatory.
In addition, add to scan results info the time that the scan actually
started, and to each scan result the time the beacon/probe was received,
both in terms of TSF of the BSS that the interface that requested the
scan is connected to (if available).
Add flags to indicate whether the driver supports dwell time
configuration and scan information reporting.
This scan configuration and information is required to support beacon
report radio measurement.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
This makes wpa_supplicant behavior more consistent with FLUSH command to
clear all state. Previously, it was possible for an ongoing scan to be
aborted when the FLUSH command is issued and the scan results from that
aborted scan would still be processed and that would update the BSS
table which was supposed to cleared by the FLUSH command.
This could result in hwsim test case failures due to unexpected BSS
table entries being present after the FLUSH command.
Signed-off-by: Jouni Malinen <j@w1.fi>
Skipping the scan altogether will hurt auto-reconnect. Also move the PNO
check down since the scan might be canceled for other reasons before we
defer it.
Signed-off-by: Arik Nemtsov <arikx.nemtsov@intel.com>
This commit enhances the existing implementation of abort scan to also
abort concurrent active vendor scans. This is achieved by passing the
the scan_cookie to the driver interface with the intention to abort
the specific scan request. This scan_cookie is returned from the driver
interface when the scan request is scheduled.
This scan_cookie is 0 if the scan is triggered through the upstream
cfg80211 interface. Thus, the scan_cookie is used to determine whether
to abort the cfg80211 or vendor scan request.
Also, the previous implementation of relying on scan_work/p2p_scan_work
for the active work to trigger the abort scan is enhanced to check for
the started state of either of these work operations. This should also
help to abort the concurrent active scan/p2p-scan operations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This commit enhances the abort scan implementation to also abort the
vendor scan, if one was used to trigger the scan.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
cfg80211 rejects the scans issued with random MAC address if the STA is
in connected state. This resulted in failures when using MAC_RAND_SCAN
while connected (CTRL-EVENT-SCAN-FAILED ret=-95). Enable random MAC
address functionality only if the STA is not in connected state to avoid
this. The real MAC address of the STA is already revealed in the
association, so this is an acceptable fallback mechanism for now.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
There are a couple of places in wpa_supplicant/hostapd where qsort() can
be called with a NULL base pointer. This results in undefined behavior
according to the C standard and with some standard C libraries (ARM RVCT
2.2) results in a data abort/memory exception. Fix this by skipping such
calls since there is nothing needing to be sorted.
Signed-off-by: Joel Cunningham <joel.cunningham@me.com>
PNO is sometimes restarted due to changes in scan parameters
(e.g., selected network changed or MAC randomization being
enabled/disabled). Restart is done by stopping PNO and immediately
starting it again. This may result in the SCHED_SCAN_STOPPED event being
received after the request for new PNO, which will make wpa_supplicant
believe PNO is not active although it is actually is. As a result, the
next request to start PNO will fail because PNO is active and should be
stopped first.
Fix this by deferring the request to start PNO until the
SCHED_SCAN_STOPPED event is received in case sched_scan is being
stopped.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
When scheduled scan stops without the interface request (for example,
driver stopped it unexpectedly), start a regular scan to continue
scanning for networks and avoid being left with no scan at all.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
This code sequence was already used at two different places (and an
additional one has been proposed), so add a common helper function to
avoid having to copy-paste this functionality in multiple locations.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
If a scheduled scan is running on select network command,
cancel and reset it before kicking off a regular scan request.
Signed-off-by: Max Stepanov <Max.Stepanov@intel.com>
This makes wpa_supplicant set default scan IEs to the driver (if the
vendor command is supported). The driver can use these IEs in the scan
requests initiated by the driver itself. Also the driver can merge these
IEs into further scan requests that it receives, in case if the scan
request doesn't carry any of the IEs sent in this command.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Previously, wpa_set_scan_ssids() fully exhausted
wpa_driver_scan_params.ssid list when hidden network IDs are provided
via the control interface. This results in us exceeding the max size for
the list advertised by the driver when we add the "wildcard" scan SSID
entry. So, ensure that we leave space for one more scan SSID entry in
the list when we exit out of wpa_set_scan_ssids().
Signed-off-by: Roshan Pius <rpius@google.com>
This adds the necessary changes to support extraction and use of the
extended capabilities specified per interface type (a recent
cfg80211/nl80211 extension). If that information is available,
per-interface values will be used to override the global per-radio
value.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Instead of reporting the memory allocation failure and stopping, run the
scan even if the frequency list cannot be created due to allocation
failure. This allows the wpa_s->reattach flag to be cleared and the scan
to be completed even if it takes a bit longer time due to all channels
getting scanned.
Signed-off-by: Jouni Malinen <j@w1.fi>
If preassoc_mac_addr is used and updating the MAC address fails in
wpas_trigger_scan_cb(), the cloned scan parameters were leaked. Fix that
and also send a CTRL-EVENT-SCAN-FAILED event in this and another error
case.
Signed-off-by: Jouni Malinen <j@w1.fi>
There is no need to have a separate if statement to skip the cases where
phase1 is not set. Just check it with the strstr comparison since this
case is not really used in practice.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_s->current_ssid is set to a non-NULL ssid pointer value here, so
there is no need for the extra if statement.
Signed-off-by: Jouni Malinen <j@w1.fi>
On receiving a WNM BSS Transition Management Request frame with a
candidate list, fetch the latest scan results from the kernel to see if
there are any recent scan results for the candidates and initiate a
connection if found. This helps to avoid triggering a new scan in cases
where a scan initiated by something else (e.g., an internal beacon
measurement report functionality in a driver) has processed Beacon or
Probe Response frames without wpa_supplicant having received a
notification of such an update yet.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The new VENDOR_ELEM value 14 can now be used to add a vendor element
into Probe Request frames used by non-P2P active scans.
For example:
VENDOR_ELEM_ADD 14 dd05001122330a
and to clear that:
VENDOR_ELEM_REMOVE 14 *
Signed-off-by: Jouni Malinen <j@w1.fi>
With the only callers in wpas_{start,stop}_pno() moved into scan.c,
there is no need to call these helper functions from outside scan.c
anymore.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds use of the driver capability (instead of hardcoded
WPAS_MAX_SCAN_SSIDS) in wpas_start_pno() similarly to what was already
done in wpa_supplicant_req_sched_scan().
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
When p2p_find is stopped, send request to the driver
in order to cancel an ongoing scan if there is one.
Signed-off-by: Ben Rosenfeld <ben.rosenfeld@intel.com>
If the BSS Transition Management Request frame includes only a single
candidate and we need to scan for the BSS to get up-to-date information,
use a scan for the known BSSID instead of wildcard BSSID. In addition,
set the SSID in the scan if it is known based on old scan results in the
BSS table. This removes unnecessary Probe Response frames when we are
interested in results from only a single BSS.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add cellular capability attribute to MBO IE and add MBO IE with cellular
capabilities to Probe Request frames. By default, cellular capability
value is set to Not Cellular capable (3).
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Add a helper function to find a certain IE inside IEs buffer by ID and
use this function in several places that implemented similar
functionality locally.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
This allows the control interface SET command to be used to update the
sched_scan_plans parameter at runtime. In addition, an empty string can
be used to clear the previously configured plan.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Add the option to configure scheduled scan plans in the config file.
Each scan plan specifies the interval between scans and the number
of scan iterations. The last plan will run infinitely and thus
specifies only the interval between scan iterations.
usage:
sched_scan_plans=<interval:iterations> <interval2:iterations2> ... <interval>
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Add 'scan plans' to driver scan parameters for scheduled scan.
Each 'scan plan' specifies the number of iterations to run the scan
request and the interval between iterations. When a scan plan
finishes (i.e., it was run for the specified number of iterations),
the next scan plan is executed. The last scan plan will run
infinitely.
The maximum number of supported scan plans, the maximum number of
iterations for a single scan plan and the maximum scan interval
are advertised by the driver.
Signed-off-by: Avraham Stern <avraham.stern@intel.com>
Connect radio work is sometimes delayed for a considerable duration if
there is an ongoing scan radio work. To avoid these delays abort the
ongoing scan on that interface before queuing a connect request. Upon a
scan done indication from the driver, connect radio work will be
scheduled.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The SCAN TYPE=ONLY results do not trigger a connection operation
automatically. As such, there was no explicit operation that would
change wpa_state after such a scan-only operation and WPA_SCANNING state
could have been left in effect until the next operation is triggered by
an external command. This is not desirable, so restore the wpa_state
that was in use when the scan was started in case WPA_SCANNING state is
still set when the scan operation completes.
This was triggered by the following mac80211_hwsim test sequence:
dbus_wps_oom scan_trigger_failure
Signed-off-by: Jouni Malinen <j@w1.fi>
Reorder terms in a way that no invalid pointers are generated with
pos+len operations. end-pos is always defined (with a valid pos pointer)
while pos+len could end up pointing beyond the end pointer which would
be undefined behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
wpa_supplicant_assoc_try() would result in the currently operating AP to
get stopped if wpa_supplicant_scan() ends up getting triggered without
MANUAL_SCAN_REQ while operating an AP. With ap_scan=2, this could
resulted in unintentional stopping of AP mode operations, so check
explicitly for that case and skip the wpa_supplicant_assoc_try() call if
needed to avoid this.
Signed-off-by: Jouni Malinen <j@w1.fi>
A typo in wpa_scan_result_compar() caused wrong scan results sorting
(and wrong roaming decision). This fixes a copy-paste regression
introduced by commit a1b790eb9d ('Select
AP based on estimated maximum throughput').
Signed-off-by: Maital Hahn <maitalm@ti.com>
Support a request to scan specific SSIDs given by user with the SCAN
command. The SSID list can be suffixed to the scan command as follows.
For example, if SSIDs "ABC" and "abc123" need to be specifically
scanned, the command should be "SCAN ssid 414243 ssid 616263313233". The
value of the SSID is passed in hexadecimal representation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
wpas_add_interworking_elements() does not need to do this since the
caller is already checking whether Interworking is enabled.
Signed-off-by: Jouni Malinen <j@w1.fi>
Always add the Extended Capabilities element to Probe Request frames (in
case it is not all zeros) to publish support for driver advertised
capabilities and wpa_supplicant specific capabilities.
This also fixes the case where Extended Capabilities element was added
for Interworking cases, but did not use the driver advertised ones and
did not handle other capabilities supported by wpa_supplicant.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
Commit 3f9ebc439c ('P2P: Allow AP/GO
interface to be started while P2P-in-progress') moved the
wpa_s->connect_without_scan and wpa_s->last_scan_req checks to an
earlier place within the wpa_supplicant_scan() function without
adjusting wpa_s->last_scan_req. This variable was set between the old
and new location, so the new location needs to use wpa_s->scan_req.
This fixes an issue where AP/GO operations were not properly started in
some operation sequence. Instead, a station mode scan was executed. This
issue could be triggered, e.g., by running the no_go_freq test case
followed by autogo_random_channel.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
The dedicated P2P management instance (wpas->p2p_mgmt == 1) using
cfg80211 P2P Device cannot be used for non-P2P uses or connection (there
is no netdev). Reject or ignore such operations to avoid unexpected
operations if enabled network blocks are configured in the
wpa_supplicant instance used to control this interface.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit a1b790eb9d ('Select AP based on
estimated maximum throughput') had a copy-paste bug than ended up
leaving one of the max_ht40_rate() cases unreachable. (CID 106087)
Signed-off-by: Jouni Malinen <j@w1.fi>
This modifies the BSS selection routines to calculate SNR and estimated
throughput for each scan result and then use the estimated throughput as
a criteria for sorting the results. This extends the earlier design by
taking into account higher throughput rates if both the AP and local
device supports HT20, HT40, or VHT80. In addition, the maximum rate is
restricted based on SNR.
In practice, this gives significantly higher probability of selecting
HT/VHT APs when there are multiple BSSes in the same ESS and SNR is not
low enough to prevent higher MCS use.
Signed-off-by: Jouni Malinen <j@w1.fi>
When noise floor measurements are not available, compute SNR
using default values for the noise floor. This helps steer us
towards 5 GHz BSSes in high signal strength environments.
In more detail...
Existing code prefers a 5 GHz BSS when the 5 GHz BSS's signal
strength is "close" to that of the 2.4 GHz BSS, or when both SNRs
are large. However, the mwifiex driver does not provide noise
floor measurements, so we can't compute SNRs.
Because mwifiex doesn't provide NF measurements, the "large SNR"
code wasn't effective. By using default values for the noise floor,
we can again compute SNRs, and decide that the SNR is high enough
that we shouldn't worry about the exact difference in SNR.
The default noise floor values (one for 2.4 GHz, and one for 5 GHz)
were chosen by measurement in a noisy environment, so they should be
conservative.
Note that while this patch is motivated by mwifiex, it affects
ath9k as well. Although ath9k provides noise floor measurements
in general, it will sometimes fail to provide a measurement for
one or more specific channels.
As a result of this patch, we'll always compare BSSes based on SNR
(either measured or estimated), rather than sometimes comparing
based on signal strength. ("Always" assumes that the
WPA_SCAN_LEVEL_DBM flag is set. It is for mwifiex and ath9k.)
While there:
- fix a whitespace issue (spaces -> tab)
- clean up existing comments
- update dump_scan_res to indicate whether the noise floor is
measured, or default
Signed-hostap: mukesh agrawal <quiche@chromium.org>
This new wpa_supplicant configuration parameter can be used to force
passive scanning to be used for most scanning cases at the cost of
increased latency and less reliably scans. This may be of use for both
testing purposes and somewhat increased privacy due to no Probe Request
frames with fixed MAC address being sent out.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This restores some of the pre-radio work behavior for scanning by
retrying scan trigger if the driver rejects it (most likely returning
EBUSY in case of nl80211-drivers). Retry is indicated in the
CTRL-EVENT-SCAN-FAILED event with "retry=1".
For manual scans (e.g., triggered through "SCAN" control interface
command), no additional retries are performed. In other words, if upper
layers want to retry, they can do so based on the CTRL-EVENT-SCAN-FAILED
event.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This can be helpful in figuring out why the driver was requested to
flush its scan results prior to starting a new scan.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was possible for interworking_find_network_match() to find a possible
BSS match in a case where more thorough checks in
wpa_supplicant_select_bss() reject network. This itself is fine, in
general, but when combined with wpa_supplicant_fast_associate()
optimization and auto_interworking=1, this resulted in a busy loop of up
to five seconds and a possible stack overflow due to recursion in that
loop.
Fix this by limiting the Interworking wpa_supplicant_fast_associate()
call to be used only once per scan iteration, so that new scan
operations can be completed before going through the scan results again.
Signed-off-by: Jouni Malinen <j@w1.fi>
1. Supported MAC address randomization for scan.
2. Supported MAC address randomization for scheduled scan.
2. Supported MAC address randomization for pno.
4. Add functions to set and clear the MAC address randomization
state variables.
Signed-off-by: Ilan Peer <ilan.peer@intel.com>
The manual scan operations with the SCAN command are supposed to have
independent set of scan frequencies, so do not allow scan_freq
parameters to override scanned frequencies for scans that were triggered
with a SCAN command.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed since the SCAN command with radio work returns before the
actual driver operation to trigger a scan has been executed and as such,
cannot return result of that operation.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
With the radio work interface in place, station interface SCAN command
was not scheduled (i.e., it got continously delayed with "Delay station
mode scan while P2P operation is in progress") when a p2p_find was
operational. Fix this be delaying station mode scan only when a P2P
operation is in progress, but not in search state.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
When mesh is configured in, include the wildcard mesh id so that mesh
networks are returned.
Signed-off-by: Javier Lopez <jlopex@gmail.com>
Signed-off-by: Jason Abele <jason.abele@gmail.com>
This adds experimental support for wpa_supplicant to assign random local
MAC addresses for both pre-association cases (scan, GAS/ANQP) and for
connections. MAC address policy for each part can be controlled
separately and the connection part can be set per network block.
This requires support from the driver to allow local MAC address to be
changed if random address policy is enabled. It should also be noted
that number of drivers would not support concurrent operations (e.g.,
P2P and station association) with random addresses in use for one or
both.
This functionality can be controlled with the global configuration
parameters mac_addr and preassoc_mac_addr which set the default MAC
address policies for connections and pre-association operations (scan
and GAS/ANQP while not connected). The global rand_addr_lifetime
parameter can be used to set the lifetime of a random MAC address in
seconds (default: 60 seconds). This is used to avoid unnecessarily
frequent MAC address changes since those are likely to result in driver
clearing most of its state. It should be noted that the random MAC
address does not expire during an ESS connection, i.e., this lifetime is
only for the case where the device is disconnected.
The mac_addr parameter can also be set in the network blocks to define
different behavior per network. For example, the global mac_addr=1 and
preassoc_mac_addr=1 settings and mac_addr=0 in a home network profile
would result in behavior where all scanning is performed using a random
MAC address while connections to new networks (e.g.,
Interworking/Hotspot 2.0) would use random address and connections to
the home network would use the permanent MAC address.
Signed-off-by: Jouni Malinen <j@w1.fi>
Global freq_list scan filtar was taken into account only by
req_scan and not by req_sched_scan. We want to allow the user
to limit the channels that wpa_supplicant will scan in req_sched_scan
requests as well.
Signed-off-by: Bojan Prtvar <bojan.prtvar@rt-rk.com>
Previously, offloaded scanning (PNO) on Android was including SSIDs from
all enabled networks regardless of the scan_ssid parameter which
resulted in different behavior for the offloaded case when comparing to
wpa_supplicant initiated scans.
Use the sched_scan match filter to allow broadcast SSID to be used for
scan_ssid=1 networks also with PNO to avoid running active scans for
SSIDs that have not been explicitly marked as requiring an SSID-specific
scan. This reduces exposure of configured network names on the device
when running offloaded scans while the host device is in sleep.
Signed-off-by: Dmitry Shmidt <dimitrysh@google.com>
The new "scan_id=<comma separated list of network ids>" parameter can
now be used to specify a list of network ids that have scan_ssid=1 to
indicate active scanning of the SSID. This adds the listed SSIDs to the
scan command to allow manual scan requests to perform active scans for
hidden SSIDs. For example, "SCAN scan_id=1,7,11" would run a scan with
the SSID fetched from the configured network blocks 1, 7, and 11
(assuming those are set with scan_ssid=1). The SSIDs will be included
even from network blocks that are currently disabled.
The maximum number of SSIDs added to the request is limited by the
driver support. If more than supported values are specified, the command
will fail (returns "FAIL").
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This removes number of unnecessary #ifdef CONFIG_P2P blocks from generic
code by hiding the conditional build into p2p_supplicant.h with empty
inline functions.
Signed-off-by: Jouni Malinen <j@w1.fi>
Commit 41d5ce9e0b was intended to scan for
GO on the negotiated channel for few iterations, but it did not work
correctly due to incorrect operator being used. Fix this by requiring
both conditions to be met for the single channel scan.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Mark the scan performed by the P2P Client in search of the GO
during the persistant reinvocation as a p2p_probe to avoid
unnecessary use of 802.11b rates.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Scan for GO on the negotiated operating channel for few iterations
before searching on all the supported channels during persistent group
reinvocation. In addition, use the already known SSID of the group in
the scans. These optimizations reduce group formation time.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
