The WLANPi Extcap initiative by WiFi Nigel gives us, Windows users, an inexpensive alternative to capture 802.11 frames, and I was intrigued to find out just how good WLANPi performs compared to other solutions in the market.
So I put WLANPi to test with other tools I had available. This experiment wasn’t strictly scientific and your own results may vary. Again, I wasn’t looking for anything absolute, but an overall idea on how good WLAN Pi performs comparatively.
- WLANPi v. 1.9.1 with Comfast CF-912AC (RTL8812AU) USB
- iMac 21.5″ Mid-2011 powered by Airtool v. 1.9
- Ekahau Capture v. 1.0 with Sidekick
Setup and Test Methodology
The idea was to inject frames into the channel and used devices to capture frames concurrently. Keeping this experiment simple, the key measurement was the number of frames captured.
I used a TPLink 2×2 AP with 2 SSIDs set up on ch1@20MHz and ch36@40MHz. The client was an iPhone 7 Plus. All capture devices were stationed in close proximity to each other to ensure similar RSSI.
We started all capture devices simultaneously then connected iPhone to the 2.4GHz SSID. Once connected, I ran Fast.com to draw data frames. Upon completion, I disconnected the client (turned off Wi-Fi) and extracted only frames pertained to the iPhone’s MAC address into a new PCAP file. Then repeated the experiment on the 5GHz SSID.
Overall, data were about the same for both Sidekick and Airtool, with the former captured slightly more frames. WLANPi, on the other hand, showed relatively lower frames captured with 16% less compared to the Sidekick particularly the control and data frames.
On the 5GHz band, WLANPi’s frame capture capability massively lagged behind Sidekick and iMAC. Management, control, and data frames were 60%, 72%, and 72% less than Sidekick respectively.
While management and control frames were virtually identical, Sidekick and iMAC did not support AC so it could only pick up EAPOL and non-unicast data frames, hence the low data frame counts.
I rinsed and repeated to check for any anomalies, the results were consistent. WLANPi frame counts were low across the board and the gap was now even larger. It was able to capture only 20% of what Sidekick was able to.
But what about 5GHz 20MHz channel? Again, no difference. The winner was still Sidekick, by a landslide.
I though perhaps the CF-912 was faulty, and fortunately I happened to have a few other RTL8812AU USB NICs lying around, but that didn’t make any difference.
From the data above, it’s safe to say that Ekahau Capture with Sidekick (and any new Mac) offers a far superior data capture capability compared to the WLAN Pi. With all things considered (price, hardware), the result didn’t come unexpected but I was quite surprised by how much more frames Ekahua Capture could sniff of the air.
Having said that, WLAN Pi shouldn’t be overlooked. Apart from price, its biggest advantage compared to the Sidekick or a MacBook is the tiny form factor that makes it super portable and you can whip it out and quickly connect to your laptop and you are good to go. Of course, if you are a Mac guy, you are covered, but for me, WLAN Pi will be the first go-to tool to perform protocol analysis, and it always has its place in my computer bag.
Shortly after this blog was posted, I had a chat with Nigel and Jerry as they both pointed out that Sidekick stripped out the entire data frames making frames much smaller compared to WLANPi, and whether that correlates to the Sidekick’s superior performance. So let’s find out.
To start, I set the Frame Slice parameter to 100 bytes and started the capture.
I repeated 3 times and the results are shown below. Despite setting the max frame size, Sidekick still out-captured WLANPi but a huge margin particularly on the data frames.
So we can conclude that by enabling frame slicing, WLANPi still could not match the performance of Sidekick. The Ekahau spectrum analyzer still outperforms WLANPi by about 45 to 50%.