Captive Portal on Android

[rkistner]

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:

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.

[tzapu]

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

[rkistner]

Strange, it's the exact opposite for me.

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

[baruch]

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]

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

[kentaylor]

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.

[tablatronix]

Shouldn't this be optional as should captive portal ?

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