What's new

Build A Wi-Fi Performance Analyzer For $75

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

thiggins

Mr. Easy
Staff member
wlanpi_w_router.jpg
Think Wi-Fi analyzers that can show network activity are expensive? Here's how to build one for well under $100.

Read on SmallNetBuilder
 
With some network driver optimization it should be possible to get around 950Mbps from the AllWinner SoC's over Gigabit. Unfortunately their driver support is a bit hit and miss, but I've been involved in the development of a couple of devices based on the H3 SoC and with a bit of tweaking those devices performed quite well. That said, it might also be a PCB layout issue that limits the speed, as we had to through a couple of revisions for those projects to optimise the board layout as well. It's also possible that the single channel memory is holding the neo2 back a bit as well.
 
Looks like the CMS might have messed with the wikidevi search link... this is the corrected search query

Code:
[[Chip1 model::RTL8811AU]]
 
Nano Pi - go for the extra RAM if you can... it does help with some apps.

AllWinner support in the kernel is getting better with some of the sunxi stuff going into mainline.

If one needs more "horsepower", consider the Tinkerboard - much better memory performance, and it's close to the Intel Silvermont chips in overall performance.
 
Think Wi-Fi analyzers that can show network activity are expensive? Here's how to build one for well under $100.​
Read on SmallNetBuilder
Tim, what a great article, of course ordered the Neo2 Nano Pi immediately. And thanks to sfx2000, above, for the tip to go to one gigabyte of RAM.

Wonder how close this thing is to being usable as a $55 dollar OpenVPN (with AES encryption) or IPSec appliance. Using either a $15 dollar Tenda SG105 five-port gigabit switch, or a $20 dollar 802.11ac USB WiFi adapter, to get data both in and out.
 
Wonder how close this thing is to being usable as a $55 dollar OpenVPN (with AES encryption) or IPSec appliance. Using either a $15 dollar Tenda SG105 five-port gigabit switch, or a $20 dollar 802.11ac USB WiFi adapter, to get data both in and out.

Not enough horsepower or bandwidth to be effective as an OpenVPN/IPSec appliance or router - there are existing platforms out today that are more effective and cost-efficient.

What the project does show is a level of care and attention can go a long way - the SW integration on the platform, the tools available, it pretty cost effective and flexible.

To really appreciate the platform and tools - go to the site -- http://www.wlanpi.com
 
I need a weekend project so think I'm going to order the parts and build this.

Only thing that sucks is CF-912AC USB AC1200 adapter is not available to be shipped to Canada so will have to look for something different.

Thanks for the article!
 
I need a weekend project so think I'm going to order the parts and build this.

Only thing that sucks is CF-912AC USB AC1200 adapter is not available to be shipped to Canada so will have to look for something different.
I have found that the Realtek based adapters don't provide reliable information when used with Kismet, which I'll cover in the next article.

I updated the article yesterday with a new recommendation for adapters to use.
 
I have found that the Realtek based adapters don't provide reliable information when used with Kismet, which I'll cover in the next article.

I updated the article yesterday with a new recommendation for adapters to use.


Updated 3/9/18: I noticed odd behavior in Kismet using the Comfast adapter. Basically, it looked like different SSIDs on the 2.4 and 5 GHz bands of the same AP were showing the same packets. This behavior was also seen using an Edimax EW-7811UTC 1x1 ac adapter, which also uses the Realtek RTL8812AU. Activity was also being seen on many channels that were not active.

Switching to a dual-band N adapter (Alfa AWUS051NHv2), that uses a Ralink RT3572 chipset yielded results that made much more sense.
It's a driver issue with the 88212au - can confirm same thing with the Asus USB-56ac (same chip). That chip has been a bit of a challenge with Linux in general.

The Alfa is a good choice for the project
 
I have found that the Realtek based adapters don't provide reliable information when used with Kismet, which I'll cover in the next article.

I updated the article yesterday with a new recommendation for adapters to use.
The Alfa AWUS051NHv2 does not seem to be readily available. Do you have another low cost choice that works? Does it matter if it does not have wireless AC?
 
Any adapter supporting the Ralink RT3572 chip should work. I ordered and tried an ASUS USB-N53 adapter, which works. There is only one version of it, so you won't get messed up by ordering a different version with a different chipset.

The only thing you lose by not using an AC adapter is the ability to capture data frames from the 5 GHz band with AC devices. You also won't be able to capture data frames in 2.4 GHz with AC devices using 254 QAM. You will be able to capture data frames from 802.11a/b/g/n devices.

In any event, the management, control and Radio Tap header frames that will be captured on both bands are enough to detect everything we need to tell busy networks from idle.
 
Any adapter supporting the Ralink RT3572 chip should work. I ordered and tried an ASUS USB-N53 adapter, which works. There is only one version of it, so you won't get messed up by ordering a different version with a different chipset.

Would the Asus USB-AC56 or AC55 be a good choice also?

The AC56 is $72 CAD and the AC55 is $60 CAD

The N53 is $45 CAD but is sold out.
 
Last edited:
No. It uses the RTL8812AU chipset, which produces flaky results. At this point, you need to use an N adapter to get reliable results in monitor mode.

So all the AC models are no good because they use RTL8812AU chipset got it.

I modified the query on the Wiki Dev page to show RT3572 chipset.
 
Last edited:
So all the AC models are no good because they use RTL8812AU chipset got it.
No. Not all AC Wi-Fi adapters use that chipset. But those that do, do not produce reliable results in monitor mode, at least not from what I can see in Kismet.

If you check the Kismet readme for the latest development version (search page for
Datasource: Linux Wi-Fi) you'll see they don't have very encouraging things to say about any AC adapters. They all seem to be flaky in one way or another.

I have tried adapters based on the RTL8812AU and RTL8812BU. The AU adapters produce flaky results. The BU-based adapter I tried (Edimax EW-7822ULC) didn't work at all.

If you find an AC adapter that works well, please let us all know.
 
If you find an AC adapter that works well, please let us all know.

Nothing on Linux is really reliable for 11ac in monitor mode - at least in my experience, esp. when working with ARM cpu's... Intel's driver, kinda works, but it has issues, and is pretty crashy, but that's not useful for an ARM cpu like the H5 in any case...

There are non-public/NDA drivers for QCA and Marvell - but these are primarily focused on the AP side of things, not client adapters, and that's the only way to really monitor MU activity

that being said - finding a good B/G/A/N adapter, like some of the older Alfa's, is still very useful, as 11ac Beacon frames are required to support backwards compatibility (e.g. there is no AC only mode), and one can get a very good idea about what's happening in the 5GHz space by using one of those dongles - RealTek and Ralink both are good there...

A fun addition to the project would be to include GPS support - the old Pharos GPS-500 USB dongles (used to be bundled with Microsoft Streets and Trips) are low power, and completely supported by Linux and GPSd... and they're very cheap on eBay and Craigslist...

The shiny/clear thing is the GPS-500, the item in the middle is an FTDI Serial to USB converter.

Streets-Trips-2007-review-004-20061001-1000.jpg
 
I should add that with Kismet - make sure that the monitor interface is not associated with any AP, as that will produce spurious results in the packet captures.

It's one of the complexities about how Kismet works, and how it interacts with the interfaces - one can add an additional WiFi interface for connectivity if needed - Kismet only monitors the interface selected/configured.
 
I should add that with Kismet - make sure that the monitor interface is not associated with any AP, as that will produce spurious results in the packet captures.
Doesn't Kismet take care of this by taking control of the Wi-Fi interface?

Have you used the new development version w/ web GUI?
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top