Kismet
A wireless network and device detector, sniffer, wardriving tool, and WIDS (wireless intrusion detection) framework
What is kismet?
Kismet is a monitoring tool for wireless - originally only supporting 802.11 Wi-Fi, with the right hardware Kismet can now capture Bluetooth advertisements, BTLE, nRF-based wireless mice and keyboards, weather stations, wireless thermometers, switches, smoke detectors, 802.15.4 / Zigbee, ADSB airplane transponders, AMR wireless power, water meters, gas meters, and more.
Passive monitoring
Kismet operates almost entirely passively, with a few exceptions (such as Bluetooth scanning mode) noted in the documentation for those capture types.
Kismet is not an attack tool (generally) - to test your Wi-Fi security check out tools like Aircrack-NG or the Wi-Fi Pineapple.
Kismet is largely focused on collecting, collating, and sorting wireless data. The logs generated by Kismet can be fed into other tools (the pcap, handshakes, and other data) like hashcat, aircrack, and more.
Device-oriented display
Kismet is different from Wireshark; Kismet primarily focuses on representing devices - access points, clients, bridged wired devices, sensors, Bluetooth entities, and so on, while Wireshark focuses on displaying a deep dive of specific packets and all the content.
Kismet and Wireshark work best when used together - Kismet collects packets and logs them to standard formats (pcap and pcapng) or the kismetdb format which can be converted directly to pcap and pcapng, and collects location, changes over time, etc, while Wireshark can open the pcap logs and give extensive detailed information about specific packets. Each tool is designed for a different job, but operate together.
Source and more info: https://www.kismetwireless.net/docs/readme/intro/
Wi-Fi Channels
Wi-Fi channels in Kismet define both the basic channel number, and extra channel attributes such as 802.11N 40MHz channels, 802.11AC 80MHz and 160MHz channels, and non-standard half and quarter rate channels at 10MHz and 5MHz.
Kismet will auto-detect the supported channels on most Wi-Fi cards. Monitoring on HT40, VHT80, and VHT160 requires support from your card.
Channels can be defined by number or by frequency.
xx
Basic 20MHz channel, such as 6
or 153
xxxx
Basic 20MHz frequency, such as 2412
XXHT20
20MHz HT20 channel, such as 6HT20
XXXXHT20
20MHz frequency, such as 2412HT20
xxHT40+
40MHz 802.11n with upper secondary channel, such as 6HT40+
xxHT40-
40MHz 802.11n with lower secondary channel, such as 6HT40-
xxVHT80
80MHz 802.11ac channel, such as 116VHT80
xxVHT160
160MHz 802.11ac channel, such as 36VHT160
xxW10
10MHz half-channel, a non-standard channel type supported on some Atheros devices. This cannot be automatically detected, you must manually add it to the channel list for a source.
xxW5
5MHz quarter-channel, a non-standard channel type supported on some Atheros devices. This cannot be automatically detected, you must manually add it to the channel list for a source.
Datasource: Linux Wi-Fi
Most likely this will be the main data source most people use when capturing with Kismet.
The Linux Wi-Fi data source handles capturing from Wi-Fi interfaces using the two most recent Linux standards: The new netlink/mac80211 standard present since approximately 2007, and the legacy ioctl-based IW extensions system present since approximately 2002.
Packet capture on Wi-Fi is accomplished via βmonitor modeβ, a special mode where the card is told to report all packets seen, and to report them at the 802.11 link layer instead of emulating an Ethernet device.
The Linux Wi-Fi source will auto-detect supported interfaces by querying the network interface list and checking for wireless configuration APIs. It can be manually specified with type=linuxwifi
Last updated
Was this helpful?