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.
esp32: Fix AP mode channel configuration.
Summary
- Seems at some point (probably following an ESP-IDF update), the channel setting code added in #8991 stopped working for the AP interface. This is because
esp_wifi_config()is called afteresp_wifi_set_channel(), the old channel gets re-configured and the AP doesn't change channels as expected. - For AP mode, calling
esp_wifi_config()seems to be all that's needed to get desired behaviour. The Wi-Fi stack configures 40MHz bandwidth and selects the secondary channel based on the available channels. - However, the
esp_wifi_set_channel()call is required in the particular case of ESP-NOW being used on the STA interface without an active connection to an AP. Testing suggests this is the only way to configure a particular channel in that case (unlike if the STA is associated to an AP, which means ESP-NOW has to use the same channel as the AP). - Make some docs updates regarding Wi-Fi channels, in particular the role of channels in ESP-NOW (which is pretty restricted, I think this is something that has changed in later ESP-IDF versions).
Closes #16165.
Testing
- Added a multi-test for explicitly configuring the ESP-NOW channel. This test passed on master, and still passes in this PR with the channel fix.
- Added a wlan multi-test for simple STA and AP behaviour. This test fails for esp32 in master as the AP chooses the wrong channel, and passes in this branch. Also tested on esp8266 port and CYW43 (RPI_PICO_W). CYW43 does not currently pass, but I have some fixes to submit separately so that it passes.