Modified bootWiFi2 method to call m_wifi.connectAP forever or until it successfully connects #475
Conversation
…t successfully connects
There was a problem hiding this comment.
What if the user changes their password on their access point? This would lock up the application forever as it attempts to connect forever. Wouldn't we want to force a failure that the programmer can then handle in a distinct manner. If we just loop, we will get an issue that says "When I call Bootwifi, it just hangs".
|
Apologies. I didn't do an optimal job of explaining the reason in my original pull request. I've updated it to better explain the situation. BTW, the original pull request read: "Prior to this change, BootWiFi would sometime return before the ESP32 had successfully connected (specifically when a staDisconnected event was received)." Let me talk through my thinking. What got me on to this is that I had a small project running for a couple weeks. I found I needed to reboot it relatively frequently and sometimes had to reboot it multiple times before it finally worked again. It got me thinking that from an end-users viewpoint, they would see this behavior as being quite unreliable. After some light debugging, I've identified 2 causes (so far):
In my mind, trying to connect once, getting a Can we do better still - to your points about:
A few items:
|
|
@Brisdo, have you included the fix for issue #421 in your code? I find that it reliably connects if the configured AP can be found. My own (modified) BootWiFi switches to AP mode when the ESP32 fails connect to the configured AP. Once an IP address is obtained from the AP, it will keep trying to reconnect indefinitely if the connection is lost for some reason. I can imagine one could have the software perform a limited number of retries while connecting to the configured AP, and only then switch to AP mode. |
|
@HanVertegaal - yes, I pulled the latest yesterday which includes issue #421. The problem is in WiFi.cpp in two places:
Although So, bottom line is that if |
|
Having seen the I decided not to go that route because:
|
|
The Wifi docs, say there's a number of things that can cause a SYSTEM_EVENT_STA_DISCONNECTED event so it alone does not tell you that the password is bad. But, 4. Wi-Fi Connect Phase section says "In a case like this, <SYSTEM_EVENT_STA_DISCONNECTED> will arise and the reason for such a failure will be provided." |
|
In WiFi::eventHandler tried printing out the event->event_info.disconnected.reason. With the correct password, when reproducing the problem and the SYSTEM_EVENT_STA_DISCONNECTED event occurred and the reason code was: 2 = WIFI_REASON_AUTH_EXPIRE. Changed the password to garbage - which also caused SYSTEM_EVENT_STA_DISCONNECTED events, but this time with reason code: 201 WIFI_REASON_NO_AP_FOUND. So, another option would be for WiFi::connectAP to return a reason code rather than simply true or false. That way the programmer can then handle in a distinct manner. BootWiFi would also need to be changed to handle the reason code by either:
Thoughts? |
|
Returning the reason sounds like a good idea. The programmer can then make an informed decision on whether to retry or switch to AP mode. |
…ceives a SYSTEM_EVENT_STA_GOT_IP event. Otherwise returns wifi_err_reason_t
…ceives a SYSTEM_EVENT_STA_GOT_IP event. Otherwise returns wifi_err_reason_t
Additional to PR #475. Addresses BootWiFi::boot hanging
Prior to this change,
bootWiFi2would sometimes return before the ESP32 had successfully connected to WiFi - specifically when astaDisconnectedevent was received.This causes
BootWiFi::boot()to hang, waiting indefinitely onm_completeSemaphore.wait("boot");. This happens because the only place the semaphore is resolved is in thestaGotIpevent handler. Unfortunately, thestaGotIpevent never occurs because bootWiFi2 has returned and so there are no retry attempts.This change ensures that ESP32 has successfully connected before BootWiFi returns (or keeps trying forever).