Add transition mode SSIDs to the SSID scan-list for bgscan. This is
currently missing and bgscan fails to scan for SSIDs on the OWE
transition network if one is currently used.
Signed-off-by: David Bauer <mail@david-bauer.net>
This was done with spatch using the following semantic patch and minor
manual edits to clean up coding style and avoid compiler warnings in
driver_wext.c:
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) == 0
+ ether_addr_equal(a, b)
@@
expression a,b;
@@
- os_memcmp(a, b, ETH_ALEN) != 0
+ !ether_addr_equal(a, b)
@@
expression a,b;
@@
- !os_memcmp(a, b, ETH_ALEN)
+ ether_addr_equal(a, b)
Signed-off-by: Jouni Malinen <j@w1.fi>
Drivers will often report regdom changes in the middle of a scan if they
detect during that scan that the regulatory domain has changed. If this
happens and we enter a regdom that supports 6 GHz channels when the
previous one didn't (this often happens in 6 GHz-capable regdoms for
devices after suspend/resume), immediately trigger a 6 GHz-only scan if
we were not able to connect to an AP on a legacy band.
This should significantly improve connection time to 6 GHz AP after
regdom has been reset.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
wpa_supplicant_trigger_scan() previously wouldn't include any of the IEs
generated by wpa_supplicant_extra_ies(). Instruct it to do so in most
cases. This is necessary because MBO STAs are required to include MBO
capabilities in their Probe Request frames.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Facilitate emitting more station information over D-Bus for use by the
connection manager.
* Add storage for more NL80211_STA_INFO_* fields to data structures, and
move them through the system.
* Reorder NL80211_STA_INFO_* fields in driver_nl80211.c to match the
ordering in nl80211.h.
* Convert signal field to an integer to support holding WPA_INVALID_NOISE
and avoid changing logging.
* Add fields to hostap_sta_driver_data to capture more information
* fcs_error_count
* beacon_loss_count
* expected_throughput
* rx_drop_misc
* rx_mpdus
* rx_hemcs
* tx_hemcs
* rx_he_nss
* tx_he_nss
* avg_signal
* avg_beacon_signal
* avg_ack_signal
* Add struct hostap_sta_driver_data to struct wpa_signal_info and remove
redundant fields and redundant attribute parsing
* Change logging when printing txrate to handle unsigned long
value
Signed-off-by: David Ruth <druth@chromium.org>
The bgscan simple and learn algorithms should run regardless
of wall clock time jumps, so make them use monotonic time.
Signed-hostap: Johannes Berg <johannes.berg@intel.com>
bgscan_learn_get_probe_freq() starts from returning the second entry in
the supp_freqs arrays. Change its logic a bit to make it start from the
first entry.
Signed-hostap: Eliad Peller <eliad@wizery.com>
In case the initial signal level of the associated BSS was above the
given threshold, bgscan_learn module would begin using the
short_interval but never switch to the long_interval as there would be
no signal change event. Make the init code poll for the current signal
level and set scan_interval accordingly. This logic exists in
bgscan_simple but was missing in bgscan_learn.
Signed-hostap: Eyal Shapira <eyal@wizery.com>
Some hw modes (e.g., 11b and 11g) contain the same frequencies,
causing the supp_freqs array to be populated with redundant entries.
Check for the existence of the freq before adding it.
Signed-hostap: Eliad Peller <eliad@wizery.com>
In highly congested network (BSSes almost on every channel
within ESS) we have hit a bug when wpa_supplicant become
completly irresponsive, infinite looping on while loop.
When probe_idx was equal 0 and we are not able to probe
new frequency, following condition were never fulfilled:
"if (!in_array(freqs, data->supp_freqs[idx]))"
Signed-hostap: Pawel Kulakowski <pawel.kulakowski@tieto.com>
The hardware feature data is required in several different places
throughout the code. Previously, the data was acquired and freed on
demand, but with this patch wpa_supplicant will keep a single copy
around at runtime for everyone to use.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
The driver is likely to indicate an immediate signal event when the
threshold value is configured. Since we do this immediately after
association, there is not much point in requesting a new scan to be
started based on this event.
Store list of all discovered BSSes in the ESS and on which frequencies
they have been seen. Use this information to dynamically generated the
list of channels for background scans.