Downgrade from 5.2.157.0 to 4.2.176.0 PROBLEMS

[dbuttry]

After having lots of issues with 5.2.157.0, TAC is suggesting that I use 4.2.176.0. I have 6 production 4404s and 1 test 4402. I have wiped the config on my 4402 and loaded 4.2.176.0 code. I want to test all of my applications before trying to migrate everything over. I cannot get any APs to associate to the 4402 runing the 4.2 code. I suspect that since they are now looking for CAPWAP controllers, they aren't connecting to the LWAP controller now. Any ideas?

[wesleyterry]

What is your method for trying to get the AP to that controller?

Are you just assigning in the GUI a different primary controller? Or are you relying on "discovery" (with DNS/DHCP/Broadcast)?

Try the following command from the 5.x controller with an AP that you want to test with:

config ap primary-base

Put the 4402 controller name and controller IP address and maybe it will get the AP to register to it?

You also might want to make sure that your mobility groups are different for the time being.

If you are using DNS for controller discover, I reccomend pointing the CISCO-LWAPP-CONTROLLER entry to the 4402, and then erasing the configuration of the AP in question (GUI, configure access point and click CLEAR CONFIG)....

By the way, what problems are you having with 5.2? I'm being forced to upgrade this weekend to 5.x, so if there is a good reason not to I'd like to know.

[Scott Fella]

Westley,

Why would you go to 5.x code. 4.1.185 and 4.2.130 are Cisco Gold codes and are very stable. 4.2.176 is also very stable. We have very little deployment on the 5.x because of various issues. From my experience 5.0 is the worse, then 5.1 then 5.2. 5.2 being the latest release but its also where they combined the mesh train into the code also. Couple of my peers have downgraded their clients from 5.2 to 4.2.176 because of various issues.

[wesleyterry]

Honestly I'm doing it because my boss said she wants it done, even though they won't understand the consequences.

I think what I'm really going to do is upgrade to 5.2 (to get the experience setting it all up) and then I'll probably set it all back to the 4.1.185 like it is now...

I just was curious what problems people are really having.

[zhenningx]

From this link:

http://www.cisco.com/en/US/docs/wireless/controller/5.2/configuration/guide/c52lwap.html

"If the number of times that the discovery process starts with one discovery type (CAPWAP or LWAPP) exceeds the maximum discovery count and the access point does not receive a discovery response, the discovery type changes to the other type."

So the APs should try both CAPWAP and LWAPP discoveries unless they are 1140 APs which only support CAPWAP. Have you tried "debug lwapp" to see if the APs send out lwapp discovery?

We are running 4.2.176.0 and we have the issue that the web login page failed to load sometimes. We are considering to upgrade to 5.2.157. I am interested in what issues do you have in 5.2.157 too. Thanks!

[covalentsystems]

zhenningx,

Are you having issues with the https://1.1.1.1 auth page? We have a customer running 5.2.157 and we also have an intermittent problem where one of our controllers will not display the webauth page. Eventually it comes back but it's quite frustrating. We also are having an issue where the LDAP authentication intermittently stops working. We are considering downgrading to 4.2.176.0 but it sounds like the intermittent webauth page is a known issue at this revision as well.

[dbuttry]

We are not using webauth or LDAP auth.

[zhenningx]

Yes we are having the using with the https://1.1.1.1 auth page not loading. We have this issue on both 4.2.176 and 5.2.157. The problem seems like related to the load(web auth users number). We didn't have this problem on 4.1.185 before. Yes it is very frustrating!!

[wesleyterry]

Are you sure your webauth problem isn't because sslV2 is disabled?

In 4.2 they disabled it, which means on computers that have IE set to use SSLv2 (internet options, advanced, check box next to "use SSL v2"..) those computers can't open the https page.

This fix is to enable SSLV2 on the controller (config network secureweb cipher-option sslv2 enable) or to disable it on all the clients affected.

[zhenningx]

I am sure that is not the cause. We have that enabled.

And that one only affects IE 6 which uses sslv2. Our problem affect all the browsers and only happens under high load.

[wesleyterry]

Ok, was just pointing it out since that was a problem I had when I went to 4.2 (and was still present in 5.2)

And for the record, I had IE7 clients that were affected by it. But it is because those clients had a configuration for some reason to use SSLv2.

[Dmitry Halavin]

Hi,

When an AP is running 5.2 (CAPWAP) code, it will not join a controller running LWAPP code it does not get any CAPWAP discovery replies. So, to get it to join a LWAPP controller you have to put in an ACL so that the APs you are trying to downgrade cannot reach your 5.2 controller.

[Leo Laohoo]

Did you prime your AP's before deploying them into production? If so, is the WLC test 4402?

If the answer is yes, then the AP's are trying to join this controller.

Can you telnet/console into the AP that wouldn't join the production 4404? If yes, can the AP's ping the management IP Address of the production 4404? If yes, type the following command:

lwapp ap controller ip address

Does this help?

[dbuttry]

I am still having issues migrating APs from 5.2 to 4.2. I have put ACLs into place so that my test APs cannot reach the 5.2 WLCs. I have removed any reference to the 5.2 WLCs from DHCP. If I attach an AP that was running 5.0 code but never 5.2 code (ie: LWAP and not CAPWAP) it associates to my 4.2 WLC, downloads code, and works fine. However, any AP that has ever connected to a 5.2 WLC will not associate to my 4.2 WLC. I can see from the console port that it discovers the 4.2 WLC but then I get the message: “%LWAPP-3-CLIENTERRORLOG: Set Transport Address: no more AP manager IP addresses remain”

After lots of” spamProcessDiscoveryReply” errors it eventually ends up repeating the following: “%CAPWAP-3-ERRORLOG: Could not send primary discoveryrequest. The CAPWAP state has not moved to RUN yet”

To answer some of your questions: I have tried from WCS to “prime” the AP to the new controller and I have tried to just discover via DHCP/DNS. As far as what problems I ran into with 5.2. I have a location that has 5 APs that were running fine from the WLCs on the 5.0 code that will not associate to any controller now that they have been upgraded to 5.2. There is nothing special about this site, point to point T1s back to main campus. No ACL, no firewall, etc. Is it configured the same as several other sites that do work. If I bring an AP back to main campus it works fine. This is happening on about 8 APs at remote sites. Also since upgrading I am getting hundreds of errors for “AP Impersonation of MAC….” And “Potential Honeypot AP detected…”. I also have one controller that is now rebooting itself about every 90 min; another reboots about every 6 hours. The other 4 have not rebooted. I saw none of these issues before the upgrade to 5.2.

I just received an email back from TAC saying that I may be running into a bug with CAPWAP to LWAPP fallback on the APs. He is going to try to reproduce in his lab and get back with me.