Starting Kismet
Let’s run kismet on our wireless network …
using -c to specify our data source.
Kismet will automatically put our wireless interface in monitor mode.
Kismet uses the ncurses library to overwrite text in its console output,
which means it always shows the latest output.
Unfortunately, this means we can’t scroll back through the output and search
for anything we might have missed.
We can disable this feature with the no-ncurses option to get all output
on new lines in the console.
We will let Kismet run for a few moments, then exit by using Control c.
Kismet is fairly verbose, so let’s break down some of this console output.
The first section of output displays which config files are loaded.
The output verifies Kismet loaded our override config file.
Kismet checks for an additional override file.
This file is used to handle platform specific configurations,
such as running Kismet on OpenWrt.
We can ignore this file on Kali.
Next, we have output about Kismet’s web server.
According to the output, Kismet ran successfully
and identified multiple Wi-Fi access points
and Wi-Fi devices.
We can also verify our override file worked correctly by checking for log files
Our Kismet capture is documented in our recently created log directory.
Let’s try running Kismet again, but this time we will limit the channels.
We will use the -c option to set our data source to wlan0 and limit the capture
to channels 4, 5, and 6.
When restricting Kismet to channels 4, 5, and 6, we only found one device,
and we didn’t find any access points.
This feature is useful, but we’ll want to be careful not to miss any important
devices or access points.
We can also run Kismet as a background process using the daemonize flag.
This option allows us to run Kismet as a service at boot time when combined
with the noncurses flag to disable the ncurses wrapper.
We can interact with the daemon process through Kismet’s web interface
or through a remote capture.