Results from my previous post comparing WLANPi Extcap with Ekahau Capture + Sidekick, and a 9-year old iMAC convinced me that Ekahau Capture outperforms WLANPi Extcap considerably. By truncating data frame, possibly makes Sidekick’s capture engine faster and more efficient. So what if we enable frame slicing on WLANPi Extcap, will that yield higher frame count? And if so, by how much?
Not many people know that hidden in the “Advanced” tab, there is an option to enable frame slicing. The default value is 0, which indicates full capture. You can change that value to any frame size you want, and in the example below, any frame larger than 100 bytes would be written to a PCAP file at the reduced 100-byte.
Now let’s examine how Ekahau Capture truncates 802.11 frames.
In contrary to WLANPi Extcap, Ekahau Capture does not limit frame by a fixed size; in fact it leaves management and control frame untouched. However, it strips out the entire payload of all data frames leaving only the MAC header. The figures below show the different frame slice solutions.
The goal of this experiment was to find out if by enabling frame slicing, would that increase the frame counts. To make sure it was an apple-to-apple comparison, I used two identical WLANPi’s version 1.9.1 with two Linksys WUSB6300 USB adapters (use the same RTL8812AU chipset found in CF-912AC). For an easy reference, I will call WLANPi A and WLANPi B.
WLANPi A was set to capture entire frame whereas WLANPi B on 100 byte reduced frame. I ran Fast.com from my iPhone 7 Plus to inject frames, extracted only frames that pertained to my iPhone (wlan.addr==iPhone MAC), recorded the results, and repeated.
For simplicity, the results below depict the total frame counts, where it clearly shows that WLANPi B with the frame slice enabled captured more frames compared to WLANPi A with deltas as high as 57% or about 38% on average.
Prior to the next run, to ensure all the variables were the same, I only switched around the frame slice setting between WLANPi A and WLANPi B. All physical pieces were left untouched. And the results show, in contrary to the previous tests, WLANPi A had higher frames captured on all 3 tries with average delta of about 43%. This was a strong indication that WLANPi with frame slice setting was able to capture on average 40% more frames than using full capture.
Now, this may look like a good idea to use the truncated mode, but be mindful and don’t go crazy since WLANPi reduces all captured frames (management and control frames included) to a certain size, you may lose essential information if you set the limit too low.
Per example below, the probe response was 392 bytes, but with frame slice enabled at 100 bytes, it removed the 101st byte onward. With that, I lost part of the RSN and all the subsequent information elements like QBSS, HT, VHT capabilities, etc.
So the take away is, for WLANPi Extcap, use frame slice whenever you can. To make sure you get all the information you need, I recommend a test run first to check the maximum frame size of the managements and control frames that you care of, and set that as the frame slice limit. For me, I think 200 bytes is a good start, but if your goal is to maximize frame counts, 80 is probably the lowest I would go.