wpa_supplicant looses track of ongoing scan

Morten Hauke Solvang mhs at emlogic.no
Thu Feb 8 02:36:32 PST 2024


With reference to this patch:

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

More information about the Hostap mailing list