Wireless network stability

Unanswered Question
Jul 14th, 2010

Running WISMs on 6.0.196 and 4404's on 6.0.196 and seeing many wireless disconnects.

TAC has released to me 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.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4 (1 ratings)
rob.huffman Wed, 07/14/2010 - 07:59

Hi there,

Sadly, many people have run into this issue (check the second listed bug)


v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin:0in; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman";}

Software Advisory

Wireless LAN Controller Software


Base Code:,,

Special Build: Following options are available:

1.     Move to 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



campbech1 Wed, 07/14/2010 - 08:11

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.

John Cook Wed, 07/14/2010 - 08:52

We ran into this bug (or a very similar one) in  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.


michacollins Thu, 07/15/2010 - 06:59

My customer is experiencing similar client drops.  However, they are not using RRM or multicast, running WLC code  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.

campbech1 Thu, 07/15/2010 - 07:06

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.

campbech1 Thu, 07/15/2010 - 11:09

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..

campbech1 Mon, 07/19/2010 - 00:51

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.

Chuck Dillon Thu, 07/22/2010 - 11:51

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?

campbech1 Thu, 07/22/2010 - 11:56

Upgraded one of our controllers and the users haven't had any disconnects or performance issues, yet. So far it looks really good!

Chuck Dillon Tue, 08/03/2010 - 07:17


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?

Chuck Dillon Wed, 08/04/2010 - 07:17

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.

campbech1 Thu, 08/05/2010 - 06:21

Ok this has me worried. We too have Vocerra in our emergency department. Any more news on this?

Chuck Dillon Thu, 08/05/2010 - 06:46

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.

campbech1 Fri, 08/06/2010 - 07:30

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.

Chuck Dillon Fri, 08/06/2010 - 07:43

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 - 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.

campbech1 Fri, 08/06/2010 - 10:32

Is the bug only present if your default gateway for the wireless user is a HSRP address?

Darren Ramsey Fri, 08/06/2010 - 12:41

So I take it this is fixed in  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?

Chuck Dillon Mon, 08/09/2010 - 07:50

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. is listed as a work around and not a fix because it was released prior to 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 since 8/5 with no related issues that we were plagued with in or

campbech1 Thu, 08/19/2010 - 06:13


How has the testing been going and are you still on verison

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.

Darren Ramsey Thu, 08/19/2010 - 06:53

Yes, we were ready to go with 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 should be posted in the next 2-3 weeks.....

campbech1 Thu, 08/19/2010 - 07:04

Just got off the phone with TAC and should be released later today, Monday at the latest.

Chuck Dillon Thu, 08/19/2010 - 07:19

That's good to know.

I'm happy to report that the has been stable for us. I'll closely read through the the release notes of 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.


andreas.eichhor... Tue, 09/14/2010 - 23:35

Yes we did it and we have an improvement with the L2 roaming issue bug (CSCti21621). With we had this "20 seconds problem" and with the problems are solved.

Customer installation:

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.

michacollins Thu, 08/05/2010 - 05:51

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?



campbech1 Thu, 08/05/2010 - 06:19

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.

Vinay Sharma Sun, 09/25/2011 - 10:59

Hello Chris,

Please mark the Question as Answered, if the provided information is correct and it helped. By doing that others can take benefit as well.


Vinay Sharma

Community Manager – Wireless


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