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