Kismet: detecting wireless devices and networks since 2001

What are you working on?

Kismet is a tool for capturing and monitoring all sorts of wireless devices. It started with Wi-Fi but has grown to include other wireless protocols too - using extra hardware it can scan for Bluetooth, find wireless keyboards and mice, and wireless thermometers, sensors, and switches; it can even see planes via ADSB reception.

Why did you start Kismet?

Kismet started fairly soon after consumer Wi-Fi became readily available, around 2001. At the time there were only a handful of wireless devices supported in Linux and they all reported packets differently, making capturing packets a hassle.

Originally, Kismet was a way to list SSIDs nearby and capture a pcap file formatted to work with other tools regardless of the type of card capturing the packets. At the time, NetStumbler was gaining popularity on Windows but there wasn't any similar tool for Linux.

What were the early days like?

The original goal of Kismet was pretty simple: get packets, log them and their location, and present some decoded information about the networks.

Often, the bigger challenge was to find good hosting: in the early 2000s, there was no cheap VM based hosting and no GitHub. Sourceforge had launched but it was still new. In all, the cost of hosting and the cost of test hardware were big challenges at the time.

How have you gotten other contributors involved in Kismet?

Getting contributors to Kismet has always been a relatively difficult process: perhaps because Kismet is a fairly large C++ codebase, which isn't the most popular language, or perhaps because often the largest users are more on the networking side than the programming side of things.

Since the major overhaul of Kismet in the last few years - adding standard JSON data and a web-based interface - there have been more contributors than most of the previous decade.

How have you managed the workload and the community?

A key factor seems to be lowering the barrier to entry wherever possible. IRC has largely given way to new platforms like Slack and Discord. GitHub is sort of the de facto solution for code and issue handling, and their spam filtering system does a good job of not adding additional maintenance work just to keep the issue tracker free.

How much time do you devote to Kismet?

I've had many jobs that were wireless-centric and which have given me the ability to work on Kismet when I might not otherwise have had the time. Sometimes finding the time (and motivation) can be a challenge, but generally, I've been fortunate in having the opportunity to devote extra time to the project.

What are the biggest obstacles you've had to overcome?

One of the biggest technical problems has always been lag in distributions: every additional library or tool that your project depends on is another thing that can go wrong and cause users problems. Kismet has only recently been updated to C++11, and even that has caused problems on some distributions. Until recently, Ubuntu 14.04LTS was still in cycle with several bugs in its C++11 implementation, and Debian Stable had a version that couldn't handle C++11 sanely at all. Now that both of those have updated it may be possible to move up to C++14, but it's likely impossible to move to C++17 any time soon because of the lag in distribution support. Similar issues plague other libraries, making some of them effectively unusable - distributions either package versions that are too old or don't package them at all.

Kismet also has hardware and kernel dependencies which bring much more trouble than other projects might - because it interfaces with the Wi-Fi cards directly, it needs specific support from the kernel. Some newer cards are only supported in very recent kernels not shipped by many distributions, or which require firmware blobs not provided by the distribution. Other cards only have out-of-kernel drivers which have significant stability issues and it's a constant challenge to find a working version that can also compile under a user's kernel version.

Cross-platform support has been a minor challenge but has been less trouble in many ways than library and kernel dependencies in Linux. With WSL on Windows and brew and clang on MacOS, getting the dependencies installed hasn't been too difficult, though of course the range of hardware support may be severely limited because of the dependencies on the kernels.

What are your hopes for the future of Kismet?

The wireless arena keeps growing, with new Wi-Fi standards and more, and cheaper, software-defined radios (SDR). SDR will likely play an increasing role in Kismet, especially trying to incorporate more SDR-based detections and protocols without increasing the dependencies needed to install Kismet.

What advice do you have for other open source projects and maintainers?

Documentation isn't optional - the more you document your interfaces, and the more you can present a standard interface, the better. The interest level in interfacing with Kismet jumped tenfold or more by migrating from a custom TCP protocol to a documented REST-like interface using JSON; the simpler you can make it for your tool to integrate with other tools, and the easier you can make it for users to pick their own language for interfacing, the more engagement you'll have.

To help Mike and Kismet's work on wirless device detection, you can contribute on GitHub or sponsor Kismet on Patreon or GitHub Sponsors. If you want to use it yourself, check out the Tindie store.