Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.
During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.
We apologize for the inconvenience while we perform important updates to the Community.
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 172.16.200.50
: %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?
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.
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).
Did the TAC answer your question regarding this problem?
I have the same error messages as you have..I have the same version, same AP and controller...
thanks in advance.
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.
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.
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.
This bug is now listed as resolved for releases after 184.108.40.206. Unfortunately they did not list it in the 220.127.116.11 release notes.
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 18.104.22.168 firmware right now. Sigh.
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.
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.
Hi to all!
I got the same error.
i would like to know if the latest code 22.214.171.124 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