We recently upgraded our 4402 WLC to version 188.8.131.52. Since then, we have had issues where clients randomly get disconnected. Searching through this forum and online...I have found some references that suggest there may be a problem with the 1242 APs and 184.108.40.206, however I cannot find out any details.
Is there anyone out there with 1242AG APs that knows of issues with 220.127.116.11? We upgraded to that instead of 5.X on the recommendation of a TAC Engineer.
I posted s response on the other thread. Don't upgrade to 5.X.... listen to TAC! If you plan on downgrading to 4.1.185, you will have to reconfigure the wlc from the startup wizrad. I do have a few 1242 deployments on the 4.2.130, but this was customer upgraded not my initial code. They haven't complained about any issues.
Can you clarify what you are seeing?
Thanks for both your reply's. I think in the other thread there may have been a typo.
What started happening was that clients would be dropped from the nearest AP and then re-associate with one farther away. After a few seconds, clients would drop that association and go back to the original AP.
I think what might have been happening was the coverage hold algorithm kicked in and it was causing clients to get disconnected. We were on 4.1.171 prior to the 4.2 upgrade and didn't see that issue. Nothing else has changed in our environment...so I was thinking the issue might be re-worked code for the RRM. The timing was always kind of random (sometimes every 2-3 minutes, sometimes 10 minutes), but in the SNMP logs I always saw coverage hole messages when the issues were occurring.
Does any of this make sense?
Thanks again for your help.
It makes a lot of sense and there has been a maintenance release just published this week. This is 4.2.173 and should resolve some of your problems. I would try this before regressing to older code.
Thank you for your reply.
Do you know of any particular issues with RRM and 4.2.130...or perhaps it just didn't work correctly in 4.1.171?
It just always bothers me when something that worked fine before a software/firmware upgrade has issues after the upgrade and I cannot find any known problems with the new firmware.
I looked through the release notes for 4.2.173 and while there is a lot of good reason to upgrade...I didn't see anything particular for the coverage hole algorithm or 1242 APs losing clients.
Can you recommend a brief course of action? We have already opened a TAC case...but are waiting to hear back.
Thanks again for any help.
There are constant unlisted upgrades to RRM. If they knew that they had a problem in the 4.2.130 that they didnt have in 4.1 then they fix it and quite often you never even knew it was fixed. Until you talk to the developers of course. I would just try the new 4.2 and see what happens.
Have you received any news back from TAC about your problem you experiencing or have you solve it now please share your experience with us?
We also did an upgrade to 5.2 and kept getting deauth attacks. We tracked down the MAC addresses and it turned out to be our own APs. We downgraded to 4.2.130 because it was our previous version before the attacks and it still shows deauth attacks. Our clients will connect for about 10-20 sec before getting kicked off and try to reconnect to another AP. We have a mixture of almost 300 1230 and 1240 APs on two WiSM blades and are at a loss on what to do next. We have a TAC case open, but the TAC engineer doesn't have any answers either.
Hi to all,
I know this is an old post but i had a few months ago exactly the same problem.
I opened a case with the TAC and we were fighting with this for like a month doing all the steps that you guys have done here (upgrading, tunning the RRM,sniffers, etc) and there was no solution provided by them, because my customer was about to take the problem to "other level" we decided to replace the controller and that solve the issue, with this new controller the has not been any problems.
I guess that was a hardware failure at least in my case, were you able to find another solution???
Just wanted to update the status of this issue because it is still an issue. We recently upgraded to the latest 4.2 release. Same problem. What we are being told by Cisco is that they are seeing a lot of interference. The current theory is something along the lines of...there is actually a bug or something else going on with the older releases that allowed them to work in our environment. Now that whatever that issue is has been resolved, we are seeing the problems in our environment.
That is all I have...I would try to replace the controller...but unfortunately I don't have a spare.
The version that I have on my WLC is the 18.104.22.168, that is the one that the TAC engineer that assisted me told me to install and he said that it was at that moment the most stable release.
But as I told you before that, at least in my case, that didn't solve the issue, the only thing that solved it was the replacement of the WLC.
I believe that if you have been with the TAC this long you can escalate the case to a higher level and request an RMA for the WLC.
Hope this help
Thanks. I'll definitely mention this to the engineer.
Did the controller you had ever work properly? Our controller worked fine until we went to 4.2.xxx and downgrading it to 4.1.171 also returned it to a working state.
The controller was working fine with the version 22.214.171.124 for like 6 months since we installed it, during the troubleshooting process the TAC never told me to perform a downgrade to a 4.1.xxx version.
The replacement WLC that we installed is actually with the 126.96.36.199 and is working without any problem.
I don't know if performing that downgrade could help me in my case but it seems that in yours it does, i think if your WLC works in that version you should stay there, but still there has to be and explanation from the TAC regarding this.
I thougt I was the only one with this problem, if they provide you with another solution please share
Everybody is advised to upgrade anyway because of a security hole exploit. Most people will be upgrading to 4.2.176 and so will I.
Advisory ID: cisco-sa-20090204-wlc
Did the TAC gave you a solution for this?? It seems that the problem is back for me, the WLC worked fine again for like 6 months but my customer call yesterday telling me that the disconection is there again. I'll check the logs and all that and also upgrade to 188.8.131.52 and if that don't solve the issue I'll downgrade it to 4.1.171.
I wonder if your can tell me if there is a special procedure for the downgrade and if you didn't have to also downgrade the Boot version, I mean what are the versions that you have of IOS and boot??
Thanks in advance.