8.2MR6 Interim Release Availability

[rutvshah]

Release 8.2.154.17 Interim (8.2MR6)

We are pleased to announce Interim Release for 8.2MR6.

Please Register at below link to participate. 

http://cs.co/82MR6Interim

Once Requested for the Access on above link, Permission will be provided to download the Code from below link: 

Please select filter as 82MR6Interim

https://upload.cisco.com/cgi-bin/swc/fileexg/main.cgi?CONTYPES=wng-escalation

8.2.154.17

Resolved Caveats

Identifier	Headline
CSCvd36259	ME Controller intermittently Flaps with external AP.
CSCvd23175	2800/3800 WCPD memory leak observed
CSCvd60899	client de-authentication not working from cli and web
CSCvd61701	SSH to Standby RMI or Service port Fails
CSCvd70755	AIR-AP3802I crash due to kernel panic
CSCvb93124	WLC stopped working on spamApTask5
CSCvc82845	WLC returns nothing for SNMP get WEB ACL - cldcClientAaaOverrideAclName
CSCvd44446	EAP Response Dropped as a duplicate while First EAP Response was not even received on AP
CSCva52938	2800/3800 AP reporting incorrect CDP info to the Switch
CSCva58093	AP 3802 -N broadcasting incorrect Country Code in beacon and Probe Response
CSCvd88630	AP 3800: Ap crash due to 'wcpd' in 8.4
CSCvb11778	8.1.131.18 WLC crash on sisfSwitcherTask
CSCvd79745	Clients fail to pass auth when using L2 and Web-Auth on MAC failure on same WLAN
CSCvd86274	1800/2800/3800 Series AP does not send the Platform value via CDP when it is brand new
CSCvb93189	AP drops Retransmitted M3 from WLC
CSCvc62277	5520 crashes on running rrm commands on task emWeb
CSCvc74507	Fix incorrect commit of CSCuu59589 in 8.0-mr
CSCvd18773	8.2 clients unable to authenticate 'Sending assoc-resp with status 12 station'
CSCvb29996	1810W Hardware Watchdog reset crash PC=0xc03b3ffc, LR=0xc008af24, QCA 02698633
CSCvc08052	DFS false detection on AP2700
CSCvd98548	Kernel panic inside ForwardFrame function!
CSCvd91770	Trust-DSCP-Upstream broken on 8.2.151.0
CSCvc74876	8.2.145.21: AP2800/3800 CAPWAP disconnect then stuck in discovery loop
CSCvd98163	2800/3800 2.4Ghz TRPCID table update
CSCvd97103	IPv4 CPU ACL - IP-Address with netmask other than 255.255.255.255 doesn't work
CSCvd14806	APs randomly not showing any neighbors on both radios
CSCvc67005	2802 AP drops client ARP packets after web authentication
CSCvc65568	8821 fails 11r FT roam with "Invalid FTIE MIC"
CSCuz19004	Radio Resets on 702w
CSCva95121	Stale IP route left on Flex AP config if booting up in standalone mode
CSCvb61023	DHCP Option 82(remote-id) not present is some AP
CSCvc48624	Incorrect info of "show mesh convergence subset-channels detail milos"
CSCvc87433	Webauth with proxy does not work after 8.2
CSCvc49263	RLAN-VLAN mapping misconfigured after moving to secondary
CSCvd29564	Layer 2 Packet Drop Of CDP Packets for COS APs
CSCvb48354	RRM Not updating as per configured on WLC
CSCvc15976	Trustsec: AP: Not able to enable/disable AP inline tagging and SGACL Enforcement via SNMP
CSCvc28168	WLC set ZERO 802.11e QoS UP for part of the downstream voice packets and APs trust it
CSCvc75113	MIB compile error on CISCO-LWAPP-TUNNEL-MIB.my version 8.2
CSCvc12703	1810W LAN Port 2 maps to wrong VLAN on N+1 failover to Primary
CSCvd39346	WCPD slow memory leak
CSCvd63720	AP 3800: AP crash due to string HashMap_Arena
CSCvd78495	Failed to get ARP entry due to Aquantia PHY driver not loaded
CSCvb91652	WLC sluggishness due to flooding probe, need probe throttling configs
CSCvd30952	RM3010L-B-K9 Hyperlocation Module stopped working
CSCvc00328	with 3800 Surface pro gives less throughput
CSCvc04089	2700 series AP radio resets reason code 71 RADIO_RC_NO_REPORT
CSCvc81168	AP2702 unable to upgrade and failing with error: Unable to create temp dir "flash:/update"
CSCvd00289	2800/3800 capwapd init unsuccessful creating 2 capwapd causing WCPD watchdogd reset
CSCvd25231	Collect Stack info for silent reboot of 2800/3800
CSCvd33219	AP 3800: FW hang detected - chatter: wl1: fwHangDetect(357): FTR!
CSCvd58664	AP dropping EAP packets on Radio which is seen on Wired uplink
CSCvd61977	2800/3800 -radio coredump generation may stuck ca_status leading to IPC call function failures
CSCvd72664	1850 AP sometimes tags 802.1q vlan for native WLAN, causing ARP packet drop
CSCvd49909	COS AP - Kernel panic @ ClientCapabilitiesTracker virtual address invalid

[patoberli]

Somehow the follow link (top right menu) is broken, I get the error messages:

×

Status message

Bad token. You seem to have followed an invalid link.

You are not authorized to access this page.

[Gertjan Scharloo]

The upgrade to 8.2.154.17 has made a considerable number of access points unusable.

Are there any test users who recognize this issue ?

[slilley]

Gertjan, what kind of issues are you having?  Did you open a TAC case?  Considering deploying this version in a very-high visibility network in the next day, but your post has me a bit paranoid.

Regards,
Steve

[Gertjan Scharloo]

Different AP(s) in a reload loop are trying to boot from an incorrect path (flash:/update/…) and one AP stuck on rommon (seems to have a faulty flash)

We have 3100 APs(HD = -65dB signal)  and ~1% of our APS failed after the upgrade... 

(and Yes we have started a TAC-case for this issue)

[slilley]

OK, whew!  I've seen a 1-2% failure rate on upgrades going back 1-2 years now across multiple customers in different verticals, using either 8.0.x code or 8.2.x code.  I'm in the habit of collecting good logs before each upgrade so I can track down the failed APs and their connected switchport after an upgrade (using their CDP info).  So I hate so say it, but I don't think this is related to the beta - it's become a common problem that ends up costing me time on each upgrade I do.  At this point, I've ruled out a problem caused by Prime; it's definitely related to the AP code upgrade process (because simply rebooting the APs doesn't result in the same failures).

I'm glad you opened a TAC case...I keep thinking I should do the same, but all of my upgrades are in the middle of the night and I just want to finish and hit the road.  A TAC call at 4AM for a problem that I know they can't fix isn't appealing.  But I always hope that others open cases for it, so that it eventually gets addressed.  Huge PITA!

For those that haven't yet experienced this fun, the fix is to typically bounce the power to the AP from the switch side.  That almost always seems to correct it, but it still takes time to track down the correct switchport (and one of my big customers still has Nortel PoE switches, so CDP is useless there and they have to find the AP using it's MAC address).

Regards,
Steve

[Leo Laohoo]

For those that haven't yet experienced this fun, the fix is to typically bounce the power to the AP from the switch side.

Never, ever, execute a "reboot" command from the AP.  If one must reboot the AP, always kill the PoE to the port or pull the plug. 

NOTE:  No one from Cisco has spoken to me about this so this is all from my personal observation. 

When using the "reboot" command, the AP does a series of hidden process before actually rebooting.  Some of the process includes writing and modifying some files.

The upgrade to 8.2.154.17 has made a considerable number of access points unusable.

I'm not sure if you are seeing what I've seen when using 8.2.131.0.  During the boot-up, and after downloading the WLC codes, the AP would boot and "eat" the firmware to one of the radios.  When I mean "eat", I mean read and corrupt the file.  Since one of the radios isn't working the software crashes, taking along the AP.  The AP then goes into what I'd like to call a crash-boot-loop state.  

The only way to stop this is to break into ROMmon, format the flash and upload the IOS back up.  

Cisco has fixed this issue with 8.2.141.0 (and later). 

If this isn't what Gertjan and Steve are seeing then I'm keen to see what is going on.

[slilley]

Leo, this is the first time I've heard of a problem when issuing a reboot command from the AP.  Now admittedly, I'm not normally in the habit of needing to reboot APs -- the only time they typically get rebooted is during code upgrades or power outages.  However, I think it's completely impractical to reboot APs from the downstream switch except in one-off situations.  I hope your experience was an isolated occurrence, but I'll keep your advice in mind.  I'm actually working on a high-density deployment right now where I've been rebooting the 2 8540 WLCs and ~300 APs (using a Prime template) twice a week during off-hours, just to ensure we don't have any surprises during events when there are ~20K fans present and 4.5K devices connected.

Regards,
Steve

[Leo Laohoo]

I hope your experience was an isolated occurrence, but I'll keep your advice in mind. 

Nope.  Reboot my APs (by killing the port on the switch) regularly to fix issue with the AP loosing part of their configuration (CSCus50404).  Killing the AP until their details disappear from the controllers usually fixes the problem.  If they aren't fixed then formatting the flash and uploading the firmware fixes the problem.   Using the methods I've just explained, I never had to RMA any APs.  

I have two pairs of 8540 running on 8.2.141.0.  A third pair is being built and will be running 8.3.121.0.

[Rasika Nayanajith]

Different AP(s) in a reload loop are trying to boot from an incorrect path (flash:/update/…) and one AP stuck on rommon (seems to have a faulty flash)

I am seeing a similar behavior after upgrading to MR5 and then MR6 beta. Since most of AP are mounted, did not see console output to see what's going on, but APs are disassociated (3%).

What is your TAC reference number specific to this issue.

Also what's the fix you found so far for those ROMMON APs? 

Rasika

[Gertjan Scharloo]

Our TAC case for the flash issue is : SR 682389570

Quick fix

- 75% of the existing problems - format flash, restore recovery image

- 25% generating (syslog) message "Save LWAPP Config: error saving config file" - AP is serving client but the condition is very bad..., after reboot there is a change you will lose this AP or it will fix temporarily : It seems that the flash is really damaged...?!

We are seeing a lot of client issues with 2802/ 5520 : 8.2.154.17

- Killer Wireless-n/a/ac 1535 Wireless Network Adapter, driverVersion: 12.0.0.309

- Intel 8260: driverVersion: 19.10.1.2

On this moment there is no TAC-case : Problem is difficult to identify....

[Rasika Nayanajith]

Thanks for the detail Gretjan

[Leo Laohoo]

- 75% of the existing problems - format flash, restore recovery image

This sounds very much like CSCvd07423.

[patoberli]

Regarding your client issues, make sure to update your Intel drivers to the package 19.60:

https://downloadcenter.intel.com/download/26782/Wireless-Intel-PROSet-Wireless-Software-and-Drivers-for-Windows-10-?v=t

Intel has many bug in their drivers before 19.60. If you run Windows 10 and use Microsoft Windowsupdate (not WSUS), the driver might be updated automatically through it.

Then Microsoft released an update yesterday for the creators build 1703 which also fixes various perfomance issues with Wi-Fi, but that only affected 1703: https://support.microsoft.com/en-us/help/4022716/windows-10-update-kb4022716

[Gertjan Scharloo]

 I have update the Intel(8260) drivers 19.10.1.2 to 19.10.5.3 (package 19.60 - Win7 - 64 bit) There is no improvement. Random problem still occurs with her laptop (Elitebook 820 G3) and 2802i AP - 8.2.154.17. All other persons are still complaining.

Problem has also been observed on a macOS Sierra - 10.12.5 (16F73) MacBook Pro (Retina, 15-inch, Mid 2015) . So i have different OS and hardware in my environment. There has been no progression for more than two months (8.2MR6)

What is going on rutvshah? Why should I wait so long for an update? I have never experienced this before!!!!