LAP1142 H-REAP not associating to controller

Unanswered Question
Mar 21st, 2010
User Badges:

Hi, I have run into an issue with two H-REAP 1142 AP's that have been installed at a remote site. I added them to the controller at the main office and had them up and running. The configured them as H-REAPs with the appropriate VLAN's for the remote site, and had a user confirm H-REAP operation before sending them out. Since they have been installed on site, they have not be able to associate to the controller, although one updates the IP address shown in WCS. I logged into the AP's and they are currently operating in H-REAP mode, so I had some try to connect to them but the AP's returned that the PSK was wrong! So now im stuck. My first thought was to reset the configuration of the AP but I cannot rememeber the debug command that allows the local configuration to be changed/reset even when the local credentials hadnt been changed (so if anyone knows this please post it, its very helpful). In any case here are the log entries I get which dont make sense.


WLC Message Logs
*Mar 19 04:51:18.082: %LWAPP-6-CAPWAP_SUPP_VER: spam_lrad.c:1708 Discarding discovery request in LWAPP from AP 04:fe:7f:49:09:90 supporting CAPWAP
*Mar 19 04:51:13.616: %LWAPP-6-CAPWAP_SUPP_VER: spam_lrad.c:1708 Discarding discovery request in LWAPP from AP ec:44:76:80:65:a0 supporting CAPWAP

WLC (debug capwap events enable)
*Mar 19 04:16:59.298: DTLS connection closed event receivedserver (172:16:117:252/5246) client (172:20:17:49/65194)
*Mar 19 04:28:31.407: DTLS connection not found, creating new connection for 172:20:17:49 (65194) 172:16:117:252 (5246)

*Mar 19 04:28:32.217: DTLS Session established server (172.16.117.252:5246), client (172.20.17.49:65194)
*Mar 19 04:28:32.217: Starting wait join timer for AP: 172.20.17.49:65194

*Mar 19 04:28:32.410: Running spamSendCreateVlanMapping forec:44:76:80:65:a0
*Mar 19 04:28:32.411:  Received  SPAM_UPLOAD_STATIC_BLACKLIST_TABLE

AP (debug capwap client event)
*Mar 19 06:30:13.801: %CAPWAP-3-EVENTLOG: Could not discover any MWAR.
*Mar 19 06:30:13.801: %CAPWAP-3-EVENTLOG: Starting Discovery.
*Mar 19 06:30:13.802: %CAPWAP-3-EVENTLOG: CAPWAP State: Discovery.
*Mar 19 06:30:13.802: %CAPWAP-3-EVENTLOG: Could not resolve static gateway not sending discovery request
*Mar 19 06:30:13.802: %CAPWAP-3-EVENTLOG: Could not resolve staticgateway Not sending discovery request
*Mar 19 06:30:13.802: %CAPWAP-3-EVENTLOG: Could not resolve static gateway Not sending discovery request
*Mar 19 06:30:13.802: %CAPWAP-3-EVENTLOG: WTP descriptor: version=100709888
*Mar 19 06:30:13.803: %CAPWAP-3-EVENTLOG: Discovery Request sent to 255.255.255.255 with discovery type set to 0

From these logs, CAPWAP joins are recieved by the controller but it is not accepting them for some reason. I have rebooted the controller a few times with no success.

The WLC is using 6.0.182.0

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Leo Laohoo Sun, 03/21/2010 - 22:26
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 LAN, Wireless

To blow the config of an LWAP is "clear lwapp private".


What is the firmware of your WLC?

blakeweston Sun, 03/21/2010 - 23:25
User Badges:

The WLC is using 6.0.182.0


My issue is that the AP was associated to the controller and has a config so none of the standard commands can be used. I was hopeing someone could remember the debug command to allow full access to the CLI config. I've used it previously to recover a 1510 AP with Cisco.

Scott Fella Mon, 03/22/2010 - 05:45
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 Wireless

I think that command was only for the 1522 not any other AP type... I can't remember that command off the top of my head though.  If you initially staged that AP local and tested it in h-reap and then deployed it and then it didn't work... well check to make sure your not blocking ports for capwap and make sure the trunk port is set to native vlan.  Funny thing is that it looks like the AP can't even resolve the gateway.... so is the ap configured for the remote site or with a configuration from where it was tested?


Like Leo mentioned.... clear the config either by using that command or by deleteing some files in thefflash....becareful though woul might just end up having to tftp the rcv image again:


example


ERROR!!! Command is disabled

First, check the flash:
lap_1131#dir
Directory of flash:/

2 -rwx 279 May 09 2008 11:52:20 +00:00 env_vars
4 -rwx 6168 May 09 2008 11:52:20 +00:00 private-multiple-fs
6 drwx 256 May 09 2008 11:49:05 +00:00 c1130-k9w8-mx.124-3g.JA2
5 drwx 128 Mar 01 2002 00:03:43 +00:00 c1130-rcvk9w8-mx

15998976 bytes total (10716672 bytes free)


Then delete the LWAPP image:
lap_1131#delete /r /f flash:/c11310-k9w8-mx.124-3g.JA2

Not the one the has rcv in it!!!!!!


Thirdly reload the AP:
lap_1131#reload

Then issue a clear lwapp private-config

You'll end up with a clear AP.

*****************************************************************

Option 2 - If there in no rcv image

delete /r /f flash:private-multiple-fs

blakeweston Tue, 03/23/2010 - 01:58
User Badges:

Well, it looks like I had run into another 'weird' state for the APs. I had checked the configuration of the APs and concluded that the controller had given the AP a configuration different to what was requested in WCS in terms of the VLAN configuration. I had the switchport trunk configuration match the AP configuration (native VLANs etc) and left it for a while with CAPWAP requests reaching the controller and no association occuring. Changed the native VLAN to the one set for the WLAN (in the H-REAP settings, but not the requested native vlan) and left it for a few hours. To my amazement the AP had connected to the controller and updated the configuration. I have since updated the configuration and everything is working fine.


I may think about upgrading the WLC software again due to the initial incorrect configuration being pushed to the device. But setting a different native VLAN (17) on the port than the native VLAN (1) on the AP fixed the connection issue. WEIRD!

Scott Fella Tue, 03/23/2010 - 03:25
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    The Hall of Fame designation is a lifetime achievement award based on significant overall achievements in the community. 

  • Cisco Designated VIP,

    2017 Wireless

Yeah... that isn't right.  If you mapped the vlan on the h-reap ap and hit apply, that is the vlan you need to specify as native on your trunk port.

Actions

This Discussion

Related Content

 

 

Trending Topics - Security & Network