c57c1ed6b3
It was possible for the previous test case to leave unexpected BSS or P2P peer table entries if a scan was in progress when the FLUSH command was used. This could result in test failures, e.g., when running discovery_dev_type_go followed by discovery_group_client where a P2P peer was discovered on another channel at the end of the former test case from a scan that was running durign the FLUSH operation that was supposed to remove all P2P peers. This could result in discovery_group_client failing due to dev[2] trying to send the discoverability frame on incorrect channel (the one learned in the previous test case) since discover_peer() skipped a new device discovery. Fix this by running FLUSH operation again if a pending scan operation is detected during the first FLUSH operation. Signed-hostap: Jouni Malinen <jouni@qca.qualcomm.com> |
||
---|---|---|
.. | ||
hwsim | ||
.gitignore | ||
Makefile | ||
test-aes.c | ||
test-asn1.c | ||
test-base64.c | ||
test-bitfield.c | ||
test-https.c | ||
test-list.c | ||
test-md4.c | ||
test-md5.c | ||
test-milenage.c | ||
test-ms_funcs.c | ||
test-printf.c | ||
test-rc4.c | ||
test-sha1.c | ||
test-sha256.c | ||
test-x509.c | ||
test-x509v3.c | ||
test_x509v3_nist.sh | ||
test_x509v3_nist2.sh |