What are RadioTap Headers?

-
I've been doing some study for my CWAP (wireless analysis) exam recently, so I've been spending quite some time staring at Wirehsark traces trying to figure out precisely what all of those 802.11 fields actually mean.

One thing I noticed whilst pouring over a few capture files is that some of them seemed to have some additional fields included in the trace, which seem to have nothing to do with fields defined in 802.11 frames at all. They are in a section of the packet decode called 'RadioTap Headers'. I wasn't too sure what they were and why they are available in some captures, whilst in others they were missing.

After a little bit of research, I found out a bit more information and thought it might be worth sharing in a quick blog post.

In summary, radiotap headers provide additional information that is added to each 802.11 frame when capturing frames with an analysis application. Just to be clear, these are not part of the standard 802.11 frame format, but are additional information added at the time of capture to provide supplementary data about the frames captured. For instance, in a standard 802.11 traffic capture, there is no information regarding the receive signal level for the frame at the time of capture, which could be very useful. As another example, there is no information about which channel is being used by a station that has generated the frame, which again could be very useful.

Radiotap headers provide additional information to supplement the raw frame capture data that can be derived by analyzing the 802.11 frames.

The next logical question is: "how to I get radiotap headers in my captures?". The headers are added by the wireless adapter (or its driver) that is being used to perform the frame capture. If the adapter does not inject the additional information as it captures frames, then no radiotap headers will be added. 

I guess the best way to verify this is simply to perform a capture and see if they appear in your capture using Wireshark. In my own particular case, I was performing a capture with an AirPcap NX card, which provides radiotap information. However, I also performed captures with the internal WLAN NIC of my laptop, which does not provide radiotap data.

Here are a couple of examples so that you can see the difference between captures with and without radiotap headers:

Fig 1 - Beacon frame, no radiotap data

The capture above shows a standard capture of a beacon frame with no radio tap headers (taken with my laptop WLAN NIC card). Next, we see a beacon frame again, but this time with radiotap information included (taken with the AirPcap card):

Fig 2 - Beacon frame, with radiotap data


You can see the additional radiotap section in the frame decode highlighted with a red circle above.

Next, we'll snap open the radio tap headers and take a look at the information available:

Fig 3 - Radiotap headers detail


Right away, you can see fields which give us great supplementary information about the RF environment that the capture was taken in. Looking at the trace above, we can see that this frame was captured on channel 6 on the 2.4GHz band and that it was received by the wireless NIC capturing the frame at a level of -44dBm.

You can see that there are also additional snap-open sections to view even more information (i.e. Present flags, Flags and Channel type), so we'll take a brief look at each of those too.

Present Flags


Fig 4 - Radiotap 'Present Flags' section

The 'Present flags' section is a matrix of the information that is available in subsequent sections of the radiotap headers. The flags will vary depending on the information that can be provided by the NIC card that is performing the capture. (To see a comprehensive list of all possible fields and their meaning, take a look at the following page: http://www.radiotap.org/fields/defined )

For each field that is marked as 'true', there will be information for that section appearing in the radiotap headers that follow the 'Present Flags' matrix. For instance, in the matrix shown above we see that the flags for 'Channel' and 'dBm Antenna Signal' are true. We've already seen in a previous screen-shot that these field are included in the headers shown in the frame decode.

Flags

Fig 5 - Radiotap 'Flags' section


The flags section provides us even more information about the captured frame itself, giving details about preamble type, whether a short guard interval was used and whether the frame has a valid frame checksum.

Channel Type

Fig 6 - Radiotap 'Channel Type' section

In the 'Channel Type' section, we gain even more information about characteristics of the channel itself, such as which band is in use, the modulation type used and channel width information.

More Information

The examples shown here represent a subset of the fields that may be included in radiotap headers. To view all possible fields, and to understand their meaning, take a look at the following page: http://www.radiotap.org/fields/defined

To find out more about radiotap headers, take a look at http://www.radiotap.org which has comprehensive information on all apsects of radiotap headers.

Popular posts from this blog

The 5GHz “Problem” For Wi-Fi Networks: DFS

-
Image
Wi-Fi networking provides us with 2 bands for the operation of wireless LAN networks: the 2.4Ghz band and the 5GHz band. The 2.4GHz band has a reputation of being something of a “sewer” of a band, due to its limited number of usable channels, the number of Wi-Fi devices already using the band, and the high levels of non-Wi-Fi interference that it experiences. Many wireless LAN professionals will generally advise that you put your “important stuff” on the 5GHz band whenever possible. 5GHz has far more channels available, a corresponding lower number of devices per channel, and generally suffers much lower non-Wi-Fi interference. However, beneath the headline of “2.4Ghz = bad, 5Ghz = good”, there lurks a shadowy figure that can be troublesome if you’re not aware of its potential impact: DFS. Background Wi-Fi networks operate in areas of RF spectrum that require no licence to operate. This is in contrast to many other areas of the radio spectrum that generally require some form of (p
Read more

What Are Sticky Clients?

-
Image
One term you'll often hear banded about when talking with Wi-Fi professionals is "sticky clients". I thought it might be worth spending a few moments exploring what is meant by "sticky clients", why they are generally considered to be a bad thing in Wi-Fi networks and some approaches to mitigate them. Background Many folks dealing with Wi-Fi networks often talk about the "sticky" characteristics of wireless clients when discussing client roaming within a W-iFi network. In an ideal world, we'd like to have access points providing ubiquitous coverage across our desired area providing high-quality, consistent client coverage where-ever we go. In this wonderful land of rainbows and unicorns, our clients would gracefully roam from AP to AP, detecting and associating with their closest AP throughout the coverage area to ensure their best connection speed at all times. Unfortunately, the real world doesn’t quite reflect this roaming-client
Read more

Microsoft NPS as a RADIUS Server for WiFi Networks: SSID Filtering

-
Image
The Microsoft Network Policy Server (NPS) is often used as a  RADIUS server for WiFi networks. It can provide authentication and authorization services for devices and users on a wireless network in a Windows Active Directory environment. In this article we look at how we can use NPS to provide authentication for WiFi users across a number of SSIDs. We have previously discussed how to authenticate groups of users using the same SSID and then assign them to a VLAN that is appropriate to their security authorization. However, there may still be instances where two or more SSIDs are in-use on a wireless network and we would like to base policy decisions on the SSID that the authentication request is being generated from. As an example, if we consider a school, perhaps we would like students to only be able to authenticate if they connected to the SSID: "Student_Net". Similarly,  staff should only be able to connect using the SSID: "Staff_Net". This would
Read more