Kismet supports logging to multiple file types:
kismetis the primary log format now used by Kismet. This log combines all the data Kismet is able to gather - packets, device records, alerts, system messages, GPS location, non-packet received data, and more. This file can be manipulated with the tools in the
log_tools/directory. Under the covers, a
kismetlog is a sqlite3 database.
pcapppiis the legacy pcap format using the PPI headers. This format saves Wi-Fi packets, GPS information, and some (but not all) of the signal information per packet. Information about which datasource captured a packet is not preserved.
pcapngis the modern pcap format. While not all tools support it, Wireshark and TShark have excellent support. Most tools written using libpcap can read pcap-ng files with a single data source. When using pcap-ng, Kismet can log packets from multiple sources, preserving the datasource information and the original, complete, per-packet signal headers.
Picking a log format
Kismet can log to multiple logs simultaneously, configured in the
kismet_logging.conf config file (or in the
kismet_site.conf override configuration). Logs are configured by the
log_types= config option, and multiple types can be specified:
Log names and locations
Log naming and location is configured in
kismet_site.conf for overrides). Logging can be disabled entirely with:
or it can be disabled at launch time by launching Kismet with
$ kismet -n ...
The default log title is ‘Kismet’. This can be changed using the
or it can be changed at launch time by running Kismet with
$ kismet -t SomeCustomeName ...
Kismet stores logs in the directory it is launched from. This can be changed using the
log_prefix= option; this is most useful when launching Kismet as a service from systemd or similar when the directory it is being launched from may not be where you want to store logs:
Kismet log journal files
kismet log format uses sqlite3 to create a dynamic random-access file. If Kismet exits abnormally (such as running out of RAM or the power to the device failing), it may leave behind a
This file is part of the sqlite3 integrity protection, and contains partial data which was not written to the database.
The journal file will be automatically merged when the log file is opened, or you can manually merge them with sqlite command line tools:
$ sqlite3 Kismet-foo-whatever.kismet 'VACUUM;'