Hi, With reference to this patch: https://lists.infradead.org/pipermail/hostap/2023-July/041655.html The same bug also exists when the disconnect is triggered by e.g. select_network. The patch fixes the case when disconnecting through wpas_request_disconnection. But wpa_supplicant_select_network calls wpa_supplicant_deauthenticate directly, and then call to wpas_abort_ongoing_scan, which the patch adds, is bypassed. With the patch applied, I see the following (initial state: two configured networks, connected to first network): $ iw event & $ wpa_cli scan wlan0 (phy #12): scan started $ wpa_cli disconnect wlan0 (phy #12): scan aborted: ... But with select_network I see this (same initial state): $ iw event & $ wpa_cli scan wlan0 (phy #12): scan started $ wpa_cli select_network 1 # switch to other network $ busctl get-property fi.w1.wpa_supplicant1 /fi/w1/wpa_supplicant1/Interfaces/0 fi.w1.wpa_supplicant1.Interface Scanning b false # -> wpa_supplicant thinks it is no longer scaning. # ... some seconds later wlan0 (phy #12): scan finished: ... # -> the scan was still ongoing. Of course it's possible to also patch select_network, simmilar to request_disconnection. But then there also is the case of the connection failing e.g. because the AP is turned off during a scan. Wouldn't the same error occur then? I believe the root cause is this 'if' in wpa_supplicant_set_state: if (state != WPA_SCANNING) wpa_supplicant_notify_scanning(wpa_s, 0); It causes wpa_supplicant to register that it is no longer scanning when the state changes. This works if wpa_supplicant is disconnected when the scan starts, since then state is changed from WPA_DISCONNECTED to WPA_SCANNING, and back after the scan finishes. But when wpa_supplicant is connected during the scan, state will remain WPA_COMPLETED throughout the scan, and the scanning variable is the only way of seeing that a scan is ongoing. As far as I can see, the scanning variable gets set by wpas_trigger_scan_cb, and cleared by _wpa_supplicant_event_scan_results. But when wpa_supplicant_set_state clears the variable, wpa_supplicant looses track of the fact that a scan is ongoing. I am not very familliar with wpa_supplicant source code, so it's hard for me to say what is expected behavior here, and what fix would be needed, if any. Best regards, Morten Solvang _______________________________________________ Hostap mailing list Hostap@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/hostap
