1142 AP CAPWAP errors on 5508 WLC

Unanswered Question
Nov 24th, 2009

I'm having an issue with 1142 AP's only on a 5508 WLC running the latest 6.0.188 code.   When I try to join the 1142 AP's to the WLC, the AP's do join and download an image, but then continually reset/reload after these errors:

: %CAPWAP-3-ERRORLOG: Failed to handle capwap control message from controller

: %CAPWAP-3-ERRORLOG: Failed to process unencrypted capwap packet from

: %CAPWAP-3-ERRORLOG: Invalid AC Message Type 4

I do have 1252 AP's on the network with no issues as they are using LWAPP to connect from what I can tell.  At one point I did have the two distribution ports in a LAG on one 3750G switch.  I then took it off and just configured one port not in a LAG and still had the same issue.  I did attempt to create a seperate AP manager port on the same VLAN as the AP's and the errors stopped.  Routing is working and there is not a firewall in between the AP's and the WLC.  I also put the AP into the same VLAN as the WLC and the errors also stopped.

I've always put the AP's on a seperate VLAN from the WLC and have never had this issue.  But in this case, I cannot figure out why I would have this problem.

Seems like CAPWAP can't traverse vlans?  Am I missing something?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Leo Laohoo Tue, 11/24/2009 - 20:59

1.  Console into the AP and see if the AP can ping the Management IP address.  If you can, enter the command into the AP: lwapp ap controller ip add
2.  If the command does not fixes your issue, convert the AP into autonomous mode and re-convert to LWAP.

Hope this helps.

jake.kappus Wed, 11/25/2009 - 07:36

Thanks,  tried both of those suggestions an neither worked.  I'm opening a TAC case right now.  It's the oddest thing.

  If I put the AP's in the same VLAN as the WLC, they work fine.  I was thinking they were in Layer 2 mode, but apparently with the 5508's you don't have a choice anymore and everything is Layer 3 now.  Routing works, I can ping everything under the sun from the AP (yeah I know...security risk, but I'll fix that after this).

jake.kappus Tue, 12/22/2009 - 15:44

Still working with TAC on the issue.  Went through 3 levels of TAC engineers and now we are focusing our efforts on the core

switch that the WLC is connected to.   I'm doing a switch image change tonight to see if that solves it.  It's not normal that's for sure.

pablorebollo Fri, 01/01/2010 - 10:19

Hi Jake,

I had a similar problem.  APs joined the controller after "undebug all" an "clear log" at the AP console.  Looks like the amount of error messages exaust the AP memory.  That migth cause a problem to complete the process to join the controller.

jake.kappus Fri, 01/01/2010 - 11:37

After several escalations we finally figured this one out.   Check out Bug ID: CSCte07565

WLC is having a problem establishing the DTLS Secure tunnel between the AP and the WLC when the destination mac address does not begin with 00.  But since our gateway had a non-00 mac address, as soon as you put them in a different vlan, the destination mac address was non-00, and the DTLS session was failing.

As a workaround, we’ve changed ythe gateway to be an HSRP Standby address. Although we aren’t really running HSRP for redundant cores, adding the standby address to your vlan interface has allowed for the gateway to now have a mac address beginning with 00:00:0c, which has effectively allowed all of your APs to work.

Apparently the fix for this bug will be included in the next code release.  For now, adding the standby IP to the VLAN interface is working.  Just be sure to point the controller's gateway to that IP and it all should work.

Hope this helps everyone who is having this issue.

David Cebula Tue, 02/23/2010 - 11:13

This bug is now listed as resolved for releases after Unfortunately they did not list it in the release notes.

rmarosko Wed, 02/24/2010 - 13:03


Have run into a similar issue today with some brand new 1142Ns that now have a leading MAC OUI of c4:7d:4f:xx:xx:xx. These APs, even placed in the same L2 VLAN as the management/apmgr VLAN of the controller, will not establish the DTLS connection with the controller.

I'm downloading firmware right now. Sigh.


     Ron CCIE4526

David Cebula Wed, 02/24/2010 - 13:09

The AP's need to be in a DIFFERENT vlan than the controller in order to connect. That is my current workaround for the bug. You may need to also check the AP Authorization setttings on the Controller (AAA - AP/MSE Authorization). I have AP Authorization disabled and that works for me.

rmarosko Wed, 02/24/2010 - 13:11

Going to try that, I really don't want to have to run pull all these APs back down, especially since a couple are located in active surgery suites.


     Ron CCIE4526

uosambela Mon, 03/08/2010 - 23:29

Hi to all!

I got the same error.

i would like to know if the latest code resoved this problem.

According to the release notes it seems it´s been fixed but i want to know if anyone has test it.

Thanks in advance

fabiossilva Tue, 03/09/2010 - 06:00

Yes.. i got the same error... and after upgrade the WLC to the version the problem was solved.

rmarosko Tue, 03/09/2010 - 06:04

Yes, on my implementation, I upgraded to and the problem went away.

...Ron CCIE4526


This Discussion

Related Content



Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode