wpa_supplicant keeps a blacklist of BSSs in order to prevent repeated
associations to problematic APs*. Currently, this blacklist is
completely cleared whenever we successfully connect to any AP. This
causes problematic behavior when in the presence of both a bad AP and
a good AP. The device can repeatedly attempt to roam to the bad AP
because it is clearing the blacklist every time it connects to the good
AP. This results in the connection constantly ping-ponging between the
APs, leaving the user stuck without connection.
Instead of clearing the blacklist, implement timeout functionality which
allows association attempts to blacklisted APs after some time has
passed. Each time a BSS would be added to the blacklist, increase the
duration of this timeout exponentially, up to a cap of 1800 seconds.
This means that the device will no longer be able to immediately attempt
to roam back to a bad AP whenever it successfully connects to any other
AP.
Other details:
The algorithm for building up the blacklist count and timeout duration
on a given AP has been designed to be minimally obtrusive. Starting with
a fresh blacklist, the device may attempt to connect to a problematic AP
no more than 6 times in any ~45 minute period. Once an AP has reached a
blacklist count >= 6, the device may attempt to connect to it no more
than once every 30 minutes. The goal of these limits is to find an
ideal balance between minimizing connection attempts to bad APs while
still trying them out occasionally to see if the problems have stopped.
The only exception to the above limits is that the blacklist is still
completely cleared whenever there are no APs available in a scan. This
means that if all nearby APs have been blacklisted, all APs will be
completely exonerated regardless of their blacklist counts or how close
their blacklist entries are to expiring. When all nearby APs have been
blacklisted we know that every nearby AP is in some way problematic.
Once we know that every AP is causing problems, it doesn't really make
sense to sort them beyond that because the blacklist count and timeout
duration don't necessarily reflect the degree to which an AP is
problematic (i.e. they can be manipulated by external factors such as
the user physically moving around). Instead, its best to restart the
blacklist and let the normal roaming algorithm take over to maximize
our chance of getting the best possible connection quality.
As stated above, the time-based blacklisting algorithm is designed to
be minimally obtrusive to user experience, so occasionally restarting
the process is not too impactful on the user.
*problematic AP: rejects new clients, frequently de-auths clients, very
poor connection quality, etc.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
Within wpas_connection_failed(), the 'count' value of wpa_blacklist is
erroneously used as a tally of the number times the device has failed
to associate to a given BSSID without making a successful connection.
This is not accurate because there are a variety of ways a BSS can be
added to the blacklist beyond failed association such as interference
or deauthentication. This 'count' is lost whenever the blacklist is
cleared, so the wpa_supplicant stores an additional value
'extra_blacklist_count' which helps persist the 'count' through clears.
These count values are used to determine how long to wait to rescan
after a failed connection attempt.
While this logic was already slightly wrong, it would have been
completely broken by the upcoming change which adds time-based
blacklisting functionality. With the upcoming change, 'count' values
are not cleared on association, and thus do not necessarily even
approximate the "consecutive connection failures" which they were being
used for.
This change seeks to remove this unnecessary overloading of the
blacklist 'count' by directly tracking consecutive connection failures
within the wpa_supplicant struct, independent of the blacklist. This new
'consecutive_conn_failures' is iterated with every connection failure
and cleared when any successful connection is made. This change also
removes the now unused 'extra_blacklist_count' value.
Signed-off-by: Kevin Lund <kglund@google.com>
Signed-off-by: Brian Norris <briannorris@chromium.org>
The blacklist design will be modified in the following commits and that
would result in this validation step based on the older implementation
starting to fail. Remove this check to avoid such testing failures.
Signed-off-by: Jouni Malinen <j@w1.fi>
commit f4e3860f ("Fix AP mode default TXOP Limit values for AC_VI
and AC_VO") corrects the default values of txop_limit from 93/46
to 94/47 for AP. STA would also need the same change.
Signed-off-by: Yogesh Kulkarni <yogesh.kulkarni@nxp.com>
Signed-off-by: Cathy Luo <xiaohua.luo@nxp.com>
Signed-off-by: Ganapathi Bhat <ganapathi.bhat@nxp.com>
You can now specify BUILDDIR= on the make command line,
e.g., in order to put that into a tmpfs or similar.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
The file was already outdated again, so rewrite it to ignore
anything but c, h and sh files that start with "test-".
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
These are no longer needed now. Note that this was never actually
sufficient since src/drivers/ isn't the only thing shared, and thus a
cross-build detection didn't work in all cases.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
If the .config file changes, basically everything needs to be
rebuilt since we don't try to detect which symbols changed or
such. Now that the .config file handling is in the common
build system, make everything depend on it if there's one.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Instead of building in the source tree, put most object
files into the build/ folder at the root, and put each
thing that's being built into a separate folder.
This then allows us to build hostapd and wpa_supplicant
(or other combinations) without "make clean" inbetween.
For the tests keep the objects in place for now (and to
do that, add the build rule) so that we don't have to
rewrite all of that with $(call BUILDOBJS,...) which is
just noise there.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
This will make it easier to split out the handling in
a proper way, and handle common cflags/dependencies.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Clean up in a more common fashion as well, initially for ../src/.
Also add $(Q) to the clean target in src/
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Some things are used by most of the binaries, pull them
into a common rule fragment that we can use properly.
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
When testing SAE reflection, the incoming commit may have the H2E status
code (126) or SAE-PK (127), but the test code in the AP was always
sending back status code 0. The STA would then reject the commit
response due to expecting H2E/SAE-PK status code.
Just reflect the incoming status code so the commit can be rejected
based on the SAE contents regardless of which variant of SAE was used.
Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com>
If there is no matching interface given, but interface matching is
enabled, all interfaces on the system will try to be initialized. Non
wireless interfaces will fail and the loopback device will be one of
these, so just log a diagnostic rather than an error.
Signed-off-by: Roy Marples <roy@marples.name>
Instead, log a diagnostic so that noise to the user is reduced. This is
expected behavior with driver interfaces that do not report supported
operating modes/classes.
Signed-off-by: Roy Marples <roy@marples.name>
Unless debugging.
wpa_supplicant will log it failed to initialized the driver for the
interface anyway so this just silences some noise for users.
Signed-off-by: Roy Marples <roy@marples.name>
This is needed for clearing previously set parameters in a similar
manner that was already available through the control interface
SET_NETWORK command.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Remove this part of the dbus_network test case since it would be causing
failures after wpa_supplicant is modified to accept empty strings
through D-Bus.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Teach wpa_supplicant to {de,}initialize bgscans when bgscan parameters
are set after initial connection.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
Currently, wpa_config_set(), the function that sets wpa_supplicant
per-network properties, returns 1 when a property it attempts to set is
unchanged. Its global parallel, wpa_config_process_global(), doesn't do
this even though much of the code is very similar. Change this, and
several of the parser functions, to resemble the per-network parser and
setter functions.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
When network properties are updated via dbus, wpa_config_set() is used
to update the property in the wpa_ssid struct. If it returns 1, the
property was not changed and there's no need to perform any of the
update actions.
Signed-off-by: Matthew Wang <matthewmwang@chromium.org>
D-Bus clients can call CreateInterface() once and use the resulting
Interface object to connect multiple times to different networks.
However, if the network interface gets added to a bridge, clients
currently have to remove the Interface object and create a new one.
Improve this by supporting the change of the BridgeIfname property of
an existing Interface object.
Signed-off-by: Beniamino Galvani <bgalvani@redhat.com>
This is useful to run monitor quickly:
./run-tests.py -t run_monitor -m mon:36,20,36,0:1,20,1,0
In such example we will get one PCAP for 36/20 and 1/20.
After execution, PCAP file is in the log directory, e.g.:
./logs/2019_11_11_13_36_24/run_monitor_mon_wlp3s0_wlp5s0.pcap
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
This is mainly for standalone monitor in case we know and would like to
setup specific monitor configuration.
-m monitor:<chan>,<bw>, <cf1>, <cf2>:...
For example:
-m monitor:1,40,3,0
-m e4300:1,40,3,0:11,40,9,0
This also supports monitor with multiple interfaces (one pcap).
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Before we have to kill an application we start in the thread - in most
cases using killall and sometimes kill other applicantions, e.g., tcpdump,
iper, iperf3, tshark.
With this patch we are able to stop/kill a single application/thread
instead, based on the pid file.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
In case we are using ssh MUX (which speed up a lot test execution) with
remotehost we could hit cases where ssh will hang up. This depends on
different ssh versions and remotehost implementation.
stderr as a tmpfile fixes this problem.
Signed-off-by: Janusz Dziedzic <janusz.dziedzic@gmail.com>
Add a new configuration parameter p2p_6ghz_disable=1 to disable P2P
operation in the 6 GHz band. This avoids additional delays caused by
scanning 6 GHz channels in p2p_find and p2p_join operations in the cases
where user doesn't want P2P connection in the 6 GHz band.
Signed-off-by: Sreeramya Soratkal <ssramya@codeaurora.org>
Some legacy stations copy previously reserved RSN capability bits,
including OCVC, in (Re)Association Request frames from the AP's RSNE but
do not indicate MFP capability and/or do not send OCI in RSN handshakes.
This is causing connection failures with such erroneous STAs.
To improve interoperability with such legacy STAs allow a workaround OCV
mode to be enabled to ignore OCVC=1 from the STA if it does not follow
OCV requirements in the first protected exchange. This covers cases
where a STA claims to have OCV capability, but it does not negotiate use
of management frame protection or does not include OCI in EAPOL Key msg
2/4, FT Reassociation Request frame, or FILS (Re)Association Reqest.
The previous behavior with ocv=1 is maintained, i.e., misbehaving STAs
are not allowed to connect. When the new workaround mode is enabled with
ocv=2, the AP considers STA as OCV capable on below criteria
- STA indicates both OCV and MFP capability
- STA sends OCI during connection attempt in a protected frame
Enabling this workaround mode reduced OCV protection to some extend
since it allows misbehavior to go through. As such, this should be
enabled only if interoperability with misbehaving STAs is needed.
Signed-off-by: Veerendranath Jakkam <vjakkam@codeaurora.org>
Modify status code in FT Reassociation Response frame from
WLAN_STATUS_UNSPECIFIED_FAILURE to WLAN_STATUS_INVALID_FTE when replying
to an invalid OCI channel info (subelement of FTE) in FT Reassociation
Request frame.
Signed-off-by: Shaakir Mohamed <smohamed@codeaurora.org>
Generate a control interface event upon receipt of DPP Presence
Announcement frames. This allows external programs to instrument
wpa_supplicant with bootstrapping information on-demand.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
Generate a control interface event upon receipt of DPP Presence
Announcement frames. This allows external programs to instrument hostapd
with bootstrapping information on-demand.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
Define a control event with bootstrap id, frame source, frequency, and
chirp hash for receipt of Presence Announcement (chirp) frames.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
When a Presence Announcement frame is received, a check is done to
ensure an ongoing auth is not in progress (!hapd->dpp_auth). A new DPP
auth is then initialized, however, when setting global configurator
params for it, the hapd->dpp_auth pointer is used which was earlier
confirmed as NULL, causing a crash in dpp_set_configurator params when
the pointer is dereferenced.
This only occurs when there are global DPP configurator params to be set
and the peer has no overriding configurator params. If no global DPP
configurator params exist, the call to dpp_set_configurator exits early
and the problem is not observed.
Fix by using the newly init'ed DPP auth structure for setting global
DPP configurator params.
Signed-off-by: Andrew Beltrano <anbeltra@microsoft.com>
ignore_broadcast_ssid is supported when using with the config
file. But it generates an error if you try to set it via the
DBus interface.
Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
DPP tech spec was modified to use v1(0) instead of v2(1) for the
OneAsymmetricKey in the Configurator backup structure to match the
description in RFC 5958 Section 2 which indicates v2 to be used when any
items tagged as version 2 are included. No such items are actually
included in this case, so v1 should be used instead.
Change OneAsymmetricKey generation to use v1(0) instead of v2(1) and
parsing to accept either version to be used. This is not backwards
compatible with the earlier implementation which requires v2(1) when
parsing the received value.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
