"Sign in to Wi-Fi Network" never happens on Android devices, but redirection works fine

Question

I have a Captive Portal setup using RadiusDesk + FreeRADIUS + CoovaChilli + Nginx.

Redirection works 100% on any device (including Android). If the user is not yet authenticated, when they attempt to go to any http:// webpage, they get redirected to my captive portal "login" page as expected.

Here's where I'm struggling to understand the difference:

• on iOS devices, the moment you connect to this Wifi, the popup for "Log in" appears immediately (as expected) and it is going to my captive portal login page
• on Android devices you can connect to the Wifi, but nothing further happens. If you try to browse, you do get redirected, but where is the "Sign in to Wi-Fi network" popup?

Even more suspicious, we have a Captive Portal (this one is a proprietary "Cyberoam" system) here in our office, and when I use the same Android devices to connect to that network over Wifi, I immediately get the "Sign in to Wi-Fi network" popup as expected. What's up with my setup?

Here is my current /etc/coova/config setup:

HS_LANIF=eth2              # Subscriber Interface for client devices
HS_NETWORK=10.1.1.0        # HotSpot Network (must include HS_UAMLISTEN)
HS_NETMASK=255.255.255.0     # HotSpot Network Netmask
HS_UAMLISTEN=10.1.1.1      # HotSpot IP Address (on subscriber network)
HS_UAMPORT=3990            # HotSpot UAM Port (on subscriber network)
HS_UAMUIPORT=4990          # HotSpot UAM "UI" Port (on subscriber network, for embedded portal)
HS_NASID=localhost
HS_RADIUS=localhost
HS_RADIUS2=localhost
HS_RADSECRET=testing123    # Set to be your RADIUS shared secret
HS_UAMSECRET=greatsecret     # Set to be your UAM secret
HS_UAMALIASNAME=chilli
HS_SSID="Struisbaai"
HS_NASIP=127.0.0.1    # To explicitly set NAS-IP-Address
HS_UAMSERVER=$HS_UAMLISTEN
HS_UAMFORMAT=http://\$HS_UAMLISTEN/cake2/rd_cake/dynamic_details/chilli_browser_detect/
HS_MACAUTH=on              # To turn on MAC Authentication
HS_TCP_PORTS="80 23 8000"
HS_MODE=hotspot
HS_TYPE=chillispot
HS_WWWDIR=/etc/chilli/www
HS_WWWBIN=/etc/chilli/wwwsh
HS_PROVIDER=Coova
HS_PROVIDER_LINK=http://www.coova.org/
HS_LOC_NAME="My HotSpot"           # WISPr Location Name and used in portal
HS_COAPORT=3799

I also notice that if I connect with a PC to my hostpot network, I can ping clients3.google.com and get a response (before authentication!) which should not be possible. All other domains get no response (as expected). This would explain why the Android devices think they "have an internet connection", but nowhere do I whitelist this domain in my CoovaChilli configuration as far as I can tell...

Answer 1

Ah, figured it out myself.

If DNS servers are not explicitly configured, then for some reason (something to do with my network setup??) clients.google.com is allowed.

So I just added the following to my config file:

HS_DNS1=208.67.222.123
HS_DNS2=208.67.220.123

And now curl -i clients3.google.com/generate_204 returns the 302 response as expected, now.

That is quite odd, though?

Answer 2

I've had the same problem. I've found out that domain coova.org gets the same IP address as google.com during coovachilli startup walledgarden translations (domains to IPs). I pinged coova.org and google.com and got the same IP with:

HS_DNS1=208.67.222.222
HS_DNS2=208.67.220.220

Because of www.coova.org is set as allowed in /chilli/functions file no matters what is in your other config files, I modified the functions file content and removed www.coova.org from 'uamallowed' and problem has gone - android captive portal detection works now.

I really do not understand such behaviour - mabye some coova/opendns/systemcache, wrong dnsrecords or sth...