I was priming a lot of Cisco 1142s for an upcoming installation and somehow one of the 1142s has the wrong controller IP address stuck in it. Not sure how this happened, but it is close enough to our IP address scheme that I know it somehow got messed up on our end.
Question is... how to remove it? It associated with our controllers, was named, and showed up in our WCS. Then it somehow got the wrong IP address stuck in it and it is trying to go somewhere else.
Does anyone know how to unstick this setting? I've tried several commands with no luck.
*May 4 19:41:06.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent pee
r_ip: 10.131.255.142 peer_port: 5246?
client CAPWAP Client Information
ip CAPWAP IP configuration
location CAPWAP Location Information
mcast CAPWAP Mcast Information
You should be able to delete the capwap OS directory on the 1142 from a console session (leaving the recovery image) and once it boots up again you can do a "clear capwap private-config" and reconfigure the controller address.
This one? c1140-k9w8-mx.124-18a.JA2?
Directory of flash:/
2 -rwx 89651 Apr 18 2010 20:47:04 +00:00 event.log
3 -rwx 5144 May 4 2010 19:46:46 +00:00
5 drwx 128 Mar 1 2002 00:13:06 +00:00 c1140-rcvk9w8-mx
8 drwx 192 Apr 18 2010 04:57:54 +00:00
12 -rwx 251 May 4 2010 19:46:00 +00:00 env_vars
32385024 bytes total (25838592 bytes free)
Yep. That's the one it downloads from the controller after the initial join. Once that's gone it will boot the recovery image and you should be able stage it again.
Doesn't seem to want to lose it... Not sure where it got 10.131.255.142 from, since our controller is 10.131.255.12
The "4" got stuck in there somehow, but we don't prime them with IP addresses. We use DNS names. Strange.
*May 4 20:09:50.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent pee
r_ip: 10.131.255.142 peer_port: 5246
*May 4 20:10:04.096: DTLS_CLIENT_ERROR: ../dtls/dtls_connection_db.c:1924 Ma
x retransmission count reached!
*May 4 20:10:04.096: %DTLS-3-HANDSHAKE_RETRANSMIT: Max retransmit count for
10.131.255.142 is reached.
Did you do the "clear capwap private-config" and reboot the AP once it was running the recovery image? I just did this and it seemed to work on a 1252.
Actually took the AP to autonomous and back and it remembered the controller that doesn't exist. Erased flash completely, loaded new image from tftp server, then reloaded AP. AP remembers the ghost controller.
RMA in process.
Here's something I don't understand. It knows about our controllers, since the list is accurate. But down at the bottom, it shows trying to go to 10.131.255.142
This is strange, since none of the other Aps attempt to go here. And they all work.
AP8843.e178.33c3#sho capwap client config
location default location
ApSubMode Not Configured
Discovery Timer 10 secs
Heart Beat Timer 30 secs
Led State Enabled 1
AP ILP Pre-Standard Switch Support Enabled
AP Power Injector Disabled
Infrastructure MFP validation Enabled
Configured Switch 1 Addr 10.129.255.11
Configured Switch 2 Addr 10.129.255.15
Configured Switch 3 Addr 10.129.255.13
Configured Switch 4 Addr 10.129.255.17
Configured Switch 5 Addr 10.131.255.27
Configured Switch 6 Addr 10.131.255.23
Configured Switch 7 Addr 10.131.255.25
Configured Switch 8 Addr 10.131.255.21
Configured Switch 9 Addr 10.129.255.12
Configured Switch 10 Addr 10.129.255.16
Configured Switch 11 Addr 10.129.255.14
Configured Switch 12 Addr 10.129.255.18
Configured Switch 13 Addr 10.131.255.28
Configured Switch 14 Addr 10.131.255.24
Configured Switch 15 Addr 10.131.255.26
Configured Switch 16 Addr 10.131.255.22
Ethernet (Duplex/Speed) auto/auto
transport input ssh
% Invalid input detected at '^' marker.
RSSI IDB null
RSSI IDB null
*May 4 20:15:30.037: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY
*May 4 20:15:40.000: %CAPWAP-5-DTLSREQSEND: DTLS connection request sent pee
r_ip: 10.131.255.142 peer_port: 5246
I can see that you are running the IOS file c1140-k9w8-mx.124-18a.JA2 which is the full LWAP image. You need to run the "rcv" image, i. e. c1140-rcvk9w8-mx, to be able to use the command "clear lwapp private-config".
Aside from that, you also need to run the command "clear lwapp ap controller ip address".
Do make sure that the AP in question is not connected to the network.
Hope this helps. Please don't forget to rate our posts.
Forgot another command (sorry!). If you can console into the AP while it's connected to the network, use the command "lwapp ap controller IP add
I think you'll need to do that after clearing the private config and while you are running the recovery image.
Right-o. Sounds like your using either a 4.X or a 5.X firmware. You need to let the AP run on the "rcv" image. See my previous post.
I was running the recovery image. I sent a capture of the AP after I
put new code back on it.
I ended up RMAing the unit, and then yesterday I had another unit with
the same symptoms, but this time it was able to find the right
controller after messing around with it for a while. Our DHCP scope
option 43 doesn't send them to 10.131.255.142, and we don't have a
controller at that address.
Can't figure out where this address is coming from!
*May 6 21:49:00.733: %CAPWAP-5-DTLSREQSUCC: DTLS connection created
lly peer_ip: 10.131.255.142 peer_port: 5246
*May 6 21:49:00.733: %CAPWAP-5-SENDJOIN: sending Join Request to
*May 6 21:49:00.733: %CAPWAP-5-CHANGED: CAPWAP changed state to JOIN
*May 6 21:49:00.823: %CAPWAP-5-CHANGED: CAPWAP changed state to CFG
*May 6 21:49:00.900: %CAPWAP-5-CHANGED: CAPWAP changed state to UP
*May 6 21:49:00.902: %LWAPP-3-CLIENTEVENTLOG: Received AP Syslog IP
*May 6 21:49:01.011: %CAPWAP-5-JOINEDCONTROLLER: AP has joined
I have had similar problems. We have 2 dns records on internal dns that have helped straightedned it out. Option 43 hasnt worked well for us.
Look for cisco-capwap-controller in your local dns zone or cisco-lwapp-controller if you are on pre 6.x code. If you dont have an A record like that already, get one created and that might just help with your problem.