38021 APs issues with code set 8.2.111.0

[Patrick McHenry]

Hi,

Has anyone had issues with their 3802i APs using code set 8.2.111.0?

Luckily we have only replaced 1, 3702i with our new 3802is, but I would like to know if there is a known issue with clients disconnecting.

We are not having any wireless issues anywhere else in our environment.

Also, before installing the 3802i there was a 3702i in the same location with no issues for at least a year.

The bug tool didn't come up with much as far as bug related issues...

Thank you, Pat

[Leo Laohoo]

Pat, 

Try using 8.3.102.0.

[Patrick McHenry]

Thanks Leo -

is there a documented, known issue with the 3802i APs and 8.2.111.0 or is your recommendation based on experience?

Thank you

[Leo Laohoo]

known issue with the 3802i APs and 8.2.111.0 or is your recommendation based on

Pat,  

All I can say, for now, is I don't feel comfortable with 8.2.111.0.  I've got several TAC Cases open about 8.2.111.0 & the last time I had/have similar number of cases with TAC was 8.0.120.0 (and we all know how "stable" that particular version is).

[Patrick McHenry]

Leo,

Update on the topic:

We did go to 8.3.102.0, but found yet another issue with the code that didn't allow web auth for our Guest SSID. So, we had to go back to 8.2.111.0 ....which doesn't reliably support 3802s. We temporary took out the 3802s and replaced them with our old 3702s until a solid code version comes out that supports the 3802s.

That being said, we are running 8.2.111.0 and getting alot of calls about disconnecting issues...especially from cell phones and some slowness reports from laptops. You mentioned above there have been some complaints about 8.2.111.0...I'm thinking we should go back to 8.2.100.0 until Cisco comes out with something stable for the 3802s. That is the code we were running before we upgraded for 3802 support.

Thx

[jagan.chowdam]

Hi Patrick,

I've deployed approx. 1500 Cisco 3800 APs with 8.2.111.30 and facing issues with client connections, Clean Air, Wrong infomation showing up on WLC for XoR radios, etc. Cisco TAC recommended Maintenance release 8.2.121.12 for stability with ay deployment of 3800 series APs.

Here are the release notes for 8.2.121.0.

http://www.cisco.com/c/en/us/td/docs/wireless/controller/release/notes/crn82mr2.html

Some of the fixed bugs on that version are,

CSCuz96946 “Cisco AP2800, 3800 Series APs does not beacon WLAN with WPA+WPA2/AES+TKIP security”

CSCva46620 “Beacon stuck issue on 3802AP, off-channel 01”

CSCva37393 “Cisco 3800 AP: beacon stuck - off channel stuck”

CSCuy45955 “DFS scan causes beacon transmission to be stuck on AP”

CSCva04367 “Cisco 2800, 3800 Series AP: CPU stall followed by Cmd-Timeout”

CSCva21076 “Cisco 2800, 3800 Series AP: Rx hang detection resulting in multiple radio resets and reboots”

CSCva21474 “Cisco 2800, 3800 Series AP reset with msg “Function called by unexpected cpu#2131011124””

CSCva22630 “Cisco 3800 Series AP: client upstream data traffic stalls after roam”

CSCva32819 “AP 2800, 3800 APs: reloads unexpectedly due to Kernel panic - Out of memory: panic_on_oom”

CSCva49188 “8.2MR2: AAA VLAN override failing on Cisco 2800, 3800 AP on 8.2.111.30 release

Jagan

[Patrick McHenry]

Jagan,

Thanks for the input...

CSCuz45986....this one is based on a 8500 WLC, but still concerns me. We use 2, 5508 WLCs in Active/Standby mode

CSCva07307: Cisco 3700 APs: intermittent packet drop - that doesn't sound good either.

CSCva03376: Cisco AP3702i -UX: after primed carrier set 5-GHz only allowing four UNII3 channel - do you have any UX APs? We have deployed about 20 of them. If you have have, did you see any issues with this?

Thx

[Leo Laohoo]

Patrick, 

I recommend signing up for Release 8.2.124.x Beta (8.2MR3).

FYI to everyone, 8.3 train is classified as "long life" and 8.2 is considered as "short life".  Any improvements done to 8.2 train will be exported to 8.3.

[Patrick McHenry]

We've decided to go back to 8.2.100.0. This was the stable image we were running before trying to deploy the 3802s.

Thx

[Patrick McHenry]

Also, you might find this strange, but when I first brought up the 38021 AP at my desk I had no issues with connectivity. The port I had it connected to did not have portfast enabled.

So, just to make sure everything was the same, on the 3802i APs connecting switchport in production, I removed portfast......it seems to be more stable.

Of course, to me this sudden improvement doesn't make sense, but I've seen stranger things. I will continue to monitor for improvement.

Thanks

[Drew Speltz]

Did this correct your issue by altering portfast for those 3802 WAPs?