[GH-ISSUE #1322] Captive Portal Randomly Closes #1136

New issue

Open

opened 2026-02-28 01:28:41 +03:00 by kerem · 3 comments

kerem commented

2026-02-28 01:28:41 +03:00

Owner

Originally created by @bwjohns4 on GitHub (Dec 18, 2021).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1322

I'm trying to diagnose why the captive portal randomly closes in WiFiManager. Using an iphone to connect, sometimes the captive portal just shuts down right around the time that it loads. Does anyone know what signals the ESP8266 Webserver might send that would tell the client (iphone) to shutdown the connection? Is it the .stop()?
I know that often the iphone makes several requests that get redirected, but why might sometimes the captive portal session just randomly close down?

Is there a chance the when the .stop() is called below in response to a duplicate probe, it would close the active captive portal in use by the previous probe?

  if (doredirect) {
    #ifdef WM_DEBUG_LEVEL
    DEBUG_WM(DEBUG_VERBOSE,F("<- Request redirected to captive portal"));
    #endif
    server->sendHeader(F("Location"), (String)F("http://") + serverLoc, true);
    server->send ( 302, FPSTR(HTTP_HEAD_CT2), ""); // Empty content inhibits Content-length header so we have to close the socket ourselves.
    server->client().stop(); // Stop is needed because we sent no content length
    return true;
  }
  return false;
}

Originally created by @bwjohns4 on GitHub (Dec 18, 2021). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/1322 I'm trying to diagnose why the captive portal randomly closes in WiFiManager. Using an iphone to connect, sometimes the captive portal just shuts down right around the time that it loads. Does anyone know what signals the ESP8266 Webserver might send that would tell the client (iphone) to shutdown the connection? Is it the .stop()? I know that often the iphone makes several requests that get redirected, but why might sometimes the captive portal session just randomly close down? Is there a chance the when the .stop() is called below in response to a duplicate probe, it would close the active captive portal in use by the previous probe? ``` if (doredirect) { #ifdef WM_DEBUG_LEVEL DEBUG_WM(DEBUG_VERBOSE,F("<- Request redirected to captive portal")); #endif server->sendHeader(F("Location"), (String)F("http://") + serverLoc, true); server->send ( 302, FPSTR(HTTP_HEAD_CT2), ""); // Empty content inhibits Content-length header so we have to close the socket ourselves. server->client().stop(); // Stop is needed because we sent no content length return true; } return false; } ```

kerem added the

labels

2026-02-28 01:28:41 +03:00

kerem commented

2026-02-28 01:28:41 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 18, 2021):

Turn off cellular and see if it still does it? Usually this is a flood, I was just discussing this in another issue this week. I am not using advanced filtering for captive portals cause its a pita. But we can try that and only redirect probes. But we have to code for all possible devices and it changes randomly.

another thing we can try is use the client checking and try to block these by identifying the client has actually received the html, could use an xhr hit or detect client via user agent ?

usually the cp will come back, but its something going wrong in the client side usually and I agree its annoying af especially when you are already entering stuff

@tablatronix commented on GitHub (Dec 18, 2021): Turn off cellular and see if it still does it? Usually this is a flood, I was just discussing this in another issue this week. I am not using advanced filtering for captive portals cause its a pita. But we can try that and only redirect probes. But we have to code for all possible devices and it changes randomly. another thing we can try is use the client checking and try to block these by identifying the client has actually received the html, could use an xhr hit or detect client via user agent ? usually the cp will come back, but its something going wrong in the client side usually and I agree its annoying af especially when you are already entering stuff

kerem commented

2026-02-28 01:28:41 +03:00

Author

Owner

@bwjohns4 commented on GitHub (Dec 19, 2021):

Has this been observed on other clients other than iPhone?

@bwjohns4 commented on GitHub (Dec 19, 2021): Has this been observed on other clients other than iPhone?

kerem commented

2026-02-28 01:28:41 +03:00

Author

Owner

@tablatronix commented on GitHub (Dec 19, 2021):