iPhone/iPad authentication problem with latest iOS version #432

Cool34000 · 2018-04-20T11:37:31Z

Hi,

I'm experiencing authentication problems on latest iOS version (iPhone and iPad):

authentication popup shows up correctly
When login/pass is given, nothing happens (searching forever)

System is running on Debian with Coova Chilli 1.4.
Works OK with any other devices (tested on Windows, Ubuntu, Android, blackberry, etc.)...
So everything was working very well. With Apple's latest iOS version, it seems broken.

Am I alone or is there a known problem with latest iOS?
Is there any workaround?

Thanks

sunyitao · 2018-04-24T05:29:22Z

Possible causes for this problem is resp.challenge is null。

Trace file /www/ChilliLibrary.js at line 248.

if ( typeof (resp.challenge) != 'string' ) {
log('logonStep2: cannot find a challenge. Aborting.');
return chilliController.onError('Cannot get challenge');
}

Cool34000 · 2018-04-24T11:03:26Z

Hi,
Thanks for answering!

I don't use the embedded mini-portal (I'm using the CGI script)... Is ChilliLibrary.js used with this UAM?
Anyway, I took a look on ChilliLibrary.js but I don't speak JavaScript so I don't know how to "trace file /www/ChilliLibrary.js at line 248".
I haven't touched this file so the content is the bundled one.

Looking on the changes to ChilliLibrary.js, I've find a modification 10 months ago that I don't have (I'm using the 1.4 stable version):
f16fbd4
Could this be related?

Cool34000 · 2018-04-27T16:09:14Z

I've tested the fix in ChilliLibrary.js with no luck.
It seems that iOS has a bug with his popup because if I close the popup and use Safari instead to call the splash page, it works...

I guess we have to wait and hope that Apple fixes this bug quickly

sunyitao · 2018-04-28T06:14:49Z

exec chilli_query list on server, check user status

pashdown · 2018-08-16T17:30:51Z

Having similar problems, on IOS 11.4.1. After logging in, the IOS device never gets to the point where it can use the wifi. @sunyitao, I'm not sure what you mean by your last statement.

sunyitao · 2018-08-17T02:02:17Z

I mean, check the user status on the command line, whether it is authorized to pass

pashdown · 2018-08-17T15:20:39Z

The user is authorized to pass. I've tested several accounts. Still hangs at authentication where other devices are able to get through.

sunyitao · 2018-08-19T06:29:22Z

I do not understand。If the user status is passed, there is no reason to have this problem.

pashdown · 2018-09-25T19:22:41Z

I agree. Yet iOS hangs.

Cool34000 · 2019-01-08T16:56:14Z

Hi,
Any news about this bug?
There was 3 updates of iOS and still the same problem.

Other captive portals don't have this issue (pfsense for exemple), so there must be a reason for this behaviour and maybe a fix on Coova's side

pashdown · 2019-01-08T19:06:39Z

No news. I've given up on Coova resolving it.

Cool34000 · 2019-01-19T13:17:06Z

Hi,

I've been digging on this issue and I found something realy strange about Access-Request packets!
Here's what I see when my iPad is hitting the "login" button:

rad_recv: Access-Request packet from host 127.0.0.1 port 3779, id=132, length=267
        CoovaChilli-Version = "1.4"
        User-Name = "8C-FE-57-XX-XX-XX"
        User-Password = "8C-FE-57-XX-XX-XX"
        Service-Type = Framed-User
        Acct-Session-Id = "5c431e8e00000002"
        Framed-IP-Address = 172.17.0.4
        NAS-Port-Type = Wireless-802.11
        NAS-Port = 2
        NAS-Port-Id = "00000002"
        Calling-Station-Id = "8C-FE-57-XX-XX-XX"
        Called-Station-Id = "B8-27-EB-YY-YY-YY"
        NAS-IP-Address = 172.17.1.1
        NAS-Identifier = "nas01"
        WISPr-Location-ID = "isocc=FR,cc=33,ac=4,network=Coova,"
        WISPr-Location-Name = "XXXXXXXXX"
        Message-Authenticator = 0x4fd85f5e07437c4d83f2ef0b91a513ff

And here's what I see when my Android phone is hitting the "login" button:

rad_recv: Access-Request packet from host 127.0.0.1 port 36126, id=105, length=278
        CoovaChilli-Version = "1.4"
        User-Name = "testuser"
        User-Password = "xxxxxx"
        Service-Type = Login-User
        Acct-Session-Id = "5c431ef500000001"
        Framed-IP-Address = 172.17.0.5
        NAS-Port-Type = Wireless-802.11
        NAS-Port = 1
        NAS-Port-Id = "00000001"
        Calling-Station-Id = "EC-D0-9F-XX-XX-XX"
        Called-Station-Id = "B8-27-EB-YY-YY-YY"
        NAS-IP-Address = 172.17.1.1
        NAS-Identifier = "nas01"
        WISPr-Location-ID = "isocc=FR,cc=33,ac=4,network=Coova,"
        WISPr-Location-Name = "XXXXXXXXX"
        WISPr-Logoff-URL = "http://172.17.1.1:3990/logoff"
        Message-Authenticator = 0x4104a6f6f507d203bd8d6ba09dd7212f

As you can see, Service-Type is not th same! It looks like iOS try a MAC authentication request instead of sending username and password.

I'm sure this is why iOS devices can't connect using the built-in popup, but I don't know what can cause the issue: bug in iOS, problem with Freeradius, Coova Chilli or the hotspotlogin.php code.

Cool34000 · 2019-01-19T14:57:34Z

Hi again,

Here's what the debug of Coova Chilli shows when I hit the "login" utton on my iPad:

chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16688]: redir_getreq(2150): The path: hotspot-detect.html
chilli[16688]: redir_getreq(2251): User-Agent: CaptiveNetworkSupport-355.200.27 wispr
chilli[16688]: redir_getreq(2505): -->> Setting userurl=[http://captive.apple.com/hotspot-detect.html]
chilli[16688]: redir_main(4205): redir_accept: Original request host=captive.apple.com
chilli[16037]: auth_radius(1557): Starting radius authentication
chilli[16688]: redir_wispr2_reply(994):
chilli[16037]: chilli_handle_signal(386): caught 17 via selfpipe
chilli[16037]: _sigchld(316): child 16688 terminated
chilli[16037]: child_remove_pid(138): Freed child process 16688 [[redir]]
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: Received RADIUS packet id=8
chilli[16037]: RADIUS queue-out id=8 idx=8
chilli[16037]: cb_radius_auth_conf(4482): Received RADIUS response id=8
chilli[16037]: cb_radius_auth_conf(4629): Received RADIUS Access-Reject
chilli[16037]: dnprot_reject(2132): Rejecting UAM
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
chilli[16037]: dhcp_receive_ip(3764): Address found
^Cchilli[16037]: chilli_handle_signal(386): caught 2 via selfpipe
chilli[16037]: _sigterm(342): SIGTERM: shutdown
chilli[16037]: CoovaChilli shutting down
chilli[16037]: child_killall(286): pid 16037 killed 16037
chilli[16037]: Running /etc/chilli/down.sh
chilli[16037]: cmdsock_shutdown(109): Shutting down cmdsocket
chilli[16037]: Removing /var/run/chilli.16037.cfg.bin

And what it looks like on my Android phone:

chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[18897]: redir_getreq(2150): The path: logon
chilli[18897]: redir_getreq(2251): User-Agent: Mozilla/5.0 (Linux; Android 8.0.0; Mi MIX 2 Build/OPR1.170623.027; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/71.0.3578.99 Mobile Safari/537.36
chilli[18897]: redir_getparam(1941): The parameter username is: [testuser]
chilli[18897]: redir_getreq(2331): -->> Setting username=[testuser]
chilli[18897]: redir_getreq(2364): using uamprotocol: WISPr 1.0 (1)
chilli[18897]: redir_getparam(1941): The parameter password is: [9f05d1c8b0d0671c78e8d102ede326a5]
chilli[18897]: redir_main(3963): checking modules...
chilli[18897]: redir_main(3990): redir_accept: Sending RADIUS request
chilli[18897]: RADIUS client 0.0.0.0:0
chilli[18897]: redir_radius(2749): created radius packet (code=1, id=137, len=31)
chilli[18897]: redir_radius(2792): User password 16 [xxxxxx]
chilli[18897]: redir_radius(2917): sending radius packet (code=1, id=137, len=278)
chilli[18897]: Received RADIUS packet id=137
chilli[18897]: RADIUS queue-out id=137 idx=0
chilli[18897]: redir_cb_radius_auth_conf(2524): Received RADIUS response
chilli[18897]: redir_cb_radius_auth_conf(2629): +attribute EAP msg (0 bytes):
chilli[18897]: redir_main(4016): handling Access-Accept
chilli[18897]: redir_wispr1_reply(783):
chilli[18897]: redir_main(4054): -->> Msg userurl=[http://connect.rom.miui.com/generate_204]
chilli[17320]: Successful UAM login from username=testuser IP=172.17.0.1
chilli[17320]: dnprot_accept(2359): Calling connection up script: /etc/chilli/conup.sh
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: chilli_handle_signal(386): caught 17 via selfpipe
chilli[17320]: _sigchld(316): child 18897 terminated
chilli[17320]: child_remove_pid(138): Freed child process 18897 [[redir]]
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found
chilli[17320]: dhcp_receive_ip(3764): Address found

I guess the problem is on Coova Chilli's side, but I can't go further alone as I'm not a developper

Cool34000 · 2019-01-21T09:44:26Z

I finally found the problem!

I use daloradius' builtin UAM (hotspotlogin.php) and the file js/hotspotlogin.js seems to be the problem because when I empty this file iOS devices are working again!

So to fix the problem, I've added a test in index.php

if (!preg_match ("/CaptiveNetworkSupport/", $_SERVER["HTTP_USER_AGENT"]))
{
    $isAppleDevice=1;
}

And then I've added a test in js/hotspotlogin.js to bypass the file if it's an iOS device

if(!isAppleDevice==1)
{
...
}

There is the same problem with Coova Chilli's built-in CGI script, so this fix might also work.
Exept the CGI script is written in Perl and stands in one single file.

stan-thomas · 2022-06-28T10:34:45Z

I tried this method, and it still does not work with iOS devices. Do you think this is due to the fact that CoovaChilli version currently is 1.5 and it uses SSL? How do I debug this?

Update, the UAMlisten IP address in Safari can do a login. Not the default login page that pops up.

Cool34000 closed this as completed Jan 21, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

iPhone/iPad authentication problem with latest iOS version #432

iPhone/iPad authentication problem with latest iOS version #432

Cool34000 commented Apr 20, 2018

sunyitao commented Apr 24, 2018

Cool34000 commented Apr 24, 2018 •

edited

Cool34000 commented Apr 27, 2018

sunyitao commented Apr 28, 2018

pashdown commented Aug 16, 2018

sunyitao commented Aug 17, 2018

pashdown commented Aug 17, 2018

sunyitao commented Aug 19, 2018

pashdown commented Sep 25, 2018

Cool34000 commented Jan 8, 2019 •

edited

pashdown commented Jan 8, 2019

Cool34000 commented Jan 19, 2019

Cool34000 commented Jan 19, 2019 •

edited

Cool34000 commented Jan 21, 2019

stan-thomas commented Jun 28, 2022 •

edited

iPhone/iPad authentication problem with latest iOS version #432

iPhone/iPad authentication problem with latest iOS version #432

Comments

Cool34000 commented Apr 20, 2018

sunyitao commented Apr 24, 2018

Cool34000 commented Apr 24, 2018 • edited

Cool34000 commented Apr 27, 2018

sunyitao commented Apr 28, 2018

pashdown commented Aug 16, 2018

sunyitao commented Aug 17, 2018

pashdown commented Aug 17, 2018

sunyitao commented Aug 19, 2018

pashdown commented Sep 25, 2018

Cool34000 commented Jan 8, 2019 • edited

pashdown commented Jan 8, 2019

Cool34000 commented Jan 19, 2019

Cool34000 commented Jan 19, 2019 • edited

Cool34000 commented Jan 21, 2019

stan-thomas commented Jun 28, 2022 • edited

Cool34000 commented Apr 24, 2018 •

edited

Cool34000 commented Jan 8, 2019 •

edited

Cool34000 commented Jan 19, 2019 •

edited

stan-thomas commented Jun 28, 2022 •

edited