The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
This document describes the AireOS Wireless LAN Controller (WLC) Discovery and Join Process.
Cisco recommends that you have knowledge of these topics:
Basic knowledge of the configuration of Lightweight Access Points (LAPs) and Cisco AireOS WLCs
Basic knowledge of Lightweight Access Point Protocol (CAPWAP)
This document focuses on AireOS WLCs and does not cover Catalyst 9800 althoug the join process is mostly similar.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
In a Cisco Unified Wireless network, the LAPs must first discover and join a WLC before they can service wireless clients.
However, this presents a question: how did the LAPs find the management IP address of the controller when it is on a different subnet?
If you do not tell the LAP where the controller is via DHCP option 43, Domain Name System (DNS) resolution of
, or statically configure it, the LAP does not know where in the network to find the management interface of the controller.Cisco-capwap-controller.local_domain
In addition to these methods, the LAP does automatically look on the local subnet for controllers with a 255.255.255.255 local broadcast. Also, the LAP remembers the management IP address of its controller and the controllers present as mobility peers even across reboots. However, as soon as the AP joins another WLC, it only remembers the IP of that new WLC and its mobility peers and not the previous ones. Therefore, if you put the LAP first on the local subnet of the management interface, it finds the controller management interface and remembers the address. This is called priming. This does not help find the controller if you replace a LAP later on. Therefore, Cisco recommends use of the DHCP option 43 or DNS methods.
The LAPs always connect to the management interface address of the controller first with a discovery request. The controller then tells the LAP the Layer 3 AP-manager interface (which can also be the management by default) IP address so the LAP can send a join request to the AP-manager interface next.
The AP goes through this process on startup:
cisco-capwap-controller
(good for local businesses - can also be used to find where brand new APs join) If you use CAPWAP, make sure there is a DNS entry for cisco-capwap-controller
.From this list, the easiest method to use for deployment is to have the LAPs on the same subnet as the management interface of the controller and allow the LAPs Layer 3 broadcast to find the controller. This method must be used for companies that have a small network and do not own a local DNS server.
The next easiest method of deployment is to use a DNS entry with DHCP. You can have multiple entries of the same DNS name. This allows the LAP to discover multiple controllers. This method must be used by companies that have all of their controllers in a single location and own a local DNS server. Or, if the company has multiple DNS suffixes and the controllers are segregated by suffix.
DHCP option 43 is used by large companies to localize the information by the DHCP. This method is used by large enterprises that have a single DNS suffix. For example, Cisco owns buildings in Europe, Australia, and the United States. In order to ensure that the LAPs only join controllers locally, Cisco cannot use a DNS entry and must use DHCP option 43 information to tell the LAPs what the management IP address of their local controller is.
Finally, static configuration is used for a network that does not have a DHCP server. You can statically configure the information necessary to join a controller by the console port and the APs CLI. For information on how to statically configure controller information by use of the AP CLI, use this command:
AP#capwap ap primary-base <WLCName> <WLCIP>For information on how to configure DHCP option 43 on a DHCP server, refer to the DHCP option 43 configuration example
If two controllers have the same excess capacity, then send the join request to the first controller that responded to the discovery request with a discovery response. If a single controller has multiple AP-managers on multiple interfaces, choose the AP-manager interface with the least number of APs.
The controller responds to all discovery requests without a certificate chec or AP credentials. However, join requests must have a valid certificate to get a join response from the controller. If the LAP does not receive a join response from its choice, the LAP tries the next controller in the list, unless the controller is a configured controller (Primary/Secondary/Tertiary).
After you download the configuration, the AP can reload again to apply the new configuration. Therefore, an extra reload can occur and is a normal behavior.
There are a few debug
commands on the controller you can use to see this entire process on the CLI:
debug capwap events enable
: Shows discovery packets and join packets.
debug capwap packet enable
: Shows packet level information of the discovery and join packets.
debug pm pki enable
: Shows certificate validation process.
debug disable-all
: Turns off debugs.
With a terminal application that can capture output to a log file, console in or secure shell (SSH)/Telnet to your controller, and enter these commands:
config session timeout 120 config serial timeout 120 show run-config (and spacebar thru to collect all) debug mac addr <ap-radio-mac-address> (in xx:xx:xx:xx:xx format) debug client <ap-mac-address> debug capwap events enable debug capwap errors enable debug pm pki enable
After the debugs are captured, use the debug disable-all
command to disable all debugs.
The next sections show the output of these debug
commands when the LAP registers with the controller.
This command provides information on the CAPWAP events and errors that occur at the CAPWAP discovery and join process.
This is the debug capwap events enable
command output for a LAP that has the same image as the WLC:
Note: Some lines of the output have been moved to the second line due to space constraints.
debug capwap events enable *spamApTask7: Jun 16 12:37:36.038: 00:62:ec:60:ea:20 Discovery Request from 172.16.17.99:46317 !--- CAPWAP discovery request sent to the WLC by the LAP. *spamApTask7: Jun 16 12:37:36.039: 00:62:ec:60:ea:20 Discovery Response sent to 172.16.17.99 port 46317 !--- WLC responds to the discovery request from the LAP. *spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317
!--- LAP sends a join request to the WLC.
*spamApTask7: Jun 16 12:38:33.039: 00:62:ec:60:ea:20 Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 75, joined Aps =0
*spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.472: 00:62:ec:60:ea:20 Join Version: = 134256640
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 apType = 46 apModel: AIR-CAP2702I-E-K9
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join resp: CAPWAP Maximum Msg element len = 90
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join Response sent to 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 CAPWAP State: Join
!--- WLC responds with a join reply to the LAP.
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Configuration Status from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 CAPWAP State: Configure !--- LAP requests for the configuration information from the WLC.
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP info for AP 00:62:ec:60:ea:20 -- static 0, 172.16.17.99/255.255.254.0, gtw 172.16.16.1
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP 172.16.17.99 ===> 172.16.17.99 for AP 00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Running spamDecodeVlanProfMapPayload for00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Setting MTU to 1485
*spamApTask7: Jun 16 12:38:44.019: 00:62:ec:60:ea:20 Configuration Status Response sent to 172:16:17:99
!--- WLC responds by providing all the necessary configuration information to the LAP. *spamApTask7: Jun 16 12:38:46.882: 00:62:ec:60:ea:20 Change State Event Request from 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Radio state change for slot: 0 state: 2 cause: 0 detail cause: 69
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Change State Event Response sent to 172.16.17.99:46317
.
.
.
.
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 CAPWAP State: Run
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Sending the remaining config to AP 172.16.17.99:46317!
.
.
.
. !--- LAP is up and ready to service wireless clients. *spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:17:99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.17.99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmReceiveCtrl payload sent to 172:16:17:99
*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for CcxRmMeas payload sent to 172.16.17.99
!--- WLC sends all the RRM and other configuration parameters to the LAP.
As mentioned in the previous section, once a LAP registers with the WLC, it checks to see if it has the same image as the controller. If the images on the LAP and the WLC are different, the LAPs download the new image from the WLC first. If the LAP has the same image, it continues to download the configuration and other parameters from the WLC.
You see these messages in the debug capwap events enable
command output if the LAP downloads an image from the controller as a part of the registration process:
*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Sending image data block of length 1324 and msgLength = 1327
*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Image Data Request sent to 172.16.17.201:46318
*spamApTask6: Jun 17 14:23:28.693: 00:62:ec:60:ea:20 Image data Response from 172.16.17.201:46318
Once the image download is complete, the LAP reboots and run the discovery and join the algorithm again.
As a part of the join process, the WLC authenticates each LAP by confirmation that its certificate is valid.
When the AP sends the CAPWAP Join Request to the WLC, it embeds its X.509 certificate in the CAPWAP message. The AP also generates a random session ID that is also included in the CAPWAP Join Request. When the WLC receives the CAPWAP Join Request, it validates the signature of the X.509 certificate with the AP public key and checks that the certificate was issued by a trusted certificate authority.
It also looks at the start date and time for the AP certificate validity interval and compares that date and time to its own date and time (hence the controller clock needs to be set close to the current date and time). If the X.509 certificate is validated, the WLC generates a random AES encryption key. The WLC plumbs the AES keys into its crypto engine so it can encrypt and decrypt future CAPWAP Control Messages exchanged with the AP. Note that data packets are sent in the clear in the CAPWAP tunnel between the LAP and the controller.
The debug pm pki enable
command shows the certification validation process that occurs at the join phase on the controller. The debug pm pki enable
command also displays the AP hash key at the join process, if the AP has a self-signed certificate (SSC) created by the LWAPP conversion program. If the AP has a Manufactured Installed Certificate (MIC), you do not see a hash key.
Note: All APs manufactured after June 2006 have a MIC.
Here is the output of the debug pm pki enable
command when the LAP with a MIC joins the controller:
Note: Some lines of the output have been moved to the second line due to space constraints.
*spamApTask4: Mar 20 11:05:15.687: [SA] OpenSSL Get Issuer Handles: locking ca cert table
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: x509 subject_name /C=US/ST=California/L=San Jose/O=Cisco Systems/
CN=AP3G2-1005cae83a42/emailAddress=support@cisco.com
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuer_name /O=Cisco Systems/CN=Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert Name in subject is AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Extracted cert issuer from subject name.
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert is issued by Cisco Systems.
*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultMfgCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 260e5e69 for certname cscoDefaultMfgCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultMfgCaCert in row 5 x509 0x2cc7c274
*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultNewRootCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultNewRootCaCert in row 4
*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 28d7044e for certname cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultNewRootCaCert in row 4 x509 0x2cc7c490
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification return code: 1
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification result text: ok
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: OPENSSL X509_Verify: AP Cert Verfied Using >cscoDefaultMfgCaCert<
*spamApTask4: Mar 20 11:05:15.691: [SA] OpenSSL Get Issuer Handles: Check cert validity times (allow expired NO)
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultIdCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching ID cert cscoDefaultIdCert in row 2
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: called with 0x1b0b9380
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: freeing public key
If the controller debugs do not indicate a join request, you can debug the process from the AP if the AP has a console port. You can see the AP boot up process with these commands, but you must first get into enable mode (default password is Cisco).
debug dhcp detail
: Shows DHCP option 43 information.
debug ip udp
: Shows all UDP packets received and transmitted by the AP. debug capwap client event
: Shows capwap events for the AP.
debug capwap client error
: Shows capwap errors for AP. debug dtls client event
: Shows DTLS events for the AP. debug dtls error enable
: Shows DTLS errors for the AP. undebug all
: Disables debugs on the AP.
Here is an example of the output from the debug capwap
commands. This partial output gives an idea of the packets sent by the AP at the boot process to discover and join a controller.
AP can discover the WLC via one of these options :
!--- AP discovers the WLC via option 43
*Jun 28 08:43:05.839: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.63.84.78 obtained through DHCP
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.78 with discovery type set to 2
!--- capwap Discovery Request using the statically configured controller information.
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.32 with discovery type set to 1
!--- Capwap Discovery Request sent using subnet broadcast.
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 255.255.255.255 with discovery type set to 0
!--- capwap Join Request sent to AP-Manager interface on DHCP discovered controller.
*Jun 28 08:40:29.031: %CAPWAP-5-SENDJOIN: sending Join Request to 10.63.84.78
Can the AP and the WLC communicate?
Make sure the AP gets an address from DHCP (check the DHCP server leases for the MAC address of the AP).
Ping the AP from the controller.
Check if the STP configuration on the switch is correct, so packets to the VLANs are not blocked.
If pings are successful, ensure the AP has at least one method by which to discovery at least a single WLC Console or telnet/ssh into the controller to run debugs.
Each time the AP reboots, it initiates the WLC discovery sequence and tries to locate the AP. Reboot the AP and check if it joins the WLC.
Here are some of the commonly seen issues due to which the LAPs do not join the WLC.
Certificates embedded in the hardware are valid for a period of 10 years after manufacturing. If your APs or WLC are more than 10 years old, expired certificates can cause AP join issues. More information on this issue is available in this field notice: Field Notice: FN63942.
Complete these steps in order to troubleshoot this problem:
debug dtls client error + debug dtls client event
commands on the AP:
*Jun 28 09:21:25.011: DTLS_CLIENT_EVENT: dtls_process_Certificate: Processing...Peer certificate verification failed 001A
*Jun 28 09:21:25.031: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:509 Certificate verified failed!
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Bad certificate Alert
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_client_process_record: Error processing Certificate.
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_disconnect: Disconnecting DTLS connection 0x8AE7FD0
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_free_connection: Free Called... for Connection 0x8AE7FD0
*Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Close notify Alert
This information clearly shows the controller time is outside the certificate validity interval of the AP. Therefore, the AP cannot register with the controller. Certificates installed in the AP have a predefined validity interval. The controller time must be set so it is within the certificate validity interval of the AP certificate.
show time
command from the controller CLI in order to verify the date and time set on your controller falls within this validity interval. If the controller time is higher or lower than this certificate validity interval, then change the controller time to fall within this interval.Note: If the time is not set correctly on the controller, choose Commands > Set Time
in the controller GUI mode, or issue the config time command in the controller CLI in order to set the controller time.
show crypto ca certificates
command from the AP CLI.
This command allows you to verify the certificate validity interval set in the AP. This is an example:
AP00c1.649a.be5c#show crypto ca cert
............................................
............................................
.............................................
................................................
Certificate
Status: Available
Certificate Serial Number (hex): 7D1125A900000002A61A
Certificate Usage: General Purpose
Issuer:
cn=Cisco Manufacturing CA SHA2
o=Cisco
Subject:
Name: AP1G2-00c1649abe5c
e=support@cisco.com
cn=AP1G2-00c1649abe5c
o=Cisco Systems
l=San Jose
st=California
c=US
CRL Distribution Points:
http://www.cisco.com/security/pki/crl/cmca2.crl
Validity Date:
start date: 01:05:37 UTC Mar 24 2016
end date: 01:15:37 UTC Mar 24 2026
Associated Trustpoints: Cisco_IOS_M2_MIC_cert
Storage:
..................................
....................................
......................................
The entire output is not listed because there can be many validity intervals associated with the output of this command. Consider only the validity interval specified by the Associated Trustpoint: Cisco_IOS_MIC_cert with the relevant AP name in the name field. In this example output, it is Name: C1200-001563e50c7e. This is the actual certificate validity interval to be considered.
You see this message in the debug capwap events enable
command output:
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Setting MTU to1485
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Regulatory Domain Mismatch: AP 00:cc:fc:13:e5:e0 not allowed to join. Allowed domains: 802.11bg:-A
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Finding DTLS connection to delete for AP (192:168:47:29/60390)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Disconnecting DTLS Capwap-Ctrl session 0x1d4df620 for AP (192:168:47:29/60390). Notify(true)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 acDtlsPlumbControlPlaneKeys: lrad:192.168.47.29(60390) mwar:10.63.84.78(5246)
WLC msglog show these messages :
*spamApTask5: Jun 28 11:52:06.536: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7095 00:cc:fc:13:e5:e0: DTLS connection
closed forAP 192:168:47:28 (60389), Controller: 10:63:84:78 (5246) Regulatory Domain Mismatch
The message clearly indicates there is a mismatch in the regulatory domain of the LAP and the WLC. The WLC supports multiple regulatory domains, but each regulatory domain must be selected before an AP can join from that domain. For example, the WLC that uses regulatory domain -A can only be used with APs that use regulatory domain -A (and so on). When you purchase APs, ensure they share the same regulatory domain. Only then can the APs register with the WLC.
Note: Both 802.1b/g and 802.11a radios must be in the same regulatory domain for a single AP.
In such cases, you see this message on the controller in the output of the debug capwap events enable
command:
Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received CAPWAP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '1' Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of CAPWAP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 Received CAPWAP JOIN REQUEST from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1' Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: txNonce 00:0B:85:33:52:80 rxNonce 00:0B:85:51:5A:E0 Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 CAPWAP Join-Request MTU path from AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0 Wed Sep 12 17:42:50 2007: spamRadiusProcessResponse: AP Authorization failure for 00:0b:85:51:5a:e0
If you use a LAP that has a console port, you see this message when you issue the debug capwap client error
command:
AP001d.a245.a2fb# *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: spamHandleJoinTimer: Did not receive the Join response *Mar 1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain.
This again is a clear indication the LAP is not part of the AP authorization list on the controller.
You can view the status of the AP authorization list with this command:
(Cisco Controller) >show auth-list Authorize APs against AAA ....................... enabled Allow APs with Self-signed Certificate (SSC) .... disabled
In order to add a LAP to the AP authorization list, use the config auth-list add mic <AP MAC Address>
command. For more information on how to configure LAP authorization, refer to Lightweight Access Point (LAP) Authorization in a Cisco Unified Wireless Network Configuration Example.
The LAP does not join a controller because of a certificate issue.
Issue the debug capwap errors enable
and debug pm pki enable
commands. You see messages that indicate the certificates or keys that are corrupted.
Note: Some lines of the output have been moved to second lines due to space constraints.
Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 CAPWAP Join Request does not include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0f:24:a9:52:e0. Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Deleting and removing AP 00:0f:24:a9:52:e0 from fast path Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Unable to free public key for AP
Use one of these two options in order to resolve the problem:
You see this message in the debug capwap events enable
command output:
Received a Discovery Request with subnet broadcast with wrong AP IP address (A.B.C.D)!
This message means the controller received a discovery request by a broadcast IP address with a source IP address which is not in any configured subnets on the controller. This also means the controller is the one that drops the packet.
The problem is that the AP is not what sent the discovery request to the management IP address. The controller reports a broadcast discovery request from a VLAN that is not configured on the controller. This typically occurs when trunks allowed VLANs and did not restrict them to wireless VLANs.
Complete these steps in order to resolve this problem:
If a firewall is used in the enterprise network, ensure these ports are enabled on the firewall for the LAP to join and communicate with the controller.
You must enable these ports:
Enable these UDP ports for CAPWAP traffic:
Data - 5247
Control - 5246
Enable these UDP ports for mobility traffic:
16666 - 16666
16667 - 16667
Enable UDP ports 5246 and 5247 for CAPWAP traffic.
TCP 161 and 162 for SNMP (for the Wireless Control System [WCS])
These ports are optional (dependent on your requirements):
UDP 69 for TFTP
TCP 80 and/or 443 for HTTP or HTTPS for GUI access
TCP 23 and/or 22 for Telnet or SSH for CLI access
This is another common issue seen when the AP tries to join the WLC. You can see this error message when the AP tries to join the controller.
No more AP manager IP addresses remain
One of the reasons for this error message is when there is a duplicate IP address on the network that matches the AP manager IP address. In such a case, the LAP keeps power cycle initiations and cannot join the controller.
The debugs show the WLC receives LWAPP discovery requests from the APs and transmits a LWAPP discovery response to the APs.
However, WLCs do not receive LWAPP join requests from the APs.
In order to troubleshoot this issue, ping the AP manager from a wired host on the same IP subnet as the AP manager. Then, check the ARP cache. If a duplicate IP address is found, remove the device with the duplicate IP address or change the IP address on the device so it has a unique IP address on the network.
The AP can then join the WLC.
The Lightweight Access Point does not register with the WLC. The log displays this the error message:
AAA Authentication Failure for UserName:5475xxx8bf9c User Type: WLAN USER
This can happen if the Lightweight Access Point was shipped with a mesh image and is in Bridge mode. If the LAP was ordered with mesh software on it, you need to add the LAP to the AP authorization list. Choose Security > AP Policies and add AP to the Authorization List. The AP must then join, download the image from the controller, then register with the WLC in bridge mode. Then you need to change the AP to local mode. The LAP downloads the image, reboots, and registers back to the controller in local mode.
Access points can renew their IP addresses quickly when an attempt to join a WLC is made, which can cause Windows DHCP servers to mark these IPs as BAD_ADDRESS which could quickly deplete the DHCP pool. Check for more information in the Client Roaming chapter of the Cisco Wireless Controller Configuration Guide, Release 8.2.
Revision | Publish Date | Comments |
---|---|---|
8.0 |
17-May-2024 |
updated a statement about the WLC an AP remembers across reboot |
7.0 |
12-Jan-2024 |
Added a reference to 9800 ap join |
6.0 |
11-Dec-2023 |
Final Recertification |
5.0 |
03-Nov-2022 |
Updated document styles and content to comply to current Cisco.com publication standards. |
1.0 |
31-Jul-2015 |
Initial Release |