Cisco AP1852I Fails to Join WLC - Stuck at CAPWAP Discovery (Discovery

[phuocntlk135]

Hi everyone,

I'm currently troubleshooting an issue where my Cisco AP1852I is failing to join the WLC. The AP is booting up normally, firmware is verified and loaded, radios initialize correctly, and it obtains a valid IP address via DHCP (e.g., 192.168.10.151). However, it seems to get stuck in the CAPWAP Discovery state and never proceeds to the join phase.

Here are some key logs and observations:

• Boot completed successfully with no major hardware errors.

• CAPWAP State transitions from Init to Discovery.

• The AP receives the WLC IP from DHCP option 43 (e.g., 192.168.1.100).

• Discovery Request is sent to both 192.168.1.100 and 255.255.255.255, but no Discovery Response is received.

• Looping logs show:
  ipv6 gw config loop in discovery timer expiry
  ipv6 gw config loop in Ac discovery

• dtls_init: Use MIC certificate indicates DTLS should be working.

I'm using a Catalyst 9800-CL virtual WLC, and the AP is Layer 3 adjacent to the controller (different VLANs/subnets). I’ve confirmed the following:

Option 43 is properly configured in DHCP scope.
AP has correct IP, subnet, and gateway.
WLC can ping the AP, and vice versa (when debug shell is accessible).
No ACL or firewall is blocking UDP ports 5246/5247.

However, the AP just retries discovery and never joins.

---

My Questions:

1. Are there additional configurations required on the WLC to authorize the AP (e.g., MAC whitelist)?

2. Could there be an issue with DTLS negotiation or certificate mismatch?

3. Is there a way to debug the discovery response on the WLC side to confirm if it’s being sent or dropped?

4. Could NAT between AP and WLC interfere with join, even when Option 43 is correct?

[*05/12/2025 13:31:24.3318] CAPWAP State: Discovery
[*05/12/2025 13:31:24.3318] Got WLC address 192.168.1.100 from DHCP.
[*05/12/2025 13:31:24.3318] Discovery Request sent to 192.168.1.100, discovery type STATIC_CONFIG(1)
[*05/12/2025 13:31:24.3618] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
...
[*05/12/2025 13:31:40.8167] ipv6 gw config loop in discovery timer expiry
[*05/12/2025 13:31:50.8235] ipv6 gw config loop in Ac discovery

[marce1000 · Accepted solution]

 - @phuocntlk135   >....Is there a way to debug the discovery response on the WLC side to confirm if it’s being sent or dropped?
                                               https://logadvisor.cisco.com/logadvisor/wireless/9800/9800APJoin

  M.

[Rich R]

1. Are there additional configurations required on the WLC to authorize the AP (e.g., MAC whitelist)?
   Not unless you explicitly enable it OR the AP is a mesh/outdoor AP (bridge mode) which should not apply to regular 1852i.

2. Could there be an issue with DTLS negotiation or certificate mismatch?
   Unlikely but logs and debugs would show that. You can use Radioactive trace on the WLC using MAC address of the AP.  Also see my note about trustpoint below.

3. Is there a way to debug the discovery response on the WLC side to confirm if it’s being sent or dropped?
   As per @marce1000's answer and my answer above to Q2

4. Could NAT between AP and WLC interfere with join, even when Option 43 is correct?
   Yes if the WLC IP is being NATted.  The WLC must be listening and replying from the IP the AP is trying to join. If the AP IP is getting NATted that shouldn't matter.  If you NAT the WLC IP then you must use the NAT feature on the WLC so that it replies from the correct address.

The most likely causes are that you have forgotten to configure the Wireless Management interface,  missing trustpoint, or missed some steps in configuring the 9800-CL VM (for example on ESX you must enable certain features) so go through the 9800-CL install and setup guide very slowly and carefully to make sure you did not miss any items.

Also check your WLC config using the Config Analyzer (link and details below) which will highlight many common mistakes and Best Practices items.  Also worth reviewing the entire Best Practices guide.