WiFi connection SOMETIMES fails after Config Portal with Status "WL_IDLE_STATUS"

black-snake commented 2 years ago

First of all, thanks for the great library! Amazing what you have done.

Describe the bug

So far, I sometimes experienced that when I connect to the config portal and click "SAVE", I won't the the success page afterwards telling me that it's trying to connect to the WiFi configured in the portal. Instead, the connection to the AP closes (abruptly?). This behavior was observed on an Apple iOS device as well as an Linux PC (Fedora 35).

The WiFi status is (after timeout): WL_IDLE_STATUS (no matter if the timeout is 30s or 3m)

excerpt from the log (full log further down):

[WM] WiFi save
[WM] Parameter and value : sensor.type 22
[WM] Parameter and value : sensor.temperatureUnit 1
[WM] Parameter and value : sensor.measurementIntervalInSeconds 30
[WM] Parameter and value : mqtt.host 192.168.255.252
[WM] Parameter and value : mqtt.port 1883
[WM] Parameter and value : mqtt.clientId Client1
[WM] Parameter and value : mqtt.topic Topic1
[WM] Parameter and value : mqtt.username 
[WM] Parameter and value : mqtt.password 
[WM] New Static IP = (IP unset)
[WM] New Static Gateway = 192.168.2.1
[WM] New Static Netmask = 255.255.255.0
[WM] Sent wifi save page
[WM] Waiting WiFi connection with time out
[WM] Connection timed out
[WM] Timed out connection result: WL_IDLE_STATUS
[WM] freeing allocated params!

However, this behavior cannot be reproduced reliably.

Whenever the success page of the config portal is shown (which is the case most of the time), the WiFi connections works as expected.

Steps to Reproduce

example

#include <Arduino.h>

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

#define USE_AVAILABLE_PAGES false
#define USE_ESP_WIFIMANAGER_NTP false
#define _ESPASYNC_WIFIMGR_LOGLEVEL_ 4

#include <ESPAsync_WiFiManager.hpp>
#include <ESPAsync_WiFiManager.h>

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

  while (!Serial)
  {
    delay(250);
  }

  AsyncWebServer webServer(80);
  DNSServer dnsServer;
  ESPAsync_WiFiManager ESPAsync_wifiManager(&webServer, &dnsServer, "HOST");

  ESPAsync_wifiManager.setDebugOutput(true);
  ESPAsync_wifiManager.setConfigPortalTimeout(900);
  ESPAsync_wifiManager.setConnectTimeout(30);
  ESPAsync_wifiManager.setConfigPortalChannel(0); // 0 = random

  // sensor
  ESPAsync_WMParameter type("sensor.type", "Sensor Type", "22", 2);
  ESPAsync_wifiManager.addParameter(&type);
  ESPAsync_WMParameter temperatureUnit("sensor.temperatureUnit", "Temperature Unit", "1", 1);
  ESPAsync_wifiManager.addParameter(&temperatureUnit);
  ESPAsync_WMParameter measurementIntervalInSeconds("sensor.measurementIntervalInSeconds", "Measurement Interval (s)", "30", 5);
  ESPAsync_wifiManager.addParameter(&measurementIntervalInSeconds);

  // MQTT
  ESPAsync_WMParameter host("mqtt.host", "MQTT Host", "", 128);
  ESPAsync_wifiManager.addParameter(&host);
  ESPAsync_WMParameter port("mqtt.port", "MQTT Port", "1883", 5);
  ESPAsync_wifiManager.addParameter(&port);
  ESPAsync_WMParameter clientId("mqtt.clientId", "MQTT Client ID", "", 64);
  ESPAsync_wifiManager.addParameter(&clientId);
  ESPAsync_WMParameter topic("mqtt.topic", "MQTT Topic", "", 128);
  ESPAsync_wifiManager.addParameter(&topic);
  ESPAsync_WMParameter username("mqtt.username", "MQTT Username", "", 32);
  ESPAsync_wifiManager.addParameter(&username);
  ESPAsync_WMParameter password("mqtt.password", "MQTT Password", "", 16);
  ESPAsync_wifiManager.addParameter(&password);

  ESPAsync_wifiManager.startConfigPortal("AP");
}

void loop()
{
  delay(500);
}

Expected behavior

The config portal should finish with the success page and WiFi connection should work.

Actual behavior

The success page of the config portal is not shown and the WiFi status is (after timeout): WL_IDLE_STATUS (no matter if the timeout is 30s or 3m)

From what I see, it COULD be that this problem occurs (more often) the longer the AP runs (10m gave frequent fails). SEEMS as if the request is not properly finished after the click on "SAVE" in the config portal or there is some kind of race condition? Of course, I cannot rule out that it's a memory issue on my side (or anything else).

Debug and AT-command log (if applicable)

[WM] AP IP address = 192.168.4.1
[WM] HTTP server started
[WM] startConfigPortal : Enter loop
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] DUP AP: W-LAN
[WM] DUP AP: W-LAN_Guest
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] DUP AP: W-LAN
[WM] DUP AP: W-LAN_Guest
[WM] DUP AP: Vodafone Homespot
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] DUP AP: W-LAN_Guest
[WM] DUP AP: W-LAN
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] DUP AP: W-LAN
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] DUP AP: W-LAN
[WM] DUP AP: W-LAN_Guest
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Handle WiFi
[WM] handleWifi: Scan done
[WM] Static IP = (IP unset)
[WM] Sent config page
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] Request redirected to captive portal
[WM] Location http:// 192.168.4.1
[WM] Handle root
[WM] request host IP = 192.168.4.1
[WM] startConfigPortal: About to modal scan
[WM] About to scan
[WM] Start scan
[WM] Scan done
[WM] WiFi save
[WM] Parameter and value : sensor.type 22
[WM] Parameter and value : sensor.temperatureUnit 1
[WM] Parameter and value : sensor.measurementIntervalInSeconds 30
[WM] Parameter and value : mqtt.host 192.168.255.252
[WM] Parameter and value : mqtt.port 1883
[WM] Parameter and value : mqtt.clientId Client1
[WM] Parameter and value : mqtt.topic Topic1
[WM] Parameter and value : mqtt.username 
[WM] Parameter and value : mqtt.password 
[WM] New Static IP = (IP unset)
[WM] New Static Gateway = 192.168.2.1
[WM] New Static Netmask = 255.255.255.0
[WM] Sent wifi save page
[WM] Waiting WiFi connection with time out
[WM] Connection timed out
[WM] Timed out connection result: WL_IDLE_STATUS
[WM] freeing allocated params!

Screenshots

N/A

Information

Platform.io version 5.2.4 (Core), 3.4.0 (Home)
ESP8266 core v3.0.2
ESPAsync_WiFiManager v1.11.0

Additional context

none

khoih-prog commented 2 years ago

However, this behavior cannot be reproduced reliably.

Whenever the success page of the config portal is shown (which is the case most of the time), the WiFi connections works as expected.

I'm sorry I couldn't duplicate this unreliable issue. I suggest you change the board / power supply, using Arduino IDE instead of PIO, using different CP accessing devices (Windows, Ubuntu, Mac, etc.), reduce RF channel interference, etc. to isolate the culprit.

I have to close the issue and won't reopen until the library's bug is proven.

Good Luck,

black-snake commented 2 years ago

I understand, too bad.

Here are my observations I found meanwhile:

I can reliably reproduce the issue when I wait 10 minutes.
In my original sketch I implemented an immediate restart (ESP.restart();) when the WiFi status is not WL_CONNECTED and the connection is instantaneously established. So, I hardly believe it's an RF issue.
As I said, I used different clients accessing the CP: Apple iOS (iPhone and iPad) as well as a Linux Fedora 35.
I used a different power supply, yet no other ESP8266 board because I don't have another one. However, I could not reproduce the issue with an ESP32 board (but they also use different base libraries for WiFi etc., so could be an ESP8266-specific issue?)
I couldn't try it with Arduino IDE because it fails to download the required dependencies for this library (tells something about protocol error?).

That's what I did to isolate the culprit.

khoih-prog / ESPAsync_WiFiManager