WiFi network tools have been around for quite some time. Wireshark is probably the best known of the bunch. It seems to have supported WiFi for at least a decade.
(While I couldn't find the exact date Wireshark introduced 802.11 support, I did trace the history of radiotap support back to 2010. It probably reaches further back.)
Besides Wireshark, a few other popular tools include the solid workhorse tcpdump, the hacker friendly Aircrack-ng, the entusiast Kismet, and the more programmer friendly Scapy. Graph11 is new to the scene.
The point of all of this is simply that we have tools which work well and are mature. Why do we need another one? That's what we're going to discuss here.
This is Part 1 of a two part blog series. It establishes the definitions of features used in Part 2. The explanations are moderately technical. A basic understanding of WiFi is needed to read this.
If you don't have the background, feel free to skip on to Part 2. The discussion gets less technical.
WiFi tools fall into two major buckets: those that use libpcap and those that don't. If you're not familiar with it, libpcap is a programming library, a building block to write larger applications.
It's the gold standard for siphoning network traffic off network interface cards. It works equally with ethernet and WiFi.
Programs that use libpcap sip unrefined from the network and analyze it. The analysis can be as simple as a hexdump or as complex as complete dissection of the data. (This is no easy task. WiFi dissection is described in tens of thousands of pages of specifications.)
One of the best things about libpcap is just its wide availability. Libpcap got its start in Unix-like systems. And it's Unix heritage runs fairly deep. Libpcap is available in Linux, BSD, FreeBSD, Darwin, and macOS just to name a few. Libpcap has also been ported to Windows under different guises and projects.
And then there are the WiFi tools that don't use libpcap. These tools may use some alternative library similar to pcap (or may even try to read network data directly) which would make them very sophisticated. But the vast majority of the tools in the "no libpcap" bucket don't fit this description.
Most "no libpcap" tools skip the heavy lifting themselves. They depend on other software. This might be a library like Apple's CoreWLAN. Or in some cases, they scrape the output of command-line utilities like ifconfig, iwlist, and iwconfig. They are generally less sophisticated and more of a re-imagining of an original tool's user interface.
The WiFi radio spectrum is split into a few dozen channels spread across the 2Ghz, 5GHz, and just recently, 6GHz. Most wireless network devices are designed to listen to one channel at a time. So what channel will the tool listen to? [1]
Today, a typical basic home router establishes WiFi to two channels, one in the 2GHz band and another in the 5GHz band. This might be channels 6 and 153 respectively. A neighbor might have a similar setup but is using chanels 1 and 36. A computer or a phone can, more often than not, only use a single channel. So if you wanted to inspect your own network, you'd need to somehow keep switching between channels 6 and 153. If you wanted to inspect your neighnors network, you'll also have to listen to channels 1 and 36.
There's a concept of scanning channels. This feature is available in some tools. It changes the channel at intervals and sweeps through all the channels the network interface supports. In an example scenario, the tool might listen to channel 1 for one second, channel 2 for one second, channel 3 for one second, and so forth. The pro here is that the survey is much wider and will include information about more access points and other stations than just listening to some static channel. The con is that it produces a mosaic of data with (N-1) seconds of lost data per channel for one complete sweep.
Some tools scan. Some don't. For the sake of an example, as far as I know, Wireshark does not include a scanner. One can be jury rigged by a script or using some program that does include a scanner.
Typically, a network card will only process data it needs and ignore traffic from other unrelated devices. But quite a few network cards can be put into "monitor mode." This allows the interface to capture frames that aren't meant for it. Monitor mode vastly increases the power of WiFi tools that support it.
Libpcap can leverage monitor mode. So naturally, applications that use libpcap often also feature monitor mode.
Those applications that don't support monitor mode still might have a work around. It's possible to jury rig monitor mode with command-line utilities such as ipconfig.
What's the coin of the realm? What's the basic "thing" that the tool is focusing on?
Wireshark, for example, focuses most of its attention on individual WiFi frames. It's an extensible tool that supports "dissectors." And these dissectors live up to their name. The WiFi dissector teases apart all of those fields and specifications laid out in the 802.11 specifications, which as we mentioned earlier, contains tens of thousands of pages.
Snort is an intrusion detection tool. It is a bit more stateful. Stateful means that it knows what happened a minute ago and what's happening now. When considering now and a minute ago, new conclusions can be reached. I'd call Snort a hybrid myself. It both deep dives into invidual frames like Wireshark, but it also keeps a tally on malicious activity.
If an analogy helps, consider a page ripped from a book. How useful is it? Well, it actually has a lot of information. But no context. Someone could analyze the paper, figure out the weight, see if it's acid-free. Or someone could look at the font,
see if it's serif or sans-serif, make note of the font size. Or, if the page has numbers or a header,
someone could figure out the title or possibly even the chapter. Language can be detected (English,
Cantonese, Russian). Characters and their names can be picked out if the page is from a novel.
The number of words can be counted or made into a histogram. This is kind of what Wireshark does. It takes
a single page and dissects it.
A stateful tool would look at multiple pages. A chapter is enough to start seeing character development or a plot. Each page contributes to this "bigger picture" as more and more pages are read. Snort does this to the degree needed to detect malicious activity.
Some tools process the data until it comes out like a hotdog. It's a fate the tool decides. Don't ask how it was made.
These tools make most of the decisions on how to interpret the data. Snort is an example. It sends an alert if it detects an attack, but it makes that decision itself and doesn't necessarily offer painstaking details.
Other tools let the user draw conclusions. Wireshark allows the user to decide if a deauth frame is an attack or not.
Various WiFi tools target different audiences with skills ranging from beginner to expert. Wireshark requires quite a bit of network knowledge. Snort is meant more for administrators who are more interested in the conclusions and not so much the making of them. Some tools that simply list nearby access points are meant for beginners.
Some tools, like Scapy, are meant for people who know how to write code. Other tools are more turn-key, suitable with minimal setup.
Some tools exhaust resources if left running too long. Eventually they will exhaust either memory or disk space. For each frame they interpret, they need storage. They also get bogged down in operations that affect every frame. For example, sorting frames take longer and longer time depending on run time. Wireshark is an example of this. Wireshark uses memory that is linearly proportionate to how long it runs. This is called linear performance. Software engineers abbreviate it as O(n).
Other tools can run indefinitely. They store more aggregate data. They summarize data. Snort is an example of this. It loads, runs, and basically consumes the same amount of resources after ten minutes or ten hours. This is called constant performance. Software engineers abbreviate it as O(1).
So these are some of the major differences in WiFi tools. In our second part of this post, we summarize which tools made what design decisions in tables and Venn Diagrams.