In some cases it is possible for the management to become unresponsive, where settings that are issued either in the CLI or web interface, will not take affect and the status will not update. You may also notice a long timeout before getting a response from a CLI command or old status information. It is possible that something has caused a management process to crash, which makes it impossible to manage the radio.
Because the data traffic does not run through the CPU, this issue does not affect data traffic, but will require a reboot to solve the problem.
First, to check to see if this is actually the problem you're facing, from the CLI, please run the uptime command to check for the load average:
11:48:19 up 50 min, load average: 2.12, 1.97, 1.76
In the above example, the radio appears to be working normally. If the load average is near zero, that indicates that the management process is not running, or as we commonly refer to it, the command server has crashed.
08:04:34 up 19 days, 13:19, load average: 0.00, 0.00, 0.00
To restore the management ability, a reboot is required. Since the normal service that processes commands isn't running, a reboot command from the CLI-config node will not work. You will have to issues the command from the debug prompt.
If reboot does not work (you are told it is an invalid command), please use tg_reboot instead of reboot.
You may also power cycle the radio to restore the connection.
After a command server crash occurs, the reported status of the radio will remain unchanged. This includes SNMP data, which will no longer show fluctuations in RSSI, MSE, utilization, etc.
Please ensure that you are running the latest version of the firmware for your product if you are experiencing this problem. Also, alignment mode (if utilized) should be disabled as this command is not meant to be used for long periods of time and may contribute to this problem.