TamoSoft turned 20 this August. During the last 15 of these 20 years, we’ve been making software for Wi-Fi analysis. Part of this job is to develop drivers for Wi-Fi adapters, and in this blog post I’ll shed some light on how our development team has been testing the products of their work, and how the testing process has evolved over these 15 years, along with the evolution of wireless standards and adapters. Below you’ll find many photos (often referred to as “geek porn”) and technical details.

Why Do We Need Special Drivers in the First Place?

When you make software for analyzing Wi-Fi networks, such as TamoGraph Site Survey or CommView for Wi-Fi, you need a way to receive (read, capture, sniff, intercept… those are all synonyms) Wi-Fi packets being sent between nearby access points and stations. The only way to achieve this on Windows is by writing a set of your own drivers for specific chipsets.

What’s wrong with the standard vendor-supplied drivers, you might ask? From the average user’s point of view, vendor-supplied drivers are perfectly fine. There is only one little problem: you can’t use them to receive Wi-Fi packets in passive monitor mode. Without that, you cannot create software for analyzing networks. In fact, this is a long and interesting technical topic that would require a separate blog post, which I’ll hopefully write later this year. If you are eager to learn a bit more regarding this right now, I’ll give a brief explanation in the next paragraph; if programming is not your cup of tea, just skip it.

About ten years ago, Microsoft introduced a new API for passive Wi-Fi packets capture on Windows, the so-called “monitor mode.” It’s always been possible to capture packets on Windows, and it’s not a problem to run, say, Wireshark or CommView (non-Wi-Fi) and watch the packets that go through your Wi-Fi card. The problem, however, is that you’ll see only your own packets and only data packets. All other information (packets addressed to other stations or APs, beacons, per-packet signal levels, PHY data rates, etc.) won’t be available. Microsoft’s shiny new API was created to address this issue once and for all. But it failed: virtually no major chipset vendor supports this API properly, and the API itself was already obsolete by the time it became available on Windows; Microsoft soon abandoned it. In brief, it’s been a complete failure. If you ever encounter a Wi-Fi analysis product that claims to support “virtually all modern Wi-Fi adapters,” and that product doesn’t require you to replace the vendor-supplied adapter’s driver, make no mistake: you’re looking at snake oil.

Writing special drivers for Wi-Fi monitoring is difficult, time-consuming, and expensive. There are very few software companies that can do that. In fact, I know of only three: TamoSoft, Ekahau, and NetScout.

Why Do We Need to Test Adapter + Driver Bundles?

A driver is essentially a program for interacting with hardware, written exclusively for a specific hardware type. When developers are working on a driver, they need to make sure that the driver can actually capture packets, switch between frequency channels and bands, enter and exit the hibernation state smoothly, report correct signal levels, and do many other things without which it is impossible to analyze a WLAN.

This appears to be quite a straightforward task: you just need to plug the adapter into the computer, and then you can go ahead and test this bundle for as long as you wish. In reality, there are many nuances that I’m going to talk about.

Test Bed Requirements

In order to test drivers efficiently, one needs to use a test bed, which is a platform that allows working with all kinds of hardware. This test bed should meet the following requirements:

• Easy swapping of adapters
• Ability to connect to modern computer interfaces
• Low interference from electronic components
• Mobility—during the testing process, you need to be able to move Wi-Fi adapters, changing the orientation of their antennas and the distance from the access point (otherwise, you won’t be able to calibrate their signal level readings)
• Ability to connect several adapters at the same time (a requirement specific to USB)

On top of that, it’s sometimes very helpful to take a look at how the standard driver works—in other words, to see how an adapter communicates with the host computer on the bus level. But let’s put this topic aside for now.

Archeology and Modernity

If you’ve made it past the introduction, let’s talk about hardware. We’ll recall the past (rather distant for younger readers) and review the present and future.

2003

We began making software for Wi-Fi in 2003; before that, we made software only for wired networks.  The early 2000s was the epoch in which Wi-Fi was in its infancy. The first Wi-Fi standard, 802.11, was ratified back in 1997. The 802.11b and 802.11a standards followed in 1999, but Wi-Fi hit the mass market much later. Laptops equipped with wireless adapters were few and far between, so you had to purchase adapters on your own: either external ones that could be plugged into CardBus (PCMCIA) ports for laptops, or internal ones based on the PCI standard. A small share of high-end laptops was being sold with integrated MiniPCI adapters.

Our first endeavor was the support of 802.11b CardBus adapters. Those were the blessed times: almost all of those adapters were based on the Prism chipset manufactured by a company named Intersil; the driver’s source code was freely available under an NDA, and the maximum PHY rate was 11 Mbps, which means that in reality, you could transfer data at 1 Megabyte per second at best.

A CardBus Wi-Fi adapter with external antennas

It’s worth mentioning that those adapters worked pretty well and had good sensitivity, especially if you could connect external antennas. As for the testing platform, things were simple those days: almost all laptops had one or two CardBus ports.

Do you still remember those mammoths weighing 3 or 4 kg?

So, all we had to do was plug the adapter into an external port, like that.

A CardBus adapter and the respective slot of an ancient laptop

2007

That year, CardBus adapters started to get phased out by more elegant ExpressCard adapters based on the PCI Express bus. The first 34 mm ExpressCard Wi-Fi adapters emerged on the market; they supported both 802.11g and 802.11a. Data rates were increasing, and new modulation schemes were being used.

ExpressCard Wi-Fi adapters

Just like CardBus, ExpressCard adapters were quite convenient for testing purposes. Swapping cards was easy, and laptops with ExpressCard ports were abundant.

The evolution of desktops was moving ahead as well, and in 2007 the new PCI Express 2.0 standard was ratified.  Many desktops were being equipped with PCIe adapters with external antennas.  Testing them wasn’t easy, though, as you had to remove the computer cover, replace the PCIe adapter, and then put the cover back.

2010

That year, we began to support USB 2.0 Wi-Fi adapters. USB is an extremely convenient form factor in terms of both testing and end user utilization. All you need is a USB port (or several ports, in case you want to use multiple adapters).

This was also when the legendary Proxim ORiNOCO 8494 802.11n appeared on the scene. It was based on a chipset by Atheros Communications (not yet acquired by Qualcomm at that time). All the professional Wi-Fi site survey applications were using that adapter, and deservedly so, as it had great sensitivity.

The legendary Proxim ORiNOCO 8494 USB adapter

The possibility of connecting multiple adapters at the same time is a huge advantage, because that accelerates channels sweeping time (if we’re talking about site survey applications) and allows analyzing roaming behavior (if we are talking about packet analyzers).

Nevertheless, one should keep in mind that a typical Wi-Fi USB adapter consumes between 200 and 300 mA, so if you use a passive USB hub and plug in three adapters, you might easily exceed 500 mA, which is the limit for USB 2.0.

PortaPow DC power monitor for measuring USB current

There was virtually no RF interference from USB 2.0 hubs, so other than the current being consumed, the only thing that you had to worry about was port positioning. Ports should be positioned so that you can use adjacent ports at the same time (if the ports are too close to each other, you just won’t be able to plug in adapters).

The next challenge that we faced in 2010 was the emergence of MiniPCIe adapters that replaced MiniPCI in laptops. We began with disassembling laptops in order to test new adapters. Oh boy, that was a real pain! Replacing a built-in adapter in a laptop is a slow and tedious process; you might experience many unexpected problems en route. First, if the original laptop’s adapter had two antennas and you wanted to test a model with three antennas, there was no good solution. Second, some of the laptop vendors are really evil: they hardcode the adapter models that they support into BIOS. If the new adapter is not on the whitelist, the system just won’t recognize it. Third, you might just get unlucky and break something inside.

At some point, we even had to resort to using desktops with special PCIe <-> MiniPCIe converters.  Needless to say, this solution was far from ideal, as the test bed mobility is important. However, the ideal solution was eventually found thanks to the good gentlemen at a Taiwanese company named Bplus Technology. They sell dozens of cool electronic components for prototyping, testing, and debugging, including this wonderful board:

A testing board with a MiniPCIe connector.
The board can be plugged into an ExpressCard port via a short cable.

This board became a real godsend for us for many years. It was a terrific test bed: you could easily swap adapters, it was mobile, there was no RF interference, and the board was extremely inexpensive.  All you needed was a laptop with an ExpressCard slot, but back then, it was not a problem.

The board is connected to a laptop; the
ExpressCard is plugged into the laptop.

2013

By 2013, Wi-Fi had conquered the world.  All laptops were equipped with integrated Wi-Fi modules. Those modules, in line with ubiquitous miniaturization, were being manufactured in a new form factor, M.2 (a.k.a NGFF). M.2 adapters are smaller than standard MiniPCIe adapters and have a different connector.

A MiniPCIe testing board, MiniPCIe Wi-Fi adapter, and M.2 Wi-Fi adapter

We were eager to keep on using our wonderful testing board, and Bplus Technology came to our rescue again.  They made a MiniPCIe <-> M.2 converter, so we could easily make a thick “sandwich” like this:

A “sandwich” that consists of a MiniPCIe board, MiniPCIe <-> M.2 converter,
and M.2 adapter with attached omnidirectional antennas

In 2013, laptops with ExpressCard slots were no longer available, but we had a stash of those old computers. It was evident, though, that a new solution would be needed. But more on that below.

2014

In December 2013, the 802.11ac standard was ratified; many new 802.11ac adapters hit the market in 2014. They became USB 3.0-based. Why USB 3.0? That’s because the USB 2.0 bus bandwidth was no longer sufficient. 802.11n adapters with three spatial streams could reach the data rate of 450 Mbps on the physical level, whereas 802.11ac adapters could reach 867 Mbps (two streams, 80 MHz channel) or 1300 Mbps (three streams, 80 MHz channel) or, theoretically, even 2340 Mbps (three streams, 160 MHz channel, although such adapters are not available on the market).

The only problem with USB 3.0 is that USB 3.0 devices (cables, connectors, circuitry) may generate pretty powerful wideband RF noise that makes adapters far less sensitive because signal-to-noise ratio (SNR) decreases. Without proper shielding, this effect can be easily observed. The screenshot shown below was made using TamoGraph Site Survey and Wi-Spy spectrum analyzer. You can see a typical picture of several Wi-Fi networks working in the 2.4 GHz band (the amplitudes are in the top half of the image and the waterfall view is in the bottom half). As you can see, the noise floor is approximately at -95 dBm.

No interference from the USB hub

Now let’s move the Wi-Spy antenna closer to the hub or external USB 3.0 drive. The picture has changed dramatically:

Much interference from the USB hub

There is noticeable noise approximately at the -77 dBm level. Given that the minimal SNR at which Wi-Fi can still function is about 4 dB, this noise level won’t let the adapter connect to a network if the signal from the AP in question is below -73 dBm. To circumvent this problem, one may want to try different hubs or use extension USB cables that increase the distance between the adapter and the RF noise source.

How the hell do USB 3.0 adapters live with that kind of interference? Well, they live a very interesting life. Consider, for example, Realtek-based adapters: When the adapter is not associated, it works in USB 2.0 mode, sweeping channels and detecting nearby WLANs. As soon as the adapter connects the selected WLAN, a special Windows system service re-initializes the adapter and switches it to USB 3.0 mode. The adapter stays in that mode until it gets disconnected, after which it returns to USB 2.0 mode. Don’t you love this awkward dance?

2018

As time goes by, we encounter no new problems respecting USB adapter testing (USB Type-C connectors don’t count; a cheap converter solves this problem), but a crisis was looming in regards to MiniPCIe and M.2: We could no longer live with the old “laptop with an ExpressCard slot + MiniPCIe board with an ExpressCard interface” bundle. Old laptops aren’t powerful enough to run Windows 10 and might simply die any moment, leaving us high and dry. And no, we’d hate to look for ancient laptops at the flea market.

A new solution was obviously necessary: a mobile one, preferably both for Windows and Mac OS,  with a modern interface and, naturally, direct memory access (DMA). The easiest thing would be to plug a PCIe <-> MiniPCIe converter into a desktop, but then we’d have to say good-bye to mobility. Carrying a desktop around the office is great for fitness, but not terribly productive. Besides, lately we tend to ditch desktops in favor of laptops and Intel NUCs.

So, what options were we left with? Definitely not USB, because, alas, it’s impossible to make a PCIe <-> USB bridge. What comes to mind is Thunderbolt. Thunderbolt is available in new laptops and NUCs, and a PCIe <-> Thunderbolt bridge appears to be doable. All right, the search path was clear: We needed to find a device for connecting a PCIe adapter via Thunderbolt.

After some searching, we found this little beast: Startech Thunderbolt 3 PCIe Expansion Chassis. Needless to say, never in their wildest fantasies could the makers of this device have imagined that someone would want to insert a Wi-Fi adapter into this chassis. Actually, their website lists all those fantasies that have occurred to them: “The Thunderbolt 3 PCIe chassis makes it easy to expand your system with the capabilities you need to work at peak productivity. You can add many types of PCI Express cards, such as a PCIe USB 3.1/3.0/2.0 and USB-C, SSD, network, eSATA, FireWire or video capture cards.” In theory, a Wi-Fi adapter should take off just fine. In practice…well, you know how things work in practice. If there is the slightest chance for a component to not work for any reason (driver, firmware, circuitry), then it’ll happily take that chance.

We emailed technical support. Quite explicably, they were unprepared to answer the question about Wi-Fi. They told us that they had tested Ethernet adapters, but never Wi-Fi adapters. Oh, well, we didn’t mind a little beta testing for them. The package arrived promptly, and all we needed to do was remove the case and insert a PCIe board with an M.2 connector.

Startech TB31PCIEX16 innards

Then we had to insert the Wi-Fi adapter and use two screws to fix it, connect antennas (the connectors are microscopic, so it’s hard to do that without a magnifier), attach the antennas to the expansion bracket so they were located outside the box, and, finally, connect the unit to the power supply and the laptop’s Thunderbolt port.

Fully assembled Startech TB31PCIEX16

Well, guys, it worked! Not right away, of course; hardware like that won’t surrender fast. We had to update the Thunderbolt controller firmware in the computer, but eventually things went smoothly.

Future

We’re attentively watching the industry progress. The next interface coming up is M.2 CNVio, which is used, for example, in the latest Intel 9560 adapters. The next Wi-Fi standard is 802. 11ax. At TamoSoft, we are committed to supporting the latest hardware and standards. Keep them coming!