starred/WiFiManager

Fork 0

mirror of https://github.com/tzapu/WiFiManager.git synced 2026-04-28 01:25:49 +03:00

[GH-ISSUE #114] Captive Portal on Android #86

New issue

Open

opened 2026-02-28 01:23:20 +03:00 by kerem · 6 comments

kerem commented

2026-02-28 01:23:20 +03:00

Owner

Originally created by @rkistner on GitHub (Feb 27, 2016).
Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/114

For Android (and Chrome) devices, this library currently handles /generate_204 ( for http://clients3.google.com/generate_204) to return a 204 response. This indicates to Android/Chrome that is is not a captive network, and appears like a normal WiFi network. Shouldn't this be the other way around?

If I remove that line, I get the following behaviour, which I want:

I connect to the AP.
Android asks me to "Sign in to Wi-Fi network".
Clicking on the link takes me directly to the AP configuration page for this library (192.168.4.1).

With the 204 response, I have to manually open the browser and browse to an arbitrary page, waiting for the redirect.

Originally created by @rkistner on GitHub (Feb 27, 2016). Original GitHub issue: https://github.com/tzapu/WiFiManager/issues/114 For Android (and Chrome) devices, this library currently handles `/generate_204` ( for http://clients3.google.com/generate_204) to return a 204 response. This indicates to Android/Chrome that is is _not_ a captive network, and appears like a normal WiFi network. Shouldn't this be the other way around? If I remove that [line](https://github.com/tzapu/WiFiManager/blob/0.10/WiFiManager.cpp#L96), I get the following behaviour, which I want: 1. I connect to the AP. 2. Android asks me to "Sign in to Wi-Fi network". 3. Clicking on the link takes me directly to the AP configuration page for this library (192.168.4.1). With the 204 response, I have to manually open the browser and browse to an arbitrary page, waiting for the redirect.

kerem added the

Discussion

label

2026-02-28 01:23:20 +03:00

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@tzapu commented on GitHub (Feb 27, 2016):

hi,

i don t currently have an android device to test stuff with, i do remember 204 was contributed by someone specifically for android and i know last i tested that i did get the portal...

I will try to get some android devices to test in the next week, hopefully i ll have some more time for this

cheers

@tzapu commented on GitHub (Feb 27, 2016): hi, i don t currently have an android device to test stuff with, i do remember 204 was contributed by someone specifically for android and i know last i tested that i did get the portal... I will try to get some android devices to test in the next week, hopefully i ll have some more time for this cheers

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@rkistner commented on GitHub (Feb 27, 2016):

Strange, it's the exact opposite for me.

I can test with more Android devices at my office next week.

@rkistner commented on GitHub (Feb 27, 2016): Strange, it's the exact opposite for me. I can test with more Android devices at my office next week.

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@baruch commented on GitHub (Mar 28, 2016):

The documentation for this is in http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

Looks like if you capture it and return 204 there is no detection of the captive portal. I suggest to change the code so that "if (captivePortal()) return;" is in the beginning of the function. I made the modification in my code and will test it later on. If someone else can test it too that would be great.

@baruch commented on GitHub (Mar 28, 2016): The documentation for this is in http://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection Looks like if you capture it and return 204 there is no detection of the captive portal. I suggest to change the code so that "if (captivePortal()) return;" is in the beginning of the function. I made the modification in my code and will test it later on. If someone else can test it too that would be great.

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@baruch commented on GitHub (Mar 28, 2016):

I tried it now and it didn't raise the Android popup, but neither does the current handler.

@baruch commented on GitHub (Mar 28, 2016): I tried it now and it didn't raise the Android popup, but neither does the current handler.

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@kentaylor commented on GitHub (Apr 22, 2016):

I'm convinced rkistener is correct in suggesting /generate_204 should be removed.

The generate_204 is not what I would call a captive portal test but a test of whether there is internet connectivity by calling to a google controlled address on the internet and seeing if it gets the expected response. The generate_204 response spoofs this test and returns the result expected from the remote address. Chrome books and android devices then think there is an internet connection and send out http requests from other scripts and apps running in the background. In my case this flooded the web server with requests and stuffed up background applications that could not deal with the response the ESP8266 provided when they were expecting something else.

@kentaylor commented on GitHub (Apr 22, 2016): I'm convinced rkistener is correct in suggesting /generate_204 should be removed. The generate_204 is not what I would call a captive portal test but a test of whether there is internet connectivity by calling to a google controlled address on the internet and seeing if it gets the expected response. The generate_204 response spoofs this test and returns the result expected from the remote address. Chrome books and android devices then think there is an internet connection and send out http requests from other scripts and apps running in the background. In my case this flooded the web server with requests and stuffed up background applications that could not deal with the response the ESP8266 provided when they were expecting something else.

kerem commented

2026-02-28 01:23:20 +03:00

Author

Owner

@tablatronix commented on GitHub (Aug 29, 2017):

Shouldn't this be optional as should captive portal ?

I mean would allowing wifimanager to act as an AP be useful at all ?

@tablatronix commented on GitHub (Aug 29, 2017): Shouldn't this be optional as should captive portal ? I mean would allowing wifimanager to act as an AP be useful at all ?