How to recover from BEACON_TIMEOUT, STA_DISCONNECTED and STA_LOST_IP

[GeorgeFlorian]

OS: Linux Mint 19.1
Board: ESP32 EVB

I have a server that sends data through a POST request to the ESP32. I am using ESPAsyncWebServer to handle it:

  server.on("/post", HTTP_POST, [](AsyncWebServerRequest * request){
      if(request->hasArg("number")){
          String arg = request->arg("number");
          Serial.print("The number is: ");
          Serial.println(arg);
      } else {
          Serial.println("Post did not have a 'number' field.");
      }
      request->send(200);
  });

The issue is that if the server disconnects the ESP hangs, then disconnects from the WiFi and returns the following:

[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:353] _eventCallback(): Reason: 200 - BEACON_TIMEOUT
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 5 - STA_DISCONNECTED
[W][WiFiGeneric.cpp:353] _eventCallback(): Reason: 4 - ASSOC_EXPIRE
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 8 - STA_LOST_IP

and stays like this. I have seen it reconnect only one time.
How can I force the ESP to reconnect to the WiFi ?

[CelliesProjects]

Reconnect does not work properly.
There are work-arounds.

I use something like

WiFi.onEvent( WiFiEvent );
WiFi.begin();
...

void WiFiEvent( WiFiEvent_t event ) {
  switch ( event ) {
    case SYSTEM_EVENT_AP_START:
      ESP_LOGI( TAG, "AP Started");
      //WiFi.softAPsetHostname(AP_SSID);
      break;
    case SYSTEM_EVENT_AP_STOP:
      ESP_LOGI( TAG, "AP Stopped");
      break;
    case SYSTEM_EVENT_STA_START:
      ESP_LOGI( TAG, "STA Started");
      //WiFi.setHostname( DEFAULT_HOSTNAME_PREFIX.c_str( );
      break;
    case SYSTEM_EVENT_STA_CONNECTED:
      ESP_LOGI( TAG, "STA Connected");
      //WiFi.enableIpV6();
      break;
    case SYSTEM_EVENT_AP_STA_GOT_IP6:
      ESP_LOGI( TAG, "STA IPv6: ");
      //ESP_LOGI( TAG, "%s", WiFi.localIPv6().toString());
      break;
    case SYSTEM_EVENT_STA_GOT_IP:
      //ESP_LOGI( TAG, "STA IPv4: ");
      //ESP_LOGI( TAG, "%s", WiFi.localIP());
      break;
    case SYSTEM_EVENT_STA_DISCONNECTED:
      ESP_LOGI( TAG, "STA Disconnected");
      WiFi.begin();
      break;
    case SYSTEM_EVENT_STA_STOP:
      ESP_LOGI( TAG, "STA Stopped");
      break;
    default:
      break;
  }
}

[GeorgeFlorian]

@CelliesProjects What is ESP_LOGI ?

Doesn't this bit do nothing ?

    case SYSTEM_EVENT_STA_STOP:
      ESP_LOGI( TAG, "STA Stopped");

[CelliesProjects]

@CelliesProjects What is ESP_LOGI ?

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/log.html

Control this by setting Tools > Core Debug Level in Arduino IDE.
The advantage over Serial.print() is that if you compile for log level None there will be no logging code added to your binary.
Serial.print statements produce code and bloat your binary.
Afaik not all esp32 boards support setting the loglevel.

Doesn't this bit do nothing ?

It shows connection is lost on serial output. ( if loglevel is set to Info or higher )

[CelliesProjects]

Alernative solution could be something like

if ( !WiFi.isConnected() ) WiFi.begin();

This has to be in a loop somewhere.

[GeorgeFlorian]

So the ESP can't recover from a SYSTEM_EVENT_STA_STOP ?

I think that this if ( !WiFi.isConnected() ) WiFi.begin(); in void loop() can do wonders.

[CelliesProjects]

The first suggestion does its work automagically in the background.
Second one has to be in a loop/task somewhere.
And is not as flexible in certain scenarios.

[me-no-dev]

ESP_LOGI is IDF function. It's not controlled by Arduino. What is controlled is log_i

[simap]

I think automatic reconnects for several causes were broken recently from this change:
#3085

Specifically these causes may be affected:
WIFI_REASON_AUTH_EXPIRE
WIFI_REASON_BEACON_TIMEOUT
WIFI_REASON_NO_AP_FOUND
WIFI_REASON_ASSOC_FAIL
WIFI_REASON_HANDSHAKE_TIMEOUT
WIFI_REASON_CONNECTION_FAIL

The reconnect code now calls this pair (which has changed a lot over the history of the codebase):

WiFi.disconnect();
WiFi.begin();

but in my testing this is an unreliable way to reconnect. The problem is that WiFi.disconnect() does not always immediately clear the STA bit in the WiFi mode, which WiFi.begin() checks, and if it is still set refuses to do anything.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[simap]

@me-no-dev thoughts on this?

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[OmarAlkassab]

I have faced the same problem, any solution?

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[simap]

@me-no-dev thoughts on this? We could use your insight here. The change you accepted seems to have broken basic reconnect functionality when you merged #3085

see comment #3686 (comment)

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[simap]

Is there anything I can do to help further this along or get a maintainer to take a look?

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[simap]

poke

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[Duolabs]

Hallo everyone.
I got stuck in the same point as you all.
After I created and closed 200 sockets the ESP32 Wroom looses the WiFi Connection and gets stuck there.
The log:
[D][WiFiGeneric.cpp:337] _eventCallback(): Event: 5 - STA_DISCONNECTED [W][WiFiGeneric.cpp:353] _eventCallback(): Reason: 200 - BEACON_TIMEOUT abort() was called at PC 0x4015489b on core 0

This happens every around 200-210 sockets connections:
Here is my simple routines which I call all of times:

int TCPClient_Send (const char * Domain, const char * Port, const char * Timeout, const char * Payload, char * TCPResult)
{
	int iResult = -1;
        struct addrinfo     hints;
	hints.ai_family     = AF_INET;
	//hints.ai_socktype   = SOCK_STREAM;
    	hints.ai_socktype   = SOCK_RAW;
    
    	struct addrinfo     *res;
    	struct in_addr      *addr;
    
    	iResult = getaddrinfo(Domain, Port, &hints, &res);
    	if((iResult != 0) || (res == NULL)) {
                        return -1;
        } 
        
        int s = socket(res->ai_family, res->ai_socktype, IP_PROTO_ICMP);
    	if(s < 0) {
      		Serial.println ("TCPClient_Send::TCPCLIENT_SOCKET_CREATION_ERROR");
      		return TCPCLIENT_SOCKET_CREATION_ERROR;
    	}

    	Serial.println ("TCPClient_Send::TCPSocket Created with fd= " + String(s));
          
    	// connect to the specified server
    	iResult = connect(s, res->ai_addr, res->ai_addrlen);
    	if(iResult != 0) {
      		Serial.println ("TCPClient_Send::TCPCLIENT_FAILED_TO_CONNECT");
      		closesocket(s);
      		return TCPCLIENT_FAILED_TO_CONNECT;
    	}

    	Serial.println ("TCPClient_Send::Closing Socket: " + String(s));
    	closesocket(s);
    	return 1;
}

Any help would be highly appreciated

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[simap]

Is there anything I can do to help further this along or get a maintainer to take a look?

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[simap]

[stale]

[STALE_CLR] This issue has been removed from the stale queue. Please ensure activity to keep it openin the future.

[stale]

[STALE_SET] This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.

[stale]

[STALE_DEL] This stale issue has been automatically closed. Thank you for your contributions.

[VojtechBartoska]

Hello @simap and @GeorgeFlorian , sorry for late reply. Are you able to test your issue on development version 2.0.3-RC1 to check if this is still valid? You can take a look on Docs where is explained how to choose development release version in Arduino IDE.

[VojtechBartoska]

Hello,

as there was no answer in more than 14 days, I'm closing the issue as expired to keep our backlog manageable.

If it's still needed, please reopen the issue.

Thanks for understanding.