I have an 1832i AP at a remote site with IP address in the 192.168.13.0/24 range. It was set up originally as ME and I tried to change it to CAPWAP, but that failed and the AP's on site are now not broadcasting SSID's. I have been trying to force it to AP 192.168.1.68 by priming, also by using DHCP option 43 and 60.... Do I set sub option 102 or 241? DNS is not an option for this implementation. Do I need to do a factory reset, and if so, how do I do it over CLI? I have full admin access over the network, DHCP server is Windows Server 2012R2.
The AP can ping the controller- There is no firewall between the AP and the WLC. the AP's can ping, so I am going to attempt a factory reset remotely and see if I can sign in to a computer onsite to complete the provisioning over the wireless connection.
You mentioned you have access to the cli of the AP, are you doing remote access to it through the switch where it is plugged in?
The fact that you have access to it means that your DHCP service is working for the AP.
The logs on the AP would clearly show where it gets stuck on the process of joining the WLC.
Do you see it receiving the IP address of the WLC on the AP logs?
If you don't see it then you should check your option 43 if it's configured correctly on your DHCP server.
If you see that it discovered the WLC, then next phase is joining it which would require the AP to send the request to the WLC (you will see that on the logs as well).
The rest of the process will be just the WLC pushing the config and image on the AP.
If you can share the logs we can have better view on which process it fails.
Based on your logs, it shows that the AP has joined a controller.
Aug 27 20:13:06 kernel: [*08/27/2019 20:13:06.2703] Discovery Response from 192.168.1.1 - This is the response from WLC (can you check if this is the intended ip address of WLC). If you have also seen, you have WLC ip addresses on the NVRAM of this AP. It would be good to do a hard reset on it.
Aug 27 20:13:06 kernel: [*08/27/2019 20:13:06.2603] Discovery Request sent to 192.168.13.210, discovery type STATIC_CONFIG(1)
Aug 27 20:13:06 kernel: [*08/27/2019 20:13:06.2603] Discovery Request sent to 192.168.1.68, discovery type STATIC_CONFIG(1)
Aug 27 20:13:06 kernel: [*08/27/2019 20:13:06.2703] Discovery Request sent to 192.168.1.1, discovery type STATIC_CONFIG(1)
It joined to the 2504 controller.
Aug 27 20:13:17 kernel: [*08/27/2019 20:13:16.9969] AP has joined controller WLC2504
Aug 27 20:13:17 kernel: [*08/27/2019 20:13:17.0369] Flexconnect Switching to Connected Mode!
What I suggest is to:
1. Login to that WLC and Reset the AP Config from there
2. Ensure that DHCP option 43 has then intended WLC ip configured.
3. You can also add DNS entry as an option
Forgot to include some detail- the wlc2504 is just the virtual flexconnect controller- I need it to join the WLC at 192.168.1.68... but I think it needs to be a flexconnect AP since this subnet is supposed to be 192.168.13.0/24 which is a remote site. I need to manage the SSIDs centrally. When the AP is capwap it does not seem to find the device at 192.168.1.68. Thanks though! Let me know your thoughts.
can you send me the logs on which it is trying to connect to your intended wlc.
yeah you can manage the AP remotely via flexconnect.
You can do central auth local switch, local auth local switch etc..
For flexconnect mode, you can modify those settings once the AP has joined the WLC already.
The main thing that you need to do first is ensure that the AP is on the right network.
And the dhcp scope on that has option 43.
Do you have the dhcp server local to that site? Or have you configured ip helper?
I think your main issue is still on the 1st phase of join process where AP is assigned the right ip address and it sees the wlc ip on the option.
Again, it would be good if you can send me the logs for that.
I have attached a log- it's about a week old, but I Have been troubleshooting this since- Cisco has a hangup with our smartNET contract and I am working through it with customer service still....
DHCP is handled on-site. I have option 43 set at the scope level and at the server level- it is a Win 2012r2 server. At the server level, it shows up like this:
043 Vendor Specific Info Standard f1 o4 c0 a8 44
102 1832i Aironet 1832i 31 39 32 2e 31 36 38 2e 31 2e 36 38
At the scope level, it shows up exactly the same (I made sure to remove the leading zero's and/or period).
Here is the running-config:
AP Name : USYMWAP04
Admin State : Enabled
AP Mode : Local
AP Submode : None
Location : Yuma
Reboot Reason :
Primary controller name : USMDWLC00.CORP.LOCAL
Primary controller IP : 192.168.1.68
Secondary controller name :
Secondary controller IP :
Tertiary controller name :
Tertiary controller IP :
AP join priority : 1
IP Prefer-mode : IPv4
CAPWAP UDP-Lite : Unconfigured
Last Joined Controller name: WLC2504
DTLS Encryption State : Disabled
Discovery Timer : 10
Heartbeat Timer : 30
CDP State : Enabled
Watchdog monitoring : Enabled
IOX : Disabled
RRM State : Enabled
LSC State : Disabled
SSH State : Enabled
AP Username : admin
Session Timeout : 300
Extlog Host : 0.0.0.0
Extlog Flags : 0
Extlog Status Interval : 0
Syslog Host : 255.255.255.255
Syslog Facility : 0
Syslog Level : errors
Core Dump TFTP IP Addr :
Core Dump File Compression : Disabled
Core Dump Filename :
Client Trace Status : Enabled(All)
Client Trace All Clients : Enabled
Client Trace Filter : 0x0E000000
Client Trace Out ConsoleLog: Disabled
WLC Link LAG status : Disabled
AP Link LAG status : Disabled
AP WSA Mode : Disabled
Any ideas? I have it primed to properly join the WLC... I think... Let me know.
Your hex value on the option 43 doesn't seem to be correct.
You have put it to 0.0.0.0.
It should be like below:
Type + Length + Value
Type = f1
Length = 4 (number of wlc x 4)
Value = c0a80144
So option 43 should be = f104c0a80144
Also the join process is stuck on discovery request, there is no response coming back from the controller.
Aug 28 09:41:34 kernel: [*08/28/2019 09:41:34.8035] Discovery Request sent to 192.168.1.68, discovery type STATIC_CONFIG(1)
The options on discovery it is showing is just by layer 2 broadcast and your manually configured WLC.
For some reason, your wlc is not responding to your manual config.
It could mean that capwap could be dropped along the path to the WLC or from WLC response back to AP.
Next step 1st is to try and let the AP discover WLC with the correct option 43.
2nd is to confirm that capcwap ports (5246 and 5247) is not dropped on the path.between wlc and AP.
Thanks for catching that.... I did fix option 43, and attached the log. TUrns out the date is incorrect because the source is incorrect- this is actually a current log as of this morning. I fixed this last night and let it site to make sure the AP had ample time to update and communicate with the WLC. Still not associating, but it seems to be communicating, and they can ping each other. I am working to see if traffic is passing on those ports- the logs show the AP obtaining the correct IP for the WLC... but it looks like the WLC is ignoring the AP. The WLC logs do not mention the AP's mac address. I'll update the post after I find out about the port traffic.