Access point interface active without being noticed
After flashing my ESP modules with the current version of MicroPython i use to transfer the modules and scripts I need to run on them using the glorious mpfshell. Of course various bigger modules need to be brought onto the ESP as precompiled bytecode. So there is the common workflow of deploying my script and all of its dependencies.
The programs i run on the ESP are all connecting to my wireless network and do communicate with my home servers. Therefore they are set up as wireless stations (clients).
What I just noticed is that my ESP modules are still acting as an access point. They got introduced to start this when they were initially booting their first MicroPython code.Then the inisetup.py does configure a access point with the name "MicroPython-%s" % ubinascii.hexlify(ap_if.config("mac")[-3:]). This is only because the access point interface has written it's state to the flash of the ESP module.
I have never cared about it and not even thought about that it might happen. All just because the initial state written by the inisetup.py was persisted into the flash of the ESP and so the acces point interface always gets initialized when the ESP module does start up. Just because I did never actively deactivate it.
You might say "Know your tools!" or "ESPs did this even before MicroPython!". But I bet that this does happen to a lot of people unnoticed and should be reviewed.
extmod/network_cyw43: Allow configuring active AP interface.
Summary
Configuring the AP for cyw43 writes to some buffers that are only sent to the modem when the interface is brought up. This means you can't configure the AP after calling active(True), the new settings seem to be accepted but the radio doesn't change.
This is different to the documented WLAN behaviour which says to call active(True) before configuring the interface. The esp8266 and esp32 ports require this, even. EDIT: only esp8266 requires this, esp32 works in either order
Fix this by bouncing the AP interface after a config change, if it's active. Configuring with active(False) still works the same as before.
Adds a static variable to track interface active state, rather than relying on the LWIP interface state. This is because the interface state is updated by a driver callback and there's a race: if code calls active(True) and then config(a=b) then the driver doesn't know it's active yet and the changes aren't correctly applied.
Closes #14224
This work was funded through GitHub Sponsors.
Testing
This is one of two fixes which are required for RPI_PICO_W board to pass the wlan test added in #16225.
Trade-Offs and Alternatives
It is possible this pattern will cause the AP to come up briefly with the default "PICOabcd" SSID before being reconfigured, however (due to the aforementioned race condition) it seems like this may not happen at all before the new config is applied. However, if that was a concern then we could hold off bringing the AP interface up until after it's configured. Doing it that way would be a potential breaking change, though.