Trying to migrate APs from 5.2 back to 4.2 - CAPWAP to LWAPP

Unanswered Question
Feb 4th, 2009

I am trying to migrate my controllers back from 5.2 to 4.2 code. If I have an AP associated to a 5.2 controller, I can change its configuration to point to a 4.2 controller, create an access list so that it can no longer see any of the 5.2 (CAPWAP) controllers, and then reboot it. I then see lots of errors and it never attaches to the 4.2 controller. I have attached the entire output but here are a few to take note of:

%LWAPP-3-CLIENTERRORLOG: Error decrypting packet with CCM, session id 0xFFFFFFFF is not valid

...

examining image...

extracting info (295 bytes)

Image info:

Version Suffix: k9w8-.124-10b.JDA1

Image Name: c1130-k9w8-mx.124-10b.JDA1

Version Directory: c1130-k9w8-mx.124-10b.JDA1

Ios Image Size: 3635712

Total Image Size: 3635712

Image Feature: WIRELESS LAN|LWAPP

Image Family: C1130

Wireless Switch Management Version: 4.2.176.0 Extractings Secure Msg: decrypting with CCM returned failure

...

Unable to create temp dir "flash:/update"

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Stephen Rodriguez Thu, 02/05/2009 - 07:39

examining image...

extracting info (295 bytes)

Image info:

Version Suffix: k9w8-.124-10b.JDA1

Image Name: c1130-k9w8-mx.124-10b.JDA1

Version Directory: c1130-k9w8-mx.124-10b.JDA1

Ios Image Size: 3635712

Total Image Size: 3635712

Image Feature: WIRELESS LAN|LWAPP

Image Family: C1130

Wireless Switch Management Version: 4.2.176.0

This indicates the CAPWAP AP tried to join your LWAPP controller. I helped a colleague with a case like this yesterday. Only thing we found was to give the AP time to sit and reboot and it will enventually be able to get the download.

I believe that this:

SYS-3-CPUHOG: Task is running for (1994)msecs, more than (2000)msecs (9/4),process = LWAPP CLIENT.

is part of the problem, and still working on what this is.

HTH,

Steve

dbuttry Thu, 02/05/2009 - 19:49

Steve, thanks for the response. I think your colleague is Andy and the case was mine. It's nice that you guys watch these forums and lend a hand.

ericgarnel Thu, 02/05/2009 - 11:48

I may not be of much help, but we are considering moving from 4.2 to 5.2 and I am curious why you are moving down to 4.2.x

Thanks,

Eric

dbuttry Thu, 02/05/2009 - 20:00

We ran into several bugs. I was running 5.0 code and was hitting a couple of bugs. Everyone I spoke to said that 5.0 was very buggy and I should get off of it. We went to 5.2 and started having several issues. 2 of my 6 4404 controllers started rebooting on their own. Bug CSCsx19599. I am getting thousands of AP impersonation errors reported on every controller. That too I have found out is a known bug and am told that it is cosmetic only. My users are reporting that overall wireless response is not as good since the upgrade. Most users actually didn't know about the upgrade but have had many help desk tickets since. Also had a couple of WAN sites that the APs simply would not upgrade to the new code. (The APs now use CAPWAP rather than LWAP in 5.2.) I would like to get to a stable 5.2 so that we can support the new 1140 APs however, stability of what we have is more important right now.

Leo Laohoo Thu, 02/05/2009 - 13:05

I've never seen this error message before. Can you try the following:

1. Make sure the AP is NOT joined to the WLC. Manually downgrade the RCV code to, say, 12.3.7-JA3 version. (Don't forget to change the boot statement or delete the current RCV firmware after a successfull upgrade.)

2. Once that is done, do the following commands on the AP "clear lwapp private-config".

3. Boot the AP and let it join the WLC.

Does this help?

wesleyterry Thu, 02/05/2009 - 17:26

If your clear the config of the AP it will reboot and do the auto discovery process. So when I was moving APs from 5.2 to 4.2, I had to point the dns discovery entry to the 4.2 controller, clear the config of the 5.2 APs and they would reboot and join the 4.2 controller....

dbuttry Thu, 02/05/2009 - 20:06

I have found out that this is related to bug CSCsu52812 (WLC forwards multicast/unicast traffic to AP before it is fully joined). I have to have broadcast forwarding on due to an application that requires it. Apparently this is resolved in 4.2.182.0 or later 4.2 and 5.2.157.0 or later 5.2 codes, which is why we didn't see the issue with the CAPWAP WLCs on 5.2.157.0 code. The work around is to turn off broadcast forwarding to let the APs download the code, then turn it back on to support my application.

Actions

This Discussion

 

 

Trending Topics: Other Wireless Mobility

client could not be authenticated
Network Analysis Module (NAM) Products
Cisco 6500 nam
reason 440 driver failure
Cisco password cracker
Cisco Wireless mode