I have 3 WiSMs two of them (WiSM-a and WiSM-b) are seated on the CORE1 switch (6509) and the WiSM-c is seated on CORE2 also a 6509 .
One of the controllers from WiSM-a/b keeps rebooting let's called it Con-1a and Con-2b reboots but usually more than the other one the controllers (WiSM located on CORE2 never reboot .
Both COREs have the same software code. The WiSM have been online for about a year with 18.104.22.168 version and they never rebooted until 3 months from now so a Cisco Tech suggested upgrading to 22.214.171.124 but it keeps doing it .
""IOS (tm) s72033_rp Software (s72033_rp-IPSERVICESK9_WAN-M), Version 12.2(18)SXF9, REL"
check the crash logs on the controller ... do these show anything?
It doesn't show anything , somebody suggested removing the service vlan from all the trunks but that didn't help .
Could SSH cause problems on the Wireless controllers ??
Hate to say it, but debugs are really Cisco TAC's specialty. Not a lot of forum users really know detailed debugs like what you're looking for.
What you have may well be a hardware issue that requires a replacement. I'd open a TAC case and see where it goes.
Sorry for not being able to help :/
We experienced exactly the same problem for months, driving us and Cisco crazy. The cause is an as yet unsolved ssh bug in all codes up to and including at least 126.96.36.199. Cisco told us we were almost the only user in the world having this problem, so I'm "glad" here's another victim. Try this workaround: enable an ACL in the controllers, blocking all ssh traffic (TCP port 22) from 'any' to the controller's interface in all VLANs associated to wireless clients.
How was this workaround discovered? It sounds like this bug could be a huge security issue! Have you tested whether or not ssh traffic from a wlan to the controller has an impact?
It took Cisco's TAC people months of studying several crash files and reproducing our configuration in their labs, and only the fifth (or so) patch at last worked. And speaking of security, we noticed many many ssh connections from the wired Internet to this controller port which apparently slipped through the firewall - you might call it a continuous DoS attack that every few weeks succeeds. So, a hole in our firewall revealed an obscure ssh bug in the controllers. Ssh connections from the WLAN did not seem to have any impact.
Logging in to the controller's console using ssh (instead of telnet) for management purposes. Usually you use http or manage controllers via the WCS, but some management commands can only be issued from the console. But then you connect to the controller's management IP address, never to its WLAN interface address, so shutting off this WLAN interface for ssh is shutting off something you don't need.