03-29-2010 06:47 AM
Our Help Desk is getting reports of "sluggish" redirects to the CP page on our open SSID. Help Desk seems to think this occurs in Firefox but not in IE.
Doing a quick test on my own Dell (after clearing cache and restating browsers) it does appear that the redirect takes several seconds longer to load since I upgraded to Firefox 3.6 than it used to in Firefox 3.0x. IE appears to still load immediately.
Is anyone else seeing this? Any thoughts about why or thoughts on a fix?
03-29-2010 08:24 AM
You should break this down into components. Even better, instead of opening a browser that goes somewhere, open a blank browser page, then put in the ip address of the Captive Portal so it doesn't do any DNS lookup and check the speed to see if it is the same.
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
Validated Reference Design Guides : http://community.arubanetworks.com/t5/Validated-Reference-Design/tkb-p/Aruba-VRDs
03-30-2010 05:58 AM
We are running ArubaOS 126.96.36.199. Last night the Help Desk logged a dozen t-tickets all claiming that Firefox 3.6.2 browsers were very slow to redirect, often timing out. On these same clients they reported that Internet Explorer worked fine (this is currently their workaround).
Clearing cache and browsing to the CP URL directly (no DNS games) loads the page immediately. When testing the redirect under normal redirect circumstances I notice that the URL is displayed at the bottom of the browser immediately but it takes several second to actually load the page, right on the hairy edge of the browser timing out.
I did restart the httpd process on the controller, which actually caused a system reboot (I assume this was unintended). Made no difference.
Switch uptime is 11 hours 54 minutes 13 seconds
Reboot Cause: Nanny rebooted machine - httpd_wrap process died.
Any advice, relevant show commands or things to look for in the logs would be appreciated.
I plan on opening a TAC case as soon as we can verify the browser version in additional tickets and complete more in-house testing.
03-30-2010 11:08 AM
I ran into the same thing this morning and think I may have found a solution. You may want to test whether your issue is related to OCSP by going to the Firefox menu Tools>Options>Advanced, selecting the Encrryption tab and then the Validation button. Uncheck the "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates" box and try loading the captive portal. From what I can tell, IE apparently doesn't check by default and Safari makes a best effort to check but doesn't take very long to give up and accept the certificate.
The workaround I'm using right now is to use a policy to allow all the IP addresses associated with my OCSP provider, since I couldn't figure out how to allow by hostname, and add that at the top of the list of policies in my captiveportal user role. It was a pain since there are multiple hosts that reply to the nslookup for the host name (ocsp.verisign.net in my case) but I did not want to allow access to the entire subnet (although that would work too). Hope this helps!