WLAN Analyzer and Decoder - CommView for WiFi

Prev Page Next Page
About CommView for WiFi
What's New
Using the Program
Driver Installation
Main Menu
AP and Station Details Window
Latest IP Connections
Viewing Logs
Advanced Rules
Reconstructing TCP Sessions
Reconstructing UDP Streams
Searching Packets
Statistics and Reports
Using Aliases
Packet Generator
Visual Packet Builder
NIC Vendor Identifier
Node Reassociation
Using Remote Agent for WiFi
Using Aruba Remote Capture
Port Reference
Setting Options
Frequently Asked Questions
VoIP Analysis
Working with VoIP Analyzer
SIP and H.323 Sessions
RTP Streams
Registrations, Endpoints, and Errors
Call Logging and Reports
Call Playback
Viewing VoIP Logs
Working with Lists in VoIP Analyzer
NVF Files
Advanced Topics
Monitoring 802.11n and 802.11ac Networks
Understanding CRC and ICV Errors
Understanding WPA Decryption
Understanding Signal Strength
Capturing A-MPDU and A-MSDU Packets
Using CommView for WiFi in a Virtual Machine
Multi-Channel Capturing
Spectrum Analysis
Capturing High Volume Traffic
Running CommView for WiFi in Invisible Mode
Command Line Parameters
Exchanging Data with Your Application
Custom Decoding
CommView Log Files Format
How to Purchase CommView for WiFi

Monitoring 802.11n and 802.11ac Networks

Despite the similarities between the 802.11 a/b/g and 802.11n/ac technologies, there are some peculiarities in 802.11n/ac networks that influence the way such networks should be efficiently monitored. Without going into the specific technical details of the standard, as they are publically available from many sources on the Internet, this chapter overviews the best monitoring practices and hardware requirements for 802.11n and 802.11ac networks.

Adapter Compatibility

Capturing 802.11n packets requires an 802.11n or 802.11ac adapter. Capturing 802.11ac packets requires an 802.11ac adapter. You cannot capture 802.11n packets using an 802.11 a/b/g adapter and you cannot capture 802.11ac packets using an 802.11 a/b/g or 802.11n adapter. The list of compatible 802.11n and 802.11ac adapters can be found on the CommView for WiFi download page on our web site. Depending on the configuration of the 802.11n or 802.11ac WLAN being monitored, additional requirements to the adapter might apply. They are discussed in detail below.

MIMO, Spatial Streams, and Transmit Beamforming

The use of the MIMO and Transmit Beamforming technology in 802.11n and 802.11ac networks is a serious challenge for wireless analyzers. 802.11n and 802.11ac networks create a very complex, adaptive signal intensity map with dips and bumps, some as small as a few centimeters in volume. Because a monitoring device is passive, the WLAN being monitored does not attempt to adapt to it. Signals travelling at high rates (currently up to 867 Mbps) and transmitted by multiple antennas are also hard to intercept without CRC errors. All of the above means that, generally, you should expect a considerably higher percentage of broken frames when monitoring 802.11n and 802.11ac networks versus the older 802.11 a/b/g ones. While this is not a problem when you are performing a site survey or measuring signal strength of particular devices, examining individual TCP streams or troubleshooting problems on the per-packet level may become problematic when too many frames are damaged.

To mitigate these 802.11n/ac-specific factors, consider applying the following techniques:

· Find the best position for the notebook running CommView for WiFi. Rotating it or moving it just a few inches in a different direction may dramatically increase or decrease the signal quality. In fact, even the position of your body or a raised arm may affect the percentage of CRC errors.
· Try to make sure that that the WLAN devices do not operate at their maximum rates. Successful capturing of packets with rates of 100 Mbps and below is far more likely than successful capturing of packets with higher data rates. Although this sounds counter-intuitive, if your monitoring notebook is located next to the AP, moving the client devices a few meters further from the AP will increase rather than decrease the reception quality. An 802.11n client device located one or two meters from the AP will almost inevitably transmit packets at the rate of 300 or 270 Mbps, whereas the same device located five meters from the AP will drop the rate down to 130 or 108 Mbps, which is beneficial for our purposes.

It is important to remember that the capabilities of your monitoring adapter in terms of the number of supported spatial streams must exceed or be equal to the capabilities of the WLAN being monitored. In other words, you cannot capture packets being sent from a three-stream AP to a three-stream client using an adapter that supports only one or two spatial streams (but you can capture packets being sent, for example, from a two-stream AP to a two-stream client using a three-stream adapter). It is easy to figure out the number of supported spatial streams by looking at the adapter specifications. For 802.11n, the maximum supported rate of 150 Mbps means a one-stream adapter, 300 Mbps means a two-stream adapter, and 450 Mbps means a three-stream adapter. For 802.11ac, the maximum supported rate of 433 Mbps means a one-stream adapter, 876 Mbps means a two-stream adapter, and 1,300 Mbps means a three-stream adapter.

Channel Bonding in the 2.4 GHz Band

In 802.11n WLANs, the data rate is optionally increased by bonding two 20 MHz channels (40 MHz operation). The 40 MHz operation uses wider bands, compared to 20 MHz bands in 802.11 a/b/g, to support higher data rates. While a WiFi network analyzer equipped with an 802.11n card does not have a problem with capturing two channels simultaneously, it is important to pay attention to the regulatory domains of the hardware being used. In brief, the frequency of the secondary channel in 40 MHz mode depends on the frequency of the primary channel. For example, selecting channel #1 in your hardware means that the primary 20 MHz channel will operate at the frequency of channel #1, while the secondary 20 MHz channel will operate four channels above the primary one, i.e. at the frequency of channel #5. When operating at higher channel numbers, e.g. 10 or 11, adding four to the channel number would mean that the frequency of the secondary channel would go outside of the regulatory domain constraints: in the US, the top channel in the 2.4 GHz band is 11; in most European countries, the top channel is 13. In such cases, the secondary channel uses the frequency that is below the frequency of the primary channel. For example, selecting channel #10 in your hardware means that the primary 20 MHz channel will operate at the frequency of channel #10, while the secondary 20 MHz channel will operate four channels below the primary one, i.e. at the frequency of channel #6.

The potential problem that a field engineer may encounter when working internationally is that the regulatory domain of his monitoring network adapter may be different from the regulatory domain of the WiFi network being monitored. For example, a Germany-based 802.11n WLAN working on channel #9 would bond channels #9 and #13. A monitoring adapter bought in Canada would expect the secondary channel to be #5. This will prevent the adapter from "seeing" the 40 MHz data streams in the wireless analyzer. To handle this situation, consider using hardware that belongs to the same regulatory domain or use the Sec. channel below in 40 MHz mode box on the Capture pane of the main window. Checking this box will force the adapter to use the secondary channel frequency that is below the primary channel frequency even if the regulatory domain of the network adapter does not require that.

Note that some of the adapters supported by CommView for WiFi, such as Intel-based or Broadcom-based adapters, do not support channel bonding and can capture packets on 20 MHz channels only. Please refer to the Technical Notes for the detailed information. We suggest that you choose one of the adapters marked as "Recommended" on the download page; such adapters support channel bonding.

Channel Bonding in the 5 GHz Band

In the 5 GHz band, channel bonding is similar to channel bonding in the 2.4 GHz band, but the number of bonded channels may reach eight in 802.11ac WLANs, which means that channel width may reach 160 MHz. Unlike the 2.4 GHz band, the sets of available bonded channels for the 5 GHz band is strictly defined in the standard. For example, for 40 MHz wide channels, channel 52 is always bonded with channel 56; it cannot be bonded with channel 48. For this reason, the Sec. channel below in 40 MHz mode box has no effect when you are capturing channels in the 5 GHz band with a recommended 802.11ac adapter; it automatically selects the correct set of channels. For example if you select channel 36, the adapter will capture on a 80 MHz wide channel (from 36 to 48). However, in this example, the packets sent using a 20 MHz wide channel would be visible only if they are sent on channel 36. In other words, if you are monitoring an 802.11ac access point that is configured to use channels 36-48 and the AP’s primary channel is 36, you will see both the AP’s beacons and 80 MHz data packets if you are capturing on channel 36, but you will see only 80 MHz data packets (and no beacons) if you are capturing on channel 40, 44, or 48.

BCC and LDPC Coding

On the hardware level, 802.11n packets are encoded using either Binary Convolutional Code (BCC) coding or Low Density Parity Check (LDPC) coding. BCC is the default coding method used by the majority of 802.11n devices. LDPC is an optional coding method supported by some of the 802.11n devices.  When a client associates to an AP, the HT Capabilities Info element in the association request and association response packets determine the use of one of the two coding methods. For example, if the default BCC mode is being used, the HT Capabilities Info contains the "HT LDPC coding capability: Transmitter does not support receiving LDPC coded packets" field. If the WLAN being monitored uses LDPC coding, your monitoring adapter must support LDPC coding too; otherwise, packets sent at HT rates in one or both directions will be missing or damaged. Capturing LDPC-encoded packets is supported by the latest Atheros-based mPCIe 802.11n adapters, such as AR93xx, AR94xx, and AR95xx, as well as by all the recommended 802.11ac adapters.