Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

WLC Version 7.0.250.0 Problems

I just wanted to warn that I have had serious problems with version 7.0.250.0 and have had to roll back to 7.0.240.0 on all controllers.

Initial testing on a WiSM v1 seemed ok (an upgrade fron 7.0.235.3). Still have one WISM controller working fine on this version with no issues at all.

Roll out to other WISM v1, 5508, 2500 and 3750G integrated controllers saw almost complete unusable wireless connections from almost all Windows clients (Intel 3945 6100 6200 6300 nics) attached to a WPA2 AES network with 802.1x + CCKM. Mixture of APs but mostly 1142N and 3502. MFP disabled due to previous intel client issues.

Main crux of the problems were drops in connection and when connected slowed to a complete crawl. Data transfer speeds were less than a few kb/s when they were associated at m15 speed!. I also had one controller put all a/n access points on the same channel when DFS was enabled.

All metrics seemed fine on the client RSSI/SNR etc could not see anything obvious at all.

A roll back immediately solved all problems.I was unable to log a TAC case at the time to investigate due to the severity of the issue.

17 REPLIES

Chris, Thanks for the

Chris,

 

Thanks for the feedback. Did you do any captures or debugs ? Im more curiuos than anything ..Let us know if you open a TAC case and the outcome.

__________________________________________________________________________________________ "Satisfaction does not come from knowing the solution, it comes from knowing why." - Rosalind Franklin ___________________________________________________________
New Member

Unfortunately I did not have

Unfortunately I did not have time to do debugs and dont have a spare 5508 controller to test with.

Silver

I have a TAC 630902995  open

I have a TAC 630902995  open and provided a ton of debugs and captures, but so far we could not find the reason. The engineer tends to put it on a "client issue". I admit, it does seem fixed if we upgrade the wireless drivers (currently it's 14.1.0.0 on the Intel card), but the issue isn't there with 7.0.240.0.

Silver

Small update. TAC is still

Small update. TAC is still open, so far no solution. I will now downgrade 3 of my 4 controllers and leave one on the new release for further testing.

Hall of Fame Super Silver

I have ran into issues like

I have ran into issues like this when upgrading code from an older release to a later release. This has even been an issue with the later code like 7.4.  The intel driver was always an issu issue with v14 to be honest.  This was also an big issue when going from autonomous to lightweight back in the days. The FUS was always to upgrade the driver.  If you noticed, other devices don't have this problem. 

Scott

-Scott
*** Please rate helpful posts ***
Silver

That is true. My problem is

That is true. My problem is that around 70% of our clients are unmanaged (laptops of students) and with 7.0.240.0 I can offer a reliable Wi-Fi even with the v14, which I can't do on 7.0.250.0.

On the other hand we had a LOT of issues with the v16 train on all controller releases, up to around 16.6. Since 16.7 it looks fine though.

Hall of Fame Super Silver

The other thing is that open

The other thing is that open auth even using WebAuth was never an issue. It was more when using WPA/TKIP or WPA 2/AES.  I had clients that had 80% consultants who used their own laptop. Well now your stuck supporting a code that works for them. Guest however... Never had issues since it was open auth. 

I upgraded a company recently to v7.0.250.0 on 4400's and told them they had to upgrade the drivers. They pushed the driver out to the domain machines and have had no issues. They were on v14 of the intel driver. I have other clients on the same code due to the WLC hardware and newer code versions in which they too had to upgrade their domain machines.  

Scott

-Scott
*** Please rate helpful posts ***
Silver

I can actually reproduce the

I can actually reproduce the issue even on Open Auth :( It always happens when the client is roaming a few times. Once it's stuck only a new roaming (or disabling Wi-Fi adapter on client) helps to un-stuck it. I admit that it does look like the client is throwing away the packets, but still, it was working on the 240 release.

But I think we will anyway soon upgrade our 4400's to something newer and then the clients will have to upgrade. I just hope this "soon" is late enough for newer clients with newer drivers as the standard :)

Hall of Fame Super Silver

It's always a challenge with

It's always a challenge with drivers even with the newer WLC models and code. Standards change and they implement that in the code version and laptop drivers all have their issues.  Just search on the forum for the intel card you have and I'm sure you will collect enough info to figure out what code versions will work for that. Issue is also when the laptops gets refreshed and a new wireless card comes with the new laptop. It's a challenge, but it's something I have always had to deal with. Any upgrades I do, I will mention that they need to look at their driver and it's recommended to go with the latest laptop vendors published driver version and not the wireless NIC card driver version. 

I have never had any issue with open auth to be honest. My clients would tell me right away as guest was the reason many had implemented wireless. 

Scott

-Scott
*** Please rate helpful posts ***
New Member

We have had the same problem

We have had the same problem with 7.0.250.0 and had to move straight back to 240, wish I had seen this first. This was on 4 WiSM's

Silver

It seems we also have this

It seems we also have this issue with 3502 AP and WiSM1. The previously smooth working 14.x (year 2011)  drivers from Intel with an Intel 6305 card don't anymore correctly work now. Controller doesn't show much. If I "troubleshoot" the client in Prime and collect the logfiles, then I get this all the time:

2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 0, 0, 0, 0, 0, 0, 0
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO:0, VI:0, BE:41, BK:0
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO:0:0, VI:0:0, BE:39:0, BK:0:0
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 2
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 58, 58, 58, 58, 58
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO_INNER_DSCP:0, SIG_INNER_DSCP:0, BE_INNER_DSCP:31, OTHER_INNER_DSCP:0,VO_OUTER_DSCP:0, SIG_OUTER_DSCP:0, BE_OUTER_DSCP:31, OTHER_OUTER_DSCP:0
2014-May-28, 16:17:53 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO_INNER_DSCP:0, SIG_INNER_DSCP:0, BE_INNER_DSCP:39, OTHER_INNER_DSCP:0,VO_OUTER_DSCP:0, SIG_OUTER_DSCP:0, BE_OUTER_DSCP:39, OTHER_OUTER_DSCP:0
2014-May-28, 16:17:53 CESTINFO172.16.102.11Active calls on ''{0}, radio {1}'': {2} 2c:3f:38:5a:b5:70, 2, 0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 0, 0, 0, 0, 0, 0, 0, 0, 0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 0, 0, 0, 0, 0, 0, 0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO:0, VI:0, BE:32, BK:0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO:0:0, VI:0:0, BE:20:1, BK:0:0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, 58, 58, 58, 58, 58
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO_INNER_DSCP:0, SIG_INNER_DSCP:0, BE_INNER_DSCP:16, OTHER_INNER_DSCP:0,VO_OUTER_DSCP:0, SIG_OUTER_DSCP:0, BE_OUTER_DSCP:16, OTHER_OUTER_DSCP:0
2014-May-28, 16:17:58 CESTINFO172.16.102.112c:3f:38:5a:b5:70, 2, VO_INNER_DSCP:0, SIG_INNER_DSCP:0, BE_INNER_DSCP:19, OTHER_INNER_DSCP:0,VO_OUTER_DSCP:0, SIG_OUTER_DSCP:0, BE_OUTER_DSCP:19, OTHER_OUTER_DSCP:0
2014-May-28, 16:17:58 CESTINFO172.16.102.11

Active calls on ''{0}, radio {1}'': {2} 2c:3f:38:5a:b5:70, 2, 0

 

Upgrading the Intel drivers to a paket later 16.7 seems to fix the issues, but it's still not nice that this problem is new with this release.  

Silver

Somebody posted now a bug

Somebody posted now a bug which sounds like this issue:

https://tools.cisco.com/bugsearch/bug/CSCup07492

Bug ID: CSCup07492

New Member

Same issue, logged case

Same issue, logged case 630684779, but decided to roll back as the impact was too big. Some debugs are there if Cisco people want them.

New Member

Hi.Several people mention

Hi.

Several people mention that downgrade on WiSM software is a bit risky. Things like "loosing configuration" scares me.

How was your experience when downgrading from 7.0.250.0 to 7.0.240.0?

 

Silver

I had no problem downgrading

I had no problem downgrading our two WiSMs. You could make a backup of the configuration first (which I recommend).

New Member

Thanks, patoberli.I perform a

Thanks, patoberli.

I perform a backup of the configuration every night, so I have a very up-to-date file just in case. Did you also downgrade the ER-image? As far as I have read, this image is just in case the primary image get corrupt in any way.

Silver

No I did not downgrade the ER

No I did not downgrade the ER-image. As far as I understood it, the ER is more or less the bootloader which offers some recovery options. It normally needs to be updated to reflect the version number of the same image, so that this version number is shown in the bootup. And that's it, only to have the release number visible. You could even run a much older ER release (at least the same major tree) and use the recovery tools on a new version. I never tested that though, that's just how I understood the manual :)

33
Views
0
Helpful
17
Replies
CreatePlease login to create content