Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 
Community Member

CAPWAP: Retransmission count for packet exceeded

We are noticing that WLAN-APs with HREAP-setup are jumping between different remotely located WLCs.

The APs are LAP1131 and LAP1242 with IOS 12.4(21a)JHC and WLC 4402-50-K9 with 6.0.202-image

All starts with the following Log-entries in the WLAN-APs:

*Jan 24 08:22:50.036: %CAPWAP-3-ERRORLOG: Retransmission count for packet exceeded max (CAPWAP_ECHO_REQUEST., 1)

*Jan 24 08:22:50.036: %LWAPP-3-CLIENTEVENTLOG: Switching to Standalone mode


*Jan 24 08:22:50.040: %DTLS-5-SEND_ALERT: Send WARNING : Close notify Alert to

*Jan 24 08:22:50.088: %WIDS-6-DISABLED: IDS Signature is removed and disabled.

*Jan 24 08:22:50.090: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY

*Jan 24 08:23:00.093: %CAPWAP-3-ERRORLOG: Selected MWAR 'SGOTWLC03'(index 1).

Who can tell me the reason for this behaviour ?

Is it possible to tune the CAPWAP-parameter retransmission count ?

Thanks in advance


Everyone's tags (2)
Hall of Fame Super Silver

CAPWAP: Retransmission count for packet exceeded

Do you have a primary, seconday and or tertiary wlc configured on each of these h-reap ap's?  It looks like the ap lost connectivity to the wlc it's primary to and moves to either the secondary or tertiary.  Do you have ap fallback enabled on the wlc's also to force the h-reap ap to move back to the primary wlc?  Do you have network connectivity still when these h-reap ap's move and what is the ping times between the h-reap ap and teh wlc's?

*** Please rate helpful posts ***
Community Member

CAPWAP: Retransmission count for packet exceeded

Hi Scott Fella,

thank You for Your answer. Yes the APs are configured with a primary and a secondary WLC and the WLCs are configured with "AP Fallback" enabled.

During the jumping of the WLAN AP, the radio-interfaces are shutdown obviously and we loose the WLAN clients, several barcode-scanners in a factory of the customer.

Any idea how we debug the CAPWAP-protocol ?

Is there a possibility to prioritze the CAPWAP-protocol on the Cisco-Router WAN-links ?

Hall of Fame Super Silver

Re: CAPWAP: Retransmission count for packet exceeded

There are various debuts you can run from the CLI. You can debug the ap and various others. If you want to prioritize capwap traffic, you can, just need to setup QoS on the wan or capwap protocol


Scott Fella

Sent from my iPhone

*** Please rate helpful posts ***
Community Member

Re: CAPWAP: Retransmission count for packet exceeded

Going to try to answer this a different way for anyone Googling this who needs an answer.

"Is it possible to tune the CAPWAP-parameter retransmission count?"

Yes. See here:

Browse to your WLC.

Choose "Wireless" from the top bar.

Under "Access Points" on the left, choose "Global Configuration."

In the main panel off to the right you will see "AP Retransmit Config Parameters" with 2 options: "AP Retransmit Count" and "AP Retransmit Interval."

AP Retransmit Count is how many times it will try to contact a WLC before failing. Maximum is 8.

AP Retransmit Interval is how long between each try. Maximum is 5.

(AP Retransmit Count) * (AP Retransmit Interval) = How long the AP can go without talking to a WLC, in seconds.

If you are using FlexConnect Local Switching and FlexConnect Local Auth, the AP SHOULD still be able to handle clients during this timeframe.

When an AP cannot contact a WLC...

Step 1.) When the retransmit count (max 8, with a max 5 second interval, so 40 seconds max) is exceeded, the AP goes into Standalone mode (similar to Autonomous) and tries to contact a WLC via its static IP for apprx 5 minutes.

Step 2.) If unsuccessful, the AP switches to DHCP, renews the DHCP lease (to get a new IP address) and tries again to contact a WLC for apprx 3 minutes. This repeats 3 times, for a total of apprx 9-10 minutes.

Step 3.) If after step 2 the AP could still not find a controller, the AP reboots itself and starts at Step 1 all over again. Reboot takes apprx 2-3 minutes.

Note if using DHCP addresses, the process may start at Step 2.

Yes, the maximum time an AP can be out of contact with its WLC then is 40 seconds. If you're just using CAPWAP to configure and reconfigure APs which are otherwise nearly autonomous, this can be quite the annoying level of neediness.

"Who can tell me the reason for this behaviour?"

I believe this behaviour is to ensure management capability, and also to support some of the more "interesting" (for lack of a better term) reasons for CAPWAP... maybe wireless client mobility, remote switching, remote authentication, etc. In those scenarios you DO want your APs to be "needy."

Message was edited by: Mark Withers - not mesh... -

Community Member

Mark, does changing these

Mark, does changing these global values cause any downtime with the APs, ie rebooting, radios shutting off/on, or any other client-impacting events? 


I am frequently getting APs reverting to DHCP assignments;  because we monitor APs via ICMP, we get lots of false-positive reports of APs being down.

Community Member

No downtime from adjusting

No downtime from adjusting them in my experience. It just adjusts a couple counter thresholds, so I can't imagine it would need to do anything to the radio.


However, lower values combined with unreliable network availability of the WLCs will likely result in more downtime/reboots. However, if you're doing central switching, lower values may actually REDUCE downtime by allowing the AP to reconnect more rapidly.


With static IPs and local switching, and using the WLC almost exclusively to manage AP configs... we really wish we could crank these values up to about 10x what's allowed, as any value was way too frequent for us. :(

CreatePlease to create content