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>
