search

Hieromon / AutoConnect

An Arduino library for ESP8266/ESP32 WLAN configuration at runtime with the Web interface
https://hieromon.github.io/AutoConnect/
MIT License
911 stars 190 forks source link

Autoconnect Redirect after success #590

Closed wspitts2 closed 1 year ago

wspitts2 commented 1 year ago

When I connect to the esp32ap through the wifi network list in android. It pops up the configuration screen (great!). I configure everything and then hit connect. Instead of going to the new device IP address /_ac/success it goes to the default 172.217.28.1/_ac/success which is not reachable and barfs a page not found error from the portal popup on android (I believe the SSID is shut down after a successful connection and thus not listening). Shouldn't there be a default delay between changing the network, and the success page before shutting down the esp32ap SSID SoftAP? If so, how could I implement this.

Hieromon commented 1 year ago

@wspitts2

he default 172.217.28.1/_ac/success which is not reachable and barfs a page not found error from the portal popup on android (I believe the SSID is shut down after a successful connection and thus not listening). Shouldn't there be a default delay between changing the network, and the success page before shutting down the esp32ap SSID SoftAP?

No, SoftAP is alive. Stop only DNS if the connection is successful. Also, the client (your Android device) keeps connection to SoftAP even if the STA side of the ESP32 connects successfully. AutoConnect for ESP32 does not change the network.

Instead of going to the new device IP address /_ac/success it goes to the default 172.217.28.1/_ac/success which is not reachable and barfs a page not found error from the portal popup on android

This means that the client device (Android) leaves the ESP32's SoftAP and automatically switches connections to the same access point that the ESP32 STA just connected to. Can your android do that?

Hieromon commented 1 year ago

@wspitts2 Please take the AC_DEBUG trace. I would like to proceed to diagnose the problem a bit on my end. There have been other issue reports of redirects to 172.217.28.1/_ac/success failing after a successful connection on some Android devices. This phenomenon may be caused by the combination of a specific Android version and the ESP32 Arduino core, and is also discussed in the ESP32 repo. I would like your help investigating this issue, as its resolution may benefit other users.

Also, can you reproduce the problem by changing the SoftAP IP address? I would like you to configure the AutoConnectConfig::softAPIP setting and try the SoftAP IP address with 8.8.4.4/8.8.4.4/255.255.255.0. Comparing the AC_DEBUG trace at that time with the AC_DEBUG trace at 172.217.28.1 might reveal something. This concerns how the Android OS uses DNS to determine internet transparency under a captive portal.

wspitts2 commented 1 year ago

I will absolutely do that over the next few days! Thanks for the reply!

wspitts2 commented 1 year ago

I have done what you requested. Also, here is a link to my code that I am using (without the added Debug code)... https://drive.google.com/file/d/12ChEBuA8UIB8tabLtgVJSz5m6KmVptsb/view?usp=sharing

Both of these result in a failed load of the _ac/success

Original: [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/_ac/config,generated:/_ac/config, allocated [AC] Host:172.217.28.1,/_ac/config,already allocated [AC] 13 network(s) found, 1137 buf [AC] Host:172.217.28.1,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/_ac/connect,generated:/_ac/connect, allocated [AC] Host:172.217.28.1,/_ac/connect,already allocated [AC] Queried SSID:DrGPmesh [AC] WiFi.config(IP=0.0.0.0, Gateway=0.0.0.0, Subnetmask=0.0.0.0, DNS1=0.0.0.0, DNS2=0.0.0.0) [AC] WiFi.begin(DrGPmesh,a9b8c7d6e5) ch(9)..........established IP:10.0.0.20 [AC] Host:172.217.28.1,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20 [AC] DNS server stopped [AC] Maintain SoftAP [AC] Event<13> handler registered [AC] DrGPmesh credential saved WiFi connected: IP: 10.0.0.20 Gateway: 10.0.0.1 Subnet: 255.255.255.0 DNS: 10.0.0.1 MAC: 84:CC:A8:5E:75:80 mDNS responder started [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20 [AC] Host:connectivitycheck.gstatic.com,/_ac/result,generated:/_ac/result, allocated [AC] Host:172.217.28.1,/_ac/result,already allocated [AC] Leaves:118[ms] [AC] Resulting in http://172.217.28.1/_ac/success [AC] Host:172.217.28.1,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20

Updated: [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/_ac,generated:/_ac, allocated [AC] Host:8.8.4.4,/_ac,already allocated [AC] Host:8.8.4.4,/favicon.ico,ignored [AC] Host:8.8.4.4,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/_ac/config,generated:/_ac/config, allocated [AC] Host:8.8.4.4,/_ac/config,already allocated [AC] 9 network(s) found, 1049 buf [AC] Host:8.8.4.4,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.115 [AC] Host:connectivitycheck.gstatic.com,/_ac/connect,generated:/_ac/connect, allocated [AC] Host:8.8.4.4,/_ac/connect,already allocated [AC] Queried SSID:DrGPmesh [AC] WiFi.config(IP=0.0.0.0, Gateway=0.0.0.0, Subnetmask=0.0.0.0, DNS1=0.0.0.0, DNS2=0.0.0.0) [AC] WiFi.begin(DrGPmesh,a9b8c7d6e5) ch(9)...........established IP:10.0.0.20 [AC] Host:8.8.4.4,/_ac/result,generated:/_ac/result, allocated [AC] Host:8.8.4.4,/_ac/result,already allocated [AC] Leaves:209[ms] [AC] Resulting in http://8.8.4.4/_ac/result [AC] DNS server stopped [AC] Maintain SoftAP [AC] Event<13> handler registered [AC] DrGPmesh credential saved WiFi connected: IP: 10.0.0.20 Gateway: 10.0.0.1 Subnet: 255.255.255.0 DNS: 10.0.0.1 MAC: 84:CC:A8:5E:75:80 mDNS responder started [AC] Host:8.8.4.4,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20 [AC] Host:connectivitycheck.gstatic.com,/generate_204,ignored [AC] Detected application, connectivitycheck.gstatic.com, 10.0.0.20

Hieromon commented 1 year ago

@wspitts2 I will let you know the results of my diagnosis of your sketch. Your sketch is weak in several ways.

  1. Unnecessary AsyncTCP and ESPAsyncWebServer are included. Please exclude these. Also, if you plan to use ESPAsyncWebServer together in the future, please be aware that it cannot coexist with the HTTP request handler of the ESP32 core library.
  2. #ifdef ARDUINOJSON_VERSION_MAJOR >= 6 preprocessor directive is incorrect. It is a syntax error.
  3. I2C LCD is used, but please do not use I2C interrupts while WiFi.begin is running. The ESP-IDF WiFi driver is vulnerable to I2C interrupts. This issue is discussed in the ESP32 Arduino Core Repository. Some workarounds can also be found in the Issue topics. Similarly, the use of timer interrupts should not inadvertently generate interrupts. You are free to use the timerAlarm, but your sketch lacks exclusive control. You should implement semaphore synchronization or Mutex exclusive control so that the sketch disables timer interrupts while the FreeRTOS TCP stack is running.

  4. The procedure for executing Portal.handleClient() is incorrect. Perhaps this mistake is the most likely cause of your sketch's work defects.

    void loop() {
  // Handling the update of the sensor values to the local webserver
  if ((millis() - lastTime) > timerDelay) {
    readSensors();
    delay(10);
    updateDisplay();
    wifiClient();
    lastTime = millis();
    // uses BOOT button as GPIO0 button
    if (button1.pressed) {
      Serial.printf("Button 1 has been pressed %u times\n", button1.numberKeyPresses);
      button1.pressed = false;
    }
  }
}

    In the above code, the wifiClient() statement calling Portal.handleClient() is executed only once every 1000 ms. This procedure is a common mistake that prevents the ESP32 TCP stack from running. Fix your sketch as below and try again. It will probably solve the post-connection redirect problem.

    void loop() {
  wifiClient();
  // Handling the update of the sensor values to the local webserver
  if ((millis() - lastTime) > timerDelay) {
    readSensors();
    delay(10);
    updateDisplay();
    lastTime = millis();
    // uses BOOT button as GPIO0 button
    if (button1.pressed) {
      Serial.printf("Button 1 has been pressed %u times\n", button1.numberKeyPresses);
      button1.pressed = false;
    }
  }
}

I usually don't diagnose user sketches in detail. Because I'm not debugger. But in this case, I was hoping that this issue could be a clue to a still unresolved issue with certain versions of Android. But the cause is the fragility of the sketch. I will close this issue and move it to Discussions.