Wireless Access

Has anyone had trouble getting blackberries to work with Captive Portal Authentication hosted on the Aruba Controller?

My test blackberries are configured to notify about the available hotspot.  When directed to the Captive portal, the blackberries issue the below errors which suggest they have an issue with the URL:

"The protocol specified is not support by the handheld.  Please try a different URL" for blackberry 9800 running 6.0 version of the OS 

"Invalid Address: "https://securelogin.arubanetworks.com/upload/custom/Guest-Captive-Profile/cp.htm?cmd=login&mac=40:00:00:34:62:b2&ip=192.168.11.223&essid=CompanyAA&2DGuest%00%00%00%00%00%00&url=http%3A%2F%2Fwww%2Eblackberry%2Ecom%2Fselect%2fwifiloginsuccess%2F". for blackberry curve 8130

We are using a custom captive portal page that provides public access with just an Accept button.  We have also tested this with the default captive portal page, and an older authenticated captive portal setup working on ArubaOS 6.0.

We are currently running on Aruba 6000 with Aruba OS 6.1.3.

All other devices (PC/Mac laptops, iOS, Android) are working fine.

Any help is appreciated,

Thanks

Hello,

We ran into this after we upgraded to 6.1.3.0, we believe. Certain Blackberry OS's don't seem to like the redirection URL that the controller passes back to the device. We found BB OS 6 worked, while 5 and 7 don't. Also, we have one SSID that is a single character/letter that has the issue while another SSID that has 8 characters works fine on the BB.

Aruba/Amigopod TAC is doing some testing and investigating.

Thanks,
Bryan

We have also come across this issue with ArubaOS 6.1.3.0 and Amigopod providing the Guest Solution.  Initially I thought it was due to the SSL123 certificates we installed (which is a whole other story) but it does look to be down to something with the redirect.

Please update this thread if TAC does come back to you.

TAC said it will be fixed in 6.1.3.2.  The issue is:

"We found the root cause for this issue where the controller is adding variables to URL encoding which breaks the re-direction URL. We had raised this issue to Engineering team and this will fixed on 6.1.3.2 which is not yet released.
However,  we have a work around to increase the characters in the range of  2 + (n * 3) characters, e.g. "AB", "ABCDE", "ABCDEFGH".  This will make sure the URL encoded info lands on a complete %00 which is a valid URL encoded value."

So, it depends on the length of your SSID.  Our SSID that has one character has the problem, but another SSID that is 11 Chars long falls within the 2+(n+3) so that one works. 

Thanks Bryanc,

That solved our problem.  I also had a dash in the SSID which was causing problems even when the number of characters conformed with the formula (3*n)+2.  I tested with an 8 character SSID without a dash and it worked.  Doubting that it could be this simple, I added another character the the SSID (making it 9 chars) and tested again and it failed.   I'll test it again when they release 6.1.3.2.

Cheers,

One of our SSIDs has a dash in it also.  At first we couldn't figure out why this SSID worked because it added up to 9 characters.  Later, we learned that a dash gets URL encoded to something that counts as two characters, so their formula does apply.