These can fail during heavy CPU load due to active scan dwell time not
being long enough to catch the delayed Probe Response frame from the AP.
Work around this by allowing multiple scan attempts to see the response.
Signed-off-by: Jouni Malinen <j@w1.fi>
There was a bug in this code path that resulted in the
skip-scan-to-start-GO case to not actually skip the scan. It looks like
this could be hit at least when autoscan was enabled, but it is possible
that some other sequences could hit this as well.
Signed-off-by: Jouni Malinen <j@w1.fi>
Since P2P Client scan case is now optimzied to use a specific SSID, the
WPS AP will not reply to that and the scan after GO Negotiation can
quite likely miss the AP due to dwell time being short enoguh to miss
the Beaco frame. This has made the test case somewhat pointless, but
keep it here for now with an additional scan to confirm that PBC
detection works if there is a BSS entry for a overlapping AP.
Signed-off-by: Jouni Malinen <j@w1.fi>
The single channel scan while associated to another AP and immediately
after starting the second AP can miss the Probe Response frame
especially under heavy CPU load. Avoid false error reports by allowing
multiple scan rounds to be performed. wpas_ctrl_bssid_filter is also
modified to take into account different get_bss() behavior.
Signed-off-by: Jouni Malinen <j@w1.fi>
This adds a test case for the server fragmenting an EAP-IKEv2 message.
In addition, the fragmentation threshold is made shorter to trigger
fragmentation for all messages.
Signed-off-by: Jouni Malinen <j@w1.fi>
The BSS id numbers were assumed to start from 0 at the beginning of this
test case, but that is only the case if this is run as the first test
after starting wpa_supplicant. Fix the test case to figure out the id
values dynamically to avoid false errors.
Signed-off-by: Jouni Malinen <j@w1.fi>
Extend EAP-SIM/AKA/AKA' test coverage by setting up another
authentication server instance to store dynamic SIM/AKA/AKA' information
into an SQLite database. This allows the stored reauth/pseudonym data to
be modified on the server side and by doing so, allows testing fallback
from reauth to pseudonym/permanent identity.
Signed-off-by: Jouni Malinen <j@w1.fi>
This allows control interface issues to be caught in a bit more readable
way in the debug logs. In addition, dump pending monitor socket
information more frequently and within each test case in the log files
to make the output clearer and less likely to go over the socket buffer
limit.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It is possible for the scan to miss a Probe Response frame especially
under heavy load, so try again to avoid reporting invalid failures.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible for a scan to fail to see Probe Response or Beacon frame
under heavy load (e.g., during a parallel-vm.sh test run) since the
dwell time on a chanenl is quite short. Make the test cases using
INTERWORKING_SELECT more robust by trying again if the first attempt
does not find a matching BSS.
Signed-off-by: Jouni Malinen <j@w1.fi>
It is possible for the final step of the test case to fail under load
(e.g., when using parallel-vm.sh with large number of VMs), so run
through additional scan iterations if the WPS-AUTH flag does not get
removed immediately.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Verify that AP acts on 40 MHz intolerant STA association/disassociation
and on 20/40 co-ex report indicating 40 MHz intolerant AP showed up and
removed.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
It turned out that the initial test case found the GO based on the
initial full scan instead of the progressive search part. Fix this by
started the GO only after the initial full scan.
Signed-off-by: Jouni Malinen <j@w1.fi>
This can fail if Probe Response frame is missed and Beacon frame was
used to fill in the BSS entry. This can happen, e.g., during heavy load
every now and then and is not really an error, so try to workaround by
runnign another scan.
Signed-off-by: Jouni Malinen <j@w1.fi>
It seems like it is possible for a CTRL-EVENT-REGDOM-CHANGE event from a
previous test case to "leak" through to the execution of this test case.
That can result in the validation steps here failing, so wait a bit and clear the pending events before starting the test.
Signed-off-by: Jouni Malinen <j@w1.fi>
