08-23-2011 10:13 AM
I can SSH into them and they appear to be functioning properly, but several of our tech support are only familiar with the web interface and GUI - checking for clients associated, checking AP status, etc.
Is there a CLI command to restart the web interface, or something I can do to troubleshoot why these few controllers are having this issue?
If it matters, these are 620 controllers running 220.127.116.11. I don't have this issue with other controllers running 18.104.22.168 and 22.214.171.124, so I'm a little confused about why it is just a handful of controllers.
08-23-2011 04:21 PM
Engaged.....although after 2-3 reboots, both of the
APs- sorry, I meant controllers seem to be working now.
Normally would have tried that first, but difficult when you have 20+ users that are working fine and are all considered "mission critical." :rolleyes:
08-23-2011 04:25 PM
Aruba Customer Engineering
Looking for an Answer? Search the Community Knowledge Base Here: Community Knowledge Base
08-24-2011 08:05 AM
Sorry, I meant controllers. I SSH'd in and reloaded the controllers after business hours.
1 controller was at 126.96.36.199 - users called in reporting connectivity issues. Appeared that 1 AP was offline. Since they were already complaining, and only had 3 connected users, I took that opportunity to upgrade to 188.8.131.52. After the upgrade the web interface would not come up. I SSH'd in and rebooted that controller twice with no result. After the second reboot I remembered the CLI for checking users and saw 7-8 connected users so I left it alone. AP still appears to be offline, so that will require further troubleshooting today.
The other controller was already at 184.108.40.206 from my previous upgrade marathon (8/12). That office called in complaining about coverage issues in the office. Having the commands fresh in my mind, I SSH'd in and found 14 users and all 4 APs online. They are a larger office and cannot be taken down during business hours. Since it's a coverage issue I'll just use Airwave and VisualRF to see where the problem is.
I've often seen posts where you (or other person) will give a CLI command to check something. I wasn't sure if there was a way to check the web service, or whatever controls the web interface.
Since I can't replicate the problem I'll just cancel the support case. Probably for the best since this is their response (my ticket is worded exactly as my original post):
1. Is this a wireless client or wired client?
2. If it is wired client is the port untrusted?
3. If it is wireless client which role the client is falling?
08-24-2011 09:13 AM
Yes, I did that as well as tried to access those 2 controllers from several different computers - my desktop (XP) - IE, Firefox, Chrome; my laptop (Win7) - IE & Firefox; Mac Mini (Safari); servers in both of the offices (win2003).
All of them returned that 403 forbidden error - web site requires you login but no page displayed.....or something to that affect. The wording in the different browsers is all different, but after looking them up the general meaning was that the website requires you to login, but the web server failed to deliver a login screen.
I originally thought it was because of the firmware upgrade, and the new certificate not being trusted, but I never had that problem with the other controllers - they all gave the prompt that the cert is untrusted, accept or deny.
I even tried entering the IP of the controller in the address bar, then the whole "http://" thing, then "https://" and even adding the :4343 - even though all that usually gets done automatically.
After being able to SSH into the controllers I thought maybe a service had failed and needed to be restarted.