captive portal issue with iOS devices

  • 2
  • Question
  • Updated 4 years ago
  • Answered
Hello,

I'm demoing a HiveAP121 unit. I'm running into an issue with iOS devices and the captive web portal. I click on the SSID and then the iOS device pops up its own separate window to do the authentication. I authenticate successfully and then the device just sits on the success page with only back button and cancel button as options. If I click on any of those or the home button, it will not connect to the SSID. Now what is supposed to happen is the 'cancel' button will turn into a 'done' button and the wireless icon will then appear showing that you are now connected to the SSID. This only happens sometimes and when it does it takes 30-60 seconds for the 'cancel' button to turn into the 'done' button.

I have tried changing every redirection option thinking that may be the problem but its the same problem every time. I'm not blocking any traffic outbound and I did a capture on our firewall and that shows nothing interesting happening with the AP. I have tested using 5 different iphones and ipads and they are all experiencing the same issue.

I talked to a support engineer and went through a bunch of different options and he pretty much came up empty. I'm out of ideas and wondering if anyone has came across this as well? 

Thanks. 
Photo of Tom

Tom

  • 5 Posts
  • 0 Reply Likes

Posted 4 years ago

  • 2
Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
I have a support call open right now for the exact same issue. In our case, turning off the "Success" page and just redirecting the user directly to a specific page works around the issue.

Note that you don't want to redirect to the originally requested page, as on iOS (and other) devices, this will be a test page that the device tries to reach to test for Internet connectivity (all you will see is a blank page with the word "Success!" at the top). This is referred to in iOS as CNA (Captive Network Assistance) - it's designed to make the user experience better by detecting the presence of a CWP and automatically displaying it, rather than waiting for the user to go into Safari and open a web page.

My belief at present is that the issue is one of timing. It seems from my testing that as soon as iOS receives the "Success" page from the CWP following login/acceptance/registration (depending on type of CWP), it tries again immediately to do the CNA "probe" to an external website. If the AP has not yet *quite* finished dismantling the captive portal filters and intercepts, this probe will fail - iOS then seems to have a (stupid) behaviour of waiting around 45 seconds before it tries again.

Another possible workaround (I am going to test today) is to use the option in the CWP to use the AP's DHCP server with a 10 second lease for the initial captive session. This might also workaround the issue, but it might make it worse.

What's interesting is that I don't see this problem at all customers (though I can reproduce it consistently in my lab) - this adds to the likelihood the issue is a timing-related one in some way.
Photo of Tom

Tom

  • 5 Posts
  • 0 Reply Likes
Thanks for the details, Robert. I'm glad I'm not the only one with this issue. I had a hard time finding any information on this. 

I would agree with your timing theory as I have seen it work correctly ( though I'm talking like 5% of the time) 

Your first workaround has worked for me as well so thanks for that. At least I have some place to go from here now. 

I'm using the AP DHCP server currently but not with a 10 second lease. Are you testing using the AP just for the captive portal session then have it get a new address from another dhcp server after the cwp login? 

If you can, let me know if you get anywhere with support. They pretty much said it was an iOS issue that I would need to work through after an hour of changing settings.  I do agree the behavior of iOS is causing this but it needs to be a configuration setting with the AP to get around it. I never had an issue like this using HP and Aruba's captive portals. 

Photo of Roberto Casula

Roberto Casula, Champ

  • 231 Posts
  • 111 Reply Likes
Yes, the intention is to have the AP dish out an IP address just for login/AUP acceptance/registration then the final IP address be served by a DHCP server on the LAN, but that could just as well be internal DHCP in the AP too - the CWP DHCP/DNS override is used only for the initial CWP process. Still haven't had a chance to test yet.

To be fair, I've had problems of various kinds with the interaction between captive portals and specific devices on many different vendors' equipment over the years - I don't particularly like CWP as a mechanism as it is prone to cause a lot of support overhead for an IT department. This is one of the reasons why PPSK is so popular.

Apple have "broken stuff" several times in the past. BlackBerries used to be appalling with CWP (not much better now I believe). The increasing use of HTTPS also causes problems (if your homepage is an HTTPS homepage, for example Company extranet, or even Facebook or Google now) - there's no way for the AP to intercept and redirect an HTTPS request (at least not without some messy DNS spoofing which causes other problems with certificates and DNS caching). Corporate devices with proxy servers configured were always a nightmare.

All this is why most operating systems now try to "detect" the presence of a captive portal and directly display it, rather than relying on the user to interact via the browser.
Photo of Haydn St

Haydn St

  • 17 Posts
  • 1 Reply Like
There is another workaround and its completely by chance we came across this. We too were having issues with it sitting on blank page with "Success" at the top.

If you simply try to scroll/swipe up or down the cancel changes to "Done" you can press this and it will connect to the SSID. Not very pretty work around but a work around none the less.