Using Apple Products with Captive Portal

laoistom

Sounds simple. Apologies however for how stupid this may sound but I can't find a section in Captive Portal Config to Whitelist a website. Any hints on where I would find it.

laoistom

Ok folks I was just tired and stupid. I used the allowed hot name section to whitelist www.apple.com but no joys. Anyway I've another branch to this question. Is the captive portal feature in the latest release of pfsense a complete implementation?? Is there a captive portal 2.0 on the way that will better handle the likes of mobile devices and such.

doktornotor

Sorry, but once again, Apple is simply retarded. And getting way more retarded lately, read about the CP "improvements" in iOS7.

This is a completely wrong place to complain, plus not exactly something to be fixed in pfSense.

laoistom

Ok point taken. Bitten fruit are poxy at best.

Explain to me then when Alcatels captive portal in the same network as my newly added pfsense box allows all traffic from all apps.

It's probably some firewall rule that the I'd not visible to is. Regardless it needs sorting.

Guest

people who apply the "retarded" label to a corporation seem… retarded.

deltix

There is a workaround for Apple "improvements".

After googling and reading some forums I came across this

http://forum.daviddarts.com/read.php?9,8879,8910#msg-8910

https://github.com/PirateBox-Dev/PirateBoxScripts_Webserver/blob/stable/piratebox/piratebox/www/library/test/success.html

I don't have Apple product on hand, but I changed Firefox useragent to emulate it and got it working.

What I did is that I inserted right below

expire.url = (
				"" => "access 50 hours",	
        )

EOD;

the following code into /etc/inc/system/inc starting at line 1121

$lighty_config .= "\$HTTP[\"useragent\"] =~ \"CaptiveNetworkSupport\" {\n";
$lighty_config .= "server.document-root =  \"/usr/local/www/library/test/\"\n";
$lighty_config .= "index-file.names        = ( \"success.html\" )\n";
$lighty_config .= "dir-listing.activate    = \"disable\"\n";
$lighty_config .= "server.error-handler-404 = \"/success.html\"\n";
$lighty_config .= "}\n";

This is not maybe 100% correct place and code can be more elegant, but I'm not PHP coder and this is the only way I was able to get it working.

Also, you have to create /usr/local/www/library/test/success.html


<title>Success</title>

Success

When CP enabled, I would get regular CP authentication page if I use default useragent. When I change useragent to CaptiveNetworkSupport I would get success.html page.

Can somebody look into this solution, test it, fix code and maybe if that turns to be ok submit it as bug or feature. As I said, I'm not coder.

Gertjan

Strange.

Running a hotel. See many devices - also the "fruit" related. I even use an iDevice to the test portal - and all AP's ….
I never had any problems, this one, 2.1.2-RELEASE or even the older ones (1.x.x series).
I just checked, and I have NO url's like www.apple.com white listed.
Please note that iOS checks if it has a "Internet connexion" by hittin a site and it isn't always "www.apple.com" that's being used (it was before). Other urls are also used tested.

So, I conclude that there must be another reasons if iDevices wont take the portal as any other WiFi device.

Btw: the portal interface was always present in pFSense, as pfSense is derived from M0n0Wall, several years ago.

deltix

@deltix:

There is a workaround for Apple "improvements".

After googling and reading some forums I came across this

http://forum.daviddarts.com/read.php?9,8879,8910#msg-8910

https://github.com/PirateBox-Dev/PirateBoxScripts_Webserver/blob/stable/piratebox/piratebox/www/library/test/success.html

I don't have Apple product on hand, but I changed Firefox useragent to emulate it and got it working.

What I did is that I inserted right below
expire.url = (
				"" => "access 50 hours",	
        )

EOD;
the following code into /etc/inc/system/inc starting at line 1121
$lighty_config .= "\$HTTP[\"useragent\"] =~ \"CaptiveNetworkSupport\" {\n";
$lighty_config .= "server.document-root =  \"/usr/local/www/library/test/\"\n";
$lighty_config .= "index-file.names        = ( \"success.html\" )\n";
$lighty_config .= "dir-listing.activate    = \"disable\"\n";
$lighty_config .= "server.error-handler-404 = \"/success.html\"\n";
$lighty_config .= "}\n";
This is not maybe 100% correct place and code can be more elegant, but I'm not PHP coder and this is the only way I was able to get it working.

Also, you have to create /usr/local/www/library/test/success.html
<title>Success</title>

Success
When CP enabled, I would get regular CP authentication page if I use default useragent. When I change useragent to CaptiveNetworkSupport I would get success.html page.

Can somebody look into this solution, test it, fix code and maybe if that turns to be ok submit it as bug or feature. As I said, I'm not coder.

This is cleaner version. I forced myself to read through some stuff about PHP.

Replace this

	$lighty_config .= << <eod<br>## error-handler for status 404
#server.error-handler-404   = "/error-handler.html"
#server.error-handler-404   = "/error-handler.php"

## to help the rc.scripts
server.pid-file            = "{$g['varrun_path']}/{$pid_file}"

## virtual directory listings
server.dir-listing         = "disable"

## enable debugging
debug.log-request-header   = "disable"
debug.log-response-header  = "disable"
debug.log-request-handling = "disable"
debug.log-file-not-found   = "disable"

# gzip compression
compress.cache-dir = "{$g['tmp_path']}/lighttpdcompress/"
compress.filetype  = ("text/plain","text/css", "text/xml", "text/javascript" )

{$server_upload_dirs}

{$server_max_request_size}

{$fastcgi_config}

{$cgi_config}

{$captive_portal_mod_evasive}

expire.url = (
				"" => "access 50 hours",	
        )

EOD;</eod<br>

with this


	$lighty_config .= << <eod<br>## error-handler for status 404
#server.error-handler-404   = "/error-handler.html"
#server.error-handler-404   = "/error-handler.php"

## to help the rc.scripts
server.pid-file            = "{$g['varrun_path']}/{$pid_file}"

## virtual directory listings
server.dir-listing         = "disable"

## enable debugging
debug.log-request-header   = "disable"
debug.log-response-header  = "disable"
debug.log-request-handling = "disable"
debug.log-file-not-found   = "disable"

# gzip compression
compress.cache-dir = "{$g['tmp_path']}/lighttpdcompress/"
compress.filetype  = ("text/plain","text/css", "text/xml", "text/javascript" )

{$server_upload_dirs}

{$server_max_request_size}

{$fastcgi_config}

{$cgi_config}

{$captive_portal_mod_evasive}

expire.url = (
				"" => "access 50 hours",	
        )

\$HTTP["useragent"] =~ "CaptiveNetworkSupport" {
server.document-root =  "/usr/local/www/library/test/"
index-file.names        = ( "success.html" )
dir-listing.activate    = "disable"
server.error-handler-404 = "/success.html"
}

EOD;</eod<br>

laoistom

I've tested the solution above and while it works for a success page redirection it doesn't work for allowing the likes of Facebook, Youtube or twitter apps on iOS devices. Looks like i'll have to wait for an apple "update" to hopefully do something that fixes this.

Cheers for the help guys
TQ

deltix

@laoistom:

I've tested the solution above and while it works for a success page redirection it doesn't work for allowing the likes of Facebook, Youtube or twitter apps on iOS devices. Looks like i'll have to wait for an apple "update" to hopefully do something that fixes this.

Cheers for the help guys
TQ

This solution is not intended to fix your Facebook problem. It is workaround for Apple's "CP improvements" as described on many other forums as well as here before. Maybe I hijacked your thread with this, sorry. I don't use/own Apple products, so I cannot test anything, but if you do some packet capture and post it here maybe we can come up with some solution.