IOS 6 issues



  • I noticed problems with iOS 6 too. I have a basic Captive portal setup on pfSense (2.0.2-RELEASE (i386) built on Fri Dec 7 16:30:25 EST 2012 FreeBSD 8.1-RELEASE-p13), installed on Intel D2500CCE with 4 GB CF card.

    When connecting to my WI-FI network with an iOS 5 device (iPad), the "crippled" browser with my captive page is shown. Once I press the login button, this browser redirects me to apple.com and Internet becomes accessible to device.

    But if I connect using iPhone with iOS 6, pressing the button produces popup stating: "Error opening page - Hotspot login cannot open the page because it is not connected to the Internet." When clicking OK and clicking captive's login button again, another popup is shown, but this time with a different message: "Error opening page - Hotspot login cannot open the page because the server cannot be found." If I open Safari afterwards (or any other application connecting to the Internet), everything works normally with full Internet access.

    What is causing this behaviour, is this a known iOS 6 bug? Is there any way to prevent these popups? I tried adding apple.com to Allowed Hostnames without success (if I understand this correctly, http://www.apple.com/library/test/success.html attempts to be accessed by an iOS device when determining Internet accessibility).

    Beside this, I would also like to know if there is some more universal way to "trick" a device into thinking that Internet is available once the user selects a WI-FI hotspot, and only when a browser opens, Captive login page is shown? The best solution for me would be to be able to do this for any device/OS. Should I add certain IPs/hostanems to Captive's Allowed IP Addresses/Allowed Hostanems, and which ones, if so?

    I'm sorry if the above questions were already answered, but after some searching I haven't found anything helpful.

    I would be grateful for any explanations/directions or hints.

    Best regards,

    elektroljub



  • The "allowed hostnames" feature (also known as "walled-garden") won't work very well with sites like Google, Apple that resolve to many different IPs and/or use Akamai.

    When I was testing pfsense's CP interaction with various popular devices some time ago, I solved this particular issue you describe by doing an internal redirect of Apple's success page (modifying pfsense's lighttpd config file to serve the file locally).



  • @dhatz:

    The "allowed hostnames" feature (also known as "walled-garden") won't work very well with sites like Google, Apple that resolve to many different IPs and/or use Akamai.

    When I was testing pfsense's CP interaction with various popular devices some time ago, I solved this particular issue you describe by doing an internal redirect of Apple's success page (modifying pfsense's lighttpd config file to serve the file locally).

    Hi, thank you for your quick reply!

    After some searching I found out that lighty configuration file is generated at boot, by the /etc/inc/system.inc script (http://doc.pfsense.org/index.php/Limiting_access_to_web_interface).

    So if I want this redirect to persist across reboots, I must modify /etc/inc/system.inc script. Unfortunately I don't have any idea what exactly should be changed/added to system.inc. Is there perhaps a way to achieve this via the web GUI?

    I would be very happy to see an example on how to do this, but I haven't found many relevant info on the Internet. Could you please provide me such example?

    Thanks again, best regards,

    elektroljub



  • Hi,

    I found out that this file should be served inside a lighttpd document root, i.e. /usr/local/www/. So I should create a path to this file, like this: /usr/local/www/library/test/success.html and redirect any device that requests http://www.apple.com/library/test/success.html to it.

    I'm quite new to pfSense and unfortunately still don't have a clue how to modify lighttpd.conf (which, at least under this name, doesn't exist on pfSense). As mentioned in my previous post, if I understand things correctly, lighttpd configuration is generated at boot time by /etc/inc/system.inc script which has to be modfied to include this redirection. It seems that I'm stuck here, could someone please provide me some guide/example on how is this redirection actually done? I searched the pfSense documentation, but haven't found anything that would answer my particular question.

    Any help or hint is greatly appreciated,

    best regards,

    elektroljub



  • Indeed you'll need to change system.inc which will in turn create the respective lighttpd config file for CP.

    Quoting from my 1+ year old notes on the subject (version 2.0), you'll need to change it to something like:

    $captive_portal_rewrite = "url.rewrite-once = ( "^/library/test/success.html$" => "/apple-success.html", "(.*captivep..



  • @dhatz:

    Indeed you'll need to change system.inc which will in turn create the respective lighttpd config file for CP.

    Quoting from my 1+ year old notes on the subject (version 2.0), you'll need to change it to something like:

    $captive_portal_rewrite = "url.rewrite-once = ( "^/library/test/success.html$" => "/apple-success.html", "(.*captivep..

    Hi,

    thank you for your answer.

    Here is another thing that I noticed: as mentioned in my first post, I was testing Captive portal with 2.0.2 version. I downgraded pfSense to 2.0 today and the error popups on iPhone running iOS 6 don't appear any more; Captive login page opens inside the "crippled" browser and upon clicking the login button, I'm redirected to Apple's success.html. After this, the Internet is accessible to device. So this problem must be 2.0.2 related.

    However, I still don't know how to do an internal redirect. After looking to system.inc file, there are a couple of PHP functions - where exactly should I put the line you provided? I also don't understand why do you have apple-success.html, shouldn't be this simply http://www.apple.com/library/test/success.html?

    I'm sorry for my noobish questions, but I'm quite lost here. My "simple" goal is to "trick" all kinds of popular devices/operating systems (Linux, Windows, Android, OS X, iOS,…) into detecting as they have a full Internet access, until a browser is opened; then (or after clicking a link to a non-cached page) they should be presented with a Captive portal page. It seems that this is not so easy to achieve after all.

    Best regards,

    elektroljub



  • Hi,

    I've been fiddling about with this issue too with my two IOS devices.
    My custom captive portal (CP) is working fine on the macbook, but still not on IOS6.
    On IOS6, upon connecting to the WiFi, a hotspot login page slides up from the bottom, if safari cannot reach the site www.apple.com/library/test/success.html
    The solution proposed by dhatz is to make safari believe it can reach above site by redirecting to a local file providing the same response.
    You can achieve the same result by adding "www.apple.com" to the allowed hostnames under Services > Captive Portal, Allowed Hostnames tab, field Hostname.
    However, if the hotspot login page does not pop up anymore, you will need to authenticate with Safari. If you open e.g. App Store before authenticating,
    an error message will be shown "Cannot connect to iTunes Store".

    Coming back to your question about how to do an internal redirect:
    Connect to your pfSense box via SSH (instructions on how to set up SSH see here: http://doc.pfsense.org/index.php/HOWTO_enable_SSH_access
    Modify the system.inc file and add an additional rule.
    The filesystem is mounted as read-only, so we have to remount it as read-write. See http://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write

    /etc/rc.conf_mount_rw
    cd /etc/inc
    vi system.inc
    

    Enable line numbers in vi (:set nu)
    Line 741 contains the following: $captive_portal_rewrite = "url.rewrite-once = ( "(.captiveportal.)" => "$1", "(.*)" => "/index.php?redirurl=$1" )\n";
    There are two rules, separated by comma: ("<regex>" => "<relative-uri>")
    It basically means: If the webserver receives a request which matches the regular expression => redirect to the new target.
    For a description on what url.rewrite-once does, see the Lighttps wiki under http://redmine.lighttpd.net/projects/1/wiki/Docs_ModRewrite

    We now want to store locally what ever we would get under www.apple.com/library/test/success.html. dhatz is proposing to store it as a file
    named "apple-success.html". Name it to your liking, but it should contain the following: <title>Success</title>Success, and the new rewrite rule must match the filename.

    We can upload the file via WebGUI, Services > Captive Portal, File Manager tab.
    pfSense will rename the file automatically to "captiveportal-apple-success.html", store it in /var/db/cpelements/ and create a symlink with the same name in /usr/local/captiveportal/

    Now let's add our new redirect rule as the first of the three, so that it reads as follows:
    $captive_portal_rewrite = "url.rewrite-once = ( "^/library/test/success.html$" => "/captiveportal-apple-success.html", "(.captiveportal.)" => "$1", "(.*)" => "/index.php?redirurl=$1" )\n";

    Save the file and exit vi with ":x", remount the filesystem as readonly (/etc/rc.conf_mount_ro) and exit ssh.

    pfSense will now trick the IOS6 devices and pretend to have an internet connection. There will be no hotspot login page, unless you misspelled the rule or the filename, then the hotspot login page will still slide up from the bottom, but show a "404 - Not Found" error.

    Hope that helps
    Best regards
    regonius</relative-uri></regex>



  • @regonius:

    Hi,

    I've been fiddling about with this issue too with my two IOS devices.
    My custom captive portal (CP) is working fine on the macbook, but still not on IOS6.
    On IOS6, upon connecting to the WiFi, a hotspot login page slides up from the bottom, if safari cannot reach the site www.apple.com/library/test/success.html
    The solution proposed by dhatz is to make safari believe it can reach above site by redirecting to a local file providing the same response.
    You can achieve the same result by adding "www.apple.com" to the allowed hostnames under Services > Captive Portal, Allowed Hostnames tab, field Hostname.
    However, if the hotspot login page does not pop up anymore, you will need to authenticate with Safari. If you open e.g. App Store before authenticating,
    an error message will be shown "Cannot connect to iTunes Store".

    Coming back to your question about how to do an internal redirect:
    Connect to your pfSense box via SSH (instructions on how to set up SSH see here: http://doc.pfsense.org/index.php/HOWTO_enable_SSH_access
    Modify the system.inc file and add an additional rule.
    The filesystem is mounted as read-only, so we have to remount it as read-write. See http://doc.pfsense.org/index.php/Remount_embedded_filesystem_as_read-write

    /etc/rc.conf_mount_rw
    cd /etc/inc
    vi system.inc
    

    Enable line numbers in vi (:set nu)
    Line 741 contains the following: $captive_portal_rewrite = "url.rewrite-once = ( "(.captiveportal.)" => "$1", "(.*)" => "/index.php?redirurl=$1" )\n";
    There are two rules, separated by comma: ("<regex>" => "<relative-uri>")
    It basically means: If the webserver receives a request which matches the regular expression => redirect to the new target.
    For a description on what url.rewrite-once does, see the Lighttps wiki under http://redmine.lighttpd.net/projects/1/wiki/Docs_ModRewrite

    We now want to store locally what ever we would get under www.apple.com/library/test/success.html. dhatz is proposing to store it as a file
    named "apple-success.html". Name it to your liking, but it should contain the following: <title>Success</title>Success, and the new rewrite rule must match the filename.

    We can upload the file via WebGUI, Services > Captive Portal, File Manager tab.
    pfSense will rename the file automatically to "captiveportal-apple-success.html", store it in /var/db/cpelements/ and create a symlink with the same name in /usr/local/captiveportal/

    Now let's add our new redirect rule as the first of the three, so that it reads as follows:
    $captive_portal_rewrite = "url.rewrite-once = ( "^/library/test/success.html$" => "/captiveportal-apple-success.html", "(.captiveportal.)" => "$1", "(.*)" => "/index.php?redirurl=$1" )\n";

    Save the file and exit vi with ":x", remount the filesystem as readonly (/etc/rc.conf_mount_ro) and exit ssh.

    pfSense will now trick the IOS6 devices and pretend to have an internet connection. There will be no hotspot login page, unless you misspelled the rule or the filename, then the hotspot login page will still slide up from the bottom, but show a "404 - Not Found" error.

    Hope that helps
    Best regards
    regonius</relative-uri></regex>

    Hi,

    thank you for your most detailed explanation, it was most helpful.

    I followed your steps, tested both the internal redirect and the walled garden approach, both solutions work perfectly as they should. I'm aware of the limitation you mentioned; opening any other application than Safari (e.g. the App store, that you mentioned), that requires Internet access, results in errors when attempting to connect.

    I added apple.com to Captive's Allowed hostnames in the first place, which didn't work; I didn't know that I should add www.apple.com instead.

    Thank you very much for your kind help,

    best regards,

    elektroljub


Log in to reply