Resolve #3967: set connected false once disconnected

[mitchins]

Have tested this and it appears to behave as expected, am not sure if there is historical reason why connected was never set to false, however after:

1. creating and connecting to a hotspot
2. disabling hotspot for 3-5 seconds (such that it tries to reconnect and spews logs)
3. re-enable hotspot

I can confirm the device reconnects with a proper ifconfig (which was 0.0.0.0 during the hotspot downtime). Can also confirm during step 2, that the status is connecting (1001).

@dpgeorge issue was created for discussion, however this seems to retain the auto-reconnect while providing a status() that returns STAT_CONNECTING while it is reconnecting instead of STAT_GOT_IP.

wifi_reconnect_fix_log.log

logs attached

[peterhinch]

You might want to test under conditions of gradually reducing signal strength - walk away with the device until connectivity is lost, then walk it back towards the AP. This can produce different results compared to switching the AP off and back on.

[peterhinch]

Also see this issue.

[mitchins]

Interesting. I can do further checking, however with first “beacon timeout” and then “NO AP” it follows the steps to keep retrying - it’s just until it connects the status now says “connecting” rather than “connected”.

From the linked issue it seems like you’re connecting first time, which works fine.

Without this fix, the status will be stuck as STAT_GOT_IP because the modnetwork.c flag for connected will never be false. At least now it says STAT_CONNECTING, and when the AP is reconnected to automatically there is definitely another event from ESP-IDF which boots the status flag back to connected.

From a user point of view querying the interface if the AP becomes unavailable I’ll get the status as connected even though Ifconfig returns “0.0.0.0”.

Does this make sense?

[peterhinch]

Yes, it makes sense and I think what you're doing is important: we need a truly reliable way of determining connected - connecting - disconnected status.

In testing I did find differences in the behaviour of ESP32 between switching the AP off and on compared with gradually reducing the signal strength as described above. There are other ways in which connectivity can be lost such as sporadic RF interference but these are hard to test. The best I could manage was to run the ESP32 for long periods near to the limit of radio range.

In my resilient asynchronous MQTT client I failed to achieve resilient operation on ESP32 partly because (to quote from my README):

In particular the ESP32 does not recover from WiFi outages.

Incidentally a way to do these tests is to power the device from one of those USB batteries intended for recharging smartphones.

[mitchins]

I’m actually looking at using the MQTT client, right now I’m using the simple client.

Currently I am working on a wifi manager which reads in a network file and that can run on the cooperative event loop to detect the changes in state every so often. This becomes more important if you travel with the ESP32 or need to maintain different config, or in my case use a roaming profile now that BSSID can be specified.

Where the whole thing fell over was with detecting that the wifi disconnected, the STA_IF would always report it was connected as mentioned above.

From an “OS” later that’s all it should really do, just try to reconnect.
Any more complicated behaviour should be in the application layer so that’s what I’m working on, if the status changes from connected it will switch to the first preferred network in the scan().

[tlvlp]

Hi, is there any update on this? I just ran into the same problem using the latest MicroPython build.
The network.WLAN(network.STA_IF) automatically loops to reconnect but isconnected() keeps returning True, so my other asynchronous tasks cannot react properly to the outage and I also have no way of catching when the wifi finally reconnects.

Or is there another approach/library/MP variant everyone is using these days for ESP32 that solves these problems?

[mitchins]

Hi, is there any update on this? I just ran into the same problem using the latest MicroPython build.
The network.WLAN(network.STA_IF) automatically loops to reconnect but isconnected() keeps returning True, so my other asynchronous tasks cannot react properly to the outage and I also have no way of catching when the wifi finally reconnects.

Or is there another approach/library/MP variant everyone is using these days for ESP32 that solves these problems?

No updates, I was waiting for this to be merged but no answer. I'll have to rebase it now. @dpgeorge might shed some light. If there's an opportunity for this to go in I will take another look.

Long story short, I end up using the IP_ADDRESS != '0.0.0.0' - not ideal but gives the intended results assuming DHCP is working.

[dpgeorge]

Sorry @mitchins , this got lost.

I very recently merged #4538 in 21f9329 which is almost the same as this PR, but that one also removed the reconnected variable.

@tlvlp did you try the very latest build? Can you explain exactly how to reproduce the error that you see?

[tlvlp]

@mitchins thanks a lot! :)

@tlvlp did you try the very latest build? Can you explain exactly how to reproduce the error that you see?

@dpgeorge Ha! It seems that the build I've been using was from late from Feb. and indeed isconnected() returns a proper value with the latest build. Thank you! :)

[dpgeorge]

Ok, thanks @tlvlp for the confirmation that master works.

I'll close this then because it really is the same as #4538 (and sorry again for letting this get lost and preempted).

[mitchins]

Thanks, I'm glad it's resolved.