Why isn't my Galaxy S8 popping up my Captive Portal login page? I'm dealing with a Raspberry Pi 3 that is using hostapd to create its own wireless network.

When an Android client first connects to the network, it tries to grab the page http://connectivitycheck.gstatic.com/generate_204 to see if it's behind a client portal. My Raspberry Pi redirects this request to an instance of nginx that it is running, and returns a 302 redirect to my login page.

Because Android didn't get the response it was looking for (an HTTP 204), but got a 302 instead, from what I understand, it's supposed to popup my login page. I've seen this in action using other captive portal hardware.

In my case however, Android just shows a popup that says "Internet may not be available: Connect to another network or turn on Switch to mobile data".

Am I doing something wrong? Is there something specific Android is looking for in the login page before it will make it pop up?

Most of my testing is on my Galaxy S8. I tried it on a friend's S9, and that doesn't work either. Using a Windows 10 laptop though, the login page does popup.
After some digging, it appears it's working now.

When a client tries to access http://connectivitycheck.gstatic.com/generate_204, it needs to use DNS to resolve connectivitycheck.gstatic.com first. I had my dnsmasq setup to look like this:

interface=wlan0
dhcp-range=192.168.30.20,192.168.30.60,255.255.255.0,24h
address=/#/10.45.12.1


Where 10.45.12.1 is just a random IP I chose. It didn't really matter what that IP was, because as soon as the client resolves it to that IP, and tries to get /generate_204 from it, my iptables firewall rules would redirect all requests to nginx running on the Pi.

The only limitation I was aware of was that the IP couldn't be on the same LAN (192.168.30.0/24), or the Pi would try to use ARP to figure out its MAC address, and fail, without making the actual HTTP request.

It turned out that if the IP you are resolving everything to (in my case 10.45.12.1) is a LAN IP, Android won't popup the login page. No idea why.

The fix was to change from:

address=/#/10.45.12.1


to

address=/#/1.2.3.4


where 1.2.3.4 is any PUBLIC LAN IP (an IP outside of the '10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16' range). This fixed my problem. Hopefully it fixes someone else's as well.

NOTE: My setup does NOT require the client to ever have internet. They connect to the Pi, and get a page popup for configuration purposes. If you need the device to have internet, which would probably be a more common use case, you probably can't just resolve EVERYTHING to 1.2.3.4 like I do