This parameter has no impact to TLS client functionality, so these is
not really any point to maintain these test cases.
Signed-off-by: Jouni Malinen <j@w1.fi>
A test may want to check multicast connectivity independent of unicast
or check multicast without exercising unicast first. Factor out the
multicast connectivity check code into its own function.
Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com>
"finally" handler should not trigger a new exception when trying to
clear state for non-DPP builds. In addition, couple of checks for DPP
capability in the build were missing.
Signed-off-by: Jouni Malinen <j@w1.fi>
It was clearly too easy to get unexpected behavior by accidentially
passing in a string instead of a list of strings to these functions, so
enforce the correct type to notice such issues automatically.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
dbus_p2p_go_neg_init, dbus_p2p_group_idle_timeout, and
dbus_p2p_group_termination_by_go could end up print a "DETACH failed"
exception as a warning from WpaSupplicant.__del__ for the dev1 instance
used within the TestDbusP2p class. This did not cause the test cases to
fail, but the output is a bit confusing, so clean this up be explicitly
closing the control interface monitor sockets and furthermore by
ignoring the "DETACH failed" exception within __del__.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use a helper function to perform this common sequence to disconnect and
stop any possibly started reconnection attempt.
Signed-off-by: Jouni Malinen <j@w1.fi>
The long wait for the monitor socket events resulted in another socket
running out of TX buffer space. Split the wait into smaller segments and
clear the other socket in each iteration.
Signed-off-by: Jouni Malinen <j@w1.fi>
Some of the test cases left behind attached control interface monitor
sockets that could result in hitting the wpa_supplicant socket TX queue
limit. Try to be a bit more careful about detaching and closing the
sockets to avoid this.
Signed-off-by: Jouni Malinen <j@w1.fi>
The wait_event() call for scan completion could have processed a
previously received event from a prior scan instead of the newly started
one. This could result in flush_scan_cache() assuming there are still
results in the cache even though the scan request to clear the cache had
not even be started yet.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
Use more readable "foo not in bar" construction for the couple of places
that did "not foo in bar".
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
There was a race condition on starting the flush_scan_cache() operations
if a scan happened to be in progress when the test case ended since the
ABORT_SCAN success case did not wait for the pending scan operation to
be completed. Wait for the scan completion event in addition to the
disconnection event if the ABORT_SCAN command is accepted.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
