Troubleshooting Guide For Wireless Client

Interoperability Issues with CUWN

Contents
Introduction
Prerequisites
Requirements
Components Used
Background Information
I. Problem Definition
II. WLC Configuration And General Logs
Run-Config
WLC Configuration File
GUI
CLI
Syslogs from the WLC
III. Client Device Details and Information
IV. Network Topology
V. Track Additional Details and the Specifics
VI. WLC - Show and Debug Commands
WLC Debug Commands
WLC Show Commands
VII. AP - Show and Debug Commands
Lightweight Cisco IOS Access Points
AP Show Commands
AP Debug Commands
AP-COS Access Points
AP-COS Show Commands
1800 series | AP-COS Debug Commands
2800/3800 Series | AP-COS Debug Commands
VIII. Client Side Packet Captures
IX. Over-the-Air (OTA) Packet Captures
802.11n Captures
802.11ac OTA Captures
X. Summary
I. Problem Definition
II. WLC Configuration and Logs
III. Client Device Information
IV. Network Topology Diagram
V. Create a Spreadsheet To Record All Client Issues
VI. Show and Debug Commands on the WLC
VII. Show and Debug Commands on the AP
Lightweight Cisco IOS APs
AP-COS APs
VIII. Client Side Captures
IX. OTA Captures
802.11n Captures
802.11ac Captures
XI. Appendix A - Additional Tips and Tricks
Windows
macOS (formerly OS X)

Introduction
This document describes in detail what information needs to be initially collected to effectively
investigate and troubleshoot such wireless interoperability issues when they arise with Cisco's
Unified Wireless Network (CUWN) solution. The need for such a comprehensive approach
becomes increasingly important with the ever growth in numbers and combinations of wireless
client devices and access point (AP) radios.

Prerequisites
Requirements

Cisco recommends that you have knowledge of these topics:

● Cisco Wireless APs

● Wireless LAN Controllers (WLC)
● Related Network Devices

Components Used

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.

Note: The intended audience for this document are experienced wireless network engineers
and administrators who are already familiar with the use, configuration and troubleshooting
of these topics.

Background Information
It can be common to find that given the various client devices that both exist and continue to be
developed. A variety of issues can arise with regards to establish, maintain, or simply to get the
most out of their connection to the wireless network and to support infrastructure.

This can often come down to a simple configuration issue on the part of the client device and/or
the wireless infrastructure itself. However, in some cases this can be attributed to an
interoperability issue with regards to a specific client device and components that support it (i.e.
supplicant, WLAN adapter, wireless driver, etc.), and/or the APs in question. As wireless
engineers, such interoperability issues pose an opportunity to identify, troubleshoot, and resolve
potentially complex challenges.

Additional information to what is outlined in this article might be requested and needed to be
collected on a case by case basis, given the unlimited number of variables that might dictate such
requirements. However, the information detailed here is a generic guideline to address any
potential wireless client interoperability issue.

I. Problem Definition
The first step to effectively approach any problem with the intent to get resolute, is to accurately
define the issue at hand. To do so, ensure that at a minimum of these questions are asked and
their answers are clearly documented:

● Is the issue restricted to a specific model of APs and/or radio type (i.e. 2.4 GHz versus 5
GHz)?
● Is the issue observed only on specific version(s) of WLC software?
● Is the issue experienced with only specific version(s) of client type(s) and/or software (i.e. OS
version, WLAN driver version, etc.)
● Are there any other wireless devices which do not experience this issue? If so, what are they?
● Is the issue reproducible while the client is connected to a simplified wireless setup such as an
open SSID, with a channel width of 20 MHz, and 802.11ac disabled? (i.e. does the issue
happen on 802.11n mode versus 802.11ac mode only?).
● If the issue is not reproducible with an open SSID, at what minimum security configuration is
the issue seen? (i.e. PSK or 802.1X on the WLAN).
● What were the previous working configuration and software versions?

II. WLC Configuration And General Logs

Run-Config

Without exception, it is of absolute necessity to collect the customer's WLC configuration for a
detailed review of features used by the customer, their specific setup, and other such details. To
do so, you must establish a Telnet/SSH session to the WLC(s) in question and save the output of
these CLI commands to a text file:

config paging disable

show run-config
The full run-config output is always preferred, as it includes detailed information with regards to the
joined APs and associated RF information, etc. Though in some cases and situations, such as
when you initially work with a WLC with a large number of APs joined (i.e. 8510 WLC with 2500+
APs). It might be preferred to initially collect just the configuration of the WLC without such AP
information for quick review, as the full show run-config might take 30 minutes or more to complete
the given the number of APs. However, it might still be needed to collect the full run-config output
at a later time.
To do so, you can optionally collect the output of these CLI commands to a text file:

config paging disable

show run-config no-ap

show wlan apgroups

WLC Configuration File

In addition to either the show run-config or show run-config no-ap output, it is also
recommended to collect a full backup of the WLC configuration as well. This is of assistance, if a
lab recreate needs to be conducted by both TAC/HTTS and BU Escalation, to try and reproduce
the customer's issue in a Cisco lab environment. A backup of the WLC can be collected via the
GUI or the CLI of the WLC in question, with the use of either TFTP or FTP to save the
configuration file to the external TFTP/FTP server. The below example shows the usage of both
the GUI and CLI to save a backup of the WLC, with the use of TFTP:

GUI

Commands > Upload File > Configuration > Upload as shown in the image.

CLI

transfer upload datatype config

transfer upload mode tftp transfer upload serverip <TFTP-Server_IP-address> transfer upload path
/ transfer upload filename <desired-filename> transfer upload start

Syslogs from the WLC

At this time, you also want to collect the current logs from the WLC for additional review as
needed. Ideally, you want to collect these logs immediately after your test with a wireless client
whereby the reported issue is reproduced. If the customer exports the WLC logs to an external
syslog server, then you want to retrieve them from there. Otherwise, you can save the msglog and
traplog currently stored locally on the WLC by saving this CLI session output to another text file:

config paging disable

show msglog

show traplog
III. Client Device Details and Information
The next step is to gather as much information and specifics with regards to the client device(s) in
use that experience a potential wireless interoperability issue. Such information should include, but
is not necessarily limited to these:

● Client type (i.e. tablet, smartphone, notebook PC, etc.)

● Device make and model
● OS version
● WLAN adapter model
● WLAN adapter driver version
● Supplicant used (i.e. Windows Zero Config / Auto Config, Intel PROSet, etc.)
● Security configured for use by the wireless client and WLAN (i.e. Open, PSK, EAP-
PEAP/MSCHAPv2, etc.)
● Note any client parameters that have been changed from the default settings provided by
the vendor in question (i.e. sleep state, roaming parameters, U-APSD, etc.).

Note: Any additional information or notes with regards to the client device(s) up to which
includes screenshots of its WLAN related configuration(s), and so forth must also be
included as needed.

IV. Network Topology

To further expedite troubleshooting efforts and the Root Cause Analysis (RCA) process, it is
always recommended to provide a detailed and thorough network topology diagram. The network
topology diagram should not only include details about the network and wireless infrastructure, but
also provide an insight into the wireless device(s) in question which operates within the network
(i.e. printers/scanners, what client VLAN(s) are in use, etc.) and their location(s) relative to one
another.

A number of tools (i.e. Microsoft Visio, draw.io, etc.) and a variety of styles can be used to create
such a network diagram. The important aspect is to simply ensure that the proper information is
clearly reflected in the diagram provided for review by all involved parties and vendors. An
example network topology that captures basic, but useful information with regards to both the
infrastructure and client devices as shown in the image.
V. Track Additional Details and the Specifics
To help ensure that the appropriate information is collected at the time of any test with the client
device(s) that end users experience issues with. It is recommended to preemptively create a
spreadsheet or similar to record all the client issues and related details observed at the time of the
test, such as this example:

Time end Ping WiFi Signal

Description
user default status
MAC Address Username of Reported Record ipconfig /all (or e
observed gateway (Connected/trying
Symptom
symptom Y/N to Connect)
 ifconfig en0
en0:
Lost
flags=8863<UP,BROAD
network
Intermittently mtu 1500
connectivity
disconnects ether xx:yy:aa:bb:00:1
xxyy.aabb.0011 test_user1 and N Trying to Connect
from access inet6 fe80::848:cb8f:88
wireless
point. inet 192.168.10.237 ne
association
nd6 options=201<PER
from AP3.
media: autoselect
status: active

The goal of this exercise is to help document and determine a common pattern of interest, as well
as to get an accurate picture of the issue(s) at hand. Once this spreadsheet is prepared to be used
for data collection, you are now ready to begin your tests. Some additional, yet important
considerations are as follows:

Note: All debugs and packet captures collected need to be synchronized to the same NTP
server for easier correlation with the logs, and must be taken at the same time for any given
test.

Note: Provide an accurate timestamp of when the issue is observed, and when the issue
seems to recover (if applicable).

Note: Always collect debugs filtered per client MAC address on both the AP and WLC.

Note: Do not run show and debug commands on the AP within the same
Telnet/SSH/console session, these should be done separately in a different session
accordingly.

Note: AP debugs are preferred to be taken on Telnet/SSH versus Console, as the console is
typically too slow to be effective.

VI. WLC - Show and Debug Commands

When tests are conducted to reproduce and troubleshoot potential wireless client interoperability
issues, it is imperative that debugs and additional logs be collected from the wireless infrastructure
in use. These two sections can explain in detail the specific logs and initial debug output that
should be collected from the WLC and AP(s), respectively.

WLC Debug Commands

config sessions timeout 0

debug client <MAC_address> debug dhcp message enable
With respect to the nature of the issue at hand, you can also add these WLC debugs on a case by
case basis:
 ● debug aaa detail enable - use this if there are authentication related issues with the AAA
server
● debug aaa events enable - use this if there are authentication related issues with the AAA
server
● debug aaa all enable - use this for auth issues; the output for this debug is verbose so use it
only when absolutely needed (i.e. for AAA override cases, etc.)
● debug mobility handoff - use when there are roaming issues between WLCs
Once the issue is reproduced with the wireless client in question, and all of the information
outlined in the sections prior and after this are collected and documented. In order to execute
these CLI commands, you must disable the debugs on the WLC.

debug disable-all

WLC Show Commands

config paging disable

show time

show client detail <MAC_address>

ping <client_IP-address> <repeat count [1-100]>

As previously mentioned, ensure to run the WLC debugs in one Telnet/SSH session and collect
the output for these show commands in another Telnet/SSH to the WLC. You must do the same to
collect the AP debugs and show commands output detailed in these section.

VII. AP - Show and Debug Commands

Lightweight Cisco IOS Access Points

Before you start any debugs on any lightweight IOS AP(s) involved in the test, such as the 2600,
2700, 3700 or prior model Cisco access points. You must first execute these CLI commands on
the AP, in order to avoid a timeout at the time of a Telnet/SSH/console session to the AP(s) in
question when your client test(s):

debug capwap console cli

config t

line vty 0 4

exec-timeout 0

session-timeout 0

You can also follow these steps to use the console connection and replace the line vty 0 4
statement with line console 0 instead, in order to disable the exec and session timeouts for a
serial/console connection accordingly.

● line console 0 - use to modify serial session timeout parameters

 ● line vty 0 4 - use to modify Telnet/SSH session timeout parameters

AP Show Commands

Before you begin the test, you must first collect a sample of these show commands on the AP.
You should collect the output of these show commands at least twice for each test which involves
the wireless client in question; both before and after the test is complete.

term len 0

show clock

show tech

show capwap client mn

show int do1 dfs

show logging

more event.log

show trace dot11_rst display time format local

show trace dot11_rst

show trace dot11_bcn display time format local

show trace dot11_bcn

AP Debug Commands

Once you have collected the initial output of the aforementioned show commands, you can now
enable the debugs on the same access point in a separate Telnet/SSH session as shown. Ensure
to save the entire output to a text file.

debug dot11 {d0|d1} monitor addr <client_MAC-address>

debug dot11 {d0|d1} trace print clients mgmt keys rxev txev rcv xmt txfail ba

term mon

Legend

Flag Description
d0 2.4 GHz radio (slot 0)
d1 5 GHz radio (slot 1)
mgmt Trace management packets
ba Trace Block ACK information
rcv Trace received packets
keys Trace set keys
rxev Trace received events
txev Trace transmit events
txrad Trace transmit to radio
xmt Trace transmit packets
txfail Trace transmit failures
rates Trace rate changes

To disable the debugs on the AP once the test and data collection process is completed, you can
execute this CLI command on the AP:

u all

AP-COS Access Points

For 802.11ac wave 2 capable access points and later, such as the 1800, 2800 and 3800 model
access points. These newer model APs introduce a completely new operating system for the
access point platforms referred to as AP-COS. As such, not all commands as previously used on
the traditional lightweight Cisco IOS based access points as detailed above still apply. If when you
troubleshoot an issue involves interoperability issue with various client STA devices and AP-COS
model APs, then these information should be collected from the AP-COS access point(s) involved
with the equivalent test.

Before you start any debugs on any AP-COS model AP(s) involved in the test. You must first
execute these CLI command on the AP, in order to avoid a timeout at the time of a
Telnet/SSH/console session to the AP(s) in question when your client test(s):

exec-timeout 0

AP-COS Show Commands

Before you begin the test, you must first collect a sample of these show commands on the AP.
You should collect the output of these show commands at least twice for each test which involves
the wireless client in question; both before and after the test is complete.

term len 0

show clock show tech

show client statistics <client_MAC-address>

show cont nss status

show cont nss stats

show log

1800 series | AP-COS Debug Commands

These debugs are specific to the 18xx series of access points. This is due to the fact that the
chipset(s) used for the 1800 series of APs differ from those found in the 2800/3800 series access
points, and thus a different set of debugs are required in this scenario by comparison. The
corresponding debugs for the 2800/3800 series APs is covered in the next section.

Once you have collected the initial output of the aforementioned show commands, you must now
enable the debugs on the same 1800 access point(s) in a separate Telnet/SSH session as shown.
Ensure to save the entire output to a text file.
debug dot11 client level events addr <client_MAC-address>

debug dot11 client level errors addr <client_MAC-address>

debug dot11 client level critical addr <client_MAC-address>

debug dot11 client level info addr <client_MAC-address>

debug dot11 client datapath eapol addr <client_MAC-address>

debug dot11 client datapath dhcp addr <client_MAC-address>

debug dot11 client datapath arp addr <client_MAC-address>

In some cases, you might need to also enable the additional debugs on the 18xx AP to further
troubleshoot client interoperability issues. However, this should be done only if/as requested by a
Cisco TAC engineer for a corresponding service request/case.

As additional debugs might not only be far more verbose in their output but can also introduce
additional load on the AP as well hence it requires additional time for proper analysis. Which under
certain conditions can potentially disrupt service, if many client devices attempts to connect to the
same AP under test or similar variables.

To disable the debugs on the AP-COS variant access point - whether on an 1800 or 2800/3800
series AP - once the test and data collection process is completed, you can execute this CLI
command on the AP:

config ap client-trace stop

2800/3800 Series | AP-COS Debug Commands

Once you have collected the initial output of the aforementioned show commands, you must now
enable the debugs on the same 2800/3800 access point(s) in a separate Telnet/SSH session as
shown. Ensure to save the entire output to a text file.

config ap client-trace address add <client_MAC-address>

config ap client-trace filter all enable
config ap client-trace output console-log enable
config ap client-trace start
term mon
To disable the debugs on the 1800/2800/3800 series AP once the test and data collection process
is completed, you can execute this CLI command on the AP:

config ap client-trace stop

VIII. Client Side Packet Captures

From the client device in use if it is a notebook PC, MacBook or similar, you must collect the
promiscuous mode packet capture from the wireless interface of the client device used to
reproduce the issue. Common utilities like Netmon 3.4 (Windows only) or Wireshark can be readily
downloaded and used to collect this capture and save it to a *.pcap file. It depends on the device,
there might also be means to collect a tcpdump or similar from the client in question, so you might
need to consult with the client device manufacturer for assistance in this regard.
Here is an example to configure a Wireshark capture for the wireless interface on a MacBook Pro:

As with any packet capture, regardless of what utility is used to collect it, ensure to save the file in
a pcap file format (i.e. *.pcap, *.pcapng, *.pkt, etc.). This is to ensure that not only Cisco engineers
in any department can view the packet capture files with ease, but engineers from other vendors
and organizations as well (i.e. Intel, Apple, etc.). This allows for a more seamless cooperation and
collaboration process,which further facilitates both Cisco and the client device vendor(s) to better
work together to investigate and resolve any potential interoperability issues.

IX. Over-the-Air (OTA) Packet Captures

In order to effectively troubleshoot any potential or existing wireless interoperability issues, it is
crucial to collect a quality OTA packet capture of the issue. This allows for the detailed analysis of
the actual 802.11 wireless communication between the wireless client and access point radio(s) in
question, in addition to give further perspective to the client side and wireless infrastructure logs,
debugs, etc. This is a critical step that must be accomplished for every test of a potential wireless
interoperability issue, without exception.

However, often times the end customer is not properly equipped or prepared to collect OTA packet
captures. This is a common obstacle that wireless engineers often face, and they must work with
the customer to overcome this in a variety of ways. This article from the Cisco support forums can
serve as a good start point to help guide and educate the customer accordingly:

802.11 wireless sniffing / packet capture

It is of paramount importance that the OTA packet capture(s) be collected in a pcap file format (i.e.
*.pcap, *.pcapng, *.pkt, etc.), and includes 802.11 meta data (i.e. RSSI, channel, data rate, etc.).
The OTA sniffer should also be kept in close proximity to the client device in question at all times
during the test(s), to ensure an accurate perspective of the traffic sent and received to/from the
client device being tested.

Note: If the test(s) in question involve a client device roaming scenario, whereby more than
one 802.11 channel needs to be monitored in an aggregated packet capture. Then it is not
currently recommended to use AirMagnet WiFi Analyzer from Fluke Networks.
The reason for this is due to the fact that aggregated packet captures with the use of this utility are
currently saved in a proprietary file format, and not in a pcap style format that can be readily
viewed in Wireshark or other similar utilities. Ensure that your OTA packet capture is in a non-
proprietary file format, this helps ensure that all parties and vendors involved can readily review
any capture files at all times, and ultimately help expedite any resolution efforts.

in a format that is readable by current Wireshark, and that includes 802.11 meta data (RSSI,
channel, data rate) - See more at: https://supportforums.cisco.com/document/75331/80211-
wireless-sniffing-packet-capture#sthash.Xhlx5LSS.dpuf
Here are some common methods to collect an OTA packet capture:

● AirPCAP with Wireshark

● MacBook Pro
● OmniPeek Professional, OmniPeek Enterprise, etc.
● OmniPeek Remote Assistant (ORA)
● Cisco AP in Sniffer mode

802.11n Captures

For OTA packet captures which involves 802.11n wireless clients, there is at present more
flexibility and ease of use. This is due to a wider variety of available wireless USB WLAN adapters
that can be readily used with a number of tools, such as OmniPeek and others.

Do take note as to how the capabilities of the specific wireless adapter(s) used to collect an
802.11n OTA capture compare with the capabilities of the actual WLAN chipset used by the client
device(s) which you attempt to troubleshoot. For instance, if the client device experiences a
potential wireless interoperability issue which uses a 2 spatial stream (2SS) capable 802.11n
chipset. Then it is highly recommended to ensure that the wireless adapter used to collect an OTA
packet capture is also a 2SS or better adapter, with 802.11n or newer specifications.

802.11ac OTA Captures

For 3 spatial stream (3SS) 802.11ac captures, you can use the native sniffing capabilities of a
2014 model MacBook Pro or later running Mac OS X 10.10.x or higher. If troubleshooting a 2
spatial stream 802.11ac client device, you can also use a MacBook Air for 802.11ac captures. The
Air model of MacBooks use 2SS only WLAN chipsets currently at the time of this writing. You can
refer to the below Cisco support forums article for instructions on how to collect OTA packet
captures with the use of Mac OS X, through a variety of methods:

Wireless Sniffing with the use of Mac OS X 10.6+

You can also use either a 2702/2802/3702/3802 series or similar AP in sniffer mode to collect a
proper 802.11ac packet capture with 3SS. You can also refer to the below resource for a current
list of available 802.11ac wireless adapters. Some of which may be able to potentially be used
with common tools like OmniPeek and others to collect an 802.11ac packet capture (i.e. chipsets
from Ralink, Atheros, etc.):

https://wikidevi.com/wiki/List_of_802.11ac_Hardware#Wireless_adapters

You can also use either a 2702/2802/3702/3802 series or similar AP in sniffer mode to collect a
proper 802.11ac packet capture with 3SS. For convenience, step by step instructions on how to
configure a Cisco AP in sniffer mode and collect an OTA packet capture can be found in the below
Cisco support forums article:

Cisco AP in Sniffer mode

For troubleshooting roaming scenarios with a wireless client device, the common challenge is to
effectively collect an OTA packet capture across multiple channels. This method of simultaneously
monitoring multiple 802.11 channels is achieved by the collection of aggregated OTA packet
capture. It is recommended to use multiple, compatible 802.11ac capable USB WLAN adapters
with a compatible network analysis software in order to achieve this. Some common 802.11ac
capable USB WLAN adapters include the Savvius WiFI Adapter for OmniPeek (802.11ac),
Netgear A6210, or similar.

X. Summary
Here is a brief recap of the information that needs to be collected to effectively troubleshoot a
potential wireless client interoperability issue with a CUWN. This section is intended to serve as a
quick reference section, as needed.

I. Problem Definition

● Is the issue restricted to a specific model of access point(s) and/or radio type (2.4 GHz versus
5 GHz)?
● Is the issue observed only on specific version(s) of wireless LAN controller (WLC) software?
● Is the issue experienced with only specific version(s) of client type(s) and/or software (i.e. OS
version, WLAN driver version, etc.)
● Are there any other wireless devices which do not experience this issue? If so, what are they?
● Is the issue reproducible while the client is connected to an open SSID, a channel width of 20
MHz, and 802.11ac disabled? (i.e. Does the issue happen on 11n mode versus 11ac mode
only)
● If the issue is not reproducible with an open SSID, at what minimum security configuration is
the issue seen? (i.e. PSK or 802.1X on the WLAN)
● What was the previous working configuration and software versions?

II. WLC Configuration and Logs

Collect this from the CLI of the WLC(s) in question:

● config paging disable

● show run-config
Alternatively, you can also collect just these output as needed:

●config paging disable

●show run-config no-ap
●show wlan apgroups
Backup of the WLC configuration via TFTP, FTP, etc. (GUI: Commands > Upload File >
Configuration)

Syslogs from the WLC

III. Client Device Information

● Client type (i.e. tablet, smartphone, notebook PC, etc.)

● Device make and model
● OS version
● WLAN adapter model
● WLAN adapter driver version
● Supplicant used (i.e. Windows Zero Config / Auto Config, Intel PROSet, etc.)
● Security configured for use by the wireless client and WLAN (i.e. Open, PSK, EAP-
PEAP/MSCHAPv2, etc.)

Note: Any client parameters changed from default settings provided by the vendor in
question. (i.e. sleep state, roaming parameters, U-APSD, etc.)

IV. Network Topology Diagram

This should include a representation and/or details with regards to the wireless devices in the
network (i.e. printers/scanners, WLCs, etc.)

V. Create a Spreadsheet To Record All Client Issues

Example:

Description Time end

WiFi Signal status Record ipconfi
MAC of user Ping default
Username (Connected/trying to /all (or
Address Reported observed gateway Y/N
Connect) equivalent)
Symptom symptom

The goal of this exercise is to help identify a common pattern, and to showcase a more accurate
picture of the issue(s) at hand.

VI. Show and Debug Commands on the WLC

Collect these WLC debugs via the CLI:

●config sessions timeout 0

●debug client <MAC_address>
●debug dhcp message enable
Add the additional debugs on case by case basis:

● debug aaa detail enable - use this if there are authentication related issues with AAA server
● debug aaa events enable - use this if there are authentication related issues with AAA server
● debug aaa all enable - use this for auth issues; this is verbose so use it only when needed
(i.e. for AAA override cases etc)
● debug mobility handoff - use when roaming issues between WLCs
Collect the output for the WLC show commands via the CLI:

● config paging disable

 ●show time
●show client detail <mac-address of client> (note the client state on the WLC)
●Ping the client from the WLC
Once the test is complete, use this command to stop all current debugs on the WLC:

● debug disable-all

VII. Show and Debug Commands on the AP

Lightweight Cisco IOS APs

This section details the debugs required for the 1700/2700/3700 series or prior model access
points.

To avoid an AP session timeout at the time of a Telnet/SSH/console session, use these

commands:

● debug capwap console cli

● config t
● line console 0 -- use to modify serial session timeout parameters
● line vty 0 4 -- use to modify Telnet/SSH session timeout parameters
● exec-timeout 0
● session-timeout 0
● term len 0
Before you start the test, collect a sample of these show commands on the AP. At a minimum
collect two samples of this output, both before and after completion of tests with the use of these
AP show commands via the CLI:

● term len 0
● show clock
● show tech
● show capwap client mn
● show int do1 dfs
● show logging
● more event.log
● show trace dot11_rst display time format local
● show trace dot11_rst
● show trace dot11_bcn display time format local
● show trace dot11_bcn
Collect these AP debugs via the CLI:

●debug dot11 { d0 | d1 } monitor addr <MAC_address>

●debug dot11 { d0 | d1 } trace print clients mgmt keys rxev txev rcv xmt txfail ba
●term mon
Once the test is complete, use this command to disable the debugs:

● u all
AP-COS APs

This section details the debugs required for the 1800/2800/3800 series APs.

To avoid an AP session timeout at the time of a Telnet/SSH/console session, use these

commands:

● exec-timeout 0
Before you start the test, collect a sample of the below show commands on the AP. At a minimum
collect two samples of this output, both before and after completion of tests with the use of these
AP show commands via the CLI:

● term len 0
● show clock
● show tech
● show client statistics <client_MAC-address>
● show cont nss status
● show cont nss stats
● show log
For the 1800 series access points, collect these AP debugs via the CLI:

● debug dot11 client level events addr <client_MAC-address>

● debug dot11 client level errors addr <client_MAC-address>
● debug dot11 client level critical addr <client_MAC-address>
● debug dot11 client level info addr <client_MAC-address>
● debug dot11 client datapath eapol addr <client_MAC-address>
● debug dot11 client datapath dhcp addr <client_MAC-address>
● debug dot11 client datapath arp addr <client_MAC-address>
● term mon
For the 2800/3800 series access points, collect these AP debugs via the CLI:

●config ap client-trace address add <client_MAC-address>

●config ap client-trace filter all enable
●config ap client-trace output console-log enable
●config ap client-trace start
●term mon
Once the test is complete, use this command to disable the debugs:

● config ap client-trace stop

VIII. Client Side Captures

Collect either a promiscuous Netmon 3.4 (Windows XP or 7 only) or Wireshark packet capture
from the client device's WLAN adapter.

IX. OTA Captures

802.11n Captures
 ● AirPCAP with Wireshark
● MacBook Pro
● OmniPeek Professional, Enterprise, etc.
● OmniPeek Remote Assistant (ORA)
● Cisco AP in Sniffer mode

802.11ac Captures

● For 11ac 3SS captures, you can use a 2014 Macbook Pro or later running 10.10.x or higher
(don’t use MacBook Air for 11ac captures if possible, as it is a 2SS only device currently).
● You can also use either a 2702, 3702 or similar Cisco AP in sniffer mode.
● For roaming scenarios and with the use of professional network analysis software such as
OmniPeek from Savvius. It is recommended to use multiple, compatible 802.11ac capable
USB WLAN adapters, such as the Savvius WiFI Adapter for OmniPeek (802.11ac), Netgear
A6210, or similar.

XI. Appendix A - Additional Tips and Tricks

Windows

To collect some additional information with regards to the current wireless connection and other
related details directly from a Windows PC. You can make use of these netsh wlan related
commands in the Windows command line (CMD):
C:\Users\engineer>netsh wlan show ?
These commands are available:
Commands in this context:
show all - Shows complete wireless device and networks information.
show allowexplicitcreds - Shows the allow shared user credentials settings.
show autoconfig - Shows whether the auto configuration logic is enabled or
disabled.
show blockednetworks - Shows the blocked network display settings.
show createalluserprofile - Shows whether everyone is allowed to create all
user profiles.
show drivers - Shows properties of the wireless LAN drivers on the system.
show filters - Shows the allowed and blocked network list.
show hostednetwork - Show hosted network properties and status.
show interfaces - Shows a list of the wireless LAN interfaces on
the system.
show networks - Shows a list of networks visible on the system.
show onlyUseGPProfilesforAllowedNetworks - Shows the only use GP profiles on GP
configured networks setting.
show profiles - Shows a list of profiles configured on the system.
show settings - Shows the global settings of wireless LAN.
show tracing - Shows whether wireless LAN tracing is enabled or disabled.

C:\Users\engineer>netsh wlan show interfaces

There are 3 interfaces on the system:

Name : Wireless Network Connection 8

Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter #5
GUID : 6beec9b0-9929-4bb4-aef8-0809ce01843e
Physical address : c8:d7:19:34:d5:85
 State : disconnected

Name : Wireless Network Connection 4

Description : WildPackets Conceptronic Nano Wireless 150Mbps USB
Adapter
GUID : 23aa09d4-c828-4184-965f-4e30f27ba359
Physical address : 48:f8:b3:b7:02:6e
State : disconnected

Name : Wireless Network Connection

Description : Intel(R) Centrino(R) Advanced-N 6200 AGN
GUID : 8fa038f8-74e0-4167-98f9-de0943f0096c
Physical address : 58:94:6b:3e:a1:d0
State : connected
SSID : snowstorm
BSSID : 00:3a:9a:e6:28:af
Network type : Infrastructure
Radio type : 802.11n
Authentication : WPA2-Enterprise
Cipher : CCMP
Connection mode : Profile
Channel : 157
Receive rate (Mbps) : 300
Transmit rate (Mbps) : 300
Signal : 80%
Profile : snowstorm

Hosted network status : Not started

C:\Users\engineer>netsh wlan show networks bssid | more

Interface name : Wireless Network Connection

There are 21 networks currently visible.

SSID 1 : snowstorm
Network type : Infrastructure
Authentication : WPA2-Enterprise
Encryption : CCMP
BSSID 1 : 00:3a:9a:e6:28:af
Signal : 99%
Radio type : 802.11n
Channel : 157
Basic rates (Mbps) : 24 39 156
Other rates (Mbps) : 18 19.5 36 48 54
BSSID 2 : 00:3a:9a:e6:28:a0
Signal : 91%
Radio type : 802.11n
Channel : 6
Basic rates (Mbps) : 1 2
Other rates (Mbps) : 5.5 6 9 11 12 18 24 36 48 54

-- More --

macOS (formerly OS X)

In order to collect the equivalent output as the ipconfig /all command on a Windows PC, you can
instead use the common Linux/Unix command of ifconfig to list detailed information for all of the
network interfaces on an Apple MacBook. As needed, you can also specify to receive the output
for just the native wireless interface for a given MacBook (either en0 or en1, it depends on the
model). Such as this example:
bash-3.2$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 14:10:9f:de:df:f3
inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4
inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255
nd6 options=1<PERFORMNUD>
media: autoselect
status: active

In order to get some quick but detailed information with regards to the current wireless connection
on a MacBook. You can also select the WiFi icon in the top right corner of the desktop while you
simultaneously hold the option button on your keyboard as shown in the image.

Another useful option is to utilize the hidden command line utility called airport. It is highly
recommended to only utilize this with your own MacBook or one in use in a lab environment. As
some network administrators might not wish to grant access to this utility on an end user's
MacBook, so use the appropriate level of caution accordingly. To proceed, enter this in Terminal
on the MacBook in question:
bash-3.2$ ifconfig en0
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 14:10:9f:de:df:f3
inet6 fe80::1610:9fff:fede:dff3%en0 prefixlen 64 scopeid 0x4
inet 10.150.128.40 netmask 0xffffe000 broadcast 10.150.159.255
nd6 options=1<PERFORMNUD>
media: autoselect
status: active

Now you can call upon the airport CLI utility with ease. An example of which includes this:

bash-3.2$ airport -I
agrCtlRSSI: -61
agrExtRSSI: 0
agrCtlNoise: -90
agrExtNoise: 0
state: running
op mode: station
lastTxRate: 216
maxRate: 300
lastAssocStatus: 0
802.11 auth: open
link auth: wpa2
BSSID: 0:3a:9a:e6:28:af
SSID: snowstorm
MCS: 13
channel: 157,1

To further ease the process to collect a reliable, single 802.11 channel OTA packet capture with
the use of the capabilities of a MacBook Pro or similar. You can either leverage the embeded
capabilities in macOS with the use of the Wireless Diagnostics > Sniffer method or similar as
discussed previously, but optionally you can use a third-party utility called Airtool as well (OS X
10.8 and later). The benefit is a simple interface to quickly collect an OTA packet capture, which
gets saved directly to the desktop with just a few clicks through the app UI right from the top menu
bar on your screen.
Further information and download links for Airtool can be found at this URL:

https://www.adriangranados.com/apps/airtool