startConfigPortal()'s connectWiFi() method is broken

tekhedd commented 6 years ago

Hardware

WiFimanager Branch/Release:

[ ] Master
[ X] Development

Esp8266/Esp32:

[X ] ESP8266
[ ] ESP32

Hardware: ESP-12e, esp01, esp25

[ ] ESP01
[ X] ESP12 E/F/S (nodemcu, wemos, feather)
[ ] Other

ESP Core Version: 2.4.0, staging

[ ] 2.3.0
[X ] 2.4.0 (2.4.2?)
[ ] staging (master/dev)

Description

Run from start(), startConfigPortal() always fails in the connectWifi() phase with 0. If you run startConfigPortal() from loop(), the connectWiFi() phase will always bail out with "already connected". At no point does it actually confirm that wifi is connected.

It fails when running from start, i think, because wifi is not connected, and the "is connected" logic at the top of startConfigPortal() (which appears to be backward), puts the esp into AP mode to force a disconnect. (Which is necessary for many reasons, if we were connected!) Later, connectWiFi() fails because it can not connect as a client in AP mode, and the code never put the esp back into STA_AP mode!

When running from loop, even if I completely fail to initialize the wifi in any way, isConnected() returns true. In this case, the esp is put into STA_AP mode. Then connectWifi() always enters the "Already connected. Bailing out." phase. Possibly STA mode with a connected client is considered to be a status of WL_CONNECTED, so again the STA mode ssid/pass is not checked.

A handy workaround is to set a very short connectTimeout, set breakAfterConfig to true, and do your own wifi connection status checking after startConfigPortal() exits.

In summary:

I am not sure it is possible to synchronously check the connection state without first switching to STA-only mode.
I am fairly certain that it is not possible to check connection state while in AP-only mode.
I suspect that the logic at the top of startConfigPortal() is backwards.

If I come up with a better solution than setBreakAfterConfig(true) and a loop, I'll submit a PR.

  if(!WiFi.isConnected()){ // if it's NOT connected, we force a disconnect? Is this right?
    WiFi.persistent(false);
    // disconnect sta, start ap
    WiFi.disconnect(); //  this alone is not enough to stop the autoconnecter
    WiFi.mode(WIFI_AP);
    WiFi.persistent(true);
  } 
  else {
    //setup AP
    WiFi.mode(WIFI_AP_STA);
    DEBUG_WM(F("SET AP STA"));
  }

Settings in IDE

LOLIN(WEMOS) D1 R2 & Mini

Additional libraries: Tyler Glenn BME280 lib https://github.com/finitespace/BME280 v2.3.0

built-in WiFi 1.2.7

ESP8266hardware libs from git

void setup() { ... WiFiManager wifiManager;

   // Enter portal mode only if hardware button is pressed on startup
   if (digitalRead(RESET_PIN) == LOW)
   {
      // go into a blocking loop awaiting configuration

      // WiFiManager does not work well in this mode. It sets the mode to AP, but then
      // tries to test the client connection, which naturally fails.

      // With infinite timeout, WiFiManager calls WiFi.waitForConnectResult(). This can
      // result in either an infinite timeout or an immediate failure (even on success),
      // so set the "connect to wifi" timeout to something...anything...
      wifiManager.setConnectTimeout(120000);
      // wifiManager.setBreakAfterConfig( true ); // force startConfigPortal to return on failure

      if (!wifiManager.startConfigPortal(AP_NAME, AP_PASSWORD))
      {
         Serial.println("Failed to connect and hit timeout. Resetting. :(");
         // ... reset here
      }
   }
   else start up wifi etc

Debug Messages

*WM: Configuring access point... 
*WM: DIOT
*WM: AP IP address: 
*WM: 192.168.4.1
*WM: HTTP server started
*WM: Request redirected to captive portal
*WM: Request redirected to captive portal
*WM: Handle root
*WM: Scan done
*WM: DUP AP: xfinitywifi
*WM:  
[list of access points here]
*WM: Sent config page
*WM: Request redirected to captive portal
[5 times]
*WM: WiFi save
*WM: Sent wifi save page
*WM: Connecting to new AP
*WM: Connecting as wifi client...
*WM: Waiting for connection result with time out
[blocks until timeout, then reenters config loop or exits depending on configuration]
[returns immediately with failure if no timeout set]

tekhedd commented 6 years ago

Note: I am wrong about the WiFi.isConnected() logic. It looks like if it is already connected in STA mode, it is attempting to stay connected by using AP_STA mode, whereas if it is not connected, it attempts to clear the ssid/password without storing the setting.

The code in connectWiFi needs to be changed to force STA-only mode if it is to actually test the supplied user/password. I think this is OK because it actually enters AP-only mode on success in any case. I need to test it in the loop code but I believe I have a general fix. I mean, assuming it doesn't break EVERYONE else's code. :)

tablatronix commented 6 years ago

I am not going to even try to read that. Please post clear reproduction steps and expected result and actual result and logs.

There was some discussion in another issue where saving always failed similar to what you are saying, it turned out to be an issue with esp core and reoslved when updating it.

tekhedd commented 6 years ago

Oh holy crap. I got my git all wrong and haven't even been on the development branch. A program as powerful as git should really have a better email client built into it, don't you think? Starting over from scratch.

1) I did work all day on this, you know, but thanks for being rude.

2) The saving bug is real but it's not present in development branch, so anyone who is still reporting it has the release branch. I have a fix/PR ready to go, but, as I said, wrong branch and apparently you rewrote some of that. So it's a nonissue. I mean for anyone not using the official release of course.

tablatronix commented 6 years ago

Try hotfixes branch.

Not being rude, there is a template for filing bugs, and your report was confusing.

tzapu / WiFiManager