wpa_supplicant looses track of ongoing scan

[Morten Hauke Solvang]

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