08-22-2011 09:52 AM
08-23-2011 08:57 AM
May want to look at upgrading your firmware. The fix that I experienced at a customer site was included in 18.104.22.168.
09-12-2011 08:53 AM
I turned on user-debug and every log entry looks the same when it works and when it doesn't.
09-13-2011 01:40 AM
Any advice for ipad with Captive Portal.
09-13-2011 01:28 PM
might be related to the auto login feature on the iOS devices. Something
about the user failing to cache "login" information during that initial
login screen, then the device disconnecting from the SSID instead of
staying connected to allow the user to re-attempt login via Safari
(or any other iOS browser).
This login "mode" apparently can be disabled using DNS trickery (polluting
your /etc/hosts file, hijacking apple.com in your DNS server's info, etc. -
there's some notes at http://www.cloudpath.net/workaround_iphone.php)
but as the CP is already doing it's own redirection once the user has attempted TCP
connections ... I think this should be do-able completely within the CP framework (maybe).
If the iOS device is trying to get a "success" result when it goes to
http://www.apple.com/library/test/success.html ... it's simple
enough to add a "success.html" file to the CP files and return that. I'm not
sure how to do the filesystem trickery with the CP files, though. If I had
control/access of this directory normally, I'd either create those directories
or create loopback symlinks so that both ./library and ./test pointed to the
Is it possible to construct a custom redirection rule within a CP configuration?
Or will the CP pop off all references to directories and simply return the
"success.html" file as though it were placed within "/library/test/" ??
This *might* correct this disconnect behavior that seems to be showing up
in the iOS platform.
09-13-2011 01:49 PM
tricks that I would normally do within the filesystem could *possibly*
be done using a CGI written as the login page?
I'm not really sure what happens when you try to access a page that
doesn't exist in a directory that also doesn't exist, but the login page
would be where you're redirected in almost all pre-login cases. A bit
of CGI scripting there could check the requested URL and return the
contents of the success.html file when it's warranted.
Unfortunately, I've never had a need to write a CGI within the captive
portal framework and I'm not even sure if this method is possible either.
09-13-2011 03:41 PM
If you are currently using ArubaOS 6.1 and above, you can try the following:
netdestination www.apple.com <----In ArubaOS 6.1 you can create an alias that points to a www
ip access-list session apple-cp <---- We can then create an ACL to permit all traffic to www.apple.com
user alias www.apple.com svc-http permit
ip name-server 22.214.171.124 <------- Configure a DNS server or two that the controller will use to resolve www addresses
ip name-server 126.96.36.199
ip domain lookup <------- Turn on DNS resolution
ip domain-name arubanetworks.com <------------ Set a domain for your controller (this can be anything, frankly)
user-role guest-logon <----------- Add the newly created access list to your captive portal initial role in position 1.
ip access-list session apple-cp position 1 <-----This will allow all http traffic to www.apple.com so that frame will not come up.
There is a "show firewall dns-names" command that will show what dns names resolve to that will be added in ArubaOS 6.2:
(host) # show firewall dns-names
FW DNS names
Name Id InUse List
---- -- ----- ----
ocsp.usertrust.com 1 1 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124
yahoo.com 2 1 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 126.96.36.199 188.8.131.52 184.108.40.206 220.127.116.11 18.104.22.168 22.214.171.124 74.6.1
www.apple.com 3 1 126.96.36.199 188.8.131.52 184.108.40.206
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
09-13-2011 04:04 PM
but we're using the same sort of approach to allow that traffic through
(and manually updating the netdestination list). I had been hoping to
exploit the redirection capabilities to:
not pass needless traffic and
not pass unwanted traffic (since Akamai hosts a LOT of content
My last "trick" method is one that I'm not really willing to try given that
my student population returns tomorrow ... but I had t...
09-16-2011 11:21 AM
One caveat I have discovered is that this now breaks the functionality of an app that requires network connectivity automatically launching the CP and then closing it after authentication. i.e. If I launch Flipboard with this workaround in place, it presents a connection error (when I am still in the guest logon role). Before, when the CP randomly works and randomly doesn't, the "crippled" browser displaying the CP would pop-up.
I assume this is because with the workound the iPad2 can now reach http://www.apple.com/library/test/success.html and doesn't think you need to popup a CP. Essentially - it's one problem solved and a new one created :)