Starting a thread to initiate DPP before starting the responder through
sigma_dut can result in unexpected testing behavior since there may not
be enough time to get the responder enabled before timing out som
initiator actions. Wait a second at the beginning of the initiator
thread in dpp_init_conf() similarly to how this was handled in other
initiator-from-thread cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
Wait for stdout/stderr in a more robust manner to avoid blocking the
pipes and kill the sigma_dut process if it fails to terminate cleanly.
Signed-off-by: Jouni Malinen <j@w1.fi>
This event may be sent before CTRL-EVENT-CONNECTED, so modify the test
cases to wait directly for TRANSITION-DISABLE by skipping the separate
wait for CTRL-EVENT-CONNECTED.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
It is possible for the sigma_dut process to be scheduled in a manner
that ends up combining the status,RUNNING and status,COMPLETE lines into
a single TCP message. This was supposed to be handled in the
sigma_dut_cmd() implementations, but that design had been broken by code
refactoring that changed the indentation level incorrectly.
Fixes: d68946d510 ("tests: sigma_dut and DPP push button first on Enrollee")
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
When these are issued while associated, scanning all channels can take a
significant amount of time. That happened to work for existing test
cases somewhat by accident since the scan was sometimes limited to only
the current operating channel. However, that is now changing and the
following two test cases started failing with the change, so make them
wait longer:
sigma_dut_sae_pw_id_ft sigma_dut_ft_rsnxe_used_mismatch
Signed-off-by: Jouni Malinen <j@w1.fi>
This makes sigma_dut_ap_dpp_qr* test cases with SAE more robust by
avoiding unexpected behavior. This was found with the following test
sequence:
mesh_sae_anti_clogging sigma_dut_ap_dpp_qr_sae
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Clear the dpp_connector_privacy_default parameter value that sigma_dut
set in wpa_supplicant at the end of the test case to avoid surprising
behavior for the following test cases. This was found with a failure in
the following test sequence:
sigma_dut_dpp_qr_mutual_resp_enrollee_connector_privacy
sigma_dut_dpp_proto_peer_disc_req
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
The part about checking the supported curves from the peer depends on
CONFIG_DPP3 and this test case needs to be skipped without that.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Prepare for an implementation change for the PB discovery channel list.
Move the standlone (not an AP) PB Configurators to a preferred channel
and enable Configurator connectivity indication in APs that act as PB
Configurators.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
These were testing only of SAE, not SAE-PK capability, and needs to be
skipped in SAE-PK is not included in the build.
Signed-off-by: Jouni Malinen <j@w1.fi>
BoringSSL is known not to support this option, so skip it to allow rest
of the test case to be performed without known failures.
Signed-off-by: Jouni Malinen <j@w1.fi>
The first sock.recv() may return both the status,RUNNING and the
following status line if the sigma_dut process ends up being faster in
writing the result than the test script is in reading the result. This
resulted in unexpected behavior and odd error messages when parsing the
result in the test cases. Fix this by dropping the status,RUNNING line
from the result in case the buffer includes multiple lines.
Signed-off-by: Jouni Malinen <j@w1.fi>
This is needed to avoid test failures when a previous test case might
have restricted the set of allowed SAE groups.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
Now that wpa_supplicant does this internally as a part of the FLUSH
command, there is no need for the test scripts to try to clear the
parameter between test cases.
Signed-off-by: Jouni Malinen <quic_jouni@quicinc.com>
This test case was missing an explicit CAPI ap_reset_default and that
could result in hostapd being left running at the end of the test case.
This could result in issues with following test cases if they used a new
radio interface from HWSimRadio().
Signed-off-by: Jouni Malinen <j@w1.fi>
These commands were being issues to incorrect wpa_supplicant instance
and were missing clearing of the MAC_RAND_SCAN parameter.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was possible for these test cases to fail if the first scan iteration
did not find the AP since the 10 second timeout was small enough to
terminate the second attempt before fetching the scan results. Increase
this timeout to allow at least two full scan iterations to be completed
before declaring failure.
Signed-off-by: Jouni Malinen <j@w1.fi>
