UAM redirection

[José Borges]

How on earth i make the browser open the UAM upon the user connecting to the wireless network?

1. User turns on WIFI on the smartphone (android/ios)
2. User selects correct WIFI SSID
3. User taps LOGIN to connect to WIFI
4. ... Chilli/FreeRadius/Chilli do their stuff ...
5. Browser open with the UAM url in it
6. User can then type his username/password to access internet.

I'm only missing step 5... The browser wont open... :(

I use this HS_REDIRDNSREQ=on on /etc/chilli/config, but sometimes it works sometimes it doesnt.

Any advise?

Here's my /etc/chilli/config

GRASE_VARS=$(cat /etc/dnsmasq.d/01-grasehotspot | grep #)
HS_NETWORK=$(echo "$GRASE_VARS" |grep chilli_network|awk '{print $2}');
HS_NETMASK=$(echo "$GRASE_VARS" |grep chilli_netmask|awk '{print $2}');
HS_UAMLISTEN=$(echo "$GRASE_VARS" |grep chilli_lanip|awk '{print $2}');
HS_WANIF=$(echo "$GRASE_VARS" |grep chilli_wanif|awk '{print $2}');
HS_LANIF=$(echo "$GRASE_VARS" |grep chilli_lanif|awk '{print $2}');
HS_REDIRDNSREQ=on
HS_WANIF=${HS_WANIF:-eth0}
HS_LANIF=${HS_LANIF:-eth1}
HS_NETWORK=${HS_NETWORK:-10.1.0.0}
HS_NETMASK=${HS_NETMASK:-255.255.255.0}
HS_UAMLISTEN=${HS_UAMLISTEN:-10.1.0.1}
HS_UAMPORT=3990
HS_UAMUIPORT=4990
HS_DNS_DOMAIN=hotspot.lan
HS_DNS1=$HS_UAMLISTEN
HS_DNS2=$HS_UAMLISTEN
HS_MAXCLIENTS=65000
HS_NASID=nas01
HS_RADIUS=localhost
HS_RADIUS2=localhost
HS_UAMALLOW=$HS_UAMLISTEN
HS_RADSECRET=SuperSpecialSecret 
HS_UAMALIASNAME=grase
HS_UAMDOMAINS=".google-analytics.com,.googletagmanager.com,.gstatic.com,.googleapis.com"
HS_UAMSERVER=$HS_UAMLISTEN
HS_UAMFORMAT=http://\$HS_UAMSERVER/grase/uam/hotspot
HS_UAMHOMEPAGE=http://\$HS_UAMSERVER/grase/uam/hotspot
HS_MACAUTH=on

HS_TCP_PORTS="80 443 22 2812 53 3990 3128"
HS_MODE=hotspot
HS_TYPE=chillispot
HS_ADMUSR=CoovaChilli
HS_ADMPWD=radmin
HS_DEFINTERIMINTERVAL=150
HS_WWWDIR=/etc/chilli/www
HS_WWWBIN=/etc/chilli/wwwsh
HS_PROVIDER=Grase
HS_PROVIDER_LINK=http://hotspot.purewhite.id.au/
HS_LOC_NAME="GRASE HotSpot"

[José Borges]

Come on... noone can help me? Tim?

[Timothy White]

This is device dependent.

Most modern devices will detect a hotspot, and open a special browser frame with the UAM. Other devices will need you to open a browser and try and browse to a non HTTPS site.

Please provide more information about your setup (see collecting support info page on the website) as well as specifics about your test clients.

Tim

--
This mailing list is for the Grase Hotspot Project http://grasehotspot.org
---
You received this message because you are subscribed to the Google Groups "Grase Hotspot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grase-hotspo...@grasehotspot.org.
To post to this group, send email to grase-...@grasehotspot.org.
Visit this group at https://groups.google.com/a/grasehotspot.org/group/grase-hotspot/.
To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/a7c8b504-c18c-4933-a034-4d3914ce0a61%40grasehotspot.org.

[José Borges]

Yes true...

Im just making sure that my Chilli config file is ok, because the first time I connect to the WIFI i get the UAM login page, but if i disconect from the wifi without enter any login (so im rejected), and then connect later on i reconect to the WIFI again, the UAM login page doesnt show up, the WIFI just says CONNECTED.

That's my "problem"... Do i have something missconfigured or same thing happens to you?

[Timothy White]

Again, please provide device information. It's impossible to know if this is device behaviour or hotspot behaviour.

Does it happen for you on Android devices? iOS?

I expect it's a client behaviour because you've not chosen to login, and it's remembered that it already offered you a login that you reject.

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/ada2929d-2611-4fac-aac7-0930d7d6b567%40grasehotspot.org.

[José Borges]

Tim, its the same on several mobile devices with diferente OS's (Android versions and IOS versions)

Apple Iphone 4

Apple Iphone 5S

Samsung Galaxy Note 4

Samsung Galaxy 5

Samsung Galaxy Tab A

All of them same workflow:

1 - first time i connect to WIFI hotspot i get the browser window with GRASE UAM.

2 - i disconect from the WIFI hotspot without doing anything (no login).

3 - second time i connect to WIFI hotspot i get the phone OS saying that im connected to the WIFI hotspot but no browser window.

Unfortunately im aware of the HTTPS redirection 'problem', but this doesnt seem to be the case.

First time works, second and further times doesnt... At least until i restart CHILLI manualy with /etc/init.d/chilli restart 

That's why i think i have something missconfigured.

[Emmanuel Nyachoke]

I think I noticed this even with windows clients but it seemed irregular in my case the very first time I connected the client I got the message 'additional login my be required' but did not see the message subsequently. This does not bother me  much but other hotspot management systems do this consistently. 

[José Borges]

Unfortunately this does bother me and i have been searching for an answer for months... because mobile clients fire up they wifi, connect to the open wifi hotspot and launch facebook... and they dont understand they have to go to http://10.1.0.1 and do a login... i keep getting asked why doesnt it show the UAM login when i connect to the wifi as other solutions do. I did a fresh install of grase hotspot and it happens the same thing, so it isn't anything i changed by myself. 

Everyone has this behaviour or could it be a hardware (hotspot server) issue?

[Henry Terkura Swende]

I think the reason it gives you the uam login page first time is because dhcp lease for that IP had expired and was assigned as new dhcp request... Hence when you disconnect from wifi and reconnect before the dhcp lease expires you'll have to navigate to a non HTTPS website to get the uam login page. I think it has a lot to do with how coovachilli works .....you get blocked when you try to access services not allowed without authentication and authorization..... My observations over time

--

This mailing list is for the Grase Hotspot Project http://grasehotspot.org
---
You received this message because you are subscribed to the Google Groups "Grase Hotspot" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grase-hotspo...@grasehotspot.org.
To post to this group, send email to grase-...@grasehotspot.org.
Visit this group at https://groups.google.com/a/grasehotspot.org/group/grase-hotspot/.

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/1f09a37e-45b1-47e4-a3dc-69dbcb114d2b%40grasehotspot.org.

[José Borges]

Ooookkkk... Testing time then...

I did what you mention...

Made chilli local.conf with lease=10 and then tested.

I was given the same IP address even after chilli_query stopped listing me in chilli_query dhcp-list

Meaning, that 5 minutes after i had my DCHP release, the IP i was given again was the same, and i did try to conect another device prior, to see if i was given the first available ip from the ippool...

So no luck there... No Browser was open again (on second connection to wifi, which was 5 minutes after i disconected the wireless).

my chilli.conf

interval=60

nousergardendata

defidletimeout=604800

dhcpstart=2

lease=10

output of chilli_query dhcp-list (theres a 60 seconds lease grace period, that why the 19/10 on bold line).

18-1E-B0-BE-68-2B 10.1.0.6 dnat 1/10

80-65-6D-2C-BE-49 10.1.0.2 dnat 19/10

00-90-FB-42-65-4D 10.1.0.5 dnat 9/10

Im tearing my hair out... since i tried with three diferent versions of android (5, 5.1.1, 4) but only the iphones worked!!! connect /disconnect / connect / disconnect ... it always shows the UAM on the iphones (i cant believe i am saying this).

[Henry Terkura Swende]

Ok, I think I didn't get the full  picture, thought the problem applied to all devices you were using .....but now I think it's device specific.

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/6e988722-0fe6-4488-958e-b9512a1a5b85%40grasehotspot.org.

[José Borges]

It applied to ALL DEVICES prior to me adding this:

"I use this HS_REDIRDNSREQ=on on /etc/chilli/config, but sometimes it works sometimes it doesnt."

Before none opened the Browser, now ONLY iphones open always. Android only opens on first connection to WIFI.

[Timothy White]

Hi José

Finally replicated this. And it hints of a big bug somewhere, just got to work out where. Figured I'd do a scientific test to only change 1 thing at a time to work out the issue. Finally got it after about the 12th time of connecting/disconnect. And looking at the packet captures there is something disturbing. The request to http://connectivitycheck.gstatic.com/generate_204 to check for connectivity gets through.

I tested further, and even though that request got through, seconds later attempting to connect to yahoo.com fails.

I only have Android Nexus5X running marshmallow to test. I assume the reason this works for iPhones is that they use a different mechanism for checking if the internet works.

I'll keep digging and see if I can work out what causes it. At this stage it appears to be a Coova Chilli bug, where, I have no idea.

Tim

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/1de8672c-5834-4502-8014-7205a69b647d%40grasehotspot.org.

[Timothy White]

And just like that, I've found the issue.

At some point the coova project moved to Github, and appear to maybe use Google domains to redirect www.coova.org to the new url. www.coova.org is in the uamallowed list. Sometimes to connectivitycheck.gstatic.com address resolves to the same IP as www.coova.org, which means that the generate_204 is allowed through!

Why is www.coova.org in the uamallowed list? It's been there for years because it's part of the defaults of coova chilli.

I'll aim to get an updated coovachilli package built in the next few days and into the nighlies so people can test it. At some point I do need to update to the latest version, but I'll do that as a separate package.

That was pure luck discovering the reason!

[Timothy White]

Please test the coova packages in nightly.

http://nightly.packages.grasehotspot.org/pool/main/c/coova-chilli/coova-chilli_1.3.0-22-g39df09b_i386.deb or http://nightly.packages.grasehotspot.org/pool/main/c/coova-chilli/coova-chilli_1.3.0-22-g39df09b_amd64.deb

I've not built the ARM packages. Let me know if these work before I spend time building the arm ones. If they are good I'll promote them to stable!

Regards

[José Borges]

Hi Tim

First of all, thank you for taking up your time with this.

After checking your nightly, on a new grase install, I double checked what's changed and applied those changes to my box.

 

I only noticed a change in the functions chilli file (should there be more please let me know):

FROM MINE

uamallowed "www.coova.org${HS_UAMSERVER:+,$HS_UAMSERVER}$webadmin$uamallow"

 

TO YOURS

uamallowed "${HS_UAMSERVER:+$HS_UAMSERVER}$webadmin$uamallow"

What im guessing, no time to test yet, is that the DHCP RELEASE time is also important.

What i noticed, based on your feedback, about the CAPTIVE PORTAL checking url... im our android (v5) the url is connectivitycheck.android.com/generate_204 (for instance on my Samsung Note 4) and not connectivitycheck.gstatic.com as you mention on your NEXUS 5X. Probably, it has to do with the android version of the device. removing the gstatic.com domain from the uamallowed started to show the UAM consistently, but on older android versions like 4 the url is http://clients3.google.com/generate_204, but no UAM is shown still. 

Apple has its own captivel portal url, doing a simple google search is easy to figure out which.

To test everything i commented the HS_UAMDOMAINS line in Chilli config file.

But better results no doubt... still not perfect... but better.

[José Borges]

Anyone with a KINDLE could provide feedback if the GRASE HOTSPOT works fine with that OS?

[Timothy White]

Hi José

You'll need to make sure you don't remove the uamallowed line completely. The url used by different Android versions won't have made a difference, as it's the IP it resolves to that causes the issue.

Can you post your complete uamallowed list? It may be that something in your list is resolving to the same IP as one of the checks, and it may only resolve the same sometimes.

Also, I didn't find DHCP release made any difference. Watching the packet dumps, the Android devices do the captive portal check everytime they connect, regardless of the existing DHCP lease or not. As long as it can "reach" the generate_204 url it's checking with, the uam won't be displayed.

Tim

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/7715d020-3bf1-4be1-a1ae-02e1608064d4%40grasehotspot.org.

[José Borges]

HS_UAMDOMAINS=".mobile-enterprise.com,.algardata.com,.unykapp.com,.unyk.tv,.unykvis.com,.licdn.com,.linkedin.com,.twimg.com,.twitter.com,.facebook.com,.fbcdn.net,connect.facebook.net,.zendesk.com,.google-analytics.com,.googletagmanager.com,.googleapis.com,.addthis.com,.yandex.ru,.hotjar.com,.list-manage.com,.sumome.com,.yandex.com,.onesignal.com,.mixpanel.com,.intercom.io,.hellobar.com,.heapanalytics.com,.messenger.com"

[Timothy White]

Wow. That is a huge list. Are you modifying the config file directly, or adding them via the web interface?

In theory, because uamdomains uses DNS packet inspection, it should work. However, I'm not convinced. I wouldn't be surprised if once a *.googleapis.com is allowed through, that other sites also on that IP would then be allowed through as well. 

In my quick check, DNS results for *.googleapis.com do resolve to similar IP's to the clients3.google.com domain. I expect that are on the same infrastructure and that's what's allowing the packets through. It may even be the analytics IP's doing it.

I would look at all your uamdomains, and think of them more like uamallowed, where we resolve the IP and allow that IP through. It's certainly what appears to be happening, and it's probably more to do with another client requesting a site, and then having that IP allowed for all clients.

So basically, if a site is hosted in a companies massive cloud, expect that other sites in that cloud will also be allowed through.

Tim

To view this discussion on the web visit https://groups.google.com/a/grasehotspot.org/d/msgid/grase-hotspot/12f9b895-8d6d-40bb-b50d-2252ba93cf31%40grasehotspot.org.

[José Borges]

this hardcoded list is on chilli config file, then in the backoffice anyone can add more domains should they need.

[Timothy White]

I'm going to make these nightly packages live in the stable build now. The ARM ones will have to wait until I can build them.

Tim

[Sanjeev k]

Hi Tim,

Please let me how to enable mac bind option at user`s first time login. the device should not be disconnected if the server goes rebooted.

Thanks
Sanjeev