Engineering Special 6.0.196.159 WLC Code

Cisco TAC released an engineering special version of code for wireless LAN controllers last week which resolves numerous open caveats with the 6.0 train of code.

If you're running 6.0 and have noticed issues related to these resolved caveats, call Cisco TAC and inquire about this code version. It's not available on CCO.

Addendum Release Notes for Cisco Wireless LAN Controllers and Lightweight Access Points for Special Build AS_5500_6_0_196_159

Base Code: 6.0.196.0

Special Build: AS_4200_6_0_196_159

The code is designed for AIR-WLC5500

Filename: AS_4200_6_0_196_159.aes

ENGINEERING SPECIAL BUILD

AS_4200_6_0_196_159 is a build from 6.0.196.0, and it is an engineering special that resolves the following additional caveats:

CSCta13941 - AP rejecting association request with status code 13

CSCtb02136 - AP with AP Groups and HREAP will not broadcast SSID

CSCtb20125 - CCMP errors on key rotation

CSCtc73503 - Radios are showing Tx power level 0

CSCtd28542 - WLC crash on emWeb due to AP config change

CSCtd97011 - Radio core dump: Neighbor Discovery frames stuck

CSCte19262 - Client Deauthenticated – “Unable to locate AP 00:00:00:00:00:00”

CSCte55219 - radio core dump due to large # of uplink frames in inprog queue

CSCte55458 - Web-Auth: Web page takes a long time to display under heavy load

CSCte62815 - 5508 not passing OSPF Multicast traffic

CSCte78472 - Invalid PHY rate returned on ADDTS response

CSCte81420 - Crash in process: "Dot11 driver "

CSCte89891 - AP doesn't transmit beacons

CSCte92365 - Auto Immune - AP side

CSCte93549 - The dot11a radio not able to pass traffic, tx queue getting filled.

CSCte96140 - Ethernet bridging breaks when the Ethernet interface of AP 1242 flapped

CSCtf23682 - 5508 - AP cannot join with Multicast MAC as gateway (checkpoint)

CSCtf34858 - Clients unable to pass broadcast traffic

CSCtf69598 - Memory leak in AP on CCKM Failure

CSCtc57611 Delay in Music on Hold on 7925 with HREAP AP CSCtg45014 CT5508 - CAPWAP Control traffic has incorrect DSCP marking.

CSCtg71658 ap power level reset to 0 when upgrading from 5.0 to 6.0.196.158

CSCtd43906 J: RAP not transmitting after coming up; when shut due to radar

*ENGINEERING SPECIAL USE DISCLAIMER*

The Engineering Special fix supplied herewith is a Temporary Software Module which has undergone limited testing. This temporary software module is provided “AS-IS” without warranty under the terms of the END USER LICENCSE FOR THIS PRODUCT. Please use this software at your own risk. The intention for this code fix is for you to use in your production environment until a released version is available.

This code is supported by the TAC organization. Please report all comments, suggestions, and problems about this code directly to wnbu_escalation_external@cisco.com. If you are satisfied with the solution, please inform the alias.

Contact wnbu_escalation_external@cisco.com with any questions.

Certificate Conversion

The Cisco wireless LAN controllers are shipped with built-in self-signed certificates for web management and web portal authentication. In addition, certificates can be uploaded for use with Local EAP authentication and Certificate Authority verification purposes.

However, the controllers only recognize PEM format certificates. Who knows why, since they're not used for protected email of any form. The only reason that I can think for use of this format is that it's well known and can accommodate both certificates containing private keys and certificates containing only public keys. Cisco calls certificates including private keys "Vendor Device Certificates", and certificates containing only public keys, such as a CA certificate for verifying digital signatures, a "Vendor CA Certificate".

If you're certificate authority or PKI is based on Microsoft, which does not support PEM, then you're stuck converting certificates from PKCS12, PFX, DER, or Base64 into PEM format for import on the controller. Here's how to do it:

First, download and install OpenSSL on your workstation, either linux or Windows. It can be found here:
http://www.openssl.org/
http://www.slproweb.com/products/Win32OpenSSL.html

If PFX or PCKS12 device certificates need to be converted to PEM format, complete the following steps:

• Copy the PFX or PCKS12 certificate to a PC with OpenSSL installed
• Execute the C:\OpenSSL\bin\openssl.exe file on Windows from a command prompt, or the executable file on Linux, and enter the following commands:
  
  openssl> pkcs12 –in certificate.pfx –out newcertifcate.pem
  
  Enter Import Password : existing_private_key_password
  
  MAC verified Ok
  Enter PEM Pass phrase: new_private_key_password
  
  Verifying – PEM pass phrase: new_private_key_password
  
• The certificate file is now converted to PEM format and is ready to be downloaded to the controller.

If DER or Base 64 CA certificates need to be converted to PEM format, complete the following steps:

• Copy the DER or Base 64 certificate to a PC with OpenSSL installed
• Execute the C:\OpenSSL\bin\openssl.exe file on Windows from a command prompt, or the executable file on Linux, and enter the following commands:
  
  openssl> x509 –in certificate.cer –inform DER –out newcertifcate.pem –outform PEM
  
• The certificate file is now converted to PEM format and is ready to be downloaded to the controller.

If  private key and certificate files both in PEM format need to be merged into a single PKCS12 file, complete the following steps:

• Copy the PEM private key and certificate files to a PC with OpenSSL installed
• Execute the C:\OpenSSL\bin\openssl.exe file on Windows from a command prompt, or the executable file on Linux, and enter the following commands:
  
  OpenSSL> pkcs12 -export -inkey certpvk.pem -in cert.pem -out certnew.p12
  Loading 'screen' into random state – done
  Enter Export Password: new_private_key_password
  Verifying - Enter Export Password: new_private_key_password
  OpenSSL>
  
• The certificate and private key are now merged into one PKCS12 file.

Upload the converted certificates to the controller either through the web interface or the CLI.


Andrew

Cisco Location Protocols

In the final post on the Cisco location tracking solution, I thought it would be helpful to describe the communication protocols used in the system. Cisco's documentation in this area is sketchy and disconnected at best; you really have to piecemeal all the information together from various documents on their website. Luckily for you, I have done that!

• Cisco 2700 Series Location Server API
  Used by the WCS or other 3^rd party location clients to pull information from the legacy 2700 series location appliance. The location appliance may also send northbound notifications to the WCS or 3^rd party location clients using this port. Location server uses SOAP/XML to transport data using either HTTP or HTTPS. Location server uses TCP port 8001 by default, but is configurable.

• Mobility Services Engine (MSE) API
  Used by the WCS or other 3^rd party location clients to pull information from the newer Mobility Services Engine (MSE). The MSE appliance may also send northbound notifications to the WCS or 3^rd party location clients using this port. MSE uses SOAP/XML to transport data inside either HTTP (TCP port 80) or HTTPS (TCP port 443). HTTPS is used by WCS, but HTTP can be enabled for 3^rd party applications. Legacy port 8001 is also supported, but disabled by default.

• Network Mobility Services Protocol (NMSP)
  Used by the location appliance (code version 3.1 and later) and MSE to query location information from the wireless LAN controllers (code version 4.2 and later). NMSP uses TCP port 16,113.

• Location Protocol (LOCP)
  Used by the location appliance (code version 3.0) to query location information from the wireless LAN controllers (code version 4.1). LOCP is replaced by NMSP in location appliance code version 3.1 and WLC code version 4.2. LOCP uses TCP port 16,113.

• SNMP Traps
  Used by the location appliance and MSE to send notifications to WCS or other upstream 3^rd party location clients. SNMP traps use UDP port 162.

• SNMP Management
  Used by the location appliance, MSE, and WCS to poll information from the wireless LAN controllers. Beginning in location appliance code version 3.0 and controller code version 4.1 the location appliance uses LOCP or NMSP to poll tag location information from the controllers instead of SNMP. WCS always uses SNMP to poll management information (and location information when no location appliance is in-use) from controllers. SNMP management uses UDP port 161.
  

There you have it!

Andrew

Wi-Fi Tip: AP Join in a Pinch

Ever been in an emergency situation where you need to get an AP up in
a hurry? Perhaps you didn't configure DHCP Option 43 b/c you have a
gizillion scopes, or the DNS name b/c of a common suffix across
multiple sites. Try this...

On the default gateway device (router or L3 switch) issue these
commands:

ip forward-protocol udp 12223

ip forward-protocol udp 5246



interface GigabitEthernet0/0

   ! Define the helper address for the DHCP

   ! server so APs can obtain an IP address

   ip helper-address 192.168.1.10



   ! Define the helper address for the WLC

   ! to forwarded LWAPP/CAPWAP discovery broadcasts

   ip helper-address 192.168.2.20

Configure the interface attached to the subnet the AP is connected to,
and use the controller's management interface as the helper address.

These commands tell the router to forward LWAPP and CAPWAP control
broadcast frames, including discovery requests, to configured ip
helpers which now includes the controller!

You should see the AP discover and join the controller within seconds
as if they were on the same subnet.

Cheers,
Andrew

Cisco Location Accuracy Tips

To improve the Cisco location system accuracy, follow a few guidelines. Ideally, administrators need to carefully plan and design the wireless network to support location services prior to implementation. However, many times existing networks initially deployed to only serve data clients need to be retrofitted to add voice and/or location services.

If retrofitting an existing network, consider planning for both voice and location services with the upgrade. Many design guidelines for voice and location services overlap, but there will be some differences which need to be considered.

Tips for improving location accuracy:

1. Proper AP Placement
   It cannot be stressed enough, proper network design is crucial! There are several things to keep in mind when planning access point locations:
1. Include perimiter APs. Data and voice networks don't need APs at the perimiter of a coverage area, interior APs work fine. However, location accuracy along the edges of the coverage area depend on having APs at the perimiter.
2. AP density. Location accuracy is best when APs are placed every 50-75 ft. covering 2,500 to 5,000 sq. ft. each. This will vary based on each environment, but plan on a more dense deployment than a data network, 2.4 GHz voice network, and about equivalent density to a 5GHz voice network.
3. Staggered placement. When covering hallways and long spaces, stagger APs rather than using a linear straight line.
4. AP height under 20 ft. Ideally around 10 ft.
5. Not all APs need to serve clients. Use monitor-mode APs if the density required is too great and causes excessive co-channel interference, especially on the 2.4 GHz band. Monitor mode APs don't serve clients or transmit frames, but can track client locations by listening to them.
6. Ensure a minimum of 3 APs can hear each client at -75 dBm. This is not a hard requirement for location to be determined, but will greatly improve accuracy.
2. RF Calibration
   Use a CCX v2 or later client to perform a calibration of the environment. A Cisco Aironet CB21AG card is recommended.
3. Smoothing Algorithm
   In WCS, configure the location server smoothing algorithm. This in effect reduces "jitter" of the location algorithm and weights prior client locations into the calculation of the current client location.
4. CCX Location Measurement
   If clients in the network are CCX v2 capable, enable CCX Location Measurements in each radio band. The APs will issue broadcast CCX radio measurement requests to clients prompting them to transmit probe requests. The APs in the area can then receive signal strength information immediately for all clients, even if idle.
5. Install Chokepoints
   Install chokepoints in areas of the network requiring more granular location accuracy or to trigger event notifications.

Following these tips should allow the network to locate devices within 10 meters around 90% of the time.

For more information, see the following document:

Cisco Wi-Fi Location Based Services 4.1 Design Guide

Andrew

Wi-Fi Tip: Improve Mobile Device Battery Life

To improve battery life on mobile wireless devices including phones, voice badges, and handheld scanners, increase the WLAN DTIM period to the client vendor recommended values. Each vendor typically provides optimal recommendations for DTIM settings with their devices. Examples include DTIM settings of between 2 - 10 beacon intervals.

The DTIM period controls how often the client device must wake out of power-save mode to receive the beacon indicating if any data is buffered for it at the access point. Higher DTIM periods allow the devices to stay in power-save mode longer and increase battery life.

Also, in QoS enabled networks U-APSD (unscheduled automatic power save delivery) and in 802.11n networks PSMP (power-save multi-poll) provide better power-save performance than legacy DTIM operation and are usually enabled by default.

Cisco Location Tracking Setup

In a previous post, I detailed Cisco's location tracking approach. Now on to implementation!




First, here are the requirements for implementing a 2700/2710 location appliance or MSE:

• Cisco WCS server with the "WCS Base + Location" (older) or "WCS Plus" (newer) license to configure the location server, controllers, define network maps, and synchronize everything together
• Cisco 2700, 2170, or MSE appliance to perform the location calculation
• Cisco wireless LAN controllers and access points (sorry, Autonomous is not supported)
• Verify WCS, controller, and location appliance software compatibility from the location software release notes

Implementation Steps (assuming a working WCS server with controllers and APs already imported):

1. Import campus, building, and floor area maps
2. Use the Map Editor tool to define floor attenuation characteristics
3. Assign access points to floor areas
4. Initial setup of the location server or MSE
5. Add location server to WCS
6. Configure location server tracking parameters
7. Install licenses if using MSE
8. Synchronize network designs (maps), controllers, and notification events

Steps 1 through 3 are well-documented and fairly intuitive, so we'll skip by those for now.


Step 4 - Initial Setup of the Location Server or MSE


Connect to the 2700 Series Location Appliance or Mobility Services Engine (MSE) using a DB-9 serial console cable for initial configuration using the setup wizard. A standard Cisco rollover console cable and terminal DB-9 adapter can be used.


Run the setup wizard to configure the appliance for initial use. Most of the setup questions are self-explanatory, but I want to highlight a few notable parameters. The default login for shell access (these are linux appliances) is username "root" and password "password". The default login for WCS to access the location appliance is username "admin" and password "admin". Both of these accounts can be changed during the setup wizard. 


Also, during initial setup be sure to set the time correctly. It is highly recommended to use a common NTP time source for WCS, controllers, and the location appliance.


If you need to run the setup wizard again at a later time, it is located at /opt/locserver/setup/setup.sh or /opt/mse/setup/setup.sh. You can run it again and modify only the parameters that need to be changed, including NTP servers.


To view, stop, or start the location service you can run the command "/etc/init.d/locserverd { status | stop | start | restart }" or "/etc/init.d/msed { status | stop | start | restart }".


Step 5 - Add Location Server to WCS


In WCS, navigate to the Location > Location Servers screen. In newer WCS versions this changed to the Services > Mobility Services screen.


From the drop-down menu select "Add Location Server" or "Add Mobility Services Engine" depending on which appliance you are using. Fill in the corresponding information, including the username and password to authenticate to the location appliance as configured during the setup wizard (default was admin, admin).


WCS communicates with the 2700 series appliances over port 8001 and the MSE over 443 (HTTPS) by default.


Step 6 - Configure Location Tracking Parameters


This step ensures that the location server is configured to track clients, tags, rogues, etc. In WCS 6.x versions, navigate to Services > Mobility Services, click on the appliance name, then select the Context Aware Service > Administration > Tracking Parameters menu.


Check the boxes next to the items for which location information needs to be tracked, including Wired Clients, Wireless Clients, Rogues, and RFID tags. You can also limit the amount of each type to track.

Step 7 - Install MSE Licenses


If using an MSE appliance, various services are licensed individually, including context aware service (location), wIPS intrusion prevention, and mobile routing. After purchasing a context-aware license from Cisco and registering the PAK file, Cisco will email you a license file. Install the license file through WCS in the Administration > License Center menu.


Select Files > MSE on the left menu, and click Add. Follow the prompts to add the license and assign it to a specific MSE appliance.


Step 8 - Synchronize Elements


Finally, you must synchronize network designs, controllers, and notification events in order for location tracking to be performed. At a minimum, you will want to synchronize network designs and controllers. Notifications can also be synchronized if alerting on specific location events are to be performed.


Navigate to Services > Synchronize Services, and use the "Assign" hyperlink to assign elements to the location server. Once assigned, the sync status should change to green bi-directional arrows to indicate success. If any element changes, for instance if a map is subsequently edited in WCS, the sycn status will be in error. A periodic scheduled task can be enabled to re-synchronize out-of-sync elements on a recurring basis, or the administrator can manually re-sync elements as well.


Wait for a few minutes and location tracking information should populate into WCS. To view location information, navigate to Monitor > Maps, select a synchronized map. Check the client, 802.11 tags, or rogue elements on the left hand side to view them on the map.

Client locations are shown in this image as blue squares on the map. Hover over a client to view relevant inventory and connection status information. Click on the client to open a more detailed page which includes the ability to view historical location information for that specific client (select Location History from the drop-down box on the client detail page).


In the next post on this topic, I'll provide some tips for improving location accuracy and also provide a reference on what protocols are used for communication between WCS, controllers, and location appliances.


Andrew

Wi-Fi Tip: Multicast Reliability

Multicast data is sent at the highest enabled basic-rate (Mandatory
rate). This can cause issues for clients at the edge of the cell who
are connected at a lower enabled rate and cannot properly de-modulate
the frame. To improve reliability, set only the lowest enabled data
rate as basic/mandatory to ensure that clients at the cell edge can
receive multicast frames.

Wi-Fi Tip Of The Day

In high multipath environments, enable only lower data rates to prevent excessive data rate shifting and ensure more error correction is performed.