Running WISMs on 6.0.196 and 4404's on 6.0.196 and seeing many wireless disconnects.
TAC has released to me 18.104.22.168 but still experiencing drops and another unidentified bug that I'm waiting to hear back on.
Anyone running 6.0.196 and seeing the same? Might be downgrading from 6.0.196 to 5.2.193 this weekend.
Kind of at a loss and need to get this resolved.
Sadly, many people have run into this issue (check the second listed bug)
Wireless LAN Controller Software
Base Code: 22.214.171.124, 126.96.36.199, 188.8.131.52
Special Build: Following options are available:
1. Move to 184.108.40.206 Release posted on CCO. Please note, 7.0 is a new feature release.
2. Contact TAC to get a 6.0 Special or Beta release with fixes for the bugs below.
3. Wait for the CCO release of 6.0 MR3 (Maintenance Release), which is planned for July/August 2010
The code is designed for 2100 / 4400 / 5500 / WiSM / WLC3750 / WLCM
This Software Advisory Notice is issued against all the above Wireless LAN Controller software versions due to the following bugs:
CSCtf34858 Client can't transmit traffic if it reassociates to an AP within 20 sec
CSCte89891 Radio may stop transmitting beacons periodically
Agreed, but our conditions don't match. Maybe it doesn't matter though.
AP may stop transmitting beacons intermittently (maximum for 10 seconds) in a heavy multicast environment. Clients may drop during this period.
This problem will happen only in the presence of the following 3 factors.
1) RRM should be enabled (especially off-channel scanning)
2) Lot of multicast traffic should be present on the network.
3) Presence of power save clients.
This issue has been fixed in 7.0 release and H MR3 release. All previous 6.0 releases (and earlier) have the problem.
We are using statically assigned channels and power settings. Also very little multicast traffic.
We ran into this bug (or a very similar one) in 220.127.116.11. There was not a lot of multicast, and RRM was enabled (although the power and channels were statically configured). We went to 188 and have not had the problem since. I'm very hesitant to move to one of the newer releases until we get some better feedback, but as of today, we are stable at 188 and have been for 6 months or so.
My customer is experiencing similar client drops. However, they are not using RRM or multicast, running WLC code 18.104.22.168. Please share any info that comes available from the yet to be identified bug. They've been experiencing this for the better part of 6 months now.
Thanks for the info. I have a WebEx today to look into it further.
My thought was to downgrade to 5.2.193 might have to rethink that now.
I will update the tread with whatever information I can gather.
Just found the email with the bug ID we ran into -
I don't know about versions after 22.214.171.124, but we've not run into it since. BTW, we are running older 1231 APs...
6.0.199 has just been released today (ok, its not on the download site yet) but the release notes are, and has the software advisory bugs as being resolved.
Looks like I may free up a controller this weekend and move just a single building to the new release and test it.
I will post my findings..
With this being a multi-hospital environment I would prefer stability over the new features. I have applied this two one 4404 controller and moved a single offsite practice to it for testing. Only 5 access points but these are the loudest complainers when the wireless network experiences issues.
If this proves to be stable, then I will upgrade our other 4404s and WiSMs in a few weeks.
Has anyone moved from 6.0.196 to 6.0.199?
Was it a successful change? Are you still seeing any of the 6.0.196 buggy symptoms?
Upgraded one of our controllers and the users haven't had any disconnects or performance issues, yet. So far it looks really good!
If you have Vocera in your environment stay away from 6.0.199
Going from 196 to 199 fixed many issues that we were having but broke Vocera.
What seems to be happening is the keepalive messages that badge sends to the vocera server are getting dropped, the badge goes off net, and it goes into a 'searching for server' state. It may fix itself after 30 sec, 1min, 5min etc... it's very sporadic or a battery pull might work.
Has anybody else seen this?
We have this Vocera / 6.0.199 issue narrowed down to inter-controller roaming. The badge only goes into a searching for server state during an inter-controller roam event.
Working with TAC.
I should be getting a newly generated bug id later today. I'll post
it when I get it.
Basically what we think is happening is that when the badge performs a L2, inter-controller roam, the WLC the client roamed to is not updating the switch CAM tables like it should be. So far, this does not seem to be affecting laptops. However I heard of this happening with handheld scannersas well. So my earlier statement about vocera was because they were the first to complain this is not a vocera specific bug.
I just got word from our Vocera analyst that Vocera has released a notice concerning upgrading to 6.0.199. Guess this kills my upgrade planned for this weekend. I was hoping this was an isolated issue.
The Vocera Advisory states:
Vocera is aware of an issue that customers are experiencing after moving to Cisco WLC version 6.0.199 that manifests itself in a substantial increase in difficulty with badge communications to the Vocera Application Server over the network. Badges will display "Searching For Server" or "Searching For AP."
Vocera is working closely with Cisco and its mutual customers on the problem.
Please consult with Vocera Technical Support and Cisco TAC before upgrading to 6.0.199.
Yes, stay away from the 6.0.199
Here is the bug that has been filed for this issue: CSCti21621
I'm currently on a special eng release 126.96.36.199 - which fixes both of the following bugs: CSCtf34858 Client can't transmit traffic if it reassociates to an AP within 20 sec & CSCte89891 Radio may stop transmitting beacons periodically among others.
It is prior to the 199 'fix' that introduced the above bug,CSCti21621.
We made this change last night and so far so good.
So I take it this is fixed in 188.8.131.52? Not sure I'm ready to take on Clean Air bugs to fix CSCti21621. Is TAC going to release an engineering 6.0.199.x build?
Yes, before the bug was removed they had "Conditions: This is seen in cases where the wireless client's default gateway is an HSRP address." and that is exactly how we are set up.
184.108.40.206 is listed as a work around and not a fix because it was released prior to 220.127.116.11 which included a bug fix that introduced CSCti21621.
I have not heard about a 6.0.199.x eng release yet. We have been on 18.104.22.168 since 8/5 with no related issues that we were plagued with in 22.214.171.124 or 126.96.36.199.
Good info, I gave you 4 stars!
We've been waiting for 7.0 almost 2 years, specifically for a GLBP fix (CSCsv21441 and CSCsv21464). Please keep us posted on CSCti21621.
How has the testing been going and are you still on verison 188.8.131.52?
I was all geared up and ready to install 6.0.199 until the last bug you posted. With us having some gateways on our wireless network being HSRP addresses, it wasn't worth the risk. I have to do something pretty soon. I can't stay on our 6.0.196 code any longer, I'm still having lots of issues.
Yes, we were ready to go with 184.108.40.206 as well, until we found out that 199 would break our Vocera. CSCti21621 is listed in the bug toolkit as catastrophic and the workaround is to disable LAG. Good luck with that on a WISM.
I believe TAC and the WBU are extremely negligent leaving 199 posted on CCO with the AssureWave logo. They should have pulled it down and deferred it. How many unsuspecting engineers have downloaded and upgraded based on the AssureWave testing, only to find issue and have to revert back to a previous version.
Having said that, I'm told 220.127.116.11 should be posted in the next 2-3 weeks.....
That's good to know.
I'm happy to report that the 18.104.22.168 has been stable for us. I'll closely read through the the release notes of 22.214.171.124 but I probably will not upgrade at this time. I need to look forward to 7.x because I have a large deployment coming up at the end of this calendar year that will be using 5508's and 3502's so we will want to take advantage of the new features. I'm hoping by then there will be a solid MD for the 7.x train will be released.
not sure if you looked at the CSCti21621 Bug Details recently but the 'Fixed-In' has been updated since I last looked.
Yes we did it and we have an improvement with the L2 roaming issue bug (CSCti21621). With 126.96.36.199 we had this "20 seconds problem" and with 188.8.131.52 the problems are solved.
120 1252 APs
140 7921 Phones
In the last 2 days we could not find any other bugs.
We are very dissappointed about that. We opened a TAC Case last week and the TAC Engineer ist still working on it. We told him yesterdam that we solved the problem with this software and got no more respone. I am just asking me why we have to tell this "wireless expert" that there is a new software available that is the solution for our problem. Without NetPro we would still investigating the problem and sending more and more debugs to TAC. So I would like to thank everyone here for helping because NetPro made our customer satisfied.
Have other folks that were experiencing wlan drops upgraded to 6.0.199 and noticed an improvement?
Short of end user complaints, is there any other way to detect these drops and capture data when the drops ocurr?
Is the one building that you upgraded to 6.0.199 still running smoothly with no drops?
I have had three complaints of drops / application freeze ups from them last week. The testing has been positive enough that I am going to upgrade our remaining 7 controllers on Monday morning.
I will continue to post my findings.