A Practical Introduction to Dynamic Frequency Selection November 17, 2017
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?
Importing Scan Results from AirPort Utility into WiFi Explorer Pro November 2, 2017
Apple’s AirPort Utility for iOS includes a Wi-Fi scanner you can use to scan for nearby networks from your iPhone or iPad. Scan results are presented as a list and include only a few fields to describe the networks found: BSSID, SSID, channel, RSSI, and time.
Rather than examining the scan results in the app itself, you can visualize them in WiFi Explorer Pro (1.3) with a simple copy and paste.
To scan for networks using AirPort Utility, on your iOS device, go to Settings > AirPort Utility to turn on the Wi-Fi scanner.
Next, open Airport Utility and tap Wi-Fi Scan.
To start the scan, tap Scan.
AirPort Utility scans all available bands at four-second intervals and will continue scanning until you tap Stop. You can also use the slider to set a scan duration of up to 60 seconds.
AirPort Utility offers different ways to share the scan results, including AirDrop, Mail, and Copy. You can choose any of them to import the results into WiFi Explorer Pro.
If you're running macOS Sierra (10.12) or later and have Handoff enabled, the easiest way to import the scan results from AirPort Utility is by using copy and paste. Just tap the share icon and choose Copy, then switch to WiFi Explorer Pro in your Mac and choose Edit > Paste, or press Cmd+V.
Similarly, if you choose to share the scan results by using the Mail option, you can open the email message, copy the content by pressing Cmd+A, Cmd+C and paste it into WiFi Explorer Pro with Cmd+V. Any signatures or footer information found in the text of the email is ignored, so you don't need to worry about that.
If you choose AirDrop, simply open or drag & drop the text file into WiFi Explorer Pro. The same can be done if someone sends you a file containing the results. Just make sure the file's name has the .txt or .csv extension.
Quick note: When importing the scan results into WiFi Explorer Pro, many of the columns and fields will be blank since the data from the results is very limited and doesn't include all the information that can be normally retrieved from a scan. As for the First Seen, Last Seen and Seen columns, you will notice also that WiFi Explorer Pro shows January 1, 2000 as the date. This is because the time field found in the scan results from AirPort Utility only specifies the time of the day.
I hope you find the feature useful.
Don’t Miss A Thing – Join The WLAN Pros Email List