The heavy CAPWAP losses combined with your other issues sounds like latency on the backend network. We can confirm this is the case with your CAPWAP issues by enabling CAPWAP debugs, waiting for the issue to happen again, and pulling tech data. My best guess is that we're missing echo packets.
The HiveManager and the APs have a call and response check-in system that allows them to confirm that each side of the connection is still responsive; these call and response packets are called echos. There is a specific time window within which an AP would need to respond to an echo to be considered still responsive. If the AP misses a certain number of echos back to back, it is considered disconnected until it responds again. If an AP is still connected to the internet and passing traffic while missing echos, it's likely due to latency on the network; the AP is unable to process the echo request quickly enough due to the amount of traffic it has to process before responding.
To confirm all of this, please SSH in to the AP and run the following CAPWAP debugs:
CAPWAP debugs:
_debug capwap info
_debug capwap basic
_debug capwap stat
These will be erased if the AP reboots. You can also manually disable these at any time by adding "no" to the start of the command; for example "no _debug capwap info".
Then wait for the device to disconnect from the HiveManager and reconnect, then pull tech data. This guide reviews how to get tech data in HiveManager Classic- https://thehivecommunity.aerohive.com/s/article/How-to-download-tech-data-in-Classic
If you'd like to send the tech data to me directly, my email is communityhelp@aerohive.com.
