Like every other website on the planet, SmallNetBuilder uses cookies. Our cookies track login status, but we only allow admins to log in anyway, so those don't apply to you. Any other cookies you pick up during your visit come from advertisers, which we don't control. If you continue to use the site, you agree to tolerate our use of cookies. Thank you!

NAS Charts

NAS Ranker

More Tools

Wireless How To

Introduction

In Part 1, we got acquainted with the small, but mighty NanoPi NEO2 that is the heart of our Wi-Fi Analyzer and showed how to use its built in HTML 5 speed test. This time, I'll show you how to use the WLAN Pi to choose Wi-Fi channels where you'll have the best chance of getting your share of bandwidth.

Most of us have used one of the many apps that show you the signal strength, channel and SSID of neighboring Wi-Fi networks. My current favorite is Zoltán Pallagi's WiFi Analyzer, but I'm sure you have yours. The good news about these apps is they quickly show you what you're up against in choosing "best" channels for your router.

The sample screenshot taken from WiFi Analyzer's gallery shows quite a few 2.4 GHz networks to deal with. But at least they are all using 20 MHz bandwidth and are on non-overlapping channels 1, 6 and 11.

Busy 2.4 GHz Wi-Fi neighborhood

My Wi-Fi environment, with the app running on a Moto X Gen 2 smartphone, is much cleaner because I'm in a neighborhood with lots of trees and large lots. The only networks I see are my own. The 5 GHz plot is actually misleading as we'll see in a sec.

My router is actually set to Channel 161, which is the "primary" channel. But since it's a typical consumer router, it defaults to using 80 MHz of bandwidth. If I had used channel 149, 153 or 157, the plot would look the same but the numbers in the legend would change. Similarly, using any of the four 5 GHz low band channels (36-48) would also show an 80 MHz wide chunk o' spectrum taken up.

It's worth noting that no enterprise Wi-Fi network administrator would use 80 MHz bandwidth 5 GHz channels. 5 GHz networks—even those supporting 802.11ac—you use most anywhere other than your home use 5 GHz 20 MHz channels, or, at most 40 MHz. Using 20 MHz channels provides 8 non-overlapping channels vs. the two you get using 80 MHz (this is without using DFS channels), providing higher overall network capacity.

My Wi-Fi environment - alternate view

Unfortunately, none of these apps can show the most important factor about your neighboring networks, i.e. how busy they are. The reason you care about this is that all networks operating on the same channel share its bandwidth. So you want to find a channel where you'll have a better chance at getting your share of airtime. Generally, this means you want to look for networks that have fewer and faster devices. You can't do this with a tool that shows mainly channel and signal strength information.

Kismet

The tool we'll be using is Kismet. This app has been around a long time and can be used for wardriving, wireless reconaissance and intrusion detection. The version that is installed on WLAN Pi is the current development version that uses the web GUI shown below.

Kismet main view

Kismet is accessed by clicking on its link on the WLAN Pi landing page. The Kismet Mobile version shown in the opening image above isn't really suited for what we want to do.

Lauching Kismet

The first time you access Kismet, you'll get a login error. The screenshot below, taken from the Real World Mobile WLAN Testing - Part 2 WLPC session document shows how to fix this. Login credentials are stored in the browser, so you won't have to re-enter them unless you change browsers or clear browser data.

Fixing Kismet login

Although you'll be using the web GUI most of the time, you'll need to SSH into the WLAN Pi and use the command line interface to change some Kismet parameters that aren't available from the GUI. I'm using Windows and used putty for SSH connection. I also used WinSCP, which is much easier to use for directory browsing, up and downloading files and even file viewing and editing. Both are free.

It's also important that you use a dual-band 802.11a/b/g/n adapter and not any of the 802.11ac adapters mentioned in Part 1. As I worked with WLAN Pi in preparing these articles, I realized it wasn't providing proper information. The screenshot below was taken while using the Comfast CF-912AC USB AC1200 adapter mentioned in Part 1. In addition to reporting devices on channels not actually in use, i.e. 10, 13, 48, it also misreported the meoff5 SSID on channel 165 when it was set to 161. Devices would also change channels over time and the same SSID would be shown on both 2.4 and 5 GHz channels.

Kismet is controlled using text-based configuration files stored at /usr/local/etc:

kismet.conf

kismet_alerts.conf

kismet_httpd.conf

kismet_logging.conf

kismet_memory_conf

kismet_storage_conf

kismet_uav.conf

However, since these files are owned by the root user and stored in a different directory than Kismet, they are cumbersome to change. Fortunately, Kismet has the option of creating an override config file, kismet_site.conf. Any options in this file replace options of the same name in any of the other conf files. Kismet looks for kismet_site.conf in the /usr/local/etc directory by default. But by changing the opt_override option in kismet.conf, you can locate this file where you like.

Since Kismet keeps its log files in the kismet directory by default, that's where I put my kismet_site.conf file. Here are the steps to edit the default kismet.conf file to point to the new location for kismet_site.conf.

SSH into WLAN Pi using putty or your favorite SSH client. The WLAN Pi's IP address is shown on the OLED display. Use wlanpi for both username and password.

Change to the /usr/local/etc directory:

cd /usr/local/etc

Edit the kismet.conf file changing opt_override=%E/kismet_site.conf to opt_override=/home/wlanpi/kismet_site.conf. Both vi and vim editors are supported. Be sure to preface your edit command with sudo to temporarily act as root or you won't be able to save your edits.

You can now create your kismet_site.conf in /home/wlanpi. The one I created can be downloaded and uploaded to your WLAN Pi using WinSCP. You can also create it from scratch directly in /home/wlanpi using vi or vim. My file does the following:

Sets channels 1,6,11,36,40,44,48,149,153,157,161 to be scanned. There is also a commented-out line to use to disable channel hopping and monitor only one channel

Sets channel hop speed to 2/sec

Enabels logging and changes the log type to pcapng.

Clears the device list when Kismet starts

One of the good/bad things about Kismet is that it retains captured data pretty well. This was a pain, however, once I discovered the 11ac adapter was lying to me, switched over to the dual-band 11n adapter and wanted the old data to disappear.

Including persistent_load=ondemand in the override file fixed this, clearing the main display of not only devices but also messages when Kismet was started. Restarting Kismet using sudo service kismet stop and sudo service kismet start was also pretty reliable for clearing the display and starting a new log file. If all else fails, you can power cycle the WLAN Pi to start anew.

Note: For those who want root access, WLAN Pi isn't set up to allow you to log in as root. But you can use the su command (password=Wlanpi!) to act as root for as long as you want. Just be sure to exit by typing ex when you're done with root duties.

I found the pcapng log more useful than using the default kismet log type and running one of the Python-based conversion tools found in /home/wlanpi/kismet/log_tools. The pcapng file can be opened with Wireshark to further explore captured packets to learn more about devices.

One more thing. Kismet is an HTML5 application and stores some of its data in web browser memory. So if you really want to start fresh, you'll need to clear browser history and cache. This will wipe out any settings changes you made, as well as the Kismet login