<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"> 
  <channel>
  <title>Cisco Wireless Hot Issues from Cisco TAC</title>
  <link>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</link>
  <description>Hot Issues from Cisco TAC.  Please click the link for complete details.</description>
  <language>en-us</language>

  <managingEditor>wsisk@cisco.com (Wes Sisk)</managingEditor>
  <webMaster>news-at-cisco-rss@cisco.com (Cisco Newsroom)</webMaster>
  <pubDate>Mon, 20 May 2013 10:24:22 EDT</pubDate>
  <lastBuildDate>Mon, 20 May 2013 10:24:22 EDT</lastBuildDate>
  <generator>PERL</generator>

  <docs>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</docs>
  <ttl>10080</ttl>

<item>
<title>LMS 423 Installation not installed latest device packages for Inventory.,   CSCue69689</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue69689</link>
<description> </description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue69689</guid>
</item>
<item>
<title>Enhancement: webauth support for fragmented HTTP GET request, Open CSCug74297</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74297</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
A wireless webauth client may be unable to authenticate to the network. 
The problem is seen specifically with cached pages on the client browser.
Web redirect occurs fine on the web pages that are not cached.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
The HTTP GET from the client is arriving at the WLC in multiple TCP segments.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
- Current limitation of the controller; this is as per design.
If the HTTP request intercepted by controller is fragmented, it drops the packet as the HTTP request does not contain enough information required for redirection. 

- Reconfigure your network and/or the client&#39;s TCP/IP stack to ensure that the
HTTP GET arrives in a single segment.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74297</guid>
</item>
<item>
<title>Cleanup : mmListen:Failed to release a mutual exclusion object, Fixed CSCud22588</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud22588</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Traceback and message log flood with messages like
*mmListen:   osapi_sem.c:1077 Failed to release a mutual exclusion object. mutex unlock failed, not owned by the calling thread.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
IPv6 turned on the WLC. You do not need IPv6 to be turned on your wired network to see these error messages but more this are coming from Wireless clients which are ipv6/ipv4 capable.
These are cosmetic messages.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable IPv6 if IPv6 is not needed.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud22588</guid>
</item>
<item>
<title>LMS 423 bug fix CSCub77461 breaking RME Device Selectors., Fixed CSCue06188</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue06188</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

RME Device selector may not show all devices managed in LMS.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Adding the devices newly using bulk import option in DCR in LMS4.2.3. If already devices were added in LMS4.2.2, then issue is not applicable by upgrading to 4.2.3.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Follow the below steps to patch class files,

--&gt; Delete all the devices in DCR
--&gt; Take the backup of original class files from below location and then apply the files taken from LMS4.2.2 server,

CSCOpx\MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\inventory\dm\DeviceListManager

CSCOpx\MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\nm\rmeng\inventory\dm\server\DCRMessageProcessor

--&gt; Restart the daemons.
--&gt; Add the devices again using bulk import.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue06188</guid>
</item>
<item>
<title>AP not send traffic indication to client in power saving mode in time, Fixed CSCue71856</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue71856</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP does not send traffic indication to client in power saving mode in time
Due to that, Client in power saving mode cannot receive traffic.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Client which can support power saving mode may affect this problem.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable power saving mode on client side may help problem.
Nothing on WLC/AP side.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue71856</guid>
</item>
<item>
<title>Anchor Controller Hangs intermittently, Open CSCuf03454</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf03454</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Controller Hangs intermittently
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

 Web pass through clients anchored from Foreign controller to Anchor controller.
Controller became un responsive randomly.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reboot the controller.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf03454</guid>
</item>
<item>
<title>High cpu utilization with Flexible Netflow (FNF), Fixed CSCue67873</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue67873</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
High CPU observes on a router, when Flexible Netflow configured. Alternatively may also observe netflow information not being collected.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
This happens in DMVPN configurations with the tunnels and crypto with flexible netflow enabled as input on the tunnel, and when some packets have destination of the tunnel&#39;s IP address
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Configure traditional NetFlow, or configure flexible netflow only on &quot;output&quot; for tunnels.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue67873</guid>
</item>
<item>
<title>rf-profile configuration not shown in show run-config commands, Fixed CSCue54977</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue54977</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
rf-profile configuration is not seen in show run-config commands
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
N/A
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
use config backup to ftp/tftp server.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue54977</guid>
</item>
<item>
<title>AP unable to join controller, WLC indicates max APs supported reached, Open CSCub87374</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub87374</link>
<description>Symptom:
APs may not be able to join controller when running 7.2 controller code and controller indicates the limit for maximum APs supported is reached.
&lt;br&gt;
Conditions:
Controller indicates  limit for maximum APs supported is reached when it has not been reached as indicated in &quot;show license capacity&quot;.
&lt;br&gt;
Workaround:
Reboot Controller or switch to evaluation license.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub87374</guid>
</item>
<item>
<title>Radio reset: SF3 radio &#39;tx jammed&#39; due to corrupted rcv pak pointer, Open CSCuc06605</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc06605</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;AP1142 r0 coredump: corrupted rcv pak pointer
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;AP1142 r0 coredump: corrupted rcv pak pointer
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;none



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc06605</guid>
</item>
<item>
<title>cannot access controller GUI using management via wireless on 7.4, Open CSCue87961</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue87961</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; CANNOT ACCESS THE WEB GUI OF THE WLC
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; MANAGEMENT VIA WIRELESS IS ENABLED
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; USE THE WIRED NETWORK TO ACCESS THE WLC

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue87961</guid>
</item>
<item>
<title>AP must not  bridge ARP  traffic for clients with DHCP required in wlan, Fixed CSCud44269</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud44269</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; AP sending ARP responses for a client in DHCP required state
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;  Flex mode AP on 7.3.101.0
DHCP required enabled on the wlan. Roaming breaks for clients on Flex mode AP&#39;s
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;  Disable the DHCP REQD checkbox on the WLAN

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud44269</guid>
</item>
<item>
<title>OEAP600 low TCP throughput less than 50Mbps for personal SSID, Fixed CSCtx61744</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx61744</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
OEAP600 has very low TCP throughput for its personal SSID. Typical 40-43Mbps.
Even though an Association is established between 2x2:2 802.11n client and OEAP at MCS 15 (300Mbps), the real TCP throughput does not achieve 50Mbps.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
[802.11n 2x2:2 client] )))  5GHz Personal SSID ((( [Evora](LAN port)-------[FTP/TCP client/server]
Using iperf or FTP is good to measure the TCP throughput.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx61744</guid>
</item>
<item>
<title>WebAuth fails on 7.4 when user goes to a site with cached credentials, Open CSCug74974</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74974</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC fails to redirect clients to the WebAuth/Passthrough page
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
-Any WLC model running 7.4.100.0
-WebAuth/Passthrough WLAN
-Client begins the WebAuth/Passthrough process by going to a webpage that has cached their credentials in in a Cookie (such as &quot;remember me&quot; at www.yahoo.com)
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
-Have the client go to a website that doesn&#39;t cache credentials in Cookies
-Clear the client&#39;s Cookies for that website or all websites
-Downgrade WLC to 7.0/7.2/7.3

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74974</guid>
</item>
<item>
<title>7.2.103.0 code does not accept interface name starting with &quot;all......&quot;, Fixed CSCtz76153</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz76153</link>
<description>&lt;B&gt;Symptom:
Customer upgraded the wlc from a 6.0 to the 7.2.103.0 and  lost  2  dynamic valn interfaces  which he could  not recreate on the wlc &lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Conditions:
Upgrade  wlc to  7.2.103.0 you lose  dynamic vlan  having the word starting with &quot;all&quot; like alli,allied,allis etc .

They cannot  even create a new  vlan from GUI or Cli  the lot vlan &quot;allis&quot; in this case &lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:
replace their existing vlan id with any word  that does not have &quot;all at the  beginning of  it&lt;/B&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz76153</guid>
</item>
<item>
<title>CME 9.1 crashes with TLB (store) exception in CCSIP_SPI_CONTROL, Open CSCug81754</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug81754</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Router c2800 with CME9.1 crashes with signal 10 TLB (store) exception in CCSIP_SPI_CONTROL process
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

unknown
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

unknown

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug81754</guid>
</item>
<item>
<title>RRM grouping state stuck in computation state., Fixed CSCug46616</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46616</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
RRM group leader stuck and does not do channel or power update.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Potentially be triggered if you have AP&#39;s hearing each other when joined through a large set of WLCs where RF group name is same.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Limit the RF group size to 1000 APs. So place the APs accordingly and avoid salt and pepper deployment.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46616</guid>
</item>
<item>
<title>Fastethernet0/1 stops sending traffic when Fastethernet0/0 is shutdown, Fixed CSCsu26174</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsu26174</link>
<description>Symptoms: A Cisco 1800 series router may stop passing traffic on FastEthernet 
 interface 0/1 when FastEthernet interface 0/0 is administratively shut down 
 using the interface configuration command &lt;b&gt;shutdown&lt;/b&gt;. When 
 FastEthernet 0/0 is shutdown, the following message is displayed:
 %GT96K_FE-5-LATECOLL: Late Collision on int  FastEthernet0/0
&lt;br&gt; 
 Conditions: The symptoms are observed with FastEthernet 0/0 on a Cisco 1841 
 router and when the device at the far end of interface FastEthernet 0/0 is 
 configured manually to speed 10 or 100.
&lt;br&gt; 
 Workaround: Configure the far-end device to auto-negotiate the speed with 
the 1800 router.
&lt;br&gt; 
 Further Problem Description: This problem does not occur when pulling out 
 cable and re-inserting in FastEthernet 0/0. It also does not occur when 
FastEthernet 0/1 is reversed to FastEthernet 0/0.
 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsu26174</guid>
</item>
<item>
<title>&quot;clear ap config&quot; leaves indoor AP in mesh mode, Open CSCub14556</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub14556</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

If you use the &quot;clear ap config&quot; CLI, or the &quot;clear all config&quot; option, under
&quot;Set to Factory Defaults&quot; in the GUI, on an indoor AP that has been configured
for mesh (bridge) mode, the AP will remain in bridge mode.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

An indoor AP (such as an AIR-LAP1042) that has been configured for mesh.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

First, remove the IOS_STATIC_AP_MODE environmental variable from the AP.
This can be done on the console by reloading the AP, escaping into the boot
loader, and entering the bootloader command
ap: unset IOS_STATIC_AP_MODE 

Or you can copy flash:env_vars from the AP to a TFTP server, edit the file to remove the
IOS_STATIC_AP_MODE line, and copy the file back.

Then clear the AP config.  When the AP reboots, it should be back to factory defaults.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub14556</guid>
</item>
<item>
<title>AP memory leak - %SYS-2-MALLOCFAIL: Memory allocation failed, Fixed CSCug54108</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug54108</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

AP memory leak causes SSH (to AP) to fail
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

SSH to AP does not work
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

reboot the AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug54108</guid>
</item>
<item>
<title>HA redundancy does not fail-over to standby when powercycled, Fixed CSCue02707</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02707</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
HA redundancy does not fail-over to standby when powercycled after saving config
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Steps to recreate:
1. save config and confirm - either from GUI or CLI
2. toggle power switch on power supply to turn off power.

The standby-hot controller does not fail over to primary until either you plug the RP cable into a switch or you power on the controller again.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02707</guid>
</item>
<item>
<title>WCS 7 security scans reporting IAVA 2013-A-0053, CVE-2012-3499 and 4558, Open CSCug57908</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug57908</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WCS 7 security scans reveal the following issues:

IAVA 2013-A-0053 Multiple Security Vulnerabilities for Apache Server
Apache HTTP Server is an open source, commercial-grade web server application 
for various operating systems such as UNIX, Linux, and Microsoft windows. To 
exploit these vulnerabilities, a remote attacker would entice a user to access 
to a malicious link sent via email. If successfully exploited, these 
vulnerabilities would allow an attacker to execute arbitrary code in the 
affected browser and obtain access to sensitive information resulting in the 
compromise the affected system.
At this time, there are no known exploits associated with these 
vulnerabilities; USCYBERCOM is not aware of any DoD related incidents.
 
CVE-2012-3499:
Multiple cross-site scripting (XSS) vulnerabilities in the Apache HTTP Server 
2.2.x before 2.2.24-dev and 2.4.x before 2.4.4 allow remote attackers to inject 
arbitrary web script or HTML via vectors involving hostnames and URIs in the 
(1) mod_imagemap, (2) mod_info, (3) mod_ldap, (4) mod_proxy_ftp, and (5) 
mod_status modules.
 
CVE-2012-4558:
Multiple cross-site scripting (XSS) vulnerabilities in the balancer_handler 
function in the manager interface in mod_proxy_balancer.c in the 
mod_proxy_balancer module in the Apache HTTP Server 2.2.x before 2.2.24-dev and 
2.4.x before 2.4.4 allow remote attackers to inject arbitrary web script or 
HTML via a crafted string.&quot;
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
WCS 7.0.230.0 and 7.0.240.0. Earlier versions likely affected as well.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None at this time on platform. Blocking access from unsecured IP/Ports via 
Firewall/ACL would be the only workaround via the egress/ingress router or 
Firewall.
&lt;br&gt;
&lt;b&gt;Further Problem Description:&lt;/b&gt;
Additional details about the vulnerabilities listed above can be found at 
http://cve.mitre.org/cve/cve.html

&lt;b&gt;PSIRT Evaluation:&lt;/b&gt;
The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The 
Base and Temporal CVSS scores as of the time of evaluation are 
4.3/4.3:
https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?
dispatch=1&amp;version=2&amp;vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:H/RL:U/RC:C

CVE ID CVE-2012-4558, CVE-2012-3499 has been assigned to document this issue.

Additional information on Cisco&#39;s security vulnerability policy can be found at 
the following URL:
http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug57908</guid>
</item>
<item>
<title>url-redirect-acl not working on local-switching enabled 802.1x WLAN, Fixed CSCud89654</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud89654</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
On local switching enabled 802.1x WLAN, if the clients associate to a local AP(not flex AP), after successful authentication, only url-redirect attributed is accepted by WLC, not url-redirect-acl attribute, which causes failures on redirection thereafter. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
802.1x WLAN with local switching enabled. WLC 7.2 and beyond.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable local switching on the WLAN. But it also means that we have to segregate the local AP from flex APs on different WLCs, making it an impossible solution to mix them together on a single WLC.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud89654</guid>
</item>
<item>
<title>1140 AP line up / protocol down, not beaconing anymore, Open CSCud93491</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud93491</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
1140 AP not servicing clients anymore
Show controllers indicate missed beacons 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Occuring after upgrade to 7.4.100
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reboot the affected AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud93491</guid>
</item>
<item>
<title>WLC NAS id override is taking system name, Open CSCug73845</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug73845</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC NAS-ID override is taking system name instead the nas-id configured on Apgroup/Wlan/Interface.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Configure APgroup/Wlan/Interface NAS-ID.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug73845</guid>
</item>
<item>
<title>Rate limiting out of bounds on 4400/WiSM, Terminated CSCtj23339</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj23339</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
on 4404/Wism platfomrs, some applications are able to pass much more traffic than 
the average limit expressed on the bandwidth contracts
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
TCP rate limiting on the &quot;metal&quot; assigned to the WLAN
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable ports 3/4 or 1/2, so traffic only goes through one NPU.
This is not affecting 4402 or any other hardware platform




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj23339</guid>
</item>
<item>
<title>AP3600/3500  DFS false detect, Fixed CSCub26654</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub26654</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;AP3600 DFS false detect
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;AP3600 sees false radar events from the 7925 phone.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;none



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub26654</guid>
</item>
<item>
<title>Oracle recoveryarea filling causes MSE to not make backups, Open CSCug22218</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug22218</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The MSE may display odd behaviors like not taking backups or having trouble starting when the Oracle recovery area fills up and causes the archiver process to stop.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
At this time, there is no workaround.  Contact the TAC for assistance.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug22218</guid>
</item>
<item>
<title>HA redundancy does not fail-over to standby when removing ETH cable, Fixed CSCue02718</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02718</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
HA redundancy does not fail-over to standby when removing ETH cable
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Steps to recreate:
1. save config and confirm - either from GUI or CLI
2. unplug ethernet cable.

The standby-hot controller does not fail over to primary until either you plug the RP cable into a switch or back into the original controller
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

none.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02718</guid>
</item>
<item>
<title>7.3 5508 flexconnect APs client not able to connect, Open CSCuf61599</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf61599</link>
<description>&lt;B&gt;Symptom:
clients not able join
&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Conditions:
7.3 5500 wlc with flexconnect and NAT/PAT AP ip, 
&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:
enable data encryption
&lt;/B&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf61599</guid>
</item>
<item>
<title>AP reloads with DOT11-3-NO_BEACONING &quot;Not Beaconing for too long&quot;, Fixed CSCue62388</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue62388</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Access Point reloads with the following error displayed on the AP console:

Feb 21 19:17:39.498: %SYS-5-RELOAD: Reload requested by Dot11 driver. Reload Reason: Radio Not Beaconing for too long ....
Feb 21 19:17:38.966: %DOT11-3-NO_BEACONING: Error on Dot11Radio0 - Not Beaconing for too long - Current [...] Last [...]
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
This bug only occurs with 7.4.100.0 Wireless LAN controller software or 15.2(2)JB Autonomous release (posted Dec 2012 timeframe).  It affects all 802.11n APs except the Cisco Aironet 1600 Series.  802.11a/b/g APs (Cisco Aironet 1130 Series and Cisco Aironet 1240 Series) are not affected.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue62388</guid>
</item>
<item>
<title>Poor VPN Performance on 3600 APs, Open CSCue59791</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue59791</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Slow VPN connection on 3600s
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Wireless client on a 3600 AP using a VPN connection
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Install DTLS license and enable data encryption on the AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue59791</guid>
</item>
<item>
<title>SNMP packet size requests from LMS is too large., Open CSCtj88629</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj88629</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
LMS sends more than 512 SNMP requests to the FWSM, so it rejects the requests.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This occurs with FWSM and ASA&#39;s.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None. 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj88629</guid>
</item>
<item>
<title>Duplicate &amp; Invalid Association identifier entries for HREAP clients,   CSCub21596</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub21596</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Multiple issues seen with Invalid and duplicate AID entries on the WLC on the 7.2 code

*apfReceiveTask: Jul 18 18:22:01.632: %LWAPP-3-INVALID_AID2: spam_api.c:1226 Association identifier 8 for client cc:52:af:7f:d8:8b is already in use by cc:52:af:7f:d2:1

*apfReceiveTask: Jul 18 18:03:45.096: %LWAPP-3-INVALID_AID2: spam_api.c:1226 Association identifier 2 for client cc:52:af:7f:cd:4e is already in use by cc:52:af:7f:d6:a1
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; Flex connect mode Ap&#39;s on 7.2.103.0 . Also reported symptoms clients not responding to  ARP/broadcast issues but AP&#39;s do not move to standalone mode as in

CSCtz31572 and  the escalation code fix for this does not resolve the issue 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub21596</guid>
</item>
<item>
<title>AP association counter versus WLC association counter do not fit., Open CSCtn52995</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtn52995</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
HREAP - Reached max limit on the association ID for AP
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
1. Client 1 is associated to the controller with AID =1 on ssid x
2. Client 1 sends 802.11 Auth frame on ssid y, at this point AID = 1 is
freed at the AP. Auth frames are not honored at the controller, so
controller is not informed
3. No association frame arrives from client 1 at ssid 2
4. Client 2 associates to the AP and gets AID = 1
5. AP updates the controller about client 2 and AID =1, at this point the
controller adds duplicate entries and increments the count (controller
already has client 1 AID =1).

Counter is getting incremented and reaching 256.
It is due to the network conditions at the
customer site in which the 802.11 authentication frames are sent(sometimes
on different WLAN), but is not followed by association frames.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtn52995</guid>
</item>
<item>
<title>New client 802.11 auths fail on 3600 AP on 2.4GHz band after time, Open CSCug46718</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46718</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
New 802.11 client 2.4GHz authentications will stop after a period of time
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
2.4GHz Cliect auths on 3600
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
reboot AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46718</guid>
</item>
<item>
<title>mobility to 7.0/7.2 WLCs goes down after HA failover to secondary, Open CSCue79462</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue79462</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

mobility goes down to wlc running 7.0/7.2 after a SSO failover
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

SSO failover 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

re enter the same mobility entry (using the mobility mac address) on the wlc running 7.0/7.2. basically just delete and re add the entry.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue79462</guid>
</item>
<item>
<title>Flexconnect APs stuck in limbo when DHCP server is unreachable, Fixed CSCud33577</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud33577</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Flexconnect AP stuck in loop/limbo 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

When Flexconnect AP cannot renew dhcp lease. bvi1 interface goes down
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

reboot the AP or increase lease time to a high value. You can also use static ip addresses on the AP.

this issue is not seen if the native vlan on the flexconnect ap is set to &#39;1&#39;

Create a vlan 1 from the flexconnect group

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud33577</guid>
</item>
<item>
<title>Crash in sipSPISendAck, Fixed CSCth22485</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCth22485</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Cisco router crashed while running 15.1(2)T2 with SIP calls.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Router configured to handle SIP.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCth22485</guid>
</item>
<item>
<title>DB timeout on MSE due to Oracle password expiry, Fixed CSCud77760</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud77760</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
DB password expires on MSE
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
The MSE framework may stop responding due to expired database password due to a bug in DB password expiry limits.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
1. login to mse as root
2. stop mse
3. execute &quot;oracleDBStartStop.sh start mseorcl open&quot;
4. execute &quot;source /opt/mse/install/oracleenv&quot;
5. execute &quot;getdatabaseparams&quot; and save the output string, this is the 
db user password 6. execute
          su --command=&quot;sqlplus / as sysdba&quot; oracle
7. at the SQL&gt; prompt, issue the following commands

alter user mse account unlock;
alter user loc account unlock;
alter user wips account unlock;
alter user mse identified by &quot;&lt;paste the output from getdatabaseparams
here&gt;&quot;;
alter user loc identified by &quot;&lt;paste the output from getdatabaseparams
here&gt;&quot;;
alter user wips identified by &quot;&lt;paste the output from getdatabaseparams
here&gt;&quot;;
alter profile default limit password_life_time 370;
quit

8. execute &quot;oracleDBStartStop.sh stop mseorcl&quot;
9. restart mse


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud77760</guid>
</item>
<item>
<title>3600 access point showing multiple mac addresses in switch port.,   CSCuc72288</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc72288</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

Enabling port security on 3600 AP connected switch port, shows more than one mac-address.
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;

Version 007.003(101.000) 
AP Platform : ap3g2
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc72288</guid>
</item>
<item>
<title>Discovery may not stop properly when spaces are in LMS Install Directory,   CSCuf86663</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf86663</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
LMS Discovery may fail to stop properly or show discovery results as expected

Errors such as the following may be seen in CSDiscovery.log or ngdiscovery.log may be seen:
java.io.FileNotFoundException: D:\Program%20Files\CSCOpx\MDC\tomcat\webapps\cwhp\WEB-INF\lib\discovery.jar (The system cannot find the path specified)

[ Mon Mar 25 00:30:33 UTC 2013 ] FATAL  [CSDiscoveryManager : stopDiscovery]  : URN_NOT_FOUND : urn &quot;CSDiscovery&quot; : Not found !!
[ Mon Mar 25 00:30:33 UTC 2013 ] FATAL  [DiscoverySummaryAction : perform]  : Exception occured during stop discovery in CS. Reason : URN_NOT_FOUND : urn &quot;CSDiscovery&quot; : Not found !!
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This has been seen to occur on systems where the LMS install directory/NMSROOT contains spaces or some other special characters which require URL Encoding.

That includes the default install directories on Windows, such as C:\Program Files\CSCOpx or C:\Program Files (x86)\CSCOpx

In general Solaris and the Linux Appliance will be unaffected as their default install directories are /opt/CSCOpx and unaffected by this issue.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Backup existing LMS
Reinstall LMS in a directory without any spaces or special characters, such as E:\CSCOpx
Restore backup

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf86663</guid>
</item>
<item>
<title>Processing AAA Error &#39;Out of Memory&#39;, Fixed CSCud12582</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud12582</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Client RADIUS authentication fails.  &quot;debug client&quot; shows a message similar to this:

*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.983: 00:11:22:33:44:55 Entering Backend Auth Response state for mobile f0:d1:a9:24:d8:a7
*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.985: 00:11:22:33:44:55 Processing AAA Error &#39;Out of Memory&#39; (-2) for mobile f0:d1:a9:24:d8:a7
*Dot1x_NW_MsgTask_7: Dec 17 11:43:36.999: 00:11:22:33:44:55 Sent Deauthenticate to mobile on BSSID 20:37:06:00:11:22 slot 0(caller 1x_auth_pae.c:1394)

at the same time, the msglog shows a message similar to this:

*Dot1x_NW_MsgTask_7: Dec 17 12:30:23.296: #DOT1X-3-ABORT_AUTH: 1x_bauth_sm.c:447  Authentication Aborted for client 00:11:22:33:44:55

and the traplog shows a message like this:

297 Mon Dec 17 12:36:29 2012 Client Deauthenticated: MACAddress:00:11:22:33:44:55
                             Base Radio MAC:20:37:06:00:11:22 Slot: 1 User
                             Name: unknown Ip Address: unknown Reason:Unspecif
                             ied  ReasonCode: 1      
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Large scale deployments with multiple clients. RADIUS queues fill up and fail under heavy authentication/accounting load.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Disable RADIUS accounting and authentication.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud12582</guid>
</item>
<item>
<title>3600 AP sends invalid frames (0000.0104.xxxx) when changing primary WLC, Fixed CSCud97325</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud97325</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
- 3600/2600 APs sends invalid frames sourced with address 0000.0104.xxxx
- May result in security warnings on the switch, such as:

%AUTHMGR-5-SECURITY_VIOLATION: Security violation on the interface GigabitEthernet3/46, new MAC address (0000.0104.d634) is seen.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
- This happen when the primary / secondary WLC are changed in the AP High Availability tab.
- The bug will only occur with Cisco Aironet 2600 and 3600 Series Access Points
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud97325</guid>
</item>
<item>
<title>Wism controller shows oper-down after upgrade to 7.0.98.0, Terminated CSCtk34560</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtk34560</link>
<description>Symptom:
Customer upgraded 2 controllers from 6.0.199.4 to 7.0.98.0. After the upgrade and reboot, one of the controllers had a status of oper-down. No service port or management interface addresses were present in the &#39;show wism status&#39; output.  All aps remained joined to the controller, and no negative impact was noticed for the wireless clients.  We could not ping the wlc interfaces from the sup720 or anywhere. Telnet / ssh / gui access to the wlc was available.  Could not session to the controller frmo the sup720.   The wlc could ping default-gateways and other addresses, but it could not ping any of its interfaces (including managment).No arp issues were seen. 
&lt;br&gt;

Workaround:
Reboot the controller, and its status changed to oper-up, and normal operations resumed.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtk34560</guid>
</item>
<item>
<title>Show Lag Hash commands not available with WiSM2, Terminated CSCug63001</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug63001</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The commands &quot;show lag eth-port-hash&quot; and &quot;show lag ip-port-has&quot; are not available on the WiSM2 platform.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
All code versions.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug63001</guid>
</item>
<item>
<title>wism2 crash and reboot (bcastReceiveTask+1332), Open CSCug38794</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug38794</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
wism2 crash and reboot (bcastReceiveTask+1332)
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
wism2 crash and reboot (bcastReceiveTask+1332)
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug38794</guid>
</item>
<item>
<title>annoying traps from WLC Client with MAC address has joined profile, Fixed CSCuc12395</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc12395</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
continous trap message from WLC Client with MAC address &quot;wireless mac address of client&quot; has joined profie &quot;profile name&quot;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC running 7.2 or 7.3
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Upgrade to 7.4 WLC code and disable the trap control:
config trapflags client nac-alert [enable/disable]

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc12395</guid>
</item>
<item>
<title>ARP problems with MAPs, Fixed CSCuc03576</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc03576</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
1. Duplicate address detection on MAPs is not working as expected

2. MAP disconnects periodically (e.g. every 20 minutes) from RAP, then reconnects

3. MAP associates to RAP, and gets address from DHCP, and sends DHCP DISCOVERY
packet to WLC, but MAP never receives the DHCP DISCOVERY response.

Two underlying issues were found:

1. ARP requests (GARPs and normal ARP requests) are not reaching the MAPs. Thus
it is possible to get multiple APS with duplicate addresses, both joining the
WLC.  Or, the MAPs&#39; default gateway may be unable to resolve ARP for the MAPs,
preventing CAPWAP connectivity.

2. GARP for address detection should be 1 per minute; there are some APs
sending it every second for unknown reasons
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
CUWN 7.2 through 7.4.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
To avoid multiply assigned IP addresses, make sure the DHCP scopes are separated.

To work around other ARP problems:

* configure a static ARP entry for the MAPs

* configure routers on the MAPs&#39; subnets to install ARP entries when they
receive gratuitous ARP



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc03576</guid>
</item>
<item>
<title>AP Crash  due to chunk corruption; periodic client disconnects, Fixed CSCue08313</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue08313</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

1. An AP may crash due to low memeory.

2. An AP is seen to disconnect a wireless client repetitively, for example at
22 second,
or 62 second intervals.  When the AP disconnects the client, a syslog message
similar
to the following is seen:

Apr  4 00:36:22.582: %DOT11-6-DISASSOC: Interface Dot11Radio0, Deauthenticating
Station c8f7.332b.51ab Reason: Previous authentication no longer valid

During this time, if the client is monitored via repetitive iterations of the
&quot;show dot11 associations MAC&quot;, it will be seen that the &quot;Activity Timeout&quot;
value keeps decrementing, and the &quot;Last activity&quot; value keeps incrementing,
even if the client is actively transmitting and receiving data.

Thus, the AP disconnects the client once the configured activity timeout
period - typically 20 or 60 seconds - expires.  The client will typically, but
not necessarily, immediately reassociate.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Association of wireless client to AP.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
To avoid the repetitive associations, configure maximum activity timeout values:

dot11 activity-timeout unknown default 100000
dot11 activity-timeout client default 100000 maximum 100000
dot11 activity-timeout repeater default 100000 maximum 100000
dot11 activity-timeout workgroup-bridge default 100000 maximum 100000
dot11 activity-timeout bridge default 100000 maximum 100000

Some CCX clients may not use these activity timeout values - in such a case,
you must also disable Aironet extensions on the radio:

no dot11 extension aironet





</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue08313</guid>
</item>
<item>
<title>.Foreign doesn&#39;t rehome client after interAP group roam to his home vlan, Fixed CSCtt15179</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtt15179</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

When two wireless clients that are associated to APs on the same controller
try to communicate, one may not pass traffic to the other.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

L3 roam within WLC.  For example:

Associate client to an AP on WLC1 in VLAN1.

Roam client to an AP in an AP group in VLAN2 on WLC2 - now the client is
anchored to WLC1.

Now roam the client to an AP on WLC2 but in an AP group in VLAN1.  Now, even
though the client is in VLAN1, and is on an AP on WLC2 that is in VLAN1, it
will remain anchored to WLC2.

This will cause a communication (ARP) failure when this client tries
to talk with another client that is in VLAN1, but that is local to WLC2.
&lt;br&gt; 
&lt;B&gt;Workaround:&lt;/B&gt;

Don&#39;t use AP groups for this WLAN.






</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtt15179</guid>
</item>
<item>
<title>AP group change to RAP in MAP mode results in stranded RAP, Fixed CSCug64950</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug64950</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Modifying the AP group to a RAP which is currently connected through the radio backhaul (RAP in MAP mode due to wired uplink being down), the RAP will get stranded.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Mesh AP (tested with 1552 and 1522 models) in role Root AP, with no wired backhaul available.
WLC on 7.0.240.3
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Need console/telnet/ssh access to clear the capwap private config:
 clear capwap private-config
 reload

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug64950</guid>
</item>
<item>
<title>AP crash during normal operation, Fixed CSCtu39166</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtu39166</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP rebooted with crashinfo created during normal operation.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Normal operation
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Nothing

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtu39166</guid>
</item>
<item>
<title>Custom logo not displayed when webauth secure web is disabled, Fixed CSCuc52528</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc52528</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Custom logo not displayed on webauth login page
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Internal webauth with custom logo configured
webauth secure web disabled
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Enable secure web or use a custom page


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc52528</guid>
</item>
<item>
<title>Option to Maintain Layer 3 Auth (Web Auth) Until Session Timeout, Open CSCua55111</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua55111</link>
<description>&lt;B&gt;Description:&lt;/B&gt;

Enhancement request for a setting to allow for clients to maintain Web Authentication/Passthrough (Layer 3) Sessions until the Session Timer is reached.  Today, any deauthentication event will purge the session and require the end-user to manually re-authenticate.

Enabling this setting would allow for users to not be forced to re-authenticate until the Session Timer is reached.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua55111</guid>
</item>
<item>
<title>WLC should not allow disable of MCS rates on 800ns guard interval, Fixed CSCub82468</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub82468</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Some 11n clients may fail to associate or pass traffic after connection
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
some MCS rates disabled on 0 to 15

Some interpretations of the 11n standard, may lead to  enforce that 11n MCS rates are not disabled if operating on 800 guard interval
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Do not disable 11n rates


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub82468</guid>
</item>
<item>
<title>change radius-server retransmit, timeout for FlexConnect access point, Open CSCtz16966</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz16966</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
You can configure the controller to allow a FlexConnect access point in standalone mode to perform full 
802.1X authentication to a backup RADIUS server. You can configure a primary backup RADIUS server 
or both a primary and secondary backup RADIUS server.

It&#39;s better to add a new function to configure the controller to change radius-server retransmit/timeout when a FlexConnect access point in standalone mode to perform full 802.1X authentication to a primary/secondary backup RADIUS server.

When a FlexConnect access point in standalone mode and primary backup RADIUS server is down, Windows 7 supplicant PEAP authentication gets radius reject from secondary RADIUS server.

If we can change radius-server retransmit/timeout, this authentication failure is avoidable.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Reproducibility : Yes
Software: 7.0.230.0
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
There is no workaround at this time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz16966</guid>
</item>
<item>
<title>WLC reports incorrect number of AP&#39;s joined, Open CSCug38065</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug38065</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
 WLC shows different numbers of AP&#39;s joined.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
7510 WLC with 7.3.101.0 firmware

CLI &#39;sh ap summ&#39; and GUI &#39;All AP&#39;s&#39; screen under WIRELESS tab both show 587 AP&#39;s joined to the WLC
the GUI &#39;802.11b/g/n&#39; screen under the wireless tab shows 773 AP&#39;s currently on the WLC.

License usage on GUI only reports 587 AP&#39;s out of 900 AP count RTU License config
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug38065</guid>
</item>
<item>
<title>Memory Leak in CCE dp subblock,   CSCub62582</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub62582</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

memory leak in CCE dp subblock of Chunk Manager.

&quot;show proc mem sorted&quot; and &quot;show chunk summary&quot; show the leak. 
Device will eventually crash due to low memory.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Normal
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Schedule proactive reload of the device to avoid unexpected crash

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub62582</guid>
</item>
<item>
<title>Creation of invalid AP group with special character # or %,   CSCtg45622</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtg45622</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP group name with special characters # or % cannot be created in WLC GUI and are &quot;invalid&quot;.  There may additional special characters that are considered &quot;invalid&quot;.  However, AP group creation can occur in WLC CLI.  Then, the created AP group name with # or % will include all WLANs with default mapped interfaces that cannot be modified or deleted.  This &quot;invalid&quot; AP group entry cannot be deleted in WLC GUI.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC running 5.2 or later with AP groups feature (not AP group VLAN).  WLC 5.1 or prior software allow for both CLI and GUI creation and deletion of such invalid AP group names.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Delete &quot;invalid&quot; via WLC CLI.  Make sure terminal software is not running Unicode (UTF8).



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtg45622</guid>
</item>
<item>
<title>CLI to allow MRCPv1 to support RFC 2616, Fixed CSCti50250</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti50250</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
VXML client is failing to parse Russian external grammer from Nuance Speech Server.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Russian external grammer hosted on Nuance Speech Server 5.0.2 [ASR 9.0.3 - Russian Lang Pack; Realspeak 4.5 - Russian Lang Pack]
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti50250</guid>
</item>
<item>
<title>excessive pim traffic seen over HWIC-ESW cards, Fixed CSCti88571</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti88571</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; Excessive PIM traffic to 224.0.0.13 is seen
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; When connected two layer 3 devices through two layer 2  trunked devices over ESW wics .
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; This problem is not seen when using only one layer 2 trunk over an ESW wic

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti88571</guid>
</item>
<item>
<title>Crash at disc_tx_requeue_client, Fixed CSCts33018</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCts33018</link>
<description>Symptoms: The Cisco UC500 crashes at Dot11 subsystem after upgraded from
SWP 8.1.0 (15.1(2)T2) to SWP 8.2.0 (15.1(2)T4)
&lt;br&gt;
Conditions: This symptom is observed when a Cisco 2900 PoE switch is connected
to the Cisco UC540 with Cisco phones and an iMac is connected to the switch. An
Apple laptop is also connected using wireless.
&lt;br&gt;
Workaround: There is no workaround.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCts33018</guid>
</item>
<item>
<title>clarification  maximum client count for non 6oo series AP&#39;s in OEAP mode, Open CSCug67279</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug67279</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;  maximum number of client connections on the OEAP
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;  WLC code version 7.4
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug67279</guid>
</item>
<item>
<title>Prevention of cross-site req forgery for management GUI, Open CSCud50283</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud50283</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

The Cisco Wireless LAN Controller may be affected by Cross Site Request Forgery (CSRF) attacks.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Default configuration.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None.

&lt;b&gt;PSIRT Evaluation:&lt;/b&gt;

The Cisco PSIRT has assigned this bug the following CVSS version 2 score. The Base and Temporal CVSS scores as of the time of evaluation are 4.3/4.1:

https://intellishield.cisco.com/security/alertmanager/cvssCalculator.do?dispatch=1&amp;version=2&amp;vector=AV:N/AC:M/Au:N/C:N/I:P/A:N/E:F/RL:U/RC:C

CVE ID CVE-2012-5992 has been assigned to document this issue.

Additional information on Cisco&#39;s security vulnerability policy can be found at the following URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud50283</guid>
</item>
<item>
<title>HWIC-1FE HWIC-2FE stops processing incoming packets, Terminated CSCuf02446</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf02446</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
FastEthernet port on a HWIC-1FE or HWIC-2FE will stop processing incoming packets. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This occurs when there is a prolonged duplex mismatch between the router and the peer device. Once the interface stops processing packets the only way to recover is to reload the router.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Prevent a duplex mismatch from occurring.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf02446</guid>
</item>
<item>
<title>1602e AP has insufficient TxPower on 2.4ghz (13dbm), Open CSCug73660</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug73660</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
as per the data sheet, the 1600 AP should have 17dbm of tx power on 1 antenna and up to 22 with 3 antennas.
http://www.cisco.com/en/US/prod/collateral/wireless/ps5678/ps12555/data_sheet_c78-715702.html
The reality is that it&#39;s much less in reality.
show controllers output shows that power level 1 is 13dbm on 3 antennas (8dbm per antenna)

Comparing show controllers output with a 3600e clearly shows that 1600AP has less tx Power. Field tests also show it has a much smaller coverage area.

This is on 2.4ghz. 5ghz power is meeting expectations. This was noted in -E reg domain.

Also, modifying the antenna gain has no effect at all on tx power
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
7.4.100 WLC code
European regulatory domain in countries where the expected power level is 17
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug73660</guid>
</item>
<item>
<title>Beacon drops while Radio Monitoring is running in 12.4(21a) train, Fixed CSCte84991</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte84991</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Beacon sometimes drops while Radio Monitoring which can be enabled by WLSE is running in 12.4(21a) train
Beacon drop makes a WLAN client lose the association. As a result, a communication failure happens.
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
* 12.4(21a) Train IOS ( This symptom is not observed in 12.4(10b) train)
* Introducing WLSE/WDS
* Radio Monitoring is enabled in WLSE
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
Disable Radio Monitoring in WLSE

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte84991</guid>
</item>
<item>
<title>WLC keep client entry forever, after idle timeout, Fixed CSCub51171</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub51171</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Some APS refuse new client association because they already have over 200 clients associated.
You can see that those clients are physically not present as they show as &quot;last heard&quot; by all APs a long time ago.
User idle timeout did not kick in.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC 7.2.103
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Configure session timeout

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub51171</guid>
</item>
<item>
<title>WLC crashing due to the Task Name emWeb, Fixed CSCuc33063</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc33063</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WLC crashed with the task name emWeb
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

crash on &quot;show tech-support&quot; command, while pulling TPCv2 data
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc33063</guid>
</item>
<item>
<title>serial timeout 18000 is printed on WLC, Open CSCug55532</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug55532</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
&#39;serial timeout 18000&#39; is printed in the result of &#39;show run-config commands&#39; on WLC running 7.0.235.5 in spite of the fact that the value should be 9600 at a maximum.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Upgrade a WLC image from 6.0.202.0 to 7.0.235.3.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
reconfigure the setting of serial timeout

&gt;(Cisco Controller) &gt;config serial timeout ?
&gt;[0-9600]       Enter time in seconds.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug55532</guid>
</item>
<item>
<title>AA does not send email for CRS XR BGP syslog, Terminated CSCug52479</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug52479</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

There is no Automated Action Email generated after BGP syslog is received
on LMS 3.2.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

BGP syslog from CRS1 running XR.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

N/A.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug52479</guid>
</item>
<item>
<title>Cannot change HREAP Vlan mapping -  Error :WLAN ID 3 cannot be alterd, Fixed CSCty40179</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty40179</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Cannot change HREAP Vlan mapping -  Error :WLAN ID 3 cannot be alterd
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
The issue is that the SSID &quot;SAW_Voice_Authorised_Access_only&quot; exceeds 31 bytes.
 While we allow user to create an SSID profile with 32 bytes, as part of profile payload we store only 31 bytes, which leads to mismatch and hence the controller does not allow to change the VLAN. This is the reason why only this particular WLAN causes issues.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Dont execd the  31 bytes when creating SSID profile 


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty40179</guid>
</item>
<item>
<title>3602 AP may select the  wrong country on the controller, Open CSCud84109</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud84109</link>
<description>Symptom:
When adding a new 3600 AP to a controller with multiple countries, the AP may select a country in a different regulatory domain than that of the AP.
&lt;br&gt;Conditions:
With a AIR-CAP3602I-A-K9 joining a controller with countries in regulatory domains for -A and -N.  The AP will select the country in the -N regulatory domain.
&lt;br&gt;Workaround:
Select the correct country and enable the AP admin state.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud84109</guid>
</item>
<item>
<title>Client entries replicated on AP, Open CSCug49108</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug49108</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

client entries replicated on AP
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

when using command &quot;show client ap 802.11a/802.11b &lt;ap name&gt;&quot;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Disable/enable radios to get rid of duplicated client entries

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug49108</guid>
</item>
<item>
<title>Mesh AP&#39;s don&#39;t process ICMP unless joined to controller, Fixed CSCtr33129</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtr33129</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Cisco Lightweight Access Points in bridge (mesh) mode do not process ICMP unless the AP is associated to a Wireless Lan Controller.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Lightweight Access point in bridge mode and connected to wired infrastructure.  DHCP address acquisition successful, but ap does not respond to ICMP. 
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Allow the Bridge Mode Access Point to join a Wireless Lan Controller.
&lt;B&gt;Eng-Comments:&lt;B&gt;
The ICMP function is based on (layer3) IP protocol. Before mesh AP joined controller, the icmp packet was unable to be processed by the mesh AP due to no knowledge to route to the controller then to the destination. After mesh AP joined the controller, the icmp packet will be processed by AP heading to controller to route the packet. 
The behavior of mesh AP do not process ICMP prior joined the wireless controller is expected.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtr33129</guid>
</item>
<item>
<title>ap1130 stop both transmission and receipt, Open CSCug53823</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53823</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP does not send out ACK or Probe Response though Probe Request is sent from a WLAN client.
As a result, the WLAN client associates to the far AP in spite of the nearest failed AP.

In another occurance, AP stop beaconing from wireless sniffer though dot11 stats increased beacon count on AP show controller d0.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Unknown
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
Reboot the failed AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53823</guid>
</item>
<item>
<title>AP drops EAPoL frame to client,   CSCtr57170</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtr57170</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC 6.0.202..0 AP goes into state where it will accept association from client, but fail to transmit EAP frame to client.
WLC will timeout client by M1 retransmisions, triggering a deauth.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
N/A
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtr57170</guid>
</item>
<item>
<title>RBAC - lack of security protection of data, Terminated CSCtj25505</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj25505</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
cwpass file contains no encrypted data for Roles. It is in plain text.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
If the user gets the permission to see the file he can edit the role and change it.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
None.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj25505</guid>
</item>
<item>
<title>WiSM2 crashes Reason: Reaper Reset Task:dtlArpTask, Open CSCug65454</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug65454</link>
<description>Controller may crash with a reason of Reaper Reset: Task &quot;dtlArpTask&quot; missed software watchdog


No workaround

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug65454</guid>
</item>
<item>
<title>CDP duplex mismatch when using LAG on 5508 WLC, Fixed CSCuc94082</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc94082</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When using LAG mode on WLC, lag interface sends duplex as half, all other ports are sent as full.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
getting duplex mismatch on switch logs for lag interface on wlc.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

turn off cdpv2 advertising

config cdp advertise-v2 disable

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc94082</guid>
</item>
<item>
<title>No Support For Internal DHCP Should Be Noted in 7.3.101.0 Release Notes, Fixed CSCug60151</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60151</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
In 7.3.101.0, the HA feature was introduced and noted in the release notes as a new feature. The lack of support for internal DHCP functionality should also be noted with this new HA feature.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
n/a
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
n/a

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60151</guid>
</item>
<item>
<title>Unable to change Radio Settings from the Web interface AP 1550, Open CSCug90558</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug90558</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Unable to change the radio settings from the Web interface ( as if the Apply Button doesn&#39;t work )
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

AP 1550 running (15.2(2)JB
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Configure from CLI

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug90558</guid>
</item>
<item>
<title>Incorrect Error Message When Creating Scope on HA Controller, Open CSCug60138</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60138</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Error message provided regarding scope lease on HA WLC  not beneficial and causes confusion
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Error message should be changed to reflect lack of support of internal DHCP for HA WLC
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;

none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60138</guid>
</item>
<item>
<title>WLC crashes when applying CPU ACL in HA, Fixed CSCug42677</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug42677</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WLC may crash when applying CPU ACL.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

WLC 5508 running 7.3.101.0 configured in HA.
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug42677</guid>
</item>
<item>
<title>3502 Ap&#39;s crashing, Fixed CSCuc76519</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc76519</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
3502 AP crash
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
When a tunneled traffic sent towards the AP, GRE IPV6 ect
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc76519</guid>
</item>
<item>
<title>DP crash with Watchdog detected LOCKUP,   CSCue33987</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue33987</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC crashed with console output &quot;Watchdog detected LOCKUP&quot;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Unknown
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Not known.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue33987</guid>
</item>
<item>
<title>WLC(7.3) adds new mobility peers to all anchored ssids after reboot, Fixed CSCuc19950</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc19950</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
anchored ssids on wlc 7.3.101.0 will incorrectly show recently configured peer controllers in its anchor list after reboot.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
wlc 7.3.101.0 with existing anchored ssids.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Manually go to the anchored ssid and remove the recently added peer controllers from its anchor list.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc19950</guid>
</item>
<item>
<title>Wireless clients can&#39;t connect to UC500 because stop sending beacons,   CSCsx05336</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx05336</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

Clients can&#39;t connect to AP.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

UC500 running wireless.  Wireless clients can&#39;t connect.  UC500 doesn&#39;t show any clients trying to connect.




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;













</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx05336</guid>
</item>
<item>
<title>Packets from HREAP,  Local-Switch WLAN, should never egress the WLC, Fixed CSCtx95544</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx95544</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;We notice the 6500 switch learn lot of client Mac entries from
the management interface of the WLC. these correspond to MAC addresses of the
locally switched HREAP clients 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; HREAP locally switched clients send MDNS , TCP and other
traffic to the WLC. This traffic sent between the time the WLC moves the client
into RUN state and the AP being informed of this causes the packets from the
locally switched client to egress the WLC 
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; Create a dummy interface and tie the WLAN to that interface
with a dummy VLAN that does not exist on the switch. Aditonally an ACL
interface will serve to block all egress traffic for clients on the RUN state

For MDNS traffic : Enable IGMP snooping so the controller sends a single report
on behalf of all clients



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx95544</guid>
</item>
<item>
<title>FlexConnect AID leak, Fixed CSCug91572</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug91572</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clients fail to associate with Status 17 (max client reached) after some time on a FlexConnect setup even though there&#39;s only 1 or 2 clients attempting to associate to the AP.

Sample error message on WLC debug client:
*spamApTask4: May 13 09:51:54.353: c4:71:fe:d9:30:8d Association Failed on REAP AP BSSID 10:8c:cf:b4:ae:60 (slot 0), status 17 0 Max Client Reached, recieved an AID=0
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
- WLC code 7.4.100.0
- AP: FlexConnect AP with a mix of central and locally switched SSID
- Clients: Mix of WGB+wired clients and regular PC clients roaming across FlexConnect APs
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Reload the affected AP.
&lt;B&gt;More Info:&lt;/B&gt;



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug91572</guid>
</item>
<item>
<title>Apple iOS clients report two associated wlans with bssid mac overlap, Open CSCud88177</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud88177</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Dual band Apple iOS devices may appear to be associated to two WLANs while
functioning in a Cisco Unified Wireless infrastructure.  In the client&#39;s Wi-Fi
configuration page, two WLANs may have a check character next to them,
indicating association.  The issue appears to be cosmetic and non service
impacting.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Lightweight Access Points are advertising a larger number of WLANs.  This may
cause the same mac address to be used as the BSSID on the same AP, but on
different bands.  This is expected behavior.  Utilizing the Access Point&#39;s base
radio mac address, 802.11a WLANs start ending with Hexadecimal F, and descend.
 802.11b/g WLANs start ending with Hexadecimal Zero, and ascend.  
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Configure Access Points to advertise lesser quantities of WLANs, or configure
some WLANs to function on 802.11a only, or 802.11b/g only.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud88177</guid>
</item>
<item>
<title>3500 AP crash with disc_tx_11n_aggr_timer_send on 7.2,   CSCtz91549</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz91549</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;3500 ap crashes with traceback 0x6055B8 0x6078B0 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; Aggregation scheduler crashes
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; workaround  is to  disable  aggregation scheduler :-

config 802.11a 11nSupport a-mpdu tx scheduler disable

config 802.11b 11nSupport a-mpdu tx scheduler disable

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz91549</guid>
</item>
<item>
<title>Allow FlexConnect Local Switching and mDNS Snooping on the Same WLAN, Open CSCug69382</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug69382</link>
<description>&lt;B&gt;Feature Request:&lt;/B&gt;

Allow Administrators to enable FlexConnect Local Switching and mDNS on the same WLAN.  mDNS Snooping will only operate on APs in Local Mode.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Single WLAN is used with FlexConnect Local Switching enabled and both FlexConnect and Local Mode APs are joined.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Create two separate WLANs: 1) FlexConnect Local Switching, 2) mDNS Snooping.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug69382</guid>
</item>
<item>
<title>LAP1520 excessive DFS detection for in-band/off-channel weather radar, Fixed CSCuc81022</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc81022</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The LAP1520 outdoor mesh APs may get false DFS triggers when an in-band/off-channel (ch 124) weather RADAR signals are present and received above -20 dBm, causing network instability.
A similar behavior was observed with off-band maritime radars operating in the 3.05 GHz band, but this can be addressed with Band-pass filters installed at the antenna port.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
AIR-LAP152x outdoor mesh AP installed nearby a weather RADAR installation.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
New Hidden CLI dfs-peakdetect added to address this issue

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc81022</guid>
</item>
<item>
<title>WLC may deauthenticate a client before EAP-Identity-Request Timeout, Open CSCug66306</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug66306</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Wireless LAN Controller may send Deauthentication against EAP Identity Response received before EAP-Identity-Request Timeout.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This symptom may occur when WLC sends the last retry of EAP Identity Request frame.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Input credential quickly, in order to avoid EAP Identity Request retry.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug66306</guid>
</item>
<item>
<title>3500 AP crashed on Pid 67: Process &quot;LWAPP KAM-AP process &quot;,   CSCug85643</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug85643</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
3500 AP crashed on Pid 67: Process &quot;LWAPP KAM-AP process &quot;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
3500 AP crashed on Pid 67: Process &quot;LWAPP KAM-AP process &quot;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug85643</guid>
</item>
<item>
<title>User accounts deleted after reboot on Guest controller on 5.0.148,   CSCso62881</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso62881</link>
<description>

&lt;B&gt;Symptom:&lt;/B&gt;
On a guest controller running 5.0.148 code  (both standard and debug image for CSCsm98250 ), when the controller is rebooted (mainly due to lock-up), both the local net users and the local management user accounts are deleted. 

This appears to be similar to CSCsl32786.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Guest controllers (DMZ) running 5.0.148 code.

In this specific scenario, the Guest controller is locking up due to CSCsm98250  and can only be restored by reboot. Upon reboot, all accounts are lost.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso62881</guid>
</item>
<item>
<title>Access points get disconnected during code upgrade, Fixed CSCso22875</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso22875</link>
<description>None
&lt;B&gt;Symptom:&lt;/B&gt;
During code download, some APs may disconnect/reconnect to the WLC.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCso22875</guid>
</item>
<item>
<title>WLC crashes on 7.3 with Task Name :ccxL2RoamTask,   CSCue76062</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue76062</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; WLC crashes frequently 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; 
 Software was stopped by the reaper for the following reason:
 Reaper Reset: Task &quot;ccxL2RoamTask&quot; missed software watchdog
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue76062</guid>
</item>
<item>
<title>Local switching 3600 drops IP6to4 TCP SYN ACK packets received from LAN, Fixed CSCuc02149</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc02149</link>
<description>&lt;B&gt;Symptom&lt;/B&gt;: A 3600 series AP in either autonomous IOS or FlexConnect local
switching mode drops IP6to4 TCP SYN ACK packets that are received from its LAN
port.

A wired sniff at the AP port will show, when the wireless client attempts to
establish a TCP connection over IPv6 in IPv4, that the AP transmits the TCP SYN
(in IPv6 in IPv4) to the switch, and receives the SYN+ACK from the switch, but
fails to forward the SYN+ACK packet to the wireless client.

The first time that the AP, after a reload, drops the SYN+ACK packet, the
following message will be seen on the AP console, or in its log file:

WARNING - Received pak from RXTX port - Check log for detailed info

At the same time, the wireless client can successfully ping the IPv6
address of its 6to4 gateway.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

3600 or 2600 series AP, in autonomous or FlexConnect local switching mode.
Wireless client is attempting to establish TCP connections over IPv6 in IPv4
(i.e. IPv4 protocol type 41.)
&lt;br&gt;
&lt;B&gt;Workarounds:&lt;/B&gt;

1. Use a 1040/1140/1260/3500 AP.

2. Disable IPv6 support on the application server.

3. If using lightweight mode, use a centrally switched WLAN rather than locally
switched.



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc02149</guid>
</item>
<item>
<title>Local  Mode  APs  lose  config after power cycle, Open CSCuc32335</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc32335</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Local mode APs on  wlc lose thier config and get reset to factory default
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Local AP  loses power or shut no- shut is  done to the POE port.
This was seen on a 3602 AP, 5508 WLC running 7.2.103.0
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
n/a

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc32335</guid>
</item>
<item>
<title>LAP1550 excessive DFS detection for in-band/off-channel weather radar, Fixed CSCud04901</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud04901</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The LAP1550-series outdoor mesh APs may get false DFS triggers when an in-band/off-channel (ch 124) weather RADAR signals are present and received above -20 dBm, causing network instability.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
AIR-LAP155x outdoor mesh AP installed nearby a weather RADAR installation.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud04901</guid>
</item>
<item>
<title>AP radio resets with corrupt TX/RX buffer tracebacks on 7.2.110.0, Fixed CSCub82534</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub82534</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; AP radio resets 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; Accompanied with RX/TX buffer trace backs
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCub82534</guid>
</item>
<item>
<title>cpu ACL does not block ssh to virtual ip, however telnet does, Open CSCug83271</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug83271</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Cannot block access to SSH using cpu acl.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
cpu ACL does not block ssh to virtual ip, however telnet does.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable management via wireless client.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug83271</guid>
</item>
<item>
<title>AP 3600s rebooting due to Reason: Radio Not Beaconing for too long, Open CSCue24263</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue24263</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP 3600s are intermittently rebooting due to radio driver failure. No crash files or radio core dumps are auto generated. From AP eventlog, following message is seen:

*** Access point reloading. Reason: Radio Not Beaconing for too long ... ***
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
AP 3600, running 7.2.110.0, radios going off channel for detection or containment.
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
Disable containment if enabled.

AP CLI: debug dot11 d0/d1 stop-on-failure

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue24263</guid>
</item>
<item>
<title>Guest Device not refreshing IP After being placed in no-response VLAN, Open CSCug93020</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug93020</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The DHCP server configured on a C800 router is assigning the client IP address BEFORE the port is placed in the &quot;No-Response&quot; vlan.  Once the port switches over to the no-response VLAN, the client is stuck with an IP address for the wrong VLAN
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
- C880 device is being used running following code: c800-universalk9-mz.SPA.152-4.M3.bin
- Dot1x port is configured with a no-response VLAN
- DHCP pools are locally configured on c800 router
- Windows 7 workstation configured without a dot1x supplicant
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Manually perform an ipconfig /release followed by an ipconfig /renew to refresh the IP address on the client workstation

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug93020</guid>
</item>
<item>
<title>disabled radio is enabled after AP reload when AP group uses RF profile, Fixed CSCug53945</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53945</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
After AP reload, radio which disabled before AP reload is somehow re-enabled automatically.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
AP joins non-default AP group and AP group has RF profile.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Manually disable radio on AP again after reload.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53945</guid>
</item>
<item>
<title>&quot;Radio disabled due to inline power&quot; on 7.4, Fixed CSCug45057</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug45057</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
2.4 Ghz and 5 Ghz radios disabled due to error &quot;Radio disabled due to inline power&quot;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Upgrade to 7.4.100.0
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug45057</guid>
</item>
<item>
<title>DNS resolution for syslog messages to be disabled by default in LMS OVFs, Fixed CSCty05610</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty05610</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
In LMS 4.1 OVF deployment, the DNS resolution for Syslog messages are enabled
by default.
Syslogd trying to do DNS lookup for syslogs, which could result is some syslogs
not being inserted into syslog_info file (possible causes could be the DNS
servers are slow or no of queries are large).
This is done by default in WIndows, as crmlog process doesnot resolve syslogs.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
LMS Linux OVF deployment
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable DNS resolution for Syslog messages

Edit /etc/sysconfig/syslog and edit the syslogd options to include -x, which
disables DNS resolution:
SYSLOGD_OPTIONS=&quot;-m 0 -r -x&quot;

Then restart using /etc/init.d/syslogd restart

Then restart SyslogCollector and Analyzer and check subscription

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty05610</guid>
</item>
<item>
<title>Clock save interval does not work on AP running 15.2,   CSCue56124</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue56124</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Autonomous AP running 15.2 software loses clock information after reboot.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Autonomous AP running 15.2 software. Clock information is lost even when &quot;clock save interval&quot; is configured. This is particularly important for WGB situations where the AP must use certificate based authentication (EAP-TLS, PEAP), and the certificate validation will fail the time check.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
1. Manually configure the clock after an AP reboot.

2. Configure SNTP for applications where AP is not operating as WGB with certificate based authentication:
ap(config)#sntp server a.b.c.d {version 1|2|3}

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue56124</guid>
</item>
<item>
<title>CO:WiSM controller lost heartbeat to Sup. Not able to ping the mgmt int, Fixed CSCsg59144</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsg59144</link>
<description>None







&lt;B&gt;Symptom:&lt;/B&gt;
The user is unable to ping the service port on the controller through the CAT6k switch
The heart beats between the sup 720 and the cat 6k are lost due to which the two cannot communicate. 





&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
After a hrdware reset from the cat6k switch the WISM is up.


&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;















</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsg59144</guid>
</item>
<item>
<title>5508 crash in spamReceiveTask: Reaper Reset, LOCK ASSERT apfMsConnTask_4, Fixed CSCuc59054</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc59054</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

A wireless LAN controller may unexpectedly reload with messages similar to the following on the console:

** LOCK ASSERT ** (apfMsConnTask_4) !! prio=273 root=100 word=20000

and with a crash file that looks like this:

Task Name:spamReceiveTask
Reason: Reaper Reset
[ ... ]
System Stack
[ ... ]
Frame 7: 0x102c6690: spamLradSendMgidInfo+1152
Frame 8: 0x1023c8e0: spamApiSendMgidInfo+184
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Wireless LAN controller is configured with an interface group that has no interfaces mapped to it.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Fix the configuration, so that all configured interface groups have interfaces mapped.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc59054</guid>
</item>
<item>
<title>capwap Ap 3600  gets into Boot mode &quot;ap: boot&quot; mode during  power outage, Terminated CSCuc81911</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc81911</link>
<description>&lt;B&gt;Symptom:
Capwap 3600 APs  get to stuck   &quot; ap:&quot; mode  when there is a  power outage, requiring manual Boot.

&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Conditions:

when there was a power  outagage   there is a  possibility of AP gettng stuck in boot mode&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:
ap: flash_init 
and ap: boot 

the above commands are  required t be given  to get them  working back up
&lt;/B&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc81911</guid>
</item>
<item>
<title>WLC 5508 crash due to memory corruption in task name spamApTask6, Fixed CSCue92521</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue92521</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

5508 controller crash due to memory corruption in spamApTask6. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

None
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue92521</guid>
</item>
<item>
<title>WLC not responding to SNMP from wireless client, Terminated CSCta06414</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta06414</link>
<description>Symptom:

WLC not responding to SNMP from wireless client, same client wired works fine to WLC
&lt;br&gt;

Workaround
Used wired client to manage WLC via SNMP



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta06414</guid>
</item>
<item>
<title>Global High Availability Feature, Fixed CSCti45880</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti45880</link>
<description>The Global High Availability feature is only used to help an AP move over to a controller when the current controller fails.  The back-up primary and back-up secondary are 4th and 5th in the order of controllers if primary, secondary and tertiary controllers are configured under the AP.  If the primary, secondary and tertiary controllers are not configured, then the AP will only use the back-up primary if the current controller fails.

Note:
AP will not retain any of the back-up primary or secondary controller information if it is rebooted.  

Note:
The back-up primary and secondary controller information does not work with the AP fallback feature.

Note:
If the AP move to a new controller with different global back-up controllers configured, the AP will take on the new back-up controllers
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCti45880</guid>
</item>
<item>
<title>Clean Air sensor goes down and requires a reboot, Open CSCug89084</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug89084</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clean Air sensor goes down and requires a reboot.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

first found on monitor mode APs
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reboot the AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug89084</guid>
</item>
<item>
<title>Remote Lan adds mac filtering after upgrade. OEAP radios are disabled, Fixed CSCue66944</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue66944</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

After upgrading from 7.3.112.0 to 7.4.110.0, the remote wlan adds mac filtering to layer 2 security. OEAP Radios are configured as down. 
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

upgrading from 7.3.112.0 to 7.4.110.0 with mac-filter disabled
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Enabling radio on oeap and removing mac filtering fixes this issue.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue66944</guid>
</item>
<item>
<title>Wism crashes at spamReceiveTask,   CSCug79428</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug79428</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Wism crashes at SpamReceiveTask and also mentions disablePassiveScanClientsOnLBWlan in the crash file
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
seen on 7.0.240
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug79428</guid>
</item>
<item>
<title>Clean Air sensor goes down and requires a reboot, Fixed CSCua46511</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua46511</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clean Air sensor goes down and requires a reboot.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reboot the AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua46511</guid>
</item>
<item>
<title>webauth fails on segmented HTTP GET, Fixed CSCuc68995</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc68995</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

A wireless webauth client may be unable to authenticate to the network.  When
the client opens
a browser window, the window is blank.

With &quot;debug web-auth redirect&quot; in effect, messages similar to the following may
be seen:

*webauthRedirect: Oct 15 18:43:19.470: #EMWEB-6-REQUEST_IS_NOT_GET_ERROR:
webauth_redirect.c:1055 Invalid request not GET on client socket 72

or

*webauthRedirect: Oct 10 16:36:30.715: %EMWEB-3-PARSE_ERROR: parse error after
reading. bytes parsed = 0 and bytes read = 189
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

The HTTP GET from the client is arriving at the WLC in multiple TCP segments.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Reconfigure your network and/or the client&#39;s TCP/IP stack to ensure that the
HTTP GET arrives in a single segment.

One example of client software that is known to introduce TCP segmentation
behavior that triggers this bug is AnyConnect Web Security 3.0.3054.

&lt;B&gt;More information:&lt;/B&gt;

This bug is a regression that was introduced in 7.2.  Although Cisco
acknowledges that this is a bug in our design, we do not intend to it.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc68995</guid>
</item>
<item>
<title>WISM2 WLC Data Plane crash with the Reason - Heartbeat, Open CSCug70432</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug70432</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WISM2 WLC data plane crash with the reason - Heartbeat

Version:        7.3.112.0
Data Plane ID:  0
Reason:         Heartbeat

                **   DP Crash Pointers  **
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

NA
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug70432</guid>
</item>
<item>
<title>OEAP 600 inconsistent throughput degrading with latency, Terminated CSCtz21519</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz21519</link>
<description>&lt;B&gt;Symptom:

OEAP 600 inconsistent throughput degrading with latency
Cu Environment: TCP throughput initially bursts to 10 mbps and then shapes down to 2 MBPS constant
Lab environment: RTT = 100 ms(introduced by pagent pmod), TCP Window size = 512 KB, TCP Througput between PC1 and PC2 = ~ 4 to 5 Mbps

&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Conditions:

Customer Setup:

PC-2(Iperf client)&lt;--&gt;OEAP 600 wired port&lt; --&gt; ISP(20 Mbps up/down)  { Internet RTT to PC1 ~55-100 ms } &lt;--&gt; ASA Firewall &lt;--&gt;  6500 Swtich --&gt;WISM --&gt;PC-1(Iperf server)

Result:

TCP throughput gets inital burst of 10 ms for about 5-6 seconds and then simmers down to 2 MBPS consistently. UDP constantly maintains 10 Mbps throughput. 

Lab setup:

PC-2(Iperf client)&lt;--&gt;OEAP 600 wired port&lt; --&gt; Router(1811) &lt;--&gt; Router(1841 + Pagent running PMOD) &lt;--&gt;  3750 Swtich --&gt;WLC 2504 --&gt;PC-1(Iperf server)

Results:

With PC2 to PC1 RTT = 2 ms, TCP Window size = 512 KB, TCP Througput between PC1 and PC2 = ~ 10 to 11 Mbps

With PC2 to PC1 RTT = 50 ms(introduced by pagent pmod), TCP Window size = 512 KB, TCP Througput between PC1 and PC2 = ~ 8 to 10 Mbps 

With PC2 to PC1 RTT = 100 ms(introduced by pagent pmod), TCP Window size = 512 KB, TCP Througput between PC1 and PC2 = ~ 4 to 5 Mbps


&lt;/B&gt;
&lt;br&gt;



&lt;B&gt;Workaround:

None &lt;/B&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtz21519</guid>
</item>
<item>
<title>netflow on 7.4 will not support 3rd party NMS e.g. solarwind, Open CSCue57694</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue57694</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WLC will not work with solarwind on 7.4. netflow feature.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

WLC 7.4 netflow collector is 3rd party NMS
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none.

please add it to the config guide as it is not supported as per EDCS-1157876:-

Req # 6.0.6.5.5

Admin should be able to use NCS or 3rd party NMS to gain application visibility in a large deployment. Flexible netflow record monitoring and export are typically used for integration with NMS or any standard netflow analysis tools. 

comments:-

7.4 will have the NCS support. 3rd party NMS is not supported.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue57694</guid>
</item>
<item>
<title>Ability to Disable AP Fallback to DHCP When Configured for Static IP, Open CSCua58662</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua58662</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

*Enhancement Request*

An AP with a Static IP address drops from the WLC, and is unable to join.  The AP fails over to DHCP, and successfully joins the WLC.  The AP will maintain this DHCP address until rebooted.  Need ability to disable DHCP failover to avoid APs from obtaining a DHCP assigned IP address.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Static IP Address Assigned to AP
AP Drops from the WLC, and fails to join via Static IP
&lt;br&gt;
&lt;B&gt;Workarounds:&lt;/B&gt;

Option 1) Remove DHCP scope from the subnet where the statically assigned APs reside.
Option 2) Enable DHCP Address reservations, and enable DHCP on the APs.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua58662</guid>
</item>
<item>
<title>Internal DHCP Functionality is Unsupported in an HA Configuration, Open CSCug60045</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60045</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Internal DHCP functionality fails from HA controller
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Currently, with controllers in an HA configuration, internal DHCP is not supported.  This defect is being opened as a product enhancement to support internal DHCP functionality just as when not in HA.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;

use an external DHCP server

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60045</guid>
</item>
<item>
<title>&quot;capwap ap hostname&quot; CLI returns &quot;ERROR!!! Command is disabled.&quot;, Open CSCtl96208</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtl96208</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Due to CSCsy17745, &quot;capwap ap&quot; commands on a lightweight AP can be executed anytime.
But only &quot;capwap ap hostname&quot; still returns &quot;ERROR!!! Command is disabled.&quot;


ap#show ver
Cisco IOS Software, C1250 Software (C1250-K9W8-M), Version 12.4(21a)JHB1, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2010 by Cisco Systems, Inc.
~~
ap#
ap#capwap ap hostname TEST
ERROR!!! Command is disabled.
&lt;br&gt;



&lt;B&gt;Conditions:&lt;/B&gt;
The access point is running the lightweight IOS featureset (k9w8) or recovery image (rcvk9w8).
&lt;br&gt;

&lt;B&gt;Workaround 1:&lt;/B&gt;
Configure from WLC.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtl96208</guid>
</item>
<item>
<title>running 7.3.101 verified 3600 APs with clean air sensor crash, Open CSCuc37636</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc37636</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
CleanAir becomes disabled on AP.  Requires reboot of AP to re-enable CleanAir
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Unknown what is causing the problem at this time.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Leave CleanAir disabled on AP or reboot AP to re-enable CleanAir.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc37636</guid>
</item>
<item>
<title>AP &#39;DOT11-2-RADIO_RX_BUF&#39; Crash upon receipt of WPA packet with length 0, Fixed CSCtu24889</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtu24889</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

3500, 1520, or 1260 series Access Point crashes and reboots occasionally, and the crash info on the AP contains a message similar to the following :

*Nov  3 06:29:57.234: %DOT11-2-RADIO_RX_BUF: Corrupt buf:062C97D4 rcv:A665AF9A/AAF080EF prog:0291EA44/0291EA44 pak:025DD7BC
*Nov  3 06:29:57.234: %DOT11-2-RADIO_RX_BUF2: Ring in/out:270959/270832 ProgID:270833 Last:061F3F18 Errs:0/0/0
*Nov  3 06:29:57.234: %SOAP_BUF-2-PAK: pak:025DD7BC, pool:Wlan Pool, pool size:2656
*Nov  3 06:29:57.234: %SOAP_BUF-2-PAK: magic:5C18062E, refcount:1, caller_pc:004E77D0

These errors may also be followed by messages concerning &#39;redzone corruption&#39;.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

The Access Point received a malformed WPA/WPAv2 AES encrypted frame from a client with the length field set to the value 0.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Locate and remove the offending client from the network; or, use a non-AES security mode, such as WPA-TKIP.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtu24889</guid>
</item>
<item>
<title>Cannot set broadcast address for SNMP community in 7.4, Open CSCug74325</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74325</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; Cannot set broadcast address for SNMP community in 7.4
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; WLC 7.4
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; downgrade to 7.3

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74325</guid>
</item>
<item>
<title>CWA with Flex APs require a local ACL with same name as Flex ACL, Open CSCue68065</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue68065</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
If you do Central Web authentication with Flex APs, the ACL you return as av-pair needs to exist as non-flex ACL.
It would be better to have the possibility to push a flex-only ACL name through the av-pair
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
wlc 7.2,7.3,7.4
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Have the same ACL present as non-flex ACL and flexACL

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue68065</guid>
</item>
<item>
<title>UC560 Not able to enable Presence for Internal Lines, Open CSCug51393</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug51393</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
UC560 Not able to enable Presence for Internal Lines
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
UC560 Not able to enable Presence for Internal Lines
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug51393</guid>
</item>
<item>
<title>AP HA:WLC/AP migration issues without WCS, Open CSCua00733</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua00733</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
can&#39;t configure HA of all AP globally and per AP-group on WLC
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
can&#39;t configure HA of all AP globally and per AP-group on WLC
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Manually configure HA options on all APs

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCua00733</guid>
</item>
<item>
<title>clarification on the maximum number of OEAP&#39;s behind a NAT on 7.4, Fixed CSCug67321</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug67321</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt; clarification on maximum number of OEAP devices behind NAT
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt; OEAP behind NAT
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt; NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug67321</guid>
</item>
<item>
<title>Granular AP search filter for WLC gui, Open CSCug60713</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60713</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP filter search needs to supported multiple parameter
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
AP filter search needs to supported multiple parameter
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug60713</guid>
</item>
<item>
<title>Document-ACL applied to Wired Guest WLAN does not block peer to peer, Fixed CSCuf66317</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf66317</link>
<description>Symptom:
A WLAN ACL applied to a wired guest WLAN will not block peer to peer traffic.
The same ACL applied to a wireless guest WLAN will block peer to peer traffic.
different functionality
&lt;br&gt;
Conditions:
Trying to block peer to peer communication
&lt;br&gt;
Workaround:
none - needs documented under guidlines and limitations of the CCO configuration guide. section Wired Guest.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf66317</guid>
</item>
<item>
<title>AP2600 2.4ghz radio hang with &quot;Network Interrupt Loop Detected&quot;,   CSCuf46857</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf46857</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
A Cisco 2600 Series Access Point&#39;s 2.4ghz radio may periodically stop functioning.

&quot;Network Interrupt Loop Detected&quot; is logged by the Access Point.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Lightweight 2600 associated to WLC running 7.4.100.0.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Disable aggregation scheduler.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf46857</guid>
</item>
<item>
<title>WiSM2 HA replies to ARP request with redundancy-port mac, Open CSCug83998</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug83998</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WiSM2 configured for HA may reply to ARP requests for the management IP using the redundancy-port mac address. This may cause connectivity issues with other devices.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WiSM2 running 7.3.112.0 and configured for HA
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Clear arp on the WiSM2

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug83998</guid>
</item>
<item>
<title>show wlan name in show client detail for easy troubleshooting, Open CSCug72744</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug72744</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
show wlan name from show client detail
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
show wlan name from show client detail
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug72744</guid>
</item>
<item>
<title>AP CAPWAP CLIENT Process crashed, Fixed CSCsw49486</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw49486</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
APs crashed during network blip
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
many APs joining at the same time
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Let the APs take time to settle down and that is it.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;
Only occurred during a network blip

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw49486</guid>
</item>
<item>
<title>mDNS Gateway doesn&#39;t advertise wireless device services to wired network, Open CSCue90227</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue90227</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Wired clients do not see Bonjour/mDNS advertisements from wireless devices.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
AppleTV on a WLAN with the default mDNS profile enabled.
MacBook laptop on VLAN with an interface on the WLAN with the default mDNS profile enabled.
mDNS Snooping enabled globally.
Default mDNS Profile with AirPlay and AirTunes enabled.
WLAN tied to an interface/VLAN that is different from the MacBook&#39;s VLAN.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None known at this time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue90227</guid>
</item>
<item>
<title>Reload is not required for tcp-mss-adjust to take effect, Fixed CSCug49004</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug49004</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When configuring an LAP with a tcp-mss-adjust value, we have confirmed that the reload is never required for the change to take effect on the AP. However, all the configuration guides mention that a WLC reload is required for the change to take effect:
http://www.cisco.com/en/US/partner/docs/wireless/controller/7.3/configuration/guide/b_wlc-cg_chapter_01000.html#ID4226

While the command reference guides don&#39;t mention anything about a reload:
http://www.cisco.com/en/US/docs/wireless/controller/7.3/command/reference/b_cr_7.3_chapter_010.html#wp2557458545

Therefore, we need to remove from the configuration guides the instruction that says that we need to reload the WLC...
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
Wrong documentation for the tcp-mss-adjust feature on the WLC.
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
The feature applies without the need of a WLC reload. Documentation update only.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug49004</guid>
</item>
<item>
<title>LMS 4.2.1: High Memory Usage on Windows Server 2008 on VMWare, Open CSCud21555</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud21555</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
High Memory usage about 90% showing in windows task manager
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

LMS Version - 4.2.1
Managed Devices - 40
Server - Windows 2008 Enterprise Edition with Service Pack 2 over ESXi 4.1.0
4 CPU with 2.1 GHz
RAM - 8 GB
SWAP - 16 GB

Customer has supported configuration of up to 300 devices but facing high memory usage of 85-90% with only 40 devices.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud21555</guid>
</item>
<item>
<title>Need to be able to customize logout page for external web authentication, Open CSCtb31779</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb31779</link>
<description>

&lt;B&gt;Symptom:&lt;/B&gt;

Currently only the login page can be placed on an external server when doing external web authentication.
The logout page and login fail page cannot be customized if doing external web auth. This means it cannot be translated to local language and are really different from the login page.

It would be nice to either be able to place logout and login failed pages on the external web server or at least be able to use the ones from the custom bundle along with the external web server login page.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

/
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

/
&lt;br&gt;&lt;B&gt;Further Problem Description:&lt;/B&gt;
/

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb31779</guid>
</item>
<item>
<title>WLC on 5.2.157 CLI &#39;show dhcp lease&#39; leaves out hours &amp; minutes., Fixed CSCsw34627</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw34627</link>
<description>Symptom: 
&#39;show dhcp lease&#39; in WLC 5.2.157 from the WLC omits the hours &amp; minutes. 
&lt;br&gt;Workaround:
Use the gui to display.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsw34627</guid>
</item>
<item>
<title>AP1131 running 12.4(23c)JA7/7.0.240 crashes in Check Heaps process, Open CSCug62464</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug62464</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP1131 crashing continuously
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
N/A
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug62464</guid>
</item>
<item>
<title>ap2600 stops beaconing for 2-6 sec, Open CSCug53150</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53150</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clients complaining about client disconnections, connecting to APs far away, roaming disconnections, etc...
Root cause is that APs may stop beaconing the WLANs for some periods (2-6 secs).
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
NA.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
After a reboot of the AP the problems are cleared resolved for a certain period of time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53150</guid>
</item>
<item>
<title>WLC 7.4 crash on tplusTransportThread, Open CSCug86804</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug86804</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WLC running 7.4 may crash.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

WLC running 7.4 and with TACACS+ servers configured.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug86804</guid>
</item>
<item>
<title>WLC sending RADIUS accounting retries faster than configured timeout, Fixed CSCty49012</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty49012</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;


WLC is jumping between the configured accounting radius servers too fast.

Analyzing the sniffer traces, we see it is sending the requests within a few miliseconds, which sometimes doesn&#39;t allow enough time to receive the reply.

The WLC is configured for timeout of 12 seconds and has agressive failover disabled.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Seen with WLC5508 running 7.2.103.0.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty49012</guid>
</item>
<item>
<title>wlc crash on 7.3.101.0, Fixed CSCud23648</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud23648</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
wlc crash on 7.3.101.0
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Crash on 
Task Name: osapiReaper
User Crash:     The system has encountered a fatal condition at broffu_fp_dapi_cmd.c:3679
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud23648</guid>
</item>
<item>
<title>show capwap client timers command causes unexpected reload, Fixed CSCuc25203</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc25203</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Executing &lt;b&gt;show capwap client timers&lt;/b&gt; command on Lightweight AP causes 
unexpected reload.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Executing &lt;b&gt;show capwap client timers&lt;/b&gt; command.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
To avoid executing &lt;b&gt;show capwap client timers&lt;/b&gt; and &lt;b&gt;show tech-
support&lt;/b&gt; commands.




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuc25203</guid>
</item>
<item>
<title>Need to reset 90 day license timer on secondary controller, Open CSCue38133</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue38133</link>
<description>

Symptom:
Controller will send a message after 90 days of an AP joining the controller, 
that the APs should be moved to a primary controller.
&lt;br&gt;

Conditions:
A HA-SKU WLC is being used as a secondary controller in a N+1 configuration and an AP has joined the
controller.
&lt;br&gt;

Workaround:
None


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue38133</guid>
</item>
<item>
<title>Request to support 4096 size key certificates, Open CSCtj44859</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj44859</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
7925 / 7921 not working with 4096 bit keys
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
CA or cert uploaded on the phone has a 4096 bit key
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
use 2048 bit key



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtj44859</guid>
</item>
<item>
<title>AP is crashed due to Unexpected exception to CPUvector, Open CSCug53680</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53680</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
AP rebooted with crashinfo.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
There is no outstanding trigger.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Nothing

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug53680</guid>
</item>
<item>
<title>High CPU crash on SSHPM during ADT list processing, Open CSCug58807</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug58807</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Crash on SSHPM task, due to missed watchdog
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Very high webauth activity
7.0 based code
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug58807</guid>
</item>
<item>
<title>Document 7.3 code requirement for AP802H in rel note and compat matrix, Open CSCug80769</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug80769</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
A newer version of the ap802, the AP802H is being introduced into new mode routers.

This AP requires 7.3 code for support, per this document:

http://www.cisco.com/en/US/prod/collateral/routers/ps10906/ps380/qa_c67-678460.html

We need to clearly document:

1) introduction of support for this ap in the 7.3.101.0 release notes

2) reference support in subsequent release notes

3) update the compatability matrix, indicating the difference in support of the AP802 (supported since 7.0 code), and the AP802H (7.3.101.0) first support.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Documentation update.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Refer to http://www.cisco.com/en/US/prod/collateral/routers/ps10906/ps380/qa_c67-678460.html

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug80769</guid>
</item>
<item>
<title>eapol key failure for motorola scanner, Open CSCug55048</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug55048</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Motorola scanner 319x fails on eapol-key handshake - M1 or M3
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC Client debug shows
*osapiBsnTimer: Apr 23 19:28:34.280: 00:23:68:d4:71:a5 802.1x &#39;timeoutEvt&#39;
Timer expired for station 00:23:68:d4:71:a5 and for message = M2
*dot1xMsgTask: Apr 23 19:28:34.280: 00:23:68:d4:71:a5 Retransmit 1 of
EAPOL-Key M1 (length 121) for mobile 00:23:68:d4:71:a5
*osapiBsnTimer: Apr 23 19:28:34.880: 00:23:68:d4:71:a5 802.1x &#39;timeoutEvt&#39;
Timer expired for station 00:23:68:d4:71:a5 and for message = M2
*dot1xMsgTask: Apr 23 19:28:34.880: 00:23:68:d4:71:a5 Retransmit 2 of
EAPOL-Key M1 (length 121) for mobile 00:23:68:d4:71:a5
*osapiBsnTimer: Apr 23 19:28:35.480: 00:23:68:d4:71:a5 802.1x &#39;timeoutEvt&#39;
Timer expired for station 00:23:68:d4:71:a5 and for message = M2
*dot1xMsgTask: Apr 23 19:28:35.480: 00:23:68:d4:71:a5 Retransmit 3 of
EAPOL-Key M1 (length 121) for mobile 00:23:68:d4:71:a5
*osapiBsnTimer: Apr 23 19:28:36.080: 00:23:68:d4:71:a5 802.1x &#39;timeoutEvt&#39;
Timer expired for station 00:23:68:d4:71:a5 and for message = M2
*dot1xMsgTask: Apr 23 19:28:36.080: 00:23:68:d4:71:a5 Retransmit 4 of
EAPOL-Key M1 (length 121) for mobile 00:23:68:d4:71:a5
*osapiBsnTimer: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 802.1x &#39;timeoutEvt&#39;
Timer expired for station 00:23:68:d4:71:a5 and for message = M2
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Retransmit failure
for EAPOL-Key M1 to mobile 00:23:68:d4:71:a5, retransmit count 5, mscb
deauth count 4
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Resetting MSCB PMK
Cache Entry 0 for station 00:23:68:d4:71:a5
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Removing BSSID
d0:c2:82:b6:af:6d from PMKID cache of station 00:23:68:d4:71:a5
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Setting active key
cache index 0 ---&gt; 8
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Sent Deauthenticate
to mobile on BSSID d0:c2:82:b6:af:60 slot 1(caller 1x_ptsm.c:546)
*dot1xMsgTask: Apr 23 19:28:36.680: 00:23:68:d4:71:a5 Scheduling deletion
of Mobile Station:  (callerId: 57) in 10 seconds
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reload affected AP

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug55048</guid>
</item>
<item>
<title>UC540 bad call quality on remote SSL and IPSec VPN phones, Open CSCug79949</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug79949</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
- Customer was runing 15.1(2)T4 and experiencing high CPU. Cu then upgrade to 15.1(4)M5 and high cpu seems to be resolved.
- Cu start to see that remote 525G phones over SSL VPN are being disconnected while on call.
- Upgrade phone firmware to 7.5.4 and remote phone disconnection stopped but introduced the current problem.
- Cu is experiencing bad voice quality on remote phones that leads to high cpu after about 10min into the call.
- Cu is experiencing the same voice quality issue on remote phones over IPSec but yet not confirmed if it is the result of high CPU due to the SSL VPN issue
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
 - IOS Ver: 15.1(4)M5
 - Hardware: UC540W-FXO-K9
 - CUE: 8.0.6
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
 - No workaround

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug79949</guid>
</item>
<item>
<title>After going offchannel for RRM, Intel client gets no data for awhile, Terminated CSCts35247</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCts35247</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

A wireless client device may intermittently experience pauses of up to
a minute in receiving data from the networks.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

This is seen with a lightweight AP which is going offchannel periodically
for 50ms periods to do RRM work.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Configure the client device to continually transmit data.  For Intel
clients, this may be done via registry setting, available from Intel.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

This problem is seen when the client device goes into powersave mode in
order to scan offchannel.  Then, while the client is offchannel, the AP
goes offchannel.  The client comes back onchannel, and tries to come out
of powersave mode, but the AP doesn&#39;t ack, because it&#39;s still offchannel.
The client then assumes that it&#39;s out of powersave mode, but when the AP
comes back onchannel, it assumes that the client is still in powersave
mode.  Therefore the AP buffers all traffic destined to the client, till
the client transmits a packet first.

This bug has been marked Junked, because it is Cisco&#39;s position that
this is a bug on the client side, which should never assume that its
powersave messages have been successfully transmitted, if they were
never acknowledged.

Ultimately, this situation may be addressed by having the infrastructure
and client implement the 802.11k quiet element, whereby the AP will be
able to tell the client when it is going to be offchannel.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCts35247</guid>
</item>
<item>
<title>Clients not recieving mDNS advertisements from a proxy mDNS server, Open CSCue90320</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue90320</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clients are unable to discover all devices that are being advertized by a proxy mDNS server, such as FingerPrint.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC running 7.4.100.0
mDNS Snooping enabled globally
mDNS profile enabled on the interface/wlan where services are being advertised
mDNS proxy program, such as Finger Print, advertising services on behalf of the other devices
Clients connected to the wireless network
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None know at this time

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue90320</guid>
</item>
<item>
<title>WLC crashes when configured with LDAP server, Fixed CSCsx29956</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx29956</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

WLC crashes when configured to operate with LDAP server.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC is running 5.2.157.0 




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

Task Name:	LDAP DB Task 2
Reason: 	Reaper Reset 

Analysis of Failure:

  Software was stopped by the reaper for the following reason:
     Reaper Reset: Task &quot;LDAP DB Task 2&quot; missed software watchdog

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsx29956</guid>
</item>
<item>
<title>WLC needs to support OTP with TACACS/RADIUS, Fixed CSCtc23403</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc23403</link>
<description>
 One Time Passwords (OTP) is supported on the Wireless Lan Controller (WLC) 
 using TACACS and RADIUS.  In this configuration, the WLC acts as a 
transparent 
 pass-thru device.  The controller will forward all client requests to the 
 TACACS/RADIUS server without inspecting the client behavior.  When using OTP 
 the client must only establish a single connection to the controller to 
 function properly.  The WLC currently does not have any intelligence or 
checks 
 to correct a client that is trying to establish multiple connections.  For 
OTP support the WLC should be at a minimum code level of 4.2.173 that has the 
fixes for CSCsh29597 and CSCsk21007.
 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc23403</guid>
</item>
<item>
<title>Beacon loss on only a particular WLAN, Terminated CSCud37324</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud37324</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Beacon loss on only a particular WLAN
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;

Clients are experiencing poor performance, erratic roaming, and re-association behavior.  Client debug is showing the client send new association request every couple of seconds when the problem is experienced.  Wireless captures and AP logs reveal there is intermittent beacon loss from the particular BSSID.

Wireless captures were taken to see 802.11 frames during this problem.  It was found that the beacons for this &quot;particular&quot; WLAN were stopping and we would see delta from previous beacon ranging from 1-6 seconds.  The client would see this is as a BSS loss and move to a nearby AP and then roam back when beacons returned to normal 102 ms time.

This problem will occur for 30-60 seconds, and then beacons transmit normally.  This is causing poor client performance and loss of connectivity.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCud37324</guid>
</item>
<item>
<title>FFT: %OSAPI-0-INVALID_TIMER_HANDLE: timerlib_mempool.c:240, Fixed CSCtc16222</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc16222</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Customer seeing the following messages on his WISM2 blades-
Message from syslogd@wism2-ms9-mgmt.it.osu at Sep 20 08:38:46 ...
wism2-ms9-mgmt.it.osu wism2-ms9: *spamApTask7: Sep 20 08:38:42.434: #OSAPI-0-INVALID_TIMER_HANDLE: timerlib_mempool.c:241 Task is using invalid timer handle 15069/46996

Message from syslogd@wism2-ms9-mgmt.it.osu at Sep 20 08:38:46 ...
wism2-ms9-mgmt.it.osu wism2-ms9: -Traceback:  0x113b0060 0x10a26264 0x105c9810 0x105c2760 0x105c2b90 0x105c3094 0x105a19e0 0x10348180 0x103d88ec 0x103e4ac4 0x10e4c86c 0x10a22318 0x11d316a0 0x11d8ffcc
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

WISM2 running  7.3.101.0
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
N/A

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc16222</guid>
</item>
<item>
<title>Unexpected reboot due to Sigtrap Exception on applying qos pre-classify, Fixed CSCty01234</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty01234</link>
<description>Symptoms: A router running Cisco IOS may reload unexpectedly.
&lt;br&gt;
Conditions: This symptom is observed only with low-end platforms using VDSL
interfaces, such as a Cisco 887 router. It also requires that the &lt;b&gt;qos
pre-classify&lt;/b&gt; command be used in conjunction with IPsec and GRE, such
as in a DMVPN configuration.
&lt;br&gt;
Workaround: Do not use the &lt;b&gt;qos pre-classify&lt;/b&gt; command. 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty01234</guid>
</item>
<item>
<title>WLC displays wrong interface name when having hundreds of interfaces, Open CSCug74517</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74517</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC displaying client belonging to the wrong interface name. Vlan is displayed correctly. Technically client is also assigned to the right subnet.
When connecting to one of the first 255 interfaces, there is no problem, but if connecting to one of the last 255 interfaces of the list, the client will be displayed in the wrong interface name.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Happening when using several hundreds of dynamic interfaces on the WLC.
This display error is also seen on Prime Infrastructure since it pulls the error from WLC
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none but it&#39;s not operationally impacting

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug74517</guid>
</item>
<item>
<title>AP LEDs are not globally enforced on WLC, Open CSCug48683</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug48683</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Newly joined APs have LED ON even though &quot;config ap led-state disable all&quot; is configured on WLC.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
- Disable LED globally for all AP on WLC.
- Join new AP to the controller.
- LED for that AP is ON 
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
After joining new APs to WLC re-enter &quot;config ap led-state disable all&quot;.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug48683</guid>
</item>
<item>
<title>WISM crashed on task sshpmMainTask System Crash, Fixed CSCtb74239</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb74239</link>
<description>    
&lt;B&gt;Symptom:&lt;/B&gt;
WiSM controller crashed on sshpmMainTask
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtb74239</guid>
</item>
<item>
<title>WiSM crash  instruction located at: 0x1038a140(ewsInternalAbort+348), Fixed CSCsr70862</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr70862</link>
<description>
 
  Symptom:
  
  WiSM crash instruction located at: 0x1038a140(ewsInternalAbort+348)&quot; 
&lt;br&gt;
  Condition :

  Seen on WLC running ver 4.2.130.0
&lt;br&gt;  
  Workaround:
  
  Set session timeout to zero or remove telnet access.
  
 
 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr70862</guid>
</item>
<item>
<title>HMR3: Observing AES-CCMP TSC replays on 1522 APs, Fixed CSCth52844</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCth52844</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
The Mesh AP consoles will show continuous or frequent messages of AES-CCMP TSC replays when there is some traffic on Ethernet bridged clients connected to any RAP/MAP. Packets that are identified as an AES-CCMP replay are dropped by the AP, as expected.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
No special conditions and the issue will not be seen consistent as the AP may stop the messages even with traffic on sometimes.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
No workarounds.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCth52844</guid>
</item>
<item>
<title>Controller crash in tpcv2ConstructApProfile, Fixed CSCug59937</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug59937</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Controller reboot with traceback tpcv2ConstructApProfile
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

TPC v2 enabled.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug59937</guid>
</item>
<item>
<title>Improper memory allocation by CTI process crashing CME, Fixed CSCty64721</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty64721</link>
<description>Symptoms: Improper memory allocation by CTI process crashes the CME.
&lt;br&gt;
Conditions: The CTI front end process is using up huge memory causing the CME
to crash eventually. When the crash occurs:

Processor Pool Total:  140331892 Used:  140150164 Free:     181728
      I/O Pool Total:   27262976 Used:    5508816 Free:   21754160
&lt;br&gt;
Workaround: There is no workaround. 



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty64721</guid>
</item>
<item>
<title>CLI Allows &quot;+&quot; (Plus Sign) In AP Group Name Breaking WLC Config via GUI, Fixed CSCtg42627</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtg42627</link>
<description>
WLC CLI allows a user to use the &quot;+&quot; (plus sign) in the AP Group name. 

config wlan apgroup add &lt;AP+Group+Name&gt;

This character is interpreted by the WLC as a space rather than a &quot;+&quot;, and breaks the configuration.  User cannot edit, or delete AP Group via the WLC Web GUI.

Per the WLC Web GUI, a plus sign is not a valid character. (An error is generated)
&lt;br&gt;
Workaround:

Remove the AP Group by using the following command via the WLC:

config wlan apgroup delete &lt;AP+Group+Name&gt;

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtg42627</guid>
</item>
<item>
<title>All WLCs|Code: 7.4.100.0|WLC schedule reboots at incorrect time, Open CSCug82362</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug82362</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC schedule reboots at incorrect time when set with DST time
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
If NTP server is configured and timezone configured with DST time effective
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Configure the time on the WLC manually

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug82362</guid>
</item>
<item>
<title>RRM: TPC should automatically disable radios (or auto monitor mode), Open CSCue46623</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue46623</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Wireless clients may experience poor performance, especially in 2.4GHz.

The channels are seen to be heavily congested, with numerous access points on the
same channel in the same location.  Access point radios&#39; transmit power is set very
low, and as a result rapidly moving clients may be unable to scan successfully, and
may experience intermittent connectivity.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

Access points are densely deployed, for example in order to support voice in 5GHz
and/or location services. RRM&#39;s TPC algorithm is set to control radio power.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Set a minimum transmit power level, for example 8 dBm, in order to establish
a minimum cell radius, in order to support mobile clients.  Measure co-channel
interference (CCI), for example, in the WLC Config Analyzer &gt; RF Analysis &gt; RF
Problem Finder &gt; Other APs Same Channel, and identify locations with excessive 
interference.

Manually disable radios in areas of excessive CCI.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

2.4GHz supports only 3 non-overlapping channels, and also propagates further than
5GHz.  As a result, in a dense deployment of dual band APs that supports strong
coverage in 5GHz, the 2.4GHz band is likely to experience excessive CCI.

If a large number of SSIDs are configured, and if the APs are beaconing at a low
data rate (1 or 2 Mbps), then the beacons alone are likely to consume an excessive
amount of the channel, in dense areas.  Under load, with heavy CCI, the 2.4GHz
is apt to experienced a high duty cycle and poor client performance.

With this enhancement request, RRM will be able to identify locations of excessive
density, and will be able dynamically to turn off, or set into monitor mode,
excess radios.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue46623</guid>
</item>
<item>
<title>HTTP port 80 open on  Access Points when controller is 7.4.100.0, Fixed CSCuf66202</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf66202</link>
<description>Symptom:
HTTP Port was by default enabled for all ap types

Port 80 open on access points running 7.4.100.0 controller code
&lt;br&gt;
Conditions:
AP upgraded to 7.4.100.0

&amp;lt;B&amp;gt;Workaround:&amp;lt;/B&amp;gt;

Create an ACL to block port 80 to AP subnet

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf66202</guid>
</item>
<item>
<title>WLC crash on 7.0.235.0 Task Name:     SNMPTask, Open CSCug88272</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug88272</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC crash on 7.0.235.0 Task Name:     SNMPTask
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
when snmpV3 used
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug88272</guid>
</item>
<item>
<title>Doc : Need to make clear WLAN controller Platforms supporting NAT, Fixed CSCty56374</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty56374</link>
<description>The current some CCO docs says unclear or wrong information about Wireless LAN controller Platforms supporting NAT.
Those information should be corrected.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty56374</guid>
</item>
<item>
<title>WLC crash at apfRogueTask on 4.2.207.0,   CSCte50421</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte50421</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC crashes at apfRogueTask on 4.2.207.0
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

None at this time.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCte50421</guid>
</item>
<item>
<title>Bridge 1310 doesn&#39;t reply to EAPOL when plugged to a dot1x switchport, Open CSCue75875</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue75875</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
When plugging the 1310 Bridge to a dot1x enabled switchport and having the correct configuration on both switchport and the bridge, the bridge doesn&#39;t reply back to EAPOL packets sent by the switch.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
N/A
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue75875</guid>
</item>
<item>
<title>WLC: dot1x interface create failure - &quot;Unable to find 802.1x interface&quot;, Fixed CSCue73385</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue73385</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Client authentication may fail with the following message on WLC:
*Dot1x_NW_MsgTask_0: Feb 19 09:39:13.283: xx:xx:xx:xx:xx:xx Unable to find 802.1x interface  aa:aa:aa:aa:aa:aa for mobile xx:xx:xx:xx:xx:xx

xx:xx:xx:xx:xx:xx = client MAC address
aa:aa:aa:aa:aa:aa = AP MAC address
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC running 7.0 code.
Issue found to be happening following repeated AP join failure.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Reload the WLC to clean the entries.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue73385</guid>
</item>
<item>
<title>Interface config changes after HA config, Open CSCug48432</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug48432</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
After configuring HA and the secondary reloads, the secondary goes into Maintenance mode. 
The reason to go to Maintenance mode is Communication Down.
 
We see the interface configuration gets lost on the secondary after reloading and off course there is no connectivity...
&lt;br&gt;

&lt;B&gt;Conditions:&lt;/B&gt;
Configure HA.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug48432</guid>
</item>
<item>
<title>7.4 config guide - AVC feature packet marking explanation missing, Open CSCug85641</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug85641</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
7.4 config guide doesn&#39;t have packet marking info for AVC
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
7.4 config guide doesn&#39;t have packet marking info for AVC
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
none

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug85641</guid>
</item>
<item>
<title>WLC Bonjour Gateway should provide more control of service distrobution, Open CSCue89879</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue89879</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Large campus unable to limit and control the WLC caching and responding to all queries.
For example, limiting the response to bonjour request to only respond to with devices from 1 particular VLAN
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Intending to implement bonjour devices on 1 VLAN and only have this 1 VLAN devices responding to clients
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue89879</guid>
</item>
<item>
<title>SNMP NAC should not be allowed without NAC Alert enabled, Open CSCug57545</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug57545</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Clients are unable to connect to SNMP NAC SSID with an error message of 
Unable to process out-of-band login request from &lt;MAC and IP Addr&gt; [device-filter]. Cause: OOB client&lt;MAC and IP Addr&gt; not found.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
After upgrade from 7.4
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Enable NAC Alert Client Trap

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug57545</guid>
</item>
<item>
<title>doc for LMS integration with ACS doesn&#39;t specify version requirements., Fixed CSCsr08888</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr08888</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;
Integration of LMS and CSM (or more than one LMS server) with ACS causes integration to fail for at least one of the servers.

Symptoms seen: 
only helpdesk role available for some components.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Different component versions installed on the servers. For example
Common Services 3.1.1 on one server, and Common Services 3.0.5 on another server.
&lt;br&gt;

&lt;B&gt;Workaround:&lt;/B&gt;
For Successful integration all components to be of the same version. Documentation doesn&#39;t currently clearly specify that at the moment. This defect has been opened to resolve this.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsr08888</guid>
</item>
<item>
<title>WLC not replying to SNMP after some time, Fixed CSCtx27358</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx27358</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLCs are &quot;unreachable&quot; from WCS perspective after some time.
In reality, they are fully operational and reachable except through SNMP. An snmpwalk on them will fail.
The WLC will report through debugs :
SNMPTask: Dec 22 10:00:53.076: Authentication failure, bad community string

*SNMPTask: Dec 22 10:00:53.076: Bad Community name

*SNMPTask: Dec 22 10:00:53.076: SNMPD: Failed to get result Pdu.


In reality, the community name used is the right one. And the WLC config backup shows that the same community exists on the WLC.
deleting and re-adding the community on the WLC solves the problem for some more days ...
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
unknown
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
recreate the community on wlc

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtx27358</guid>
</item>
<item>
<title>Improve performance of the filtering parameter cache, Fixed CSCug46654</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46654</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
This is not a bug but an enhancement.
It takes some tiny times (nano sec order) in case of having a tens of thousands
of entries in MAC filter.
This enhancement improves the search time much faster by optimizing the algorithm.
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
N/A
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
N/A




</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug46654</guid>
</item>
<item>
<title>WLC is reporting a large number of stale client entries, Open CSCug92421</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug92421</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
WLC is reporting a large number of stale client entries
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
WLC 7510, 7.3.103.14, numerous clients
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
None known at this time

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCug92421</guid>
</item>
<item>
<title>Roaming with PSK Fails if maxuserlogin is set to 1 on 7.0.235.3, Fixed CSCue02090</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02090</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;
Roaming fails if maxuserlogin is configured to 1
&lt;br&gt;&lt;B&gt;Conditions:&lt;/B&gt;
Maximum user login (config netuser maxuserlogin) is set to 1.
&lt;br&gt;&lt;B&gt;Workaround:&lt;/B&gt;
Disable or increase the maxuserlogin

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCue02090</guid>
</item>
<item>
<title>FlexConnect mode fallback function different for 11n and 11a, Fixed CSCuf93693</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf93693</link>
<description>
&lt;B&gt;Symptom:&lt;/B&gt;

AP is in FlexConnect mode and powered by AC adapter.
Two clients are connected to the AP, and when the ethernet cable 
is removed from the AP and then connected back to the AP in about 1 - 2 minutes,
one client still connected to network, but the other client is disconnected.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

7.3.103.12
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

NA

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCuf93693</guid>
</item>
<item>
<title>high latency with wireless N clients on 7500 WLC running 7.2 code, Fixed CSCty17976</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty17976</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

802.11n clients on a WLC 7500 will see packet latency around 2500 milliseconds.
Other WLC platforms are not affected.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

Run the following commands to disable the A-MPDU scheduler

config 802.11b 11nSupport a-mpdu tx scheduler disable
config 802.11a 11nSupport a-mpdu tx scheduler disable





</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCty17976</guid>
</item>
   
</channel>
</rss>
