802.11 Sniffer Capture Analysis - Physical Layer
Intro: physical layer info in wireless packet captures
A captured packet contains a copy of the frame data – but prepended to each frame is a metadata header, giving you information about how the frame was captured. With wired packets, the metadata isn’t much – the frame number, date when the packet was captured, the packet’s length. When doing wired packet analysis, you rarely care too much about the physical layer – with a bit error rate of 1010, you usually assume that the captured bits are what they say they are.
Wireless is another story entirely – the physical layer is vastly more complex – and treacherous – than wired. Before diving into an attempt to analyze a capture based upon the upper layers, it is usually a good idea to get an understanding of the physical layer in which the capture was taken. If the physical layer isn’t working right – then the upper layers will never have a chance.
The following physical layer qualities are particularly important to be aware of:
· Signal strength (RSSI, “signal strength”, Signal/Noise Ratio.) It’s generally best to focus on RSSI, if available – i.e. the power level in dBm at which the sniffing adapter received the packet.
o RSSI < -90 dBm: this signal is extremely weak, at the edge of what a receiver can receive
o RSSI -67dBm: this is a fairly strong signal – the edge of what Cisco considers to be adequate to support Voice over WLAN.
o RSSI > -55dBm: this is a very strong signal
o RSSI > -30dBm: your sniffer is sitting right next to the transmitter
· Channel (frequency.) As a wireless LAN may support anywhere from 3 to 25 or so different channels, it’s crucial to know exactly which channel(s) your capture was taken from. If your intention is to get a sniff from a specific AP, then lock your sniff to that AP’s channel, and validate that the capture was on that channel – otherwise, the capture will be worthless.
· Data rate – this can be anywhere from 1Mbps up to 300Mbps or more. To understand why data transmissions don’t always make it from transmitter to receiver, you must know what data rates are being used. A “marginal” RSSI of -80dBm may work horribly for a packet modulated at 54Mbps, but can be quite satisfactory at 6Mbps.
Wireless packet headers – examples
Different wireless sniffers may use different metadata header formats to encode the wireless physical layer. Do be aware that the accuracy of the information is dependent upon the specific adapter hardware and driver in use. Some values, such as noise, should generally be taken with a grain of salt.
Below are some samples, with the data rate, frequency and RSSI fields highlighted.
Mac OS X 10.7 Wireless Diagnostics (Broadcom adapter?)
OS X 10.7 uses a Radiotap v0 header, which looks like this in Wireshark:
OmniPeek 6.8 (Ralink USB adapter)
In Wireshark, an OmniPeek capture uses an Airopeek header, which looks like this:
Note that Wireshark (as of 1.6.x) doesn’t know how to decode all the wireless metadata in an OmniPeek capture – the same frame viewed in OmniPeek itself shows Signal dBm, Noise Level and Noise dBm:
Applying wireless files as Wireshark columns
It is very often much easier to understand what’s going on with a wireless sniff, if you have applied the wireless fields as columns. Here’s how to do this:1. Locate the field of interest in the packet details section (first expanding the applicable header section if necessary) and right-click it. Select Apply as Column:
2. 2. The new column appears. Now you can resize, rename (by right clicking the column header and selecting “Edit Column Details”), and move the column as desired.
3. 3. Repeat for other columns of interest. Now you have a better handle on the physical layer aspects of your capture:
4. 4. Once you’ve applied the new column, the next time you run Wireshark, the column will be available (if you don’t see it, right-click the column headers and select Displayed Columns.)