Hi all, I see an unexpected behavior of wpa_supplicant 2.9 while attempting to authenticate to access point with PEAP or TLS. If any of intermediate EAP packets is lost (interference, low signal etc.) the supplicant stuck in "receive" action: 1644224864.007560: EAP: EAP entering state SEND_RESPONSE 1644224864.007582: EAP: EAP entering state IDLE 1644224864.007602: EAPOL: SUPP_BE entering state RESPONSE 1644224864.007617: EAPOL: txSuppRsp 1644224864.007633: TX EAPOL: dst=ec:bd:1d:bd:f5:75 1644224864.007766: EAPOL: SUPP_BE entering state RECEIVE 1644224865.988042: EAPOL: startWhen --> 0 I track that condition from a control interface, and try to completely restart the whole connection process by issuing: 1644224869.110300: wlan0: Control interface command 'REASSOCIATE' 1644224869.110479: Fast associate: Old scan results 1644224869.110545: wlan0: Setting scan request: 0.000000 sec 1644224869.110763: wlan0: Starting AP scan for wildcard SSID 1644224869.110918: wlan0: Add radio work 'scan'@0xb63d90 but unfortunately nothing happens then, until a timeout is reached in 30 seconds: 1644224894.248020: EAPOL: authWhile --> 0 1644224894.248558: EAPOL: SUPP_BE entering state TIMEOUT 1644224894.248862: EAPOL: SUPP_PAE entering state CONNECTING Is there any way to attempt the connection from the very beginning, other than restarting the supplicant itself? Why the 'REASSOCIATE' command gets ignored? Regards, Anton Vinokurov anton@xxxxxxxxxx _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
