Showing results for 
Search instead for 
Did you mean: 

Access-Points randomly disassociate from WLC 5520

Joel Lallemand



After activating a monitoring policy on prime, we noticed that the AP's randomly disassociates from controller for a few minutes. After they associate again with the same controller. Only one AP at a time. No regularity can be determined, all aps are involved. Sometimes every 10 minutes a other one, then everthing runs good for 1 hour...During the disassociation, the involved switch shows nothing in the log, the physical link to the AP is always up. A routing problem can also be excluded, because we run several AP's at a location and only one AP is involved at a time.


We have the following infrastructure:


- 4 x 5520 Controller, v.8.10.162

- ~1500 Access-Points, different Models 1832, 2702, 2802

- local mode and flex connect mode

- several locations (~200) with several WAN-Links


Does anyone else notice this behavior? What can we do?


Thanks for your support.


Best regards - Joël




7 Replies 7

Leo Laohoo
VIP Community Legend VIP Community Legend
VIP Community Legend

What is the uptime of the AP? 

Try manually rebooting the AP.  
NOTE:  Do not instruct the AP to "reload".  Instead, kill the power of the AP by shutting the PoE.

Hi Leo


Thanks for your reply.

I'm going to try that and will write back soon.


Best regards


Hi rrudling


Yes, we checked the logs, but they contain no information:

Failure Source
undefined NaN, NaN, 12:NaN:NaN PM GMT-NaN:NaN
Generated By
Device IP Address


It's always the same error message. No Suspicious logs before and after the disassociation message.

It also seems to stop after killing the power of the ap, as Leo suggested. But i'm wondering for how long...

And that's maybe a solution for a small infrastructure but not for a big one.


it just surprises me that no one else has this problem?


That is not a controller log though!  I presume that is Prime?  When you say you "checked the logs" are you saying you looked at the logs on Prime or did you actually log into the WLC and check the logs on the WLC?

Quite possible others are not aware of the problem as you weren't before you started monitoring closely.

We only alarm if an AP goes down for more than 10 minutes for example.

Hi Rrudling


Your're right, this was a prime log. This is a controller log:


*apfReceiveTask: Dec 09 08:13:00.843: %LOG-4-Q_IND: capwap_ac_sm.c:8887 The system detects an invalid AP(dc:f7:19:08:e0:00) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination
*spamReceiveTask: Dec 09 08:12:58.152: %CAPWAP-4-INVALID_STATE_EVENT: capwap_ac_sm.c:8887 The system detects an invalid AP(dc:f7:19:08:e0:00) event (Capwap_configuration_update_request) and state (Capwap_dtls_teardown) combination
-Traceback: 0xb74ec2 0x9e2efb 0x84326c 0xae28c0 0x1187773 0x3ba6c07dff 0x7f834550239d
*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7126 dc:f7:19:08:e0:00: DTLS connection closed forAP 10:94:28:20 (5272), Controller: 10:129:27:5 (5246) Echo Timer Expiry
*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7871 Did not receive heartbeat reply; AP: dc:f7:19:08:e0:00


I'm not sure if this is maybe a time problem? After restarting the AP (shut down POE-Port), the AP is working properly. I'm not sure for how long.

@Joel Lallemand wrote:

*spamApTask4: Dec 09 08:12:58.152: %CAPWAP-3-ECHO_ERR: capwap_ac_sm.c:7871 Did not receive heartbeat reply; AP: 

Raise a TAC Case.  

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: