Wi-Fi: Linux

Set the source to a specific channel; combine with channel_hop=false to set the capture to a single channel forever.

Example:

source=wlan0:name=Foo,channel_hop=false,channel=6
source=wlan1:name=Wifi6eCard,channel_hop=false,channel=1W6e

Set a fixed list of channels instead of probing the source for all supported channels.

The list of channels must be:

• Comma separated
• Contained in quotes

Example:

source=wlan0:name=Foo,channels="1,2,3,4,5,6,36HT40+"

If defining datasources on the command line when launching Kismet, be aware that most shells will elide the quotes, leading to a setup error. You can avoid this by surrounding the source definition in single quotes:

kismet -c 'wlan0:name=Foo,channels="1,2,3,4,5,6,36HT40+"'

Append a list of channels to the detected list of channels.

Kismet will autodetect channels on almost all Wi-Fi sources, but some non-standard channels like half and quarter channel allocations must be manually added.

The list of channels to add must be:

• Comma separated
• Contained in quotes

Example:

source=wlan0:name=Foo,add_channels="1W5,2W5,6W10"

If defining datasources on the command line when launching Kismet, be aware that most shells will elide the quotes, leading to a setup error. YOu can avoid this by surrounding the definition in single quotes:

kismet -c 'wlan0:name=Foo,add_channels="1W5,2W5,6W10"'

Added 2019-04-git

If the interface is HT capable, automatically use HT20 channels for all 20mhz wide channels. This explicitly tells the interface to set the HT20 attributes instead of a basic channel. If default_ht20=true, then expand_ht20 is ignored.

Added 2019-04-git

If the interface is HT capable, automatically expand 20MHz channels to define the basic and the HT20 channel; for example instead of channel 1, you would now have both 1 and 1HT20.

This has the possibility to drastically increase the number of channels in the hop list, which increases the hop time.

This option is most useful on interfaces which may not report non-HT data packets when tuned to HT20.

Kismet will detect and tune to HT40 channels when available; to disable this, set ht_channels=false on your source definition.

Kismet will automatically disable HT channels on some devices which are known to have problems tuning to HT channels; if your device has trouble tuning to HT channels, or you simply don’t want to tune to HT channels when the capability is seen, specify ht_channels=false.

See the vht_channels option for similar control over 80MHz and 160MHz VHT channels.

Kismet will detect and tune to VHT (80MHz and 160MHz) channels when available; to disable this, set vht_channels=false on your source definition.

Kismet will automatically disable HT channels on some devices which are known to have problems tuning to VHT channels; if your device has trouble tuning to VHT channels, or you simply don’t want to tune to VHT channels when the capability is seen, specify vht_channels=false.

See the ht_channels option for similar control over 40MHz HT channels.

Added 2022-08-git

Enable only channels in the 2.4GHz band.

This can be combined with band5ghz=true and band6ghz=true.

By default, Kismet enables all channels it discovers on all bands. By specifying a specific band, Kismet will only enable channels on the selected bands.

Example:

# Source0 enables 2.4ghz channels only.
source=wlan0:name=Source0:band24ghz=true 
# Source1 enables 5ghz and 6ghz channels only.
source=wlan1:Name=Source1:band5ghz=true,band6ghz=true

Added 2022-08-git

Enable only channels in the 5GHz band.

This can be combined with band24ghz=true and band6ghz=true.

By default, Kismet enables all channels it discovers on all bands. By specifying a specific band, Kismet will only enable channels on the selected bands.

Example:

# Source0 enables 2.4ghz channels only.
source=wlan0:name=Source0:band24ghz=true 
# Source1 enables 5ghz and 6ghz channels only.
source=wlan1:Name=Source1:band5ghz=true,band6ghz=true

Added 2022-08-git

Enable only channels in the 6GHz band.

This can be combined with band24ghz=true and band5ghz=true.

By default, Kismet enables all channels it discovers on all bands. By specifying a specific band, Kismet will only enable channels on the selected bands.

Example:

# Source0 enables 2.4ghz channels only.
source=wlan0:name=Source0:band24ghz=true 
# Source1 enables 5ghz and 6ghz channels only.
source=wlan1:Name=Source1:band5ghz=true,band6ghz=true

Typically, Kismet will override the timestamp of the packet with the local timestamp of the server; this is the default behavior for remote data sources, but it can be turned off either on a per-source basis or in kismet.conf globally.

Generally the defaults have the proper behavior, especially for remote data sources which may not be NTP time synced with the Kismet server.

Linux mac80211 drivers use virtual interfaces or VIFs to set different interface modes and behaviors: A single Wi-Fi card might have wlan0 as the “normal” (or “managed”) Wi-Fi interface; Kismet would then create wlan0mon as the monitor-mode capture interface.

Typically, all non-monitor interfaces must be disabled (set to down state) for capture to work reliably and for channel setting (and channel hopping) to function.

In the rare case where you are attempting to run Kismet on the same interface as an access point or client, you will want to leave the base interface configured and running (while losing the ability to channel hop); by setting ignoreprimary=true on your Kismet source line, Kismet will no longer bring down any related interface on the same Wi-Fi card.

This almost always must be combined with setting channel_hop=false for this source, because channel control is not possible in this configuration, and depending on the Wi-Fi card type, may prevent proper data capture.

Many drivers use virtual interfaces or VIFs to control behavior. Kismet will make a monitor mode virtual interface (vif) automatically, named after some simple rules:

• If the interface given to Kismet on the source definition is already in monitor mode, Kismet will use that interface and not create a VIF
• If the interface name is too long, such as when some distributions use the entire MAC address as the interface name, Kismet will make a new interface named kismonX
• Otherwise, Kismet will add mon to the interface; ie given an interface wlan0, Kismet will create wlan0mon

Use the vif= option to set a specific name for the VIF. It will be created if it does not exist.

Automatically detect all local interfaces and build a BPF filter to exclude them from the capture. This is most useful for remote capture instances which are connected over wireless. The filter can only exclude the first 8 devices found, because of limits in the kernel memory buffer for BPF filtering.

This can not be combined with other filter options like filter_mgmt

Use a kernel-level BPF filter to filter out all packets except 802.11 management and EAPOL (WPA handshake) packets.

Enabling this filter will drastically reduce the amount of processing power required for Kismet, however it will exclude all other data packets. Wireless APs and clients will be visible, however wired/bridged clients will not, and data-based statistics like bandwidth will not be available, however beacon-based statistics like QBSS reports will be retained.

This feature is used by the wardrive-mode overlay.

Use a kernel-level BPF program to truncate 802.11 data frames, except for EAPOL (WPA handshake) data frames.

This sets the capture size of the packet to the end of the 802.11 headers, allowing for the data counting functions in Kismet to continue working as expected. The data component of all packets will be lost, and not logged to the pcap, kismetdb, or other logs.

This will disable any WIDS alerts that rely on the data content of packets (such as the DHCP alerts).

Enabling this filter will drastically reduce the amount of bandwidth required for remote capture, will reduce the size of logs significantlty, and will reduce the overall processing requirement of Kismet, at the cost of comprehensive data content in the logs.

802.11 Wi-Fi networks have three basic packet classes - Management, Phy, and Data. The Phy packet type is the shortest, and contains the least amount of information - it is used to acknowledge packet reception and controls the packet collision detection CTS/RTS system. These packets can be useful, however they are also the most likely to become corrupted and still pass checksum.

Kismet turns off processing of Phy packets by default because they can lead to spurious device detection, especially in high-data captures. For complete tracking and possible detection of hidden-node devices, it can be set to ’true’ but this generally results in a large number of bogus device detections.

Wi-Fi packets contain a frame checksum or FCS. Some drivers report this as the FCS bytes, while others report it as a flag in the capture headers which indicates if the packet was received correctly.

Generally packets which fail the FCS checksum are garbage - they are packets which are corrupted, usually due to in-air collisions with other packets. These can be extremely common in busy wireless environments.

Usually there is no reason to set this option unless you are doing specific research on non-standard packets and hope to glean some information from corrupted packets.

Setting this option may remove the ability to identify corrupt packets.

Some drivers have the ability to report data that looked like a packet, but which have invalid radio-level packet headers (the Wi-Fi PLCP which is not typically exposed to the capture layer). Generally these events have no meaning, and few drivers are able to report them.

Usually there is no good reason to turn this on, unless you are doing research attempting to capture Wi-Fi-like data.

Setting this option may remove the ability to identify corrupt packets.

Added 2019-07-git

Turn on verbose error reporting and warnings; this will raise alerts when channel operations take an extended period of time or if a channel fails to set correctly.