TamoSoft: Network Analysis Tools & Security Software
Contents

WLAN Analyzer and Protocol Decoder - CommView for WiFi

 
Introduction
About CommView for WiFi
What's New
Using the Program
Driver Installation
Overview
Scanner
Nodes
Channels
Latest IP Connections
Packets
Logging
Viewing Logs
Rules
Advanced Rules
Alarms
WEP/WPA Keys
Reconstructing TCP Sessions
Reconstructing UDP Streams
Statistics and Reports
Using Aliases
Packet Generator
Visual Packet Builder
NIC Vendor Identifier
Scheduler
Node Reassociation
Using Remote Agent for WiFi
Setting Options
Frequently Asked Questions
VoIP Analysis
Introduction
Working with VoIP Analyzer
SIP and H.323 Sessions
RTP Streams
Registrations
Endpoints
Errors
Call Logging
Reports
Call Playback
Viewing VoIP Logs
Working with Lists in VoIP Analyzer
NVF Files
Advanced Topics
Understanding CRC and ICV Errors
Understanding WPA Decryption
Understanding Signal Strength
Monitoring 802.11n Networks
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
Information
How to Purchase CommView for WiFi
Contacting Us
Other Products
Monitoring 802.11n Networks


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

MIMO and Transmit Beamforming

The use of the MIMO and Transmit Beamforming technology in 802.11n networks is a serious challenge for wireless analyzers. 802.11n 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 300 Mbps) 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 networks vs. the older 802.11a/b/g ones. While this is not a problem when you're 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-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, as a 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.  

Channel Bonding

In 802.11n WLANs, the data rate is increased by bonding two 20 MHz channels (40 MHz operation). The 40 MHz operation uses wider bands, compared to 20 MHz bands in 802.11a/b/g, to support higher data rates. While a WiFi network analyzer equipped with an 802.11n card doesn't have a problem with capturing two channels simultaneously, it's 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 "Secondary channel is below the primary channel in 802.11n 40 MHz mode" box in the CommView for WiFi options dialog. 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.