zephyr-cp: abandoning a scan leaves current_scan set, so all later scans raise "Already scanning for wifi networks"

[mikeysklar]

common_hal_wifi_radio_start_scanning_networks() sets self->current_scan (Radio.c:245) and only two paths ever clear it:

• common_hal_wifi_radio_stop_scanning_networks() (Radio.c:278)
• the !started && enabled branch of set_enabled() (Radio.c:112)

If iteration over the results is abandoned, for example an exception in the loop body or a break, neither runs. current_scan stays set and every later scan raises:

RuntimeError: Already scanning for wifi networks

from the guard at Radio.c:238.

Observed

A code.py that scanned and hit an exception mid-iteration left the radio in this state. Because code.py runs again on every boot, the state was recreated immediately after each reset, so it looked like the condition survived a commander device reset. It did not survive the reset itself, it was simply re-established. Recovery needed a code.py that does not scan.

Once in this state the board is not usable for scanning at all, and wifi.radio.connect() is unaffected, so it is easy to mistake for a scan-only hardware fault.

Suggested

Clear current_scan when the iterator is exhausted or collected, or make wifi_reset() clear it unconditionally rather than only via the set_enabled() path. A break out of for n in wifi.radio.start_scanning_networks(): is ordinary user code and should not brick scanning until the next power cycle.

Related: #59 (calling stop_scanning_networks() to recover hangs the board).

[mikeysklar]

Fixed on fix/zephyr-scan-clear-current, stacked on the #60 branch since both touch next().

What it took, and one wrong turn worth recording

The obvious place is wifi_reset(). That does not work. wifi_reset() is only reachable through wifi_user_reset():

void wifi_user_reset(void) {
    if (wifi_user_initiated) {
        wifi_reset();
        wifi_user_initiated = false;
    }
}

wifi_user_initiated is false whenever the supervisor brings the radio up rather than user code, which is the case on any board running the web workflow from settings.toml. So a clear placed in wifi_reset() compiles, looks correct, and never executes. Confirmed on hardware: the fix appeared to do nothing.

The clear belongs in wifi_user_reset() outside that check, since main.c:417 calls it unconditionally. Calling wifi_reset() there instead would be wrong: the radio has to stay up across a soft reboot or the web workflow drops.

Cleared in four places, matching raspberrypi: next() on scan end, deinit(), and wifi_user_reset().

Verified on a DK2605A

Run 1 completes a scan, scans again, then abandons a scan with break. Run 2 is a soft reboot.

--- run 1
   B rescan after complete: 65 OK
   C abandoned with break
   D rescan after break: FAIL RuntimeError Already scanning for wifi networks
--- run 2
   B rescan after complete: 63 OK

Run 2 scanning at all is the fix. Before this, run 1's abandoned scan poisoned every later boot, and run 2 raised on its first attempt.

D still failing is expected and is the remaining gap: abandoning the iterator inside one VM session. Fixing that needs a finaliser on the ScannedNetworks object, and that type lives in shared-bindings, so adding __del__ changes the Python API for every port. That is a design decision rather than a bug fix, and espressif has the same gap, so it is worth deciding once for all ports.

Cost

10 lines, no new state. Flash on nordic_nrf7002dk goes from 966612 to 966644 bytes of a 944 KB region, leaving 12 bytes free. That board is effectively full and needs its own issue.

[mikeysklar]

Confirmed independently on a second board, 440353787 on a different host (Linux, Simplicity Commander for Linux).

Three consecutive runs of the same code.py, which completes a scan, scans again, then abandons a scan with break. Soft reboot between runs:

D rescan after break: FAIL RuntimeError Already scanning for wifi networks
soft reboot
A complete scan: 68
B rescan after complete: 57 OK
C abandoned with break
D rescan after break: FAIL RuntimeError Already scanning for wifi networks
soft reboot
A complete scan: 64
B rescan after complete: 68 OK
C abandoned with break
D rescan after break: FAIL RuntimeError Already scanning for wifi networks

Every run recovers from the previous run's abandoned scan. Before this change the first break poisoned every later boot, and A raised immediately.

D failing is the known remaining gap: abandoning the iterator within one VM session still needs a finaliser on ScannedNetworks, which is a shared-bindings type, so it changes the Python API for every port. espressif has the same gap.

[mikeysklar]

Status update. This was going to be filed upstream after the scan wait fix, but that PR (adafruit#11214) is now closed as declined, so the ordering dependency is gone and this can stand on its own.

Confirmed on hardware while testing something else. On a SiWx917-DK2605A, interrupting a scan leaves current_scan set, and every later scan then raises:

RuntimeError: Already scanning for wifi networks

A soft reboot does not clear it. It also survives a completed scan that was not followed by stop_scanning_networks(), which is the "B rescan after complete" case in the test script on the board.

The fix branch is fix/zephyr-scan-clear-current, which clears current_scan in wifi_user_reset() outside the wifi_user_initiated guard. Worth noting for whoever picks this up: the earlier version of that fix never executed, because the only path to it was behind that guard, which is false when the supervisor owns the radio.

[mikeysklar]

Re-verified against upstream main at 069144c. Still two clear paths only, Radio.c:103 and Radio.c:261. Abandoning iteration still leaves current_scan set.

Note this is now easier to hit, not harder: with adafruit#11223 scans actually return results, so ordinary code that breaks out of the loop early is a realistic path into this state.