That's weird. When you do SSH into the AP, what is the value you see for the capwap server name? Is it correct, or is it just gone, or has it somehow been changed to an incorrect value? What version(s) of HiveOS are you running on these APs?
Has anything changed in your network topology around the time that this issue began occurring?
We would like to get more information, and have opened case 110515, and someone from our Aerohive Technical Assistance Center will be in touch with you.
The worrying thing is that this issue is not a new one. It looks to have been round for some years now yet I have found no cases here or on the web to show resolutions to the problem or potential fixes in the pipeline.
We are using the latest version of NG (cloud based) and the latest firmware for all the AP's and switches that have been affected.
Louis & all, I have several customer complaining about this behaviour and all the time they do SSL DPI Inspection at the firewall level. Once turned off, all APs get back online (capwap restart needed).
And after dong this, does the problem go away permanently or do they have to do this each time the CAPWAP connection fails?
I had customer with the same strange CAPWAP connection drops. After " dynamic airtime scheduling" has been turn off on policy all drops disappeared. All AP's has stable CAPWAP connection.