Not sure if anyone else has experienced this, but every once in a while, I will have an ePMP 1000 STA which is connecting to the AP, passing traffic normally, is accessible via http and SSH, but cannot be rebooted via the web GUI or SSH - the behavior is that hitting the reboot button in the GUI generates the normal dialog box warning that this action will affect connectivity, and it then appears to be rebooting, but the page comes back really quickly and the uptime shows that it didn't reboot. Using the "reboot" command in SSH returns a "Timeout: No Response from localhost" response, but you can still use other commands, like "show config" without errors.
Typically, these ATAs could be rebooted by cnMaestro if they had already been on-boarded, but...
I was awoken in the middle of the night the other night by my monitoring system - I have it set up to periodically poll our APs using SNMP for Ethernet port speed and GPS Sync, and both were reporting a problem for a certain ePMP2000 AP - I checked, and the SNMP daemon had crashed, but the actual values were fine, and my subs were not having any issues. But, when I tried to reboot the AP to reset the SNMP daemon, it acted in the way described above. I then attempted to use cnMaestro to reboot the AP, but it did not reboot. I re-tried the action several times, but no luck. Since this AP does not have an external power control (like a CMM, CTM, or SyncInjector/SiteMonitor), I feared I would have to drive to the AP to physically unplug it, but I tried again this morning, and even though the GUI and SSH attempts were still unsuccessful, the cnMaestro command did work this time.
So, is this a known bug (the AP is running 3.2 firmware, as are most of our subs)? Is there some other workaround if the obvious three methods fail to execute the reboot?
You know, we wouldn't have to ask questions like this if these problems and fixes were properly documented - in response to your comment (just to verify my sanity), I reviewed the release notes for 3.5.1, looking to see if I missed something important...
Here are all the SMNP mentions in Defect Fixes and Known problems:
Defect Fixes (System Release 3.5.1)
14839 SNMP MIB parameter sysLocation is not supported
14918 SNMP sysObjectID does not return Hardware SKU
Known Problems or Limitations (System Release 3.5)
14906 Unable to force Sector Antenna on ePMP2000 AP via SNMP.
Workaround: Use web management interface to force Sector Antenna
Known problems or limitations (System Release 3.2.2)
13846 It is not possible to change the SM’s Network configuration from Bridge to Router mode via
SNMP. (fixed in 3.3)
That's every one of the items which include a mention of SNMP. There is no mention of any "rogue SNMP issue" all the way back to the notes for release 2.4. To be sure, we'd observed the issue, but failing to document the bug and its eventual fix creates unnecessary problems for operators. We are reluctant to roll out the latest firmware version for pretty much every platform because of the high probability of bugs, some of which can have a major customer impact or require truck rolls, so we usually wait a while unless we need some new feature or a specific bug fix. Hiding your bug fixes means we don't know that you've fixed them. Just wanted to point that out.
You are absolutely right. Hopefully we can provide useful information regarding known issues that missed the release notes via this forum.
Here is a thread about the SNMP issue in 3.2.X.