Redirection not working for clients3.google.com

[anselanza]

I have a Coovachilli+nginx+RadiusDesk setup, which works perfectly except that Android clients aren't getting automatically prompted to sign-in to Wifi.

It turns out that clients3.google.com is being allowed through (before logon) unlike either domains such as captive.apple.com (for iOS clients).

For example, without logon I can still ping clients3.google.com (but not captive.apple.com) and curl -i clients3.google.com returns HTTP/1.1 302 Found and a blank page with "The document has moved" message, whereas curl -i captive.apple.com returns a completely different response of HTTP1.0 302 Moved Temporarily and a different body.

My /etc/chilli/config is set up like this (as you can see, clients3.google.com is not on the whitelist):

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_UAMALLOW=magnesium.tech
HS_MACAUTH=on              # To turn on MAC Authentication
HS_TCP_PORTS="80 23 8000 3000"
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

Very strange? Why is that one domain (which happens to be the one that Android devices check for Captive Portal redirection!) being handled differently to everything else?

[anselanza]

Sorry, perhaps more to the point, curl -i clients3.google.com/generate_204 returns

HTTP/1.1 204 No Content
Content-Length: 0
Date: Wed, 02 Mar 2016 13:27:38 GMT

Which is exactly what you'd expect AFTER logging in. But somehow it is being allowed through?

[anselanza]

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?

[mfaroukg]

Hi, I have seen this issue before and was suspecting the DNS same as you did, then i thought it is the port 443 which i added to the firewall list, and this happening for google only mentioned.

could you confirm if the issue is no more ?