Analyzing The Data
Now that Kismet is configured and running, let's see what it can tell us. Be warned that Kismet presents a lot of data and it's easy to get lost. But if you stay focused, you'll do fine.
The screenshot below was taken after Kismet was running for about 15 minutes on my very quiet WLAN, which is currently using a dual-band ASUS router with shutmeoff as the 2.4 GHz SSID (Name column) and meoff5 as the 5 GHz SSID.
Network summary - low activity area
Just by looking at this top level screen, we can see each SSID has about same number of STAs connected (13 on shutmeoff, 15 on meoff5), but shutmeoff shows much more data used (24.59 MB vs. 142.9 KB). This looks like a slam dunk; 2.4 GHz is handling over 100X more data than 5 GHz. But remember we're using an adapter that can't decode 802.11ac data packets! So it will be able to report 5 GHz data only for 802.11a and 11n devices.
So what we can say about the 5 GHz SSID above is that it's unlikely any 11a or 11n devices are very active.
The next screenshot shows a much more active area. The Search box acts like a case-sensitive filter and was used to filter the view to show only APs; it found 752 out of 1,443 devices were AP's!
Summary of APs in busy area
Although the data totals per AP are pretty low, you'll need to manually total the data on each channel before making a decision. Using data from just the top 13 networks shown, says we'd probably want to choose Channel 6 for 2.4 GHz.
Channel totals - busy area
The search function doesn't support multiple search terms, so we can't say "show me only 5 GHz access points". So we need to do more work to choose a low-usage 5 GHz channel. Since we're not using an 11ac adapter, Kismet can't show us data totals for 5 GHz 11ac devices, only 11a or n. So to get a more accurate view of how busy an AP is, we need to look at packet use, which is shown in the Device Details screen.
The screenshot below was created by clicking on the Channel 36 AP line (left) and top Channel 1 line (right). There is a lot more info here in multiple tabs, but what we're looking for is in the Wi-Fi (802.11) tabs. We see the 5 GHz AP moved more packets (453 vs. 367), and had a much higher management packet overhead (347 vs. 88).
Kismet 802.11 details - top 5 GHz and 2.4 GHz APs
The LLC/Management packet total includes beacons and probe requests/responses, which don't eat up a lot of airtime, but will always be the highest percentage of packet types seen in a network. But it also includes TCP/IP acknowledgements (acks) and block aks, which indicate data transfer activity. Unfortunately, Kismet doesn't provide a further breakdown of LLC/Management packets, so we'll need to make our 5 GHz judgement by comparing total LLC/Management packets.
The next screenshot shows the top two 5 GHz APs in the AP sort, using Channel 36 (left) and Channel 157 (right). The Mgmt packet totals show the Channel 36 AP is likely much busier than the Channel 157 AP (347 vs. 90). Other information we can glean from the details is that the Channel 36 AP is a two-stream 802.11ac AP (866 mbit) and is set to use only 40 MHz bandwidth vs. the usual 80. This indicates it's likely part of a business network. It also has an almost 3X faster beacon rate, which could contribute to its higher LLC/Management packet count.
Kismet 802.11 details - top 5 GHz and 2.4 GHz APs
The Channel 157 AP is a three-stream 802.11ac AP (1300 mbit) using 80 MHz bandwidth, so it's probably a consumer router. The fact it also supports WPS reinforces this conclusion.
The stream information is looked up from the MCS table below by going down the appropriate column until you find the displayed Max. Rate, then looking at the Spatial Streams column for that row. You'll usually find your rate in the SGI (Short Guard Interval) column.
Kismet Wi-Fi information for SSID shutmeoff
I should note interpreting 2.4 GHz APs is a little tricky, since the Max. Rate shows the fastest rate supported by the AP. If it's a dual-band 3x3 AP like the one shown below, you'll see 1300 mbit reported because that's what the 5 GHz radio maximum link rate is.
Kismet 802.11 details - dual-band AP
Kismet's official documentation is its readme files, found on https://www.kismetwireless.net. The Old/Stable documentation describes the character-based Kismet, which is no longer being developed. Most of the information you search up on the net will be based on this version.
The Development/Git version has the web GUI and is the one found on WLAN Pi. Because it's newer, you'll find fewer articles about it and have to be more creative in your web searches.
Channel selection is done via the hamburger menu Data Sources item and expanding the data source shown. First pause data capture, then select the Lock option to monitor only one channel. Hop will allow selecting multiple channels, but always starts by first selecting all channels when you change from Lock. This makes it tedious to narrow the list. That's why the configuration in our kismet_site.conf file mentioned earlier, starts with the channel configuration shown below.
Kismet will sometimes show alerts while it's capturing data. If you're in a busy area, you may see warnings about dropped packets like shown below. You can try messing with settings in kismet_memory.conf as suggested. But it's usually quicker and easier to scan fewer channels.
The alert also flagged up a more interesting event, announcing it had found broadcast deauthentications on that AP. These events would have forced any connected STAs off the AP. Deauthentications aren't always bad; they're sometimes used to, uh, encourage devices to move to another AP. This is sometimes referred to as roaming "assistance" and uses deauthentication of individual STAs.
Kismet doesn't flag individual deauths, but does flag broadcast deauths because they can indicate a denial of service attack, at noted in the alert. Spoofed broadcast deauths are also used to generate a lot of reassociation traffic, which is a technique used for WEP and WPA key cracking.
You can customize Kismet's display a few ways. The Settings > Device List Columns menu (under the hamburger) is where you adjust the columns shown on the main Kismet screen. I removed the Capture Phy name column because it was always 802.11.
Device List Columns setting
You can change a device name in the Device Details > Device Info tab (click on an item on the main screen). This lets you more easily recognize devices. The Fing Android app does an excellent job of resolving Host, Bonjour, SNMP and NetBIOS names and is what I used to change a few names for high data-use devices. Once you change a name, or any other setting, it will stick between WLAN Pi reboots because it is stored in web browser memory.
Changing device name
Some things that need work are the Device Details > Packet Graphs tab. The auto-rescaling seems too aggressive, probably due to limited screen space, and is applied per line. So you can't get an at-a-glance sense of relative packet volume.
Similarly, the Channel display at the bottom of the main screen isn't helpful. I couldn't find a way to relate any of the numbers it was showing to the Clients column, even using the Historical view.
Clients per channel mismatch
One last tip: keep an eye on storage use. If you leave WLAN Pi running for long periods and are in a busy area, log files can start eating into your flash capacity. If you let them grow unchecked, you'll run out of space and WLAN Pi will crash.
Since Kismet log files are stored in /home/wlanpi by default, they're easy to keep track of and remove using rm. Since you (user wlanpi) own the Kismet log files, you don't need to preface rm with sudo.
You should keep an eye on system log files in /var/log, too. Older logs are zipped (.gz) and can usually be safely removed to free up space. sudo df and sudo du can help track down space hogging files.
I hope you can see how Kismet can help you better choose a wireless channel in a busy area. It can capture a lot of data and organize it in ways that provide insight into what's going on in your Wi-Fi neighborhood. While it can't do RF spectrum analysis to show you non Wi-Fi devices that could be interfering with your Wi-Fi happiness, it can do a hell of a lot to improve your insight into your Wi-Fi surroundings...and for way under $100.
That said, it's not a perfect tool. If you're expecting to run it and have Kismet magically announce the guaranteed bestest channel, well, it's not gonna happen. It can help your decision process, but in the end, you have to put in the work to understand the data.
The other thing to remember is that your Wi-Fi environment is constantly changing. What could be the right channel during the middle of the day can become an overloaded hell come early evening. Fortunately, WLAN Pi and Kismet are great for ongoing monitoring too, whether continuously or when things get wonky in Wi-Fi land.
Have fun and happy hunting!
A big tip o' the SNB hat goes to
- Keith Parson's Wireless LAN Professionals Conference (WLPC), where I was introduced to WLAN Pi
- Scott McDermott & Jerry Olla for their work in developing WLAN Pi
- Jerry Olla for patiently answering my WLAN Pi questions
- Mike Kershaw for his tireless work on Kismet. Support him on Patreon.
- Friendly Elec for making the NEO2