WiFi.status shows connected when connection is lost

[adrian-dybwad]

WiFi.status() returns WL_CONNECTED after connection is lost when using WiFi.setAutoReconnect( false );

The included MCVE produces the following output:

SDK:3.0.0-dev(c0f7b44)/Core:2.5.0=20500000/lwIP:STABLE-2_1_2_RELEASE/glue:1.1/BearSSL:6778687

mode : sta(a0:20:a6:0a:a6:96) + softAP(a2:20:a6:0a:a6:96)
add if0
Looking for WiFi ....wlstatus:WL_IDLE_STATUS=0
WiFi.localIP():(IP unset)
.scandone
scandone
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 1
cnt 

connected with TEST, channel 3
dhcp client start...
ip:192.168.43.39,mask:255.255.255.0,gw:192.168.43.45
 connected to TEST
wlstatus:WL_CONNECTED=3
WiFi.localIP():192.168.43.39
wlstatus:WL_CONNECTED=3
WiFi.localIP():192.168.43.39
state: 5 -> 2 (3a0)
rm 0
wlstatus:WL_CONNECTED=3
WiFi.localIP():(IP unset)
wlstatus:WL_CONNECTED=3
WiFi.localIP():(IP unset)
wlstatus:WL_CONNECTED=3
WiFi.localIP():(IP unset)
wlstatus:WL_CONNECTED=3
WiFi.localIP():(IP unset)
wlstatus:WL_CONNECTED=3

The AP was turned off shortly after the connection was established and you will notice the logs show loss of IP but status() returns WL_CONNECTED. This only happens when using WiFi.setAutoReconnect( false )

#include <ESP8266WiFi.h>
#include <ESP8266WiFiMulti.h>

ESP8266WiFiMulti wifiMulti;
boolean connectioWasAlive = true;
const char* statuses[] =  { "WL_IDLE_STATUS=0", "WL_NO_SSID_AVAIL=1", "WL_SCAN_COMPLETED=2", "WL_CONNECTED=3", "WL_CONNECT_FAILED=4", "WL_CONNECTION_LOST=5", "WL_DISCONNECTED=6"};

void setup()
{
  Serial.begin(115200);
  Serial.println();

  WiFi.setAutoReconnect( false );

  wifiMulti.addAP("TEST", "12345678");
}

unsigned long timestamp = millis();
void monitorWiFi()
{
  if (millis() - timestamp > 2000) {
    timestamp = millis();
    Serial.print("wlstatus:");
    Serial.println(statuses[WiFi.status()]);
    Serial.print("WiFi.localIP():");
    Serial.println(WiFi.localIP().toString());
  }
  if (wifiMulti.run() != WL_CONNECTED)
  {
    if (connectioWasAlive == true)
    {
      connectioWasAlive = false;
      Serial.print("Looking for WiFi ");
    }
    Serial.print(".");
    delay(500);
  }
  else if (connectioWasAlive == false)
  {
    connectioWasAlive = true;
    Serial.printf(" connected to %s\n", WiFi.SSID().c_str());
  }
}

void loop()
{
  monitorWiFi();
}

[adrian-dybwad]

As a workaround, using the WiFiEventStationModeDisconnected event (which does fire), performing a disconnect (even though the connection is already disconnected) fixes the WiFi.status() problem.

void onStationModeDisconnectedEvent(const WiFiEventStationModeDisconnected& evt) {
  if (WiFi.status() == WL_CONNECTED) {
    WiFi.disconnect();
  } else {
    Serial.println("         WiFi disconnected...");
  }
}

[d-a-v]

That's a nice workaround for core release 2.5.0.
This bug has disappeared in git master version (soon to be release-2.5.1).
It also not reproducible with fw 2.2.x (SDK:2.2.2-dev(c0eb301)) available for testing with the generic esp8266 board.

edit: If a release is needed, version 2.4.2 hasn't this bug (it uses fw 2.2.1).

[TD-er]

Could this also be a nice work-around for core 2.4.x issues?

[d-a-v]

@TD-er core-2.4.2 uses fw 2.2.1, same as with current master (by default).
I tried yesterday, when I rebooted my AP the connection was showed as lost.
Do you have a different behaviour ?

[TD-er]

Well I have not tried this code myself.
But I have noticed a few times (even running core 2.4.0 a while ago) that the reported wifi status is not always reflecting the true status.

So I was hoping this would be some help also, since I have really no clue how to truly detect the connection status.
It is not always happening, but it may happen that there is no connection and the wifi status still reports it is connected.
This then often leads to something waiting for data that will never arrive or starting to initiate a connection. Both end up in a hardware watchdog reset.
I use timeouts where possible, but still see a lot of HW watchdogs happen.

[adrian-dybwad]

Well I have not tried this code myself.
But I have noticed a few times (even running core 2.4.0 a while ago) that the reported wifi status is not always reflecting the true status.

So I was hoping this would be some help also, since I have really no clue how to truly detect the connection status.
It is not always happening, but it may happen that there is no connection and the wifi status still reports it is connected.
This then often leads to something waiting for data that will never arrive or starting to initiate a connection. Both end up in a hardware watchdog reset.
I use timeouts where possible, but still see a lot of HW watchdogs happen.

I would be hesitant to implement a change as you did in your commit. It is a patch that does not solve the root cause. In my experience, WDT reset are caused by other types of problems. One of the most useful things is the ESP.getHeapFragmentation() recently introduced. It shows the state of memory better than just looking at the available memory from ESP.getFreeHeap(). You may have fragmentation problems. Also, if you are using char arrays, look out for overflows. Those will cause a lot of WDT resets.

[TD-er]

In the builds with core 2.6.0 I do have the heap fragmentation shown in the sysinfo page and also have been running some tests to see if the fragmentation was an issue.
But these WDT resets do still happen, also on test nodes that hardly do any intensive String manipulation or other stuff regarding memory allocation. (not big parts at least)
These show a very strong correlation with wifi reception quality and the WDT resets happen more often when a node is performing more network IO (thus more chance of running into these issues).

I know it isn't going to solve the root cause of these WDT resets, but it has already taken 100's of hours for me to get some grip on these WDT resets that I really want to try anything.
I was not sure yet if I was going to merge that commit into the main branch. For now that PR has been built and is running on a few nodes as a test.
These WDT resets are bugging me since I think August last year and some of them were definitely related to some bugs in our code or simply running out of resources. So that's just a number of possible reasons for crash reports, but the ones that now still occur do have a very strong correlation with wifi stability, power management, active pings to the node and those kind of things.

I will now have a good look at parts that handle strings to see if there's something that may use char arrays since calling .length() or something like that may indeed take much longer than expected.

Also the inaccuracy of the wifi connected status is also bugging me in other ways.
When trying to send something, I do perform checks on the connection state. So if this state is incorrect, it will cause significant delays in code execution of other parts, which will cause communication to sensors to be out of sync in need of re-init etc.
That's happening on a node I have in my car (offline logging data), running ESP82xx Core 2.6.0-dev, NONOS SDK 2.2.2-dev(c0eb301), LWIP: 2.1.2 PUYA support
Build Time: Mar 20 2019 23:30:57

That SDK should not have this specific issue, right?

[d-a-v]

That SDK should not have this specific issue, right?

I guess not (sdk 2.2.2-dev has not been extensively used though)

[neu-rah]

I'm using 2.5.0 and WiFiEventStationModeDisconnected is not firing unless I do some network activity, webserver sits behind a lost connection waiting for requests, WIFI state 3

the moment esp8266 does a network request, as getting NTP time, then the event fires...

as a check, I keep pinging the router and bang, the event fires as soon as the router drops the connection. However, the ping is too intrusive and generates too much instability especially if using the AP mode.

please advise.

I'm using this kind of ping to maintain net activity, it works as a test and might shed some light on the problem origin...
Is there a better way of having wifi events firing properly for web servers, because unlike sensors we don't do network unless requested.

extern "C" {
  #include <ping.h>
}

void tick_back(void *opt, void *resp) {
  constexpr int ticks_tolerance=3;//how many fails in a row will we tolerate (or something like that)
  static volatile int ticks_ok=0;
  ping_resp* ping_resp = reinterpret_cast<struct ping_resp*>(resp);
  if (ticks_ok>0&&ping_resp->ping_err==-1) ticks_ok--;
  else if (ticks_ok<ticks_tolerance) ticks_ok++;
  wifiConnected&=ticks_ok>0;//update my own state
}

//network tick, not using delay stuff and sending only one packet
void nw_tick(IPAddress dest) {
  static ping_option tick_options;
  memset(&tick_options, 0, sizeof(struct ping_option));
  tick_options.count = 1;
  tick_options.coarse_time = 0;
  tick_options.ip = dest;
  tick_options.sent_function = NULL;
  tick_options.recv_function = reinterpret_cast<ping_recv_function>(&tick_back);
  ping_start(&tick_options);
}

[d-a-v]

@neu-rah See above

[neu-rah]

@d-a-v yes I saw it, but I'm already using the wifi events. Changed to the latest core version:
using platformio, plaktformio.ini set to:
platform = https://github.com/platformio/platform-espressif8266.git (guess it makes it the latest)

and the problem persists, I'm recovering ok from a lost connection as soon as I get WiFiEventStationModeDisconnected, my problem is that it only fires when I do a network request (ping or NTP) until then the connection is on state 3 and no report of connection lost (event not firing).

my esp8266 is primarily a web server and it does not send network requests (unless set manually to do so)...

thanks for your reply 👍 I'm open to any suggestions

[neu-rah]

this ping thing is working for me, instability was due to a bug, I was requesting (and debug printing) it free-wheel on loop, now that I set up a proper 500ms the esp8266 seems stable and I get the events firing as soon as the connection is lost.

still I'm missing a WL_CONNECTING state on WiFi.status(), well i can keep my own track on that of course, but it would be nice.

a view ofesp8266/arduino code gave me no clue on how to solve this, so i guess it is even deeper.

hope it helps

[TD-er]

@neu-rah Just to be sure, you use that internal ping trick at a 500 msec interval?
And what do you usually ping? The gateway?

[neu-rah]

@TD-er yes, I'm pinging the gateway. Not sure what you mean by "internal", I'm using the pasted code to ping the gateway and yes 500ms, experimented with other values, but this one seems enough and esp8266 seems stable.