Update (01/02/2018): With the collaboration of Nigel Bowden, Nigel and I have made available this GNU Radio flow graph you can use to emulate radar signals patterns for DFS testing as described in this post. The flow graph allows you to select the center frequency and type of radar signature you want to use.
Have you ever wondered why certain channels in the 5 GHz band, more specifically in the 5.25-5.35 GHz (UNII-2) and 5.47-5.725 GHz (UNII-2e) frequency bands are (almost) never in use by Wi-Fi devices? Well, it happens that, worldwide, these unlicensed frequency bands are also used by radar systems. So, for a Wi-fi device to operate in one of these bands, it must support Dynamic Frequency Selection (DFS). DFS is a mechanism (not limited to Wi-Fi) that allows a device to dynamically select or change the operating frequency to avoid interfering with other systems. In other words, regulatory bodies require Wi-Fi devices to use DFS to make sure devices will not interfere with your local weather radar system, for example.
Not all Wi-Fi devices support DFS, so they cannot use DFS channels (hence the unused spectrum), but when they do, they must follow certain rules. DFS states, for example, that if a radar signal is detected on a channel, the device cannot use that channel for a non-occupancy period. It's for this reason that most access points do not allow manual selection of DFS channels and use "auto" instead.
When using DFS, a device selects a DFS channel to use and, prior to initiating communications, it monitors the channel for a certain time to verify no radar systems are present. If radar signals are detected during this channel start-up period, the device doesn't use the channel (and avoids it for the non-occupancy period), then selects another channel and starts again.
The same is done while communicating (in-service). The device monitors the channel being used, and if radar signals are present, it vacates the channel within a channel move time. During this time, the device may indicate other systems to stop transmitting on that channel, which won't be used for the non-occupancy period.
In the context of Wi-Fi, an access point (AP) that supports DFS must be able to detect radar signals during the channel start-up and in-service phases. If radar signals are detected, the AP will stop transmitting and then select a new channel. Once the new channel is selected, the AP informs nearby clients to clear the channel and move to a different frequency by including the Channel Switch Announcement IE in the beacon frame. DFS-compatible Wi-Fi clients, on the other hand, cannot start transmitting until authorized by the AP and cannot perform active scanning (i.e. transmit probe requests) until Wi-Fi activity from nearby APs is detected. They also must be able to clear a channel when commanded by the AP.
We can illustrate how DFS works with Wi-Fi devices by emulating radar signals using a HackRF and GNU Radio. A HackRF is a Software Defined Radio (SDR) peripheral capable of transmission or reception of radio signals from 1 MHz to 6 GHz. Why a HackRF? Because I got one during the last #WLPC and I thought I could give it some use after stumbling upon this blog post by Bastian Bloessl, where he uses GNU Radio and a USRP to emulate radar signals.
Note: I won't go into details on how to install GNU Radio and the additional packages for SDR support, however, if you have a Mac, these steps worked fine for me.
First, we need to know how radar signals look like so we can emulate them. Each country and regulatory domain defines its own DFS requirements and test radar signatures. These test waveforms are developed based on the technical characteristics of existing and future radar systems operating in the 5 GHz frequency range. In the case of the US, the FCC (Part 15 Subpart E Rules) defines 5 different short pulse radar test waveforms, 1 long pulse radar test waveform, and 1 frequency hopping radar test waveform.
As you can see, in some cases, pulse width, pulse repetition interval and number of pulses per burst are listed as a range. The reason is that back then, the US government had a need to keep actual radar signatures confidential and didn't want devices to detect specific patterns, so the FCC incorporated a randomizing element into the various radar signal types. DFS-enabled devices must be able to detect all these test radar signal patterns, even though some of them might not be in use by actual radar systems.
Second, we need to build a GNU Radio flow graph to generate the radar signal pattern over a given DFS frequency. In this example, we will use a type 4 pattern with a pulse width of 15 µs and a pulse repetition interval of 250 µs. The radar signal pattern looks like this:
The number of pulses per burst does not matter in our case because the AP will still detect the pattern even if the number of pulses exceeds an expected burst. In gnuradio-companion, we need to connect a vector source (Misc > Vector Source) to a SDR sink capable of communicating with the HackRF for transmission (Sinks > osmocom Sink), then enter various parameter values such as frequency (5.260 GHz), sample rate (1 MHz), bandwidth (20 MHz) and a vector definition to generate a signal over the selected frequency.
To generate the test waveform, we will use the following pattern:
*15 + *250 A sequence of 15 ones, followed by 250 zeros. In other words, a pulse with a duration of 15 µs, followed by 250 µs of silence. The sequence is repeated over and over to emulate a type 4 test waveform burst.
Third, we choose a DFS-compatible AP and client for testing. The AP I'm using is a TP-Link AC1750 running OpenWRT. This AP can operate on a DFS channel in the UNII-2 band (channel 52, 56, 60 or 64). When using "auto" for channel selection, the AP seems to always choose channel 52 as the primary channel.
The client is an iMac (Late 2015), which supports DFS in the UNII-2 and UNII-2e bands. I also have a MacBook Pro running GNU Radio and Airtool. Airtool is necessary so I can do a packet capture on channel 52 and grab the beacons transmitted by the AP.
That's it. When we play the GNU Radio flow graph and the HackRF starts transmitting, we can observe how the client immediately disconnects and then, 4 seconds later, reconnects to the AP on a different channel.
It can also be observed how Airtool stops "seeing" any frames on channel 52. Moreover, the last four beacons transmitted by the AP on that channel include a Channel Switch Announcement IE. The AP has moved to channel 36.
Fun! Isn't it?