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;'
Kismetdb ephemeral and timed logs
kismet log format can be used as an ephemeral (non-permanent) log file, and can automatically time-limit the data. This is extremely useful if you are using Kismet as a stand-alone sensor, where the data is being collected over the REST interface.
Kismetdb logs can be automatically purged of old data. The timeout values are in seconds -
60 * 60 * 24, which is
86400, sets a 24 hour timeout on data.
kis_log_alert_timeout=86400 kis_log_device_timeout=86400 kis_log_message_timeout=86400 kis_log_packet_timeout=86400 kis_log_snapshot_timeout=86400
Data in each of the categories is removed from the kismetdb log file after the timeout. Devices which have been idle for more than the
kis_log_device_timeout are removed.
A kismetdb log may be marked as ephemeral by setting:
An ephemeral log is removed from the filesystem upon creation; the log is not accessible on disk, and will be removed immediately upon Kismet exiting. Ephemeral logs are most useful when deploying Kismet as a permanent fixed sensor with a time-limited history; for instance retaining the past day of devices, packets, etc, but where there is no need (or desire) to keep log files.
Kismet can filter packets and devices logged in the
kismetdb log file. This can be used to exclude known devices, or include ONLY certain types of devices and packets.
Filtering is most useful when coupled with other tools, and most users won’t need to worry about it, but can be a powerful tool in specific situations.
Pass and block modes
Kismet filters operate as
block. Events which are
passed are allowed to be logged, while events which are
blocked are excluded.
Default and match modes
Kismet filters have a default mode: if a record does not match any other filter, the default mode is applied.
Records can match a pass or block mode before reaching the default mode. A filter with a default of
block can still allow specific records through with a matching
MAC addresses can be specified as a single address
AA:BB:CC:DD:EE:FF, or as a masked group
A masked group works like an IP netmask specification: the value after the
/ indicates the bytes to match on; in the case above, the match will grab any MAC address beginning with
The most common use for masked matching is to match OUIs which are the first 3 bytes of the MAC address.
Filtering device records from the
kismetdb log will not prevent Kismet from showing them, but prevents Kismet from logging them.
Devices are filtered by phyname and mac address. Mac addresses can be specified as a single MAC or as a masked group.
The default filter controls are in
kis_log_device_filter_default=pass | blockBy default, kismetdb logs are not filtered, and the default for devices is
kis_log_device_filter=phyname,macaddress,valueAdds a device filter for the given phyname and MAC address. For example:
Filtering packets from the
kismetdb log will not prevent Kismet from processing them and creating related devices, but will prevent the actual packet data from being logged.
Packets can be filtered based on the MAC address of the source, destination, network, or ‘other’ address. For Wi-Fi, the ‘other’ address is used only in WDS environments where the quad-MAC headers are used. Packet filters may also filter on ‘any’ address, which matches any of the four.
The default filter controls are in
kis_log_packet_filter_default=pass | blockBy default, kismetdb logs are not filtered, and the default for packets is
kis_log_packet_filter=phyname,addresstype,macaddress,valueAdds a packet filter for the given phyname, address type (source, destination, network, other, any), and MAC address. For example:
Live filter control
Packet filters can be enabled and manipulated live via the filter REST API.