esp_wifi_internal_reg_rxcb ret=0x3014
micropython: ESP-IDF v3.x GENERICv1.12
Can't Connect WiFi,REPL:
E (1999968) event: system_event_sta_disconnected_handle_default 294 esp_wifi_internal_reg_rxcb ret=0x3014
E (1999968) wifi: esp_wifi_connect 1134 wifi not start
ESP32 STA_IF reconnect loop
In a nutshell
If the ESP32 is connected to a network (such as a regular network or even a hotspot), and let's say the hotspot gets turned off or goes away... the logic in modnetwork.c will try to reconnect, which is not incorrect but there's the problem...
It will continue to try and reconnect forever, and at any point if you query the status it will be STAT_GOT_IP, I have narrowed it down to being wifi_sta_connected boolean in the event handler.
For WIFI_REASON_BEACON_TIMEOUT and WIFI_REASON_NO_AP_FOUND:
it will reconnect... which is ok, but watch:
esp_err_t e = esp_wifi_connect();
if (e != ESP_OK) {
ESP_LOGI("wifi", "error attempting to reconnect: 0x%04x", e);
} else {
reconnected = true;
}
and finally:
if (wifi_sta_connected && !reconnected) {
// If already connected and we fail to reconnect
wifi_sta_connected = false;
}
Since esp_err_t e = esp_wifi_connect(); would obviously be an async process, I think we're getting the success of dispatching the connect request. wifi_sta_connected = false never gets executed since for an AP that has gone away it'll just keep asking to reconnect, which is not incorrect... but neither do we get an accurate status. ifconfig() does however return MORE useful information.
It is good to reconnect, although the AP may be gone... perhaps the status should be set to connecting? To this end I propose that we could set the status to connecting, and it may still do its reconnect attempt, but the status would be more use.
I will need to rebuild and test if setting the status to connecting for reconnected == true, my hypothesis is that the true status will be known via another event handler.