This document describes common error messages in WCS and how to troubleshoot these errors.
Cisco recommends that you have knowledge of these topics:
How to configure the Cisco WCS
How to configure a wireless LAN (WLAN) with the WLAN Controllers (WLCs) and lightweight access points (LAPs)
This document is not restricted to specific software and hardware versions.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
You might receive this message when you install and run the new WCS 4.0 software on a Windows 2003 server:
"Please select another location to extract the installer to"
This error message might appear again even if another location is chosen to extract the installer file. This problem can happen if the downloaded installer file is corrupt.
In order to resolve this issue, download the installer file, and run the setup application again.
WCS license is issued based on the host name of the WCS server provided when you purchase the license.
WCS on Linux looks at the files /etc/hosts and /etc/sysconfig/network, and the output of the hostname command in order to determine the hostname of the server for licensing purposes.
One of the common problems seen during WCS license installation is where one or both the /etc/hosts and /etc/sysconfig/network files have been incorrectly built with a fully qualified domain name (FQDN), which causes the hostname command to incorrectly return the FQDN rather than just the hostname.
So, when you upload the license file (.lic) onto the WCS Linux server, the upload process may fail with this error message:
"license file does not match local host name "
Because the Cisco WCS license is tied to the host name of the server where Cisco WCS is installed, it is important to enter the correct host name during the Cisco WCS licensing registration process. If not, then the license key file generated will not match the host name of the WCS server and as a result the license key will not work. This will lead to this error message when you upload the license file.
You can resolve this issue with one of these options:
Change the host name of the WCS server to be the same as the license key file name.
In order to change the host name of the WCS server, complete these steps:
Stop the WCS service before you change the host name of the server as described in the "Stopping WCS on Linux" section of the Cisco Wireless Control System Configuration Guide.
Make a backup of the WCS database before you change the host name as described in the "Backing Up the WCS Database (for Linux)" section of the Cisco Wireless Control System Configuration Guide.
Change the host name of the WCS Linux server as described in Change your Hostname without Rebooting in RedHat Linux on the XenoCafe website.
Run a check on the database.
Navigate to the /opt/WCS4.0/bin directory (or the directory chosen during installation), and enter ./DBAdmin checkschema.
Start WCS.
Navigate to the /opt/WCS4.0/ directory (or the directory chosen during installation) and enter ./StartWCS
Request the Cisco license group to recreate a new license file with the correct host name of the server.
Wireless clients that run Temporal Key Integrity Protocol (TKIP) (mostly WPA-PSK) are reported by the WCS as having an incorrect WEP key.
The WEP Key configured at the station may be wrong. Station MAC Address is 00:11:85:1a:b4:e4', AP base radio MAC is '00:0V:85:65:2e:80' and Slot ID is '1'.
This is due to Cisco bug ID CSCse11202 (registered customers only) . This defect does not affect the performance of the WLAN. The fix for this is available with WLC release 3.2.171.6. In order to stop these error messages, upgrade the WLC software to 3.2.171.6.
When a user adds a rule to an access control list (ACL) in the WCS template, it fails if an existent number is used for the sequence number field as in the case of when a user inserts a rule in the beginning or middle of an existing list. This prevents WCS from inserting new rules into an ACL.
An exception is generated in the logs:
TRACE[com.aes] THROW java.lang.ClassCastException at com.cisco.server.managedobjects.aaa.AclHelper.addNewRule(Unknown Source)
Also, this error is presented to the user in the window:
Error(s): You must correct the following error(s) before proceeding: Error:\nUnknown Exception Occured.
This problem is due to Cisco bug ID CSCse66255 (registered customers only) . The workaround is to add a new rule to the end of the ACL or to modify the previous rule. This problem has been resolved in WCS version 4.0.87.0.
When you create a dynamic interface name within the WCS that contains capital letters and spaces (for example, Enterprise Access), the interface is successfully created. However, you might not be able to delete this dynamic interface from the WCS. You will receive this message when you try to delete the interface:
"SNMP Operation failed"
This problem is related to the bug ID CSCsc92240 (registered customers only) .
As a workaround, you can delete these interfaces only from the controller (not though WCS). Dynamic interfaces that are created with capital letters in WCS are renamed with lowercase letters in the controller. In order to delete the interface created with capital letters from the command line on the controller, you must use all lowercase letters. If there are spaces in the interface name, such as Enterprise Access, the command to delete the interface from the controller should be used with the interface name enclosed in quotation marks. For example:
config interface delete "interface name"
In this scenario, the command is config interface delete "enterprise access".
This problem is due to Cisco bug ID CSCse27134 (registered customers only) . WCS cannot save obstacles on current or new maps - nIDs exhausted. The user has reached the hard coded limit of 999. The logs show this output:
5/17/06 08:44:01.750 TRACE[general] Command is updateWalls 5/17/06 08:44:01.750 TRACE[general] SD Key is ServiceDomain!128 5/17/06 08:44:01.750 TRACE[objmgr] [DatabaseOpsHelper] Total Objects Deleted 0 5/17/06 08:44:01.750 TRACE[objmgr] [DatabaseOpsHelper] Total time in this Method is 0 5/17/06 08:44:01.766 TRACE[objmgr] [DatabaseOpsHelper] Total Objects Deleted 0 5/17/06 08:44:01.766 TRACE[objmgr] [DatabaseOpsHelper] Total time in this Method is 16 5/17/06 08:44:02.969 TRACE[com.aes] THROW com.bsn.server.api.BsnInternalException: COMMON-8,1,99999
There is no workaround, but WCS versions 4.0 and greater are not affected by this bug, so an upgrade to that release resolves the issue.
The WCS displays this minor alarm:
Client '00:14:a5:0d:fe:3c' which was associated with AP '00:17:0f:8c:96:30', interface '0' is excluded. The reason code is '1'
This minor alarm indicates that the client tried to authenticate repeatedly and failed. After the third attempt, the client was placed on the client exclusion list. At this point that particular client is not allowed to associate for 60 seconds (default or whatever you have set on the WLAN). After the 60 seconds are up, the client is freed to authenticate again.
When you install WCS 4.0 on a Windows 2003 server, you might see this error message. This is because the port 8009, which the WCS uses, is used by some other application. In order to resolve this issue, you need to determine which application uses port 8009, and stop that application. Complete these steps:
From the Windows 2003 server, choose Start > Run > cmd in order to open a command prompt.
Enter netstat -ano in order to list all the active TCP connections and TCP, UDP port numbers with the Process ID (PID).
Search for port 8009, and note the PID on the right.
Go to the Task Manager, and click View.
Select Columns, choose PID, and click OK.
Locate the process that has the PID you noted in step 3, and click End Process in order to close that application.
Heat maps are not generated in WCS 4.0 with Location Server 2.1. The user sees this error message:
'Failed to create heat map for MAC: xx:xx:xx:xx:xx:xx Reason: Failed to find any APs in the database for a RSSI list
This might be due to Cisco bug ID CSCse83815 (registered customers only) .
Complete these steps as a workaround:
Choose Monitor > Maps, and select the floor where the AP heat maps do not show up.
Go to position aps in the drop-down list on the far right.
Select the AP where the heat maps do not work.
On the left, choose Other for the Antenna Type, and click Save.
Go back to the Antenna Type and select the same antenna that it orginally used, and click Save again.
The heat map for this AP should now work.
This message indicates that the AP that was at one time marked as a trusted rogue AP is no longer seen by the controller. When a controller detects a rogue AP, you have the option to make that AP a trusted AP, once it is a trusted AP this trap message appears if the controller does not hear from that AP anymore.
These bugs are associated with this error message.
CSCsd73855 (registered customers only) —A rogue AP was detected at a remote site and marked as 'Contained' by a single access point.When the access point was no longer detected, WCS put up an alert about a trusted access point is missing or failed.
Trusted AP <mac-address> on Controller <ip-address> is missing or has failed
There is no known workaround at this time.
CSCsc59180 (registered customers only) —When a rogue access point is detected by WCS and when a user sets the state to Known - External, Cisco WCS displays the access point as Trusted Missing.
You would not be able to add and configure the APs for one of these reasons
When WCS and WLC are running incompatible versions, make sure they run the same major versions of the code.
When the controller to which the AP belongs is unreachable, ensure that WCS has connectivity to the WLC of the AP.
If WCS polls the controllers through links with lower MTU, try to tweak the variable MaxVarBindsPerPDU setting in WCS. This parameter decides the number of attributes sent in a single packet. Size of the packet can be changed if you modify the number of attriubutes sent. In order to access the variable, choose WCS installationdirectory > webnms > classes > com > cisco > server > resources. Open the SNMPparameters.properties file with the Wordpad and locate the variable MaxVarBindsPerPDU. It has the default value of 100. Change it to 50 so that WCS puts fewer attributes in the single SNMP packets, thus it has smaller packets.
You might receive this error message or other error messages when you add a Location Server to WCS:
No response from Location Server. It may be unreachable, or connectivity credentials are incorrect
There are a number of factors that can create problems when you add a Location Appliance to WCS. Follow these tips in order to troubleshoot:
Verify that the location appliance is powered on; the power light stays on and does not flash.
Verify that the WCS server can ping the Location Appliance.
Use the command-line interface of the location appliance in order to ensure that the server process is running.
If the command-line parameters are set correctly within the Location Appliance through the console, the initial user name is admin, and the password is admin when you add the Location Appliance to WCS. The check box for HTTPS should be cleared until the Location Appliance is added and the software level can be checked and upgraded as needed. The name used is case sensitive and should be only the host name assigned to the Location Appliance, not the fully qualified domain name.
Refer to Configuring Location Appliance for detailed information on how to configure the Location Appliance.
When configuring WCS to communicate with the Location Appliance, the user name, password, and port number should remain unaltered and in the default state. For more information, refer to Importing the Location Appliance into WCS.
Ensure that the time setting on the Location Server matches the WCS time.
WCS might be one revision older than the Location Server. In this case, upgrade the WCS to latest version.
If user name or password problems continue to occur, the internal database on the Location Appliance, which contains the user database, can be set back to factory defaults. In order to set the internal database back to the factory defaults, follow these steps:
Use the rm -f /opt/locserver/db/linux/server-eng.db command in order to delete the server-eng.db file.
Use the /etc/rc.d/init.d/locserver restart command in order to restart the Location Appliance.
When you import an asset information file (asset.out) for a location server that uses WCS, this error message appears:
Imported file is not of the correct type. Please import .txt file
This issue is documented in bug ID CSCsg79427 (registered customers only) and is associated with earlier versions of WCS and Location Appliance.
In order to resolve this issue, rename the asset.out file to asset.txt, and reimport the file. The file name of the asset information must end in the .txt file extension even though the file might be a valid ASCII text file. Any other extension will generate an error upon import.
This issue has been resolved in WCS version 4.1.83.0 and Location Appliance version 3.0.37.0. Refer to Importing and Exporting Asset Information for information on how to import and export asset information for location appliances that use WCS.
WCS uses a third-party application, such as MATLAB Compiler, and MATLAB uses a specific version of the DFORRT.dll library. So when an application has already installed the DFORRT.dll library in c:\windows\system32 folder, the WCS is not correctly installed. When you start WCS, you receive this error message:
The procedure entry point _FIIfexp_ could not be located in the dynamic link library DFORRT.DLL
In order to correct the problem, remove the DFORRT.dll file in c:\windows\system32 and reinstall WCS.
When you make changes to the WLAN controller through WCS, you might receive this error message:
ERROR: MIB access failed
One possible reason for this error to appear in WCS is an incorrect SNMP access parameter is set for the controller. If you enter a read-only access parameter, the controller is added, but WCS is unable to modify the configuration.
You must resolve this issue before you proceed to the next step. In order to resolve this issue, ensure that any SNMP access parameter is set to write.
Note: Cisco recommends that you always use the lastest versions of WLC and WCS.
Perform these checks:
WCS and WLC should have compatible software versions. Ensure that they run the same major version.
WCS and WLC should be synchronized with each other. On WCS GUI, choose Configure. From the pull down box in the right-hand side, click Controller and choose a WLC. Click Refresh config from controller.
If you get the Permission Denied error message when you push the template to the WLC, make sure that you are logged in as the root user on WCS.
Revision | Publish Date | Comments |
---|---|---|
1.0 |
19-Jul-2007 |
Initial Release |