Saturday, 30 November 2013

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: )

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.


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:

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

Sunday, 10 November 2013

Antenna Radiation Patterns in the Real World

I was recently reading through the most recent edition the finest WiFi text book in the world (in my opinion): the CWNA study guide. I read the previous versions a couple of times when I took my original CWNA exam and subsequent renewals.

Looking through the latest book, I've picked up a a few nuggets which I either missed, or weren't included in the previous versions that I read. I had one "light bulb" moment when reading about antenna radiation patterns. 

If you've ever looked at datasheets for antennas or access points, you may well have come across diagrams (like those shown below) that show the radiation pattern of an antenna.

Fig1 - Antenna Azimuth Chart

Fig2 - Antenna Elevation Chart

There are generally two types of radiation pattern shown for each antenna:
  • Azimuth (i.e. the RF radiation pattern when viewed from above the antenna)
  • Elevation (i.e. a side-on view of the antenna RF radiation pattern)
These are useful to understand the characteristics of the antenna, showing how directional the antenna may be, together with the presence of side-lobes, back-lobes etc. They provide a guide to how useful a particular antenna may be for a particular RF coverage requirement.

If you look at the examples shown above (which show a semi-directional patch antenna), you can see that the radiation tends to be mainly on one side of the antenna, giving it directional characteristics.

You may also note that in the charts shown, a number of concentric circles originate from the center of the chart, showing a number of dB (decibel) levels. These show the loss or gain provided by the antenna for a 360 degree sweep around the antenna. The intervals will vary from chart to chart. Typical intervals are 10dB, 5dB and 3dB - but be sure to understand the interval used.

Antennas provide varying levels of gain (a positive dB value) or loss (a negative dB value) as measurements are taken around the antenna. The physical characteristics of the antenna will determine what levels of gain or loss may be found around the antenna (and hence how directional it may be).

It is worth noting that if the outer power level of a radiation chart shows a value of '0dB', then the chart has been 'normalized'. This means that the actual gain of the antenna itself has been removed from the readings shown. This allows a more granular view of all levels on the chart. But, it needs to be factored back in when performing any calculations that use the chart for reference. 

The key point to note here is that the charts show the level of gain or loss provided by an antenna in Decibels (dB). Decibels are essentially a logarithmic measurement of the gain or loss that the antenna provides. Without getting too deeply in to the mathematics of  dB measurements (I'll leave you to read the CWNA study guide for that), the radiation patterns show gain or loss from a logarithmic point of view, rather than a (real-world) linear perspective.

As an example of this, a common rule of thumb when considering RF coverage is that an increase of 6dB in gain will actually double the distance that an RF signal will cover. Each 3dB increase in gain equates to a doubling of signal level. Therefore, an increase of 6dB (two x 3dB increases) actually quadruples the signal level. But, as previously stated, this 6dB gain leads to a doubling of the distance covered (for a 4 x signal level increase). There is evidently not a linear relationship between power levels expressed in dB and the power levels experienced in the real world.

Apologies if this seems a little over-complicated, but the point is that the radiation patterns shown in antenna data-sheets do not represent the actual radiation pattern you will see in the real world. 

Logarithmic scales are used for antenna radiation charts as they provide an opportunity to cram quite a bit of information on to a chart. Granular information can be maintained for a greater range of power levels by using a logarithmic dB scale - this would not be the case if linear scales were used. But, the scales do not represent what you will see in the real 'linear' world. If you interpret them as a literal representation of the coverage performance of an antenna, you might be a little disappointed.

I found this to be a fascinating point that I had not really considered or understood before. 

I set out to find a way to visualize what radiation patterns might look like in the real world.

This would require a bit of manipulation of the equation for 'Free Space Path Loss' (FSPL), which is no mean feat for someone as mathematically challenged as myself:

Fig3 - Free Space Path Loss Calculation 

The FSPL equation is used to show how signal levels will reduce as they travel through space away from a transmitter. It uses the variables of frequency and distance to show the loss applied to a signal as it travels through space. 

Using the FSPL formula we should be able to calculate the actual distance at which a particular signal level occurs. For instance, if am able to supply the variables for a signal frequency (i.e. 2.4GHz or 5GHz) and the gain of the antenna, I should be able to calculate the distance at which a signal level occurs for a  particular transmit power applied to an antenna. 

In simpler terms, if I know that I am applying a 1mw (0dBm) signal to an antenna, I am operating at 2.4GHz and I want to know where the -65dBm boundary of my signal falls (in terms of distance), I should be able to calculate it using the FSPL equation.

Whilst scratching around in Excel, I found a type of chart I had never seen before: a 'Radar' chart, which is very similar to the polar charts used for antenna radiation patterns.

After much head-scratching and experimentation, I came up with a formula that would calculate the projected distance from an antenna for a particular signal level, taking account of the signal frequency and the antenna gain. I then took a sample of points from an antenna polar chart and typed them in to Excel as a data series. By applying my formula I was able to create a chart showing the radiation pattern of an antenna that shows actual distances rather than logarithmic loss/gain values.

The results were fascinating. 

As shown in the CWNA study guide, when looking at the true linear values of actual coverage, the true extent of the directional nature of antennas becomes apparent. 

It was fascinating to see how much flatter the elevation pattern of a dipole antenna actually is, with side lobes travelling significant distances compared to area above and below the antenna. Also, the directional nature of patch antennas is far more apparent than is suggested simply by looking at manufacturer-supplied polar charts.

The charts created using the Excel Radar charts are not as granular as the original polar charts, due to the smaller number of sample points that it is possible to input. But, it demonstrates the real-world effect quite nicely. If you wanted to reproduce the full data from the original chart, you'd need to spend a lot of time taking measurements and adding them in to the Excel data series. Realistically, the examples I have shown have little real-world design value, as they miss a lot of important data due to their lack of granularity.

Here are a few samples which I put together:

Cisco AIR-ANT2460P-R

In this example I looked at a Cisco AIR-ANT2460P-R, which is a (2.4GHz) 6dBi patch antenna. 

Below, you can see the azimuth polar chart for the antenna from Cisco. Below the Cisco chart, you can see the calculated, real-world signal coverage for a -65dBm cell edge that the antenna might provide for a 1mW (0dBm) signal applied to the antenna. It is interesting to see the distance that this covers, but it is even more interesting to notice how much narrower the width of the coverage area is compared to what you might expect looking at the original polar chart.

Fig 4 - Cisco AIR-ANT2460P-R Azimuth Chart

Fig 5 - Cisco AIR-ANT2460P-R  Coverage (1mW, -65dBm cell edge)

Cisco AIR-ANT1728

In this second example, I looked at the Cisco AIR-ANT1728 (2.4GHz, 5.2dBi) dipole antenna. 

Again, I assumed a 1mW (0dBm) input to the antenna and looked to see what the -65dBm cell edge pattern might look like in the real world. Again, the difference between the pattern observed on the manufacturer-supplied polar chart compared to the real-world radiation pattern is striking. It's very interesting to see how much flatter the pattern is, with the side lobes extending much further in comparison to those shown on the original chart. 

One aspect of using high-gain dipoles that has always been an area of concern for me is exactly how high you could hang a dipole in a warehouse before you might start to run in to issues around the lobes below the  antenna not reaching the floor. Looking at this, you start to get some idea of the distance involved. Obviously, at higher powers this is less of an issue and of course here we are only considering direct line-of-sight paths, whereas in reality signals may arrive via other paths (e.g. reflections).
Fig 6 - Cisco AIR-ANT1728 Elevation Chart

Fig 7 - Cisco AIR-ANT1728  Coverage (1mW, -65dBm cell edge)


The examples and data I have presented realistically have little value in real-world design, but they emphasize the point that antenna polar charts need to be interpreted with a trained eye to anticipate the actual coverage that they might provide. They give an indication of the true nature of the real-world radiation pattern that they represent.

But, it must be remembered that in the real-world there are whole host of other propagation factors which come in to play (e.g. reflections, refraction, multipath, beam-forming etc.). They also take no account of the effect of a receiving station's capabilities. In addition, there are effects from cable losses and connector losses between the AP and antenna which would also affect the real world coverage that is achieved. The only way to gain a real-world view the true coverage provided is, of course, with a wireless survey.

Even so, it is an interesting exercise in understanding the linear nature of coverage that is not apparent from the manufacturer data sheets.

I've generated a number of these charts using Excel. The original sheets are available for you to download and have a play with yourself. 

Have fun!


Tuesday, 5 November 2013

Defaulting Cisco LWAPP/CAPWAP APs When You Have No Login Credentials

Occasionally you may come across an instance where you need to reset a Cisco 'lightweight' AP to it's default configuration. However, if the AP is not associated to a controller and you do not know the local username/password of the AP, then this can be something of a challenge.

In summary, here are the steps to default the AP when you cannot get in to the AP via the 'usual' methods:

  • Put a console cable in to the AP and fire up your terminal emulation program
  • Power up the AP with the reset button pressed at the same time
  • Release the reset button after 15 - 20 secs
  • On the console, you should now be dropped in to a 'ap:' prompt.
  • Type in the following command to see the files on the AP: 'dir flash:'
  • One of the files listed should be 'private-multiple-fs'
  • Enter the following command to remove the configuration: delete flash:private-multiple-fs
  • Reboot the AP - you will be able to login to the AP using the usual defaults (i.e. enable/Cisco)

(Note: this cannot be performed remotely, you must be able to physically access the AP)