Using External USB Wi-Fi Adapters with WiFi Explorer Pro January 19, 2018
For many years I've been asked to provide support for external USB Wi-Fi adapters in WiFi Explorer. Many of these adapters are either not compatible with macOS or require the use of proprietary drivers provided by the manufacturer of the wireless chipset. In order to support these adapters in a native way, it is necessary to have access to the driver's source code. Unfortunately, manufacturers have expressed no interest or simply ignored my emails, which for some reason was a common occurrence last year for these and other collaboration attempts (sad face).
But there's a way. The External Adapter Support Environment (EASE) allows WiFi Explorer Pro to use certain external USB adapters for Wi-Fi scanning, as long as these adapters are compatible with Linux and support monitor mode. EASE is basically a lightweight Debian virtual machine (about 1.7 GB on disk, 256 MB RAM) that has been customized to leverage the remote sensor functionality to automatically configure an external adapter as a pseudo-local sensor. These pseudo-local sensors are listed in WiFi Explorer Pro separately from remote sensors, but they work in the same manner: capturing beacons while hopping between all supported channels.
The majority of users have no need to use external adapters, especially because the built-in adapter works great for scanning in active and passive mode. It also works great for packet captures. However, the main advantage for using an external adapter to scan for wireless networks is that you get the benefits of using passive mode without the need of disconnecting from the network. Passive scanning cannot be used while associated to a network because it requires the adapter to be put into monitor mode, but it can find hidden networks and networks that are farther away (see Understanding the Scan Modes in WiFi Explorer Pro). It also provides more consistent scan results than active scanning. If you're using an external adapter via EASE, the built-in adapter can still be used for connectivity.
One of the nice things about EASE is that you need zero knowledge about Linux or how to build or install the different drivers needed to use these external adapters. Creation and provisioning of the virtual machine is completely automatic using a tool called Vagrant, together with VirtualBox.
git clone https://github.com/adriangranados/ease.git
The installation of the environment takes a few minutes as the VM image is downloaded and provisioned. Once done, you will find a new VM in VirtualBox called EASE. At this point, EASE is ready to use and you can proceed to attach your external USB Wi-Fi adapter.
Using VirtualBox's USB Device Filters you can configure the environment so that every time you plug in the adapter to the USB port in your computer, the adapter is automatically connected to the EASE VM:
1. Plug in the adapter to any of the USB ports in your Mac.
2. Open VirtualBox and select the EASE VM.
3. Choose Settings > Ports > USB.
4. Add a USB filter by clicking the icon with the + sign and choosing the adapter you just plugged in.
5. Click OK, then unplug and plug back in the adapter.
If the adapter is recognized as a supported Wi-Fi adapter, it will be listed under the Scan Mode menu in the WiFi Explorer Pro's toolbar and you can choose the adapter for scanning.
The WiFi Explorer Pro integration with EASE is just the first step. It demonstrates the concept while extending WiFi Explorer Pro's functionality with the use of external adapters. My plan is to use EASE for truly simultaneous packet captures on multiple channels, which can be useful for troubleshooting roaming and other aspects of the Wi-Fi environment. I also plan to develop a solution to automatically attach the adapters to the EASE VM, as well as to manage EASE from the menu bar, thus eliminating the need to invoke Vagrant via its command line tool.
A Practical Introduction to Dynamic Frequency Selection November 17, 2017
Update (1/2/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?
Don’t Miss A Thing – Join The WLAN Pros Email List