Some of the error paths in go_neg_pbc() and go_neg_pin() did not wait
for the helper thread to complete processing. This could result in
unexpected behavior when the test case could have exited while the
thread was still performing tasks for the GO Negotiation. This could
result in getting stuck in one of the following test cases with
"go_neg_init_pbc thread caught an exception from p2p_go_neg_init: Group
formation timed out" showing up in the log.
This was hit, e.g., with the following test sequence:
no_go_freq p2p_channel_drv_pref_autogo
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>
This test case was failing pretty frequently due to an issue in being
able to send out the Provision Discovery Response frame on the operating
channel. Now that wpa_supplicant has a fix for that issue, modify this
test case to hit this error condition every time. In addition, make sure
the possible exception from p2ps_exact_seek() does not get hidden with a
failing remove_group() call in the finally section.
Signed-off-by: Jouni Malinen <j@w1.fi>
This patch is made by using 2to3 command with some modifications.
$ find . -name *.py | xargs 2to3 -f imports -w -n
Signed-off-by: Masashi Honma <masashi.honma@gmail.com>
This test case verifies that wpa_supplicant is able to perform CSA to a
VHT80 channel when having to move the GO due to an avoid-frequencies
driver event.
Signed-off-by: Jouni Malinen <jouni@codeaurora.org>
The new persistent_group_peer_dropped3 test case is similar to
persistent_group_peer_dropped with the difference being in the
responding device (the one from which the persistent group information
is dropped) is not issued a separate P2P_LISTEN command and instead, a
single P2P_FIND is used through the exchange to verify that this
operation does not get stopped unexpectedly. This is a regression test
case to verify that P2P_PENDING_INVITATION_RESPONSE case ends up calling
p2p_check_after_scan_tx_continuation() in non-success case. It should be
noted that this is dependent on timing: Action frame TX request needs to
occur during the P2P_FIND Search phase (scan). As such, not every
execution of this test case will hit the previous issue sequence, but
that should be hit every now and then.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
This speeds up and clarifies error reporting for cases where the GO
fails to start in invitation.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
Verify that P2P_CANCEL gets rejected on fully re-invoked persistent
group. This did not work properly before the last couple of commits and
before this week, the P2P_CANCEL on a separate group interface in P2p
Client role could result in use of freed memory and process termination.
Signed-off-by: Jouni Malinen <jouni@qca.qualcomm.com>
