+39 02 94750217 sales@tanaza.com

iOS 7 and captive portal: a guide to captive portal requirements

by | Oct 3, 2013 | All articles, Industry news, Public Hotspots | 0 comments

ios7 and captive portal

The release of iOS 7 created a lot of issues to captive portal technology providers, splash pages designers and hotspots in general.

Apple changed completely the way any iPhone performs the test to see if the device is connected behind a Captive Portal, so most implementations stopped working. Here in Tanaza, we collected all the devices we had in our lab, as well as in the neighbours startups, and decided to spend one entire day to perform tests. We now are happy to share what we discovered in this knowledge base article, summarized in the following.

 

Captive Portal automatic detection, avoid login popups

 

1. Scenario

 

When “Captive Portal” functionalities (alias “External Splash Page” in the Tanaza configuration) are enabled on an SSID , the access point filters all the requests sent by a client and allows/ denies the user access to internet based on a policy defined on the splash page.

In this scenario, what happens is that when a user connects to that specific SSID, no matter what site he is asking for, he will be redirected to the splash page defined in the Tanaza configuration.

Since the user is not aware that he is not allowed access the internet, unless he opens a browser and tries to surf, all the Operative Systems (desktop and mobile ones) have developed a strategy through which they find out if they are behind a captive portal.
In case when they detect a captive portal a popup like brower is started asking the user to login to the captive portal.

 

2. Problem

 

These popup like brower can have some limitations (cookies not enabled, javascript disabled, anonimous session) and usually do not allow the user to experience a splash page correctly.

The best thing to do is to avoid these limited browsers to pop up, forcing the user to use a simple browser to access the splash page.

Another problem is that every Operative System (Windows, Macintosh, Android, iOs, …) has a different way of detecting the captive portal, making it difficult to disallow these limited browsers.

Apple changed the way any iPhone works with Captive Portals, so most wifi implementations stopped working
click to tweet

 

3. Solution

 

To solve this issues, Tanaza offers an easy way to configure a captive portal, allowing to skip “Captive Portal automatic detection” for all kinds of Operative Systems. Therefore, allowing the customer to be sure that the user accesses the splash page with a fully featured browser, to allow cookie storing and javascript functionalities.

In the configuration section for SSID, next to the social login sets, you can find this button:

 

no popupsNO POPUPS

 

Clicking this button, your walled garden configuration will be filled by all the domain names that are needed to be white listed to avoid the login popups.

Currently, this domain name set avoids login popups for the following O.S.:

  • Windows Desktop O.S.
  • iPhone 4/5 with iOS 6/7
  • Android

 

hostnames captive portal

 

In the next picture, the walled garden configuration after the “Captive Portal automatic detection” is enabled.

 

cap2

 

In the following section, you can find out to which O.S. each domain name is linked.

 

More details: Base captive portal auto detection strategy

 

All the O.S. use the same strategy to find out if they are behind a captive portal. Usually, they try to connect to well-known internet URL, of which they know the content.

If the wifi connection is up and running and the client is connected correctly to an SSID, if this well-known page cannot be downloaded, the O.S. suspects to be behind a captive portal.

 

Here is the list of all the different domains checked by the different O.S. types and version:

 

Android Captive Portal Detection

Domain names to white list:

  • clients3.google.com

 

iOS for iPhone

iPhone is more complicated, since it uses many different domain names, maybe for load balancing. It also changed its strategy using different domain names through different O.S. versions.

 

iOS 6

Domain names to white list:

  • gsp1.apple.com
  • *.akamaitechnologies.com
  • www.apple.com
  • apple.com

 

iOS 7

Domain names to white list:

  • www.appleiphonecell.com
  • *.apple.com
  • www.itools.info
  • www.ibook.info
  • www.airport.us
  • www.thinkdifferent.us
  • *.apple.com.edgekey.net
  • *.akamaiedge.net
  • *.akamaitechnologies.com

 

Windows Desktop O.S.

Domain names to white list:

  • ipv6.msftncsi.com
  • ipv6.msftncsi.com.edgesuite.net
  • www.msftncsi.com
  • www.msftncsi.com.edgesuite.net
  • teredo.ipv6.microsoft.com
  • teredo.ipv6.microsoft.com.nsatc.net