Kismet

Kismet 2011-01-R1Mike Kershaw http://www.kismetwireless.net

1. What is Kismet2. Upgrading from earlier versions3. Quick start4. Suidroot & security5. Capture sources6. Caveats & quirks for specific drivers7. Supported capture sources8. Plugins9. GPS10. Logging11. Filtering12. Alerts & IDS13. Server configuration options14. Kismet UI15. Kismet drones16. Talking to Kismet17. Troubleshooting18. Frequently asked questions

1. What is Kismet

Kismet is an 802.11 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wi reless card which supports raw monitoring mode, and can sniff 802 .11b, 802.11a, 802.11g, and 802.11n traffic (devices and drivers permit ting).

Kismet also sports a plugin architecture allowi ng for additional non-802.11 protocols to be decoded.

Kismet identifies networks by passively collect ing packets and detecting networks, which allows it to detect (and given time, expose the names of) hidden networks and the presence of non-bea coning networks via data traffic.

2a. Upgrading from recent versions

2009-06-R1 has changed some basic behavior when using multi-vap capable devices (ie, modern in-kernel Linux drivers). Whenever possible, it will create a new VAP and reconfigure it, inste ad of modifying the existing interface. To preserve the old behavi or, specify 'forcevap=false' on the source line.

2b. Upgrading from Kismet-old versions

This release marks a MAJOR change in how Kismet works and is configured. While many aspects are similar, many others (th e client, configuring sources and channels, etc) are very different.

To take advantage of the new features, replace your existing configuration files with the latest configurati on data. Most notably: * Sources are defined differently. See the "C apture Sources" section. * All UI configuration is handled inside the K ismet client and stored in the users home directory in ~/.kismet/kis met_ui.conf

* Most situations which were previously fatal conditions which caused Kismet to exit can now be recovered from. * New filtering options * New alert options * Completely new UI * Revamped network protocol * Significantly less CPU used for high numbers of networks * Plugins

While this release breaks almost everything fr om previous releases, it opens the door for smoother upgrades and major feature enhancements.

3. Quick start

PLEASE read the full manual, but for the impati ent, here is the BARE MINIMUM needed to get Kismet working:

* Download Kismet from http://www.kismetwireles s.net/download.shtml * Run "./configure". Pay attention to the outp ut! If Kismet cannot find all the headers and libraries it needs, major functionality may be missing. Most notably, compiling Kismet y ourself will require the development packages and headers, usually called foo-dev or foo-devel. * Make sure that all the functionality you need was enabled properly in configure. Almost all users will need pcap a nd libnl support for proper operation. * Compile Kismet with "make". * Install Kismet with either "make install" or "make suidinstall". YOU MUST READ THE "SUID INSTALLATION & SECURI TY" SECTION OF THE README OR YOUR SYSTEM MAY BE INSECURE. * If you have installed Kismet as suid-root, ad d your user to the "kismet" group

* Run "kismet". If you did not install Kismet with suid-root support, you need to start it as root in nearly all si tuations. This is not recommended as it is less secure than privsep mode, where packet processing is segregated from admin rights. * When prompted to start the Kismet server, cho ose "Yes" * When prompted to add a capture interface, add your wireless interface. In nearly all cases, Kismet will autodetect t he device type and supported channels. If it does not, you will have to manually define the capture type (as explained later in this README) * Logs will be stored in the directory you star ted Kismet from, unless changed via the "logprefix" config file or "- -log-prefix" startup option.

* READ THE REST OF THIS README. Kismet has a l ot of features and a lot of configuration options, to get the most out of it you should read all of the documentation.

3b. Windows quick start

* Note, at the time of this writing, the update d CACE install is not yet * available, so users wishing to take advantage of the newcore * functionality will need to build Kismet thems elves in Cygwin

Using the CACE Package:

* Download the Win32/Cygwin installer created b y CACE and linked from

the download page (http://www.kismetwireless. net/download.shtml * Run the installer * Start Kismet * Pick your AirPcap or Kismet Drone sources

* READ THE READ OF THIS README.

Compiling it yourself:

* Download the Cygwin setup tool (http://www.cy gwin.org) * Install Cygwin with make, GCC, libncurses, li bncurses-dev * Download the Airpcap_Devpack from CACE Suppor t * Put Airpcap_Devpack and Libpcap_Devpack in th e kismet source directory * Run "./configure", adding the options: --with-airpcap-devpack=... --with-winpcap-d evpack=... --enable-airpcap The airpcap/winpcap devpack is available from the CACE website. Due to bugs in Cygwin, it appears that the ai rpcap and winpcap directories must be inside the kismet source directory. If they are not, the Kismet binary will immediately exit with no output. * Compile Kismet with "make". * Install Kismet with "make install"

NOTE: KISMET WILL **ONLY** WORK WITH THE CACE A IRPCAP DEVICE, SAVED PCAP FILES, -OR- REMOTE KISMET DRONES RUNNING ON A S UPPORTED PLATFORM. NO OTHER HARDWARE IS SUPPORTED IN WINDOWS, PERIOD. WINDOWS DRIVERS DO NOT INCLUDE SUPPORT FOR WIFI MONITORING WHICH KISME T REQUIRES. THERE IS NO WAY TO CHANGE THIS.

3c. OSX/Darwin quick start

* Please note: Many have complained that iTerm does not send correct key events. However, Terminal.app appears to work fine, and is recommended for using Kismet.

* Download Kismet from http://www.kismetwireles s.net/download.shtml * Run "./configure". Pay attention to the outp ut! If Kismet cannot find all the headers and libraries it needs, major functionality may be missing. Notably, you may need to install libpcap manually.

The libpcap included with OSX does not suppor t PPI logging. Kismet will not be able to log to PPI correctly (so it will log 802.11 packets with no per-packet headers.)

Configure will automatically detect OSX and d efault to the group "staff" for OSX suidinstall. This may be ove rridden with the '--with-suidgroup' configure option.

* Compile Kismet with "make". * Install Kismet with either "make install" or "make suidinstall". YOU MUST READ THE "SUID INSTALLATION & SECURI TY" SECTION OF THE README OR YOUR SYSTEM MAY BE VULNERABLE. * If you have installed Kismet as suid-root, ad d your user to the "staff" group if it is not already.

* Run "kismet". If you did not install Kismet with suid-root support, you need to start it as root in nearly all si tuations. This is not recommended as it is less secure than privsep mode, where packet processing is segregated from admin rights.

* When prompted to start the Kismet server, cho ose "Yes" * When prompted to add a capture interface, add your wireless interface. In nearly all cases, Kismet will autodetect t he device type and supported channels. If it does not, you will have to manually define the capture type (as explained later in this README)

For many Macs, this will be 'en1', however st art a terminal and check the output of "ifconfig -a".

The wireless interface must be enabled in the wireless control panel for Kismet to work, otherwise it will not fin d any networks.

Kismet currently ONLY works with the Airport wireless devices, NOT USB WIRELESS DEVICES. * Logs will be stored in the directory you star ted Kismet from, unless changed via the "logprefix" config file or "- -log-prefix" startup option.

* READ THE REST OF THIS README

4. Suidroot & Security

In order to configure the wireless card for mon itor mode and start capturing packets, Kismet needs root access. T here are two ways to accomplish this: Start Kismet as root, or inst all it so that the control components are set to start as root.

Starting Kismet as root means that Kismet will continue running as root. In theory this presents no additional risk, how ever if there are any flaws in the Kismet packet dissection code then it may be possible for a malicious packet to cause code execution as roo t. Additionally, third-party plugins will run as root, and may n ot be secure.

Installing Kismet as suid-root creates a limite d-functionality binary (kismet_capture) which is only launchable by me mbers of the "kismet" group. Kismet uses this to configure cards and control the channels, while packet decoding happens only in the user component, significantly limiting the attack surface.

Distributions are strongly encouraged to use th is method as it allows standard group controls for what users can use Kismet to change card states.

Embedded systems typically have much less stora ge space and RAM, and often do not enforce user/root separation as st rictly due to these limitations. On embedded systems, Kismet may b e installed without the kismet_capture binary and run in root mode only , however the above risks still apply.

Under no situation should the kismet_server bin ary itself be set suidroot as this will bypass any security check s.

5. Capture sources

All packets in Kismet come from a capture sourc e. Capture sources are typically network cards on the local system, ho wever they can also be a previously recorded file or a remote capture sy stem running a Kismet drone.

Kismet will, in most cases, autodetect the driv er and supported channels for a capture source given only the network int erface. For many users this will be sufficient, however many expanded options are available for capture sources.

Kismet captures packets at the 802.11 layer. T his requires changing the mode of the network interface, making it unavai lable for normal use. In most cases it is not possible to remain associa ted to a wireless network while running Kismet on the same interface.

Capture sources may be added via the Kismet UI under the "Add Source" option, in which case the options may be added under the "Options:" field, comma separated. They may also be defin ed in the kismet.conf configuration file as the "ncsource=" option, s uch as: ncsource=wlan0:option1=foo,option2=bar

Source options: name=foo Custom name for the source (otherwise it will be named the same as the capt ure interface). This is completely arbitrary and m eaningful only to the user. type=foo Sources which can not autod etect the type must have the type specified. This is rarely necessary. Additional information on supported source types follows. uuid=foo Users wishing a static uniq ue identifier on sources may specify one here. Thi s is not necessary for most users. UUID is of th e format: XXXXXXXX-XXXX-XXXX-XXXX- XXXXXXXXXXXX hop=true|false Disable channel hopping on this source. Default behavior is for channel so urces to hop channels to cover the entire spectrum. velocity=# Channel hop velocity (numbe r of channels per second), Kismet can hop 1- 10 channels per second. dwell=# Channel dwell time, the num ber of seconds Kismet will wait on each channel. If hopping is enabled and a channel dwell time i s specified, Kismet will hop at N seconds per chann el, instead of N channels per second. channellist=name Use an alternate channel li st instead of the autodetected list of chann els supported by this interface. The channellis t must be defined. split=true|false When multiple sources use t he same channel list (either autodetected or by the channellist= option) Kismet will split them so that they do not cover the same channels at the same time. Sources can be forced to ignore this and begin hopping at the beginning of the channel l ist regardless of overlap. retry=true|false Kismet will attempt to re-o pen a capture source which has encountered an e rror. This behavior can be disabled if the user wa nts the source to remain closed. vap=interface Create a secondary named in terface for capture instead of trying to chang e the mode of the existing interface. This is primarily only for use by drivers using the mac80 211 interface under Linux. Users wishing to d o Kismet+Managed or Kismet+Injection should cr eate a vap. forcevap=t|f True/False. Force creation of a monitor-mode VAP

when possible (all Linux m ac80211 based drivers support this). Default is "true", a VAP will be made of the name 'mon', ie 'wlan0mon', 'wlan1mon' and capture wil l be done with this VAP. This behavior can be force d OFF with 'forcevap=false'. wpa_scan=time When using a mac80211 VAP, Kismet can use wpa_supplicant on a manage d interface to trigger hardware assisted scans, e nabling some view of the rest of the spectrum witho ut significantly disrupting operation of th e managed VAP. Suggested time for scan intervals is 15 seconds. validatefcs=t|f True/False. Kismet normall y will not bother trying to validate the FCS checks um of incoming packets because most drivers only report valid frames in the first place. Packet s ources which report invalid frames by default will enable this option automatically. If the dri vers have been manually configured to report inval id packets, this should be specified to prevent Ki smet from processing broken packets. fcs=true|false Force handling of FCS bytes on a packet source. Default is "false", which implies "native FCS handling". Packet sources which include per-packet headers like radiotap or P PI will ignore this value as the FCS is encoded in t he radio header. Packet sources such as pcapfile, reading raw 802.11 pcap files with no headers, may need this turned on for proper behavior. fcsfail=true Force a mac80211 VAP to rep ort packets with a known bad FCS (packet checksum). This is only available on Linux and only when usi ng mac80211 drivers. This MUST come after a 'va p=' option or it will be ignored. Enabling 'fcsfai l' will enable 'validatefcs' automaticall y. The 'fcsfail' option should only be enabled whe n logging to PPI; Logging to normal PCAP will not pr eserve the FCS data and will produce unreadable ou tput. WARNING: With some driver versions, enabling this seems to cause kernel OOPS warnings and the interface will become unre sponsive if capture is stopped and resume. This option is for specific expert use only, when in d oubt, leave it alone. plcpfail=true Force a mac80211 VAP to rep ort packets which do not pass the PLCP check (if po ssible on that interface). The same warn ings and conditions as 'fcsfail' apply. This opt ion is for specific, expert use only, when in d oubt, leave it alone.

Example sources (these are given as config file parameters, however they will work equally well as command-line options, ie "-c wlan0"): Capture on wlan0, channel 6, don't channel ho p ncsource=wlan0:hop=false,channel=6

Capture on wlan0, 802.11b channels only even if it supports 5GHz ncsource=wlan0:channellist=IEEE80211b

Create a VAP on wlan0 named wlan0mon and use wpa_supplicant to give us some view of other channels, while re maining associated to a

network: ncsource=wlan0:vap=wlan0mon,hop=false,wpa_sc an=15

Read from a pre-recorded pcap file: ncsource=/home/foo/old.pcap

Capture using the first Airpcap device on Win dows ncsource=airpcap

Capture using a remote capture drone ncsource=drone:host=10.10.100.2,port=2502

Channel lists:

Channel lists control the channels and patterns hopped to by capture sources in Kismet, when the channels can not be autodetected (or when the user wishes to override them for some reaso n). The default channel lists (IEEE80211b, IEEE80211a, and IEEE80211ab) are used only when a channel list is not provided by the driver, so should not be changed in most cases.

When the channel list is automatically created from the channels supported by the driver, the preferredchannels= option will control which channels are weighted for extra time. By setting this to channels known to be defaults (such as 1, 6, 11) or chan nels with known networks of interest (such as in a stationary install), Kismet will devote more time to those channels to gather more informati on. For more complex channel timing, keep reading about how channel lists work.

Channels can typically be specified as IEEE cha nnels (11, 36, etc) or as frequencies (2401, 5200) however some pla tforms and drivers may not support specifying channels or frequencies out of the IEEE standard range.

channellist=name:channel,channel,channel

Additionally, individual channels in the list c an be weighted so that more time is spent on them; for a weighting val ue of 3, 3x more time is spent on that channel.

channellist=foo:1:3,6:3,11:3,2,3,4,5,6,7,8,9,10

Up to 256 channels may be specified in a channe l list. For greater numbers of channels, a range must be specified.

Ranges may consist of channels or of frequencie s.

channellist=name:range-[start]-[end]-[overlap]- [iteration]

Channels between start and end, at a given iter ation. Kismet will not hop directly between channels that overlap.

channellist=foo:range-1-11-3-1

A similar range using frequencies (802.11 2.4GH z channels are ~20MHz wide; technically 22 but 20 suffices, and 5 MHz apart).

channellist=foo:range-2412-2462-20-5

Ranges are NOT split between sources. Multiple sources hopping on the same channel list which includes a range will n ot split the expanded range - in other words, channel ranges are trea ted as a single channel entry.

Multiple ranges can be specified in a single ch annel list, separated by commas. They may also be mixed with channels:

channellist=foo:range-1-11-3-1,36,52

6. Caveats and quirks for specific drivers:

Mac80211 General (Linux):

At the time of this release, the mac80211 dri vers in Linux are undergoing significant development, which mea ns at any given time they can exhibit extremely odd behavior or be outr ight broken. Users are encouraged to upgrade to the latest kernel, a nd to consider installing the compat-wireless backport package, if prob lems are experienced.

Madwifi (Linux):

Madwifi-ng has been largely deprecated by ath 5k/ath9k for normal usage. These drivers support multi-vap more cleanly via the mac80211 layer and do not, typically, have the same pr oblems historically present in madwifi. Madwifi-ng sources can be specified as either the VAP (ath0, mon0, etc) or as the control interface (wifi0, wifi 1). However, IF THE CONTROL INTERFACE IS SPECIFIED, Kismet cannot extract the list of supported channels, and will default to IEEE8 0211b channels.

Madwifi-ng continues to have problems with mu lti-vap and initial vap creation. It is recommended that the initial VAP creation be turned off by the module parameter "autocreate=none" whe n loading ath_pci. If the madwifi monitor vap stops reporting packets s oon after being created, this is often the cause.

Combining managed and monitor VAPs appears to still not work well.

RT28xx (Linux)

There are 2 drivers for the RT28xx chipsets. The in-kernel driver available as of Linux-2.6.31 works properly w ith Kismet. This is by far the preferred driver to use. Be sure to enable the RT28xx driver in the wireless drivers section, NOT the stag ing driver. The staging driver is not mac80211 based and will not nec essarily behave.

The out-of-kernel driver does not conform to mac80211 controls. This driver also cannot be auto-detected (the y don't provide a valid identifier in /sys) so the driver type mus be manually specified with 'type=rt2870sta' on the source line.

This driver defaults to the name 'rausbX' whi ch exposes a bug in some versions of libpcap and may require the devic e be renamed (See 'Troubleshooting' section)

rt73-k2wrlz (Linux)

An out-of-tree rt73 driver similar to rt2870s ta. It may be necessary to specify a type of 'rt73' manually when usi ng this driver.

This driver defaults to the name 'rausbX' whi ch exposes a bug in some versions of libpcap and may require the devic e be renamed (See 'Troubleshooting' section)

WL (Linux, Intel)

Broadcom has released a binary version of the ir drivers called WL. These drivers are incapable of monitor mode, and cannot be used with Kismet. Kismet will attempt to autodetect th em and report this to the user. Users of Broadcom cards should use the b43 or b43xx in-kernel drivers.

OTUS (Linux)

Atheros released a driver for the 802.11n USB devices; however, this does not have support for monitor mode and ca nnot be used with Kismet. The ar9170 driver project is providing mac802 11 kernel support for this card, and works with Kismet. ar9170 has been merged with the wireless-git development kernel and should be present in the compat-wireless packages.

Nokia ITT (Linux)

For any chance of Kismet working on the Nokia ITT, the scan interval must be set to zero in the Nokia system contr ol panel, connectivity section. It should be disconnected from any network, but wireless must be turned on.

The Nokia drivers often return FCS-invalid pa ckets. The Nokia source line should include 'fcs=true,validatefcs=tru e' to prevent these from creating multiple false networks out of inval id packets.

The Nokia device does not autodetect properly , a driver type of 'nokia770', 'nokia800', 'nokia810', or 'nokia itt' must be set. 'nokiaitt' is a generic source which should w ork on any Nokia ITT tablet.

Orinoco (Linux)

Due to problems in monitor mode with newer fi rmwares, the Orinoco kernel drivers have disabled monitor mode for newer/ "modern" firmware versions in the Orinoco cards.

Kismet will attempt to use the device, but wa rn the user that it will probably fail. Monitor support can be forced on in the module via the module parameter "force_monitor=1" when loadi ng orinoco.ko.

For non-hermes chipsets like prism2, use host ap (also in the kernel).

NDISWrapper (Linux)

The NDIS-Wrapper driver loads Windows drivers into the Linux network stack. These drivers are not capable of moni tor mode, and will not work with Kismet.

Note: The rndis drivers are NOT the same as ndiswrapper. rndis

drivers are for a specific USB chipset and ar e not related to ndiswrapper, rndis will work.

BSD (BSD Generic)

Cards which work under the generic BSD framew ork for monitor mode with radiotap headers should work with Kismet via the source types "radiotap_bsd_ag", "radiotap_bsd_a", "radiota p_bsd_g", and "radiotap_bsd". Channel detection and device type autodetection are currently not supported.

ncsource=wl0:type=radiotap_bsd_ag

Windows (Generic)

ONLY THE AIRPCAP DEVICE IS SUPPORTED UNDER WI NDOWS. THIS IS A SPECIFIC HARDWARE DEVICE MADE BY CACE TECHNOL OGIES. IF YOU DID NOT GO AND BUY AN AIRPCAP SPECIFICALLY FOR CAPTURING DATA, YOU DO NOT HAVE ONE, AND THIS WILL NOT WORK.

The Airpcap has monitor mode drivers with a * public* interface for controlling them. This is the only device Ki smet can capture packets from on Windows.

AirPcap (Windows)

By default Kismet will open the first Airpcap device found. Multiple devices can be opened by using the full named interface, which can be found in the AirPcap tools but follows the pa ttern \\.\airpcapXX ; The first device is \\.\airpcap00, the second is \\.\airpcap01, and so on.

USB Devices (OSX)

Only devices using the Airport IOKit drivers are supported on OSX. USB devices are, in general, not supported be cause the drivers lack monitor mode or a method to set the channel.

7. Supported capture source types

Capture source types are only required in speci fic situations where Kismet cannot detect the capture source type au tomatically.

Linux Capture Sources:

All modern drivers on Linux use the mac80211 driver framework. Kismet will auto-detect any driver using this framew ork. A generic source type 'mac80211' can be used for forcing a typ e, however it is not strictly useful to do so.

adm8211 Kernel adm8211 driver acx100 Kernel acx100 driver hostap Kernel prism2 driver ipw2100 Kernel Intel 2100 driver ipw2200 Kernel Intel 2200 driver ipw2915 Kernel Intel 2915 driver ipw3945 Kernel intel 3945 driver mac80211 Generic mac80211 catch-all source for any mac80211 drivers. madwifi Madwifi/Madwifi-ng

madwifi_a Alias for madwifi, default 802.11a channels madwifi_b Alias for madwifi, default 802.11b/g channels madwifi_g Alias for madwifi, default 802.11b/g channels madwifi_ag Alias for madwifi, default 802.11abg channels nokia770 Conexant-based driver in No kia Maemo tablets nokia800 Alias for nokia770 nokia810 Alias for nokia770 nokiaitt Alias for nokia770

pcapfile Pcap-formatted previously r ecorded file rt2870sta Out-of-kernel/Staging rt287 0 11n driver (use in-kernel instead) wl12xx Patched wl12xx drivers for the N900, must use patched drivers from http: //david.gnedt.eu/blog/, otherwise autodetected. drone Remote Kismet packet captur e, source options "host=..." and "port=..." a re required. ncsource=drone:host=localho st,port=2502

BSD Capture Sources:

Currently, the BSD packet capture sources do not support autodetection or channel detection.

Capture on BSD should work with any driver wh ich supports monitor mode and which uses the standard BSD IOCTLs to set the mode and channel.

Patches/Additional BSD support welcome.

radiotap_bsd Generic BSD capture source, default 802.11b/g channels radiotap_bsd_g Default 802.11b/g channels radiotap_bsd_a Default 802.11a channels radiotap_bsd_ag Default 802.11abg channels

pcapfile Pcap-formatted previously r ecorded file drone Remote Kismet packet captur e, source options "host=..." and "port=..." a re required.

Windows Capture Sources:

Currently ONLY THE AIRPCAP DEVICE, PCAP FILE, AND DRONES RUNNING ON A SUPPORTED PLATFORM are supported under Window s. NO OTHER DEVICES CAN BE USED FOR PACKET CAPTURE.

airpcap Airpcap generic source. Wi ll autodetect the channel ranges. Interface 'airpcap ' will detect the first airpcap device (ncsource=ai rpcap), interface paths may be used to specify spec ific devices (ncsource=\\.\airpcap01) airpcap_ask List available sources and ask which one to use. Should NOT be used when lau nched by the Kismet UI.

pcapfile Pcap-formatted previously r ecorded file drone Remote Kismet packet captur e, source options "host=..." and "port=..." a re required.

OSX/Macintosh Capture Sources: darwin Any device controlled by th e Airport IOKit drivers under OSX. Default 802.11b /g channels.

pcapfile Pcap-formatted previously r ecorded file drone Remote Kismet packet captur e, source options "host=..." and "port=..." a re required.8. Plugins

Kismet plugins can do almost anything that the native Kismet process can do. This includes extending the logging capabi lity, adding IDS alerts, defining new capture sources (within some limit ations), and adding new features to the Kismet UI.

Plugins need access to the Kismet source (and c onfiguration information) to compile, and should ALWAYS be r ecompiled when the Kismet version changes (for those using Kismet- SVN development code, this may require rebuilding plugins every time a checkout is done).

Plugins bundled with Kismet (and third-party pl ugins extracted into the Kismet source dir) can be built with 'make plug ins' and installed with 'make plugins-install' or 'make plugins-userins tall'. These commands will automatically configure the plugin to comp ile using the current Kismet source directory, for third-party plugin s compiled outside of the tree (or for manually compiling plugins), the K IS_SRC_DIR variable must be set or the symlinks to the Kismet source mus t be set up properly (see the README for the plugin you are trying to com pile for more information).

Plugins for the Kismet server (capture and logg ing process) are loaded from the system-wide plugin directory (/usr/loc al/lib/kismet/ by default) or from the users Kismet settings dire ctory (~/.kismet/plugins).

When running Kismet with privilege separation e nabled (installed kismet_capture as root), plugins are only loade d by the Kismet server process and not the root-level Kismet capture p rocess, and plugins cannot perform tasks that require root privileg es.

When running Kismet without privilege separatio n (launching as root), plugins run with root privileges. This is not recommended.

Server plugins are only loaded when kismet.conf contains: allowplugins=true

Client plugins are loaded from the system-wide plugin directory (/usr/local/lib/kismet_client by default) or fr om the users Kismet settings directory (~/.kismet/client_plugins).

The Kismet UI provides mechanisms for loading p lugins (and specifying plugins to be loaded automatically on startup) via the Plugins menu item.

Once a Kismet UI plugin is loaded, it cannot be unloaded. To unload a Kismet plugin, go to the Plugins window, config ure the plugin to not load on start, and restart Kismet. To configur e plugin loading in the UI, select the plugin (the list is automaticall y generated from plugins installed in the system and user plugin directo ries) and press enter. Plugins will be loaded when the plugin window i s closed.

Kismet server plugins cannot currently be manip ulated via the Kismet UI, but loaded plugins will be displayed.

If a plugin causes startup problems (most likel y because it was compiled for a different Kismet binary), Kismet will exi t and explain which plugin caused the crash during startup. Plugin s may also cause instability during runtime; if runtime crashes occur while plugins are loaded, remove them and re-test. Often, recomp iling the plugins against the running Kismet source will help resolve the se issues.

9. GPS

Kismet can integrate with a GPS device to provi de coordinates for networks it has detected. These can be logged to the pcap file when PPI logging is enabled, and to an XML file for proc essing with Kismap, included with the Kismet source, as well as other third- party tools.

Kismet can use the GPS network daemon 'gpsd', o r can parse NMEA directly from the GPS unit.

The GPS is controlled with the Kismet server co nfig, kismet.conf. For using gpsd with gpsd running on the local syste m:

gps=true gpstype=gpsd gpshost=localhost:2947 gpsmodelock=false gpsreconnect=true

By specifying gpsreconnect, if gpsd crashes or Kismet otherwises looses its connection, it will be re-established. Gps modelock compensates for certain broken GPS/GPSd combinations, where the GPS never reports a valid lock. By forcing a gpsmodelock=true, Kis met assumes the GPS always has a 2d lock.

For using a GPS device without gpsd:

gps=true gpstype=serial gpsdevice=/dev/ttyS0 gpsreconnect=true

The gpsdevice parameter should be set to the pr oper serial device for your GPS. For USB GPS devices this will typica lly be /dev/ttyUSB0, and for bluetooth devices this will often by /dev/r fcomm0 or similar. Check the output of "dmesg" after plugging in your de vice.

Kismet cannot know the location of a network, i t can only know the location where it saw a signal. By circling t he suspected location, you can provide more GPS data for processing th e network center point.

Kismet keeps running averages of the network lo cation, however this is not incredibly accurate, due to averaging and i mprecision in floating point math. For plotting network loca tions, the GPSXML file should be used.

10. Logging

By default Kismet will log the pcap file, gps l og, alerts, and network log in XML and plaintext.

By default, Kismet will try to log to pcapfiles using the PPI per-packet

header. The PPI header is a well-documented he ader supported by Wireshark and other tools, which can contain sp ectrum data, radio data such as signal and noise levels, and GPS data.

PPI is only available with recent libpcap versi ons. When it is not available, Kismet will fall back to standard 80 2.11 format with no extra headers.

The pcap logging format is controlled by: pcapdumpformat=ppi or pcapdumpformat=80211

The naming of logfiles is controlled by the "lo gtemplate" configuration option. By default, Kismet logs in the directo ry it is started in (unless modified with the "--log-prefix" option ).

The following variables can be used in the logt emplate: %p Prefix (as given by --log-prefix) %n Logging name (as given by --log-tit le) %d Starting date, Mmm-DD-YYYY %D Starting date, YYYYMMDD %t Starting time, HH-MM-SS %i Incremental, in the case of multipl e logs of the same name %l Log type (pcapdump, netxml, etc) %h Home directory of the user Kismet w as started as

The default log template with a --log-prefix of /tmp and a --log-title of Kismet would expand from: logtemplate=%p%n-%D-%t-%i.%l to (for example): /tmp/Kismet-20090428-12-45-33-1.pcapdump

Nested directories may be used (for example, wi th a template of the form "%p/%l/%D-%t"), however they must be created pr ior to starting Kismet, Kismet will not create the directories itself.

Most users should never need to change the logt emplate, however the option remains available. When changing the te mplate, be sure to include the "%p" prefix option in a logical loc ation (ie, at the beginning of the template) or else the --log-pr efix argument will not function as expected.

11. Filtering

Kismet supports basic filtering; networks can b e excluded from tracking, pcap logging, or general logging, based on BSSI D, source, or destination MAC addresses.

Filters, when enabled, are "positive-pass"; any thing matched by the filter will be allowed, and all other matches a re excluded. To process ONLY packets to or from the network with the BS SID AA:BB:CC:DD:EE:FF:

filter_tracker=BSSID(AA:BB:CC:DD:EE:FF) This behavior can be inverted by using the '!' operator. To exclude packets to or from the BSSID AA:BB:CC:DD:EE:FF:

filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF)

Multiple MAC addresses can be stacked on the sa me filter line, to filter two all packets from AA:BB:CC:DD:EE:FF and 00:1 1:22:33:44:55:

filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF,!00 :11:22:33:44:55)

MAC addresses may also be masked in a fashion s imilar to IP netmasks; to process only networks of a single manufacturer:

filter_tracker=BSSID(AA:BB:CC:00:00:00/FF:F F:FF:00:00:00)

Similarly, SOURCE(...), DEST(...), and ANY(...) may be used to filter packets. To process only packets FROM the MAC address 11:22:33:44:55:66:

filter_tracker=SOURCE(11:22:33:44:55:66)

12. Alerts & IDS

Kismet includes IDS functionality, providing a stateless and stateful IDS for layer 2 and layer 3 wireless attacks. Kismet can alert on fingerprints (specific single-packet attacks) a nd trends (unusual probes, disassociation floods, etc).

Kismet can integrate with other tools using the tun/tap export to provide a virtual network interface of wireless traffic; tools such as Packet-o-Matic and Snort can use this exported data to perform additional IDS functions.

Kismet as an IDS is most effective in a station ary (ie, non-wardriving) setup, and for best results, a non-hopping sour ce should be available on the channels the primary networks are on. Kism et IDS functions CAN be used in mobile or channel-hopping installations (and are turned on by default) but accuracy may suffer.

Alerts are configured with the "alert=" configu ration option in kismet.conf, and have two time parameters: Thr ottle, and Burst. The throttle option controls how many alerts are al lowed total per time unit, while the burst option controls how many alerts are allowed in a row. For example:

alert=NETSTUMBLER,5/min,1/sec

Will allow 1 alert per second, at a maximum of 5 per minute.

Kismet supports the following alerts, where app licable the WVE (Wireless Vulnerability and Exploits, http://www.wve.org) ID is included:

AIRJACKSSID Fingerprint Dep recated The original 802.11 hacking tools, Airj ack, set the initial SSID to 'airjack' when starting up. This al ert is no longer relevant as the Airjack tools have long since be en discontinued.

APSPOOF Fingerprint A list of valid MAC addresses for a SSI D may be given via the 'apspoof=' configuration file option. If a beacon or probe response for that SSID is seen from a M AC address not in that list, this alert will be raised. This can be used to detect conflicting access points, spoofed acce ss points, or attacks

such as Karma/Airbase which respond to all probe requests.

The 'apspoof=' configuration option can specific exact SSID matches, regular expressions (if Kismet is compiled with PCRE support), and single, multiple, or mask ed MAC addresses: apspoof=Foo1:ssidregex="(?i:foobar) ",validmacs=00:11:22:33:44:55

apspoof=Foo2:ssid="Foobar", validmacs="00:11:22:33:44:55,AA :BB:CC:DD:EE:FF"

When multiple MAC addresses are specifi ed, they should be enclosed in quotes (as above).

For more information about forming PCRE -compatible regular expressions, see the PCRE docs (man pcr epattern).

BSSTIMESTAMP Trend/Stateful Invalid/Out-of-sequence BSS Timestamps can indicate AP spoofing. APs with fluctuating BSS timestamps cou ld be suffering an "evil twin" spoofing attack, as many tools do not attempt to sync the BSS timestamp at all, and the fine-grai ned nature of the BSS timestamp field makes it difficult to s poof accurately. Some APs may reset the BSS timestamp regular ly, leading to a false-positive.

References: WVE-2005-0019

CHANCHANGE Trend/Stateful A previously detected access point chan ging channels may indicate a spoofing attack. By spoofin g a legitimate AP on a different channel, an attacker can lure clients to the spoofed access point. An AP changing channel d uring normal operation may indicate such an attack is in proce ss, however centrally managed networks may automatically chan ge AP channels to less-used areas of the spectrum.


CRYPTODROP Trend/Stateful Spoofing an AP with less-secure encrypt ion options may fool clients into connecting with compromise d credentials. The only situation in which an access point shou ld reduce encryption security is when the AP is reconfigured .

DEAUTHFLOOD Trend/Stateful BCASTDISCON Trend/Stateful By spoofing disassociate and deauthenti cate packets an attacker may disconnect clients from a network, causing a denial-of-service which lasts only as l ong as the attacker is able to send the packets.

References: WVE-2005-0019, WVE-2005-0045, WVE-2 005-0046, WVE-2005-0061 http://802.11ninja.net http://home.jwu.edu/jwright/papers/ l2-wlan-ids.pdf

DHCPCLIENTID Fingerprint

A client which sends a DHCP DISCOVER pa cket containing a Client-ID tag (Tag 61) which doesn't ma tch the source MAC of the packet may be doing a DHCP denial-of-se rvice to exhaust the DHCP pool.

DHCPCONFLICT Trend/Stateful Clients which receive a DHCP address an d continue to use a different IP address may indicate a mis configured or spoofed client.

DISASSOCTRAFFIC Trend/Stateful A client which is disassociated from a network should not immediately continue exchanging data. This can indicate a spoofed client attempting to incorrectl y inject data into a network, or can indicate a client being the victim of a denial-of-service attack.

DISCONCODEINVALID Fingerprint DEAUTHCODEINVALID Fingerprint The 802.11 specification defines valid reason codes for disconnect and deauthenticate events. Various client and access point drivers have been reported to imp roperly handle invalid/undefined reason codes.

DHCPNAMECHANGE Trend/Stateful DHCPOSCHANGE Trend/Stateful The DHCP configuration protocol allows clients to optionally put the hostname and DHCP client vendor/ope rating system in the DHCP Discover packet. These values should o nly change if the client has changed drastically (such as a dual -boot system). Changing values can often indicate a client spoo fing/MAC cloning attack.

LONGSSID Fingerprint The 802.11 specification allows a maxim um of 32 bytes for the SSID. Over-sized SSIDs are indicative of an attack attempting to exploit vulnerabilities in several d rivers.

LUCENTTEST Fingerprint Dep recated Old Lucent Orinoco cards in certain sca nning test modes generate identifiable packets.

MSFBCOMSSID Fingerprint Some versions of the Windows Broadcom w ireless drivers do not properly handle SSID fields longer than the 802.11 specification, leading to system compro mise and code execution. This vulnerability is exploited by the Metasploit framework.


MSFDLINKRATE Fingerprint Some versions of the Windows D-Link wir eless drivers do not properly handle extremely long 802.11 v alid rate fields, leading to system compromise and code execution . This vulnerability is exploited by the Metasploit framework.


MSFNETGEARBEACON Fingerprint Some versions of the Windows netgear wi reless drivers do not properly handle over-sized beacon frame s, leading to system compromise and code execution. This vu lnerability is exploited by the Metasploit framework.

NETSTUMBLER Fingerprint Dep recated Older versions of Netstumbler (3.22, 3. 23, 3.30) generate, in certain conditions, specific packets.

NULLPROBERESP Fingerprint Probe-response packets with a SSID IE t ag component of length 0 can cause older cards (prism2, orinoco, airport-classic) to fail.


PROBENOJOIN Trend/Stateful Active scanning tools such as Netstumbl er constantly send network discovery probes but never join any of the networks which respond. This alert can cause ex cessive false positives while channel hopping, and is disabled by default.

13. Other Configuration

Kismet is divided into two main processes: kis met_server and kismet_client. The server portion (responsible for capture, logging, and decoding) is controlled by kismet.conf (by default in /usr/local/etc) and the client is configured vi a preferences options.

For the most part, Kismet can run with no addit ional configuration by adding capture sources runtime with the UI, how ever for standalone/headless operation or advanced confi guration, users will want to edit the config file.

The Kismet config is a plain text file with opt ion=value pairs. Lines beginning with # are considered comments and ar e ignored.

Most configuration options are self-explanatory or documented in the config file itself.

By default Kismet only listens to the loopback interface on port 2501. This may be changed:

listen=tcp://ip:port Define the IP and port Kismet listens on. By default, for security reasons, Kismet will listen only on 127.0. 0.1, the loopback interface. To listen on any inte rface, use the IP 0.0.0.0. allowedhosts=... Comma-separated list o f IP addresses allowed to connect to the Kismet server. IP ranges may be specified with netmas ks (ie 10.10.10.0/24) maxclients=N Maximum number of clie nts allowed to simultaneously connect to the Kismet server. maxbacklog=5000 Maximum number of back logged "lines" the server keeps for clients whi ch are not keeping up with the network prot ocol. This also affects the amount of RAM pot entially used by the Kismet server process , and may need to be

lowered on extremely RAM-limited systems.

Kismet servers may also be configured to act as Kismet drones, exporting a TCP stream of live packets:

dronelisten=.. Same as above, for dro ne capabilities droneallowedhosts=.. ... dronemaxclients=.. ... droneringlen=65535 Equivalent of maxbackl og for Kismet clients, maximum amount of spa ce used for backlogged packets as a drone. May be reduced on extremely RAM-limited systems.

Kismet can export packets directly to other too ls by creating a virtual network interface (supported on Linux, minimal support on OSX and BSD due to limited tuntap driver implementations on these platforms):

tuntap_export=true Enable tuntap export tuntap_device=kistap0 Virtual network interf ace created

Kismet can decrypt WEP networks for which the W EP key is already known:

wepkey=bssid,hexkey

Only the hex key can be given, since there is n o consistent method to turn a pass-phrase into a hex key for WEP for d ifferent vendors.

Sound and speech can be generated by the Kismet server, however typically this would be done by the Kismet UI i nstead. Sound is disabled by default in the Kismet server:

enablesound=true|false Play sound soundbin=... Path and options fo r sound player binary sound=xxx,true|false Enable playing soun d trigger xxx

enablespeech=true|false Speak speechbin=... Text-to-Speech play er speechtype=raw|festival If using Festival ( but NOT flite) speech type must be set t o 'festival', all other tools should be se t to 'raw' speechencoding=... NATO, Spelling, Spe ech. Encoding of speech fields for clarity , spell network SSIDs as NATO, spelled-out letters, or speak them normally. speech=xxx,"format" Format of spoken st rings, see the Kismet UI section for more i nformation on formatting of speech strings.

The OUI file (used by Kismet to determine the m anufacturer of a device) can be shared with other tools (such as Wiresha rk), so long as they use a compatible format. By default, Kismet search es: /etc/manuf /usr/share/wireshark/wireshark/manuf /usr/share/wireshark/manuf Additional search paths can be added with the ' ouifile=' configuration option.

14. Kismet UI

The default Kismet UI uses the text-based ncurs es library. Additional UIs may be available from the Links page on the Kismet website (http://www.kismetwireless.net/links.shtml)

The Kismet UI functions much as any other curse s application (such as Midnight Commander or Links) does. The menu is activated with 'escape', '`' or '~'. Navigation between elements of the UI is done with 'tab'.

Use of a mouse is supported in much of the Kism et UI, although not all widgets fully support mouse operation. Basic u se of the UI with no keyboard should be reasonable, however.

The main Kismet window consists of the network list, GPS information, a summary of the current server statistics and packet source status, and the status panel where errors and announcements are printed. Additional components of the main window may be turned on with the 'View' menu.

- Preferences

Configuration of the Kismet UI is done entirely inside the UI via the 'Kismet->Preferences->...' menus. Preference c hanges are (for the most part) immediate and do not require restarting.

By default, the Kismet UI will prompt on startu p to launch the Kismet server, this behavior (as well as auto-connecti on and server setup) can be changed via the Startup and Shutdown prefere nces (Kismet->Preferences->Startup and Shutdown):

Open Kismet server launch window automatica lly - Kismet will open the server startup w indow when the UI is loaded, if the default server is not running. Ask about launching server on startup - Ask to start a server (instead of jus t opening the server window) Show Kismet server console by default - Automatically open the Kismet server console window after starting the server Shut down Kismet server on exit automatical ly - Kill locally started servers and issu e a shutdown command to remote servers when the UI exits Prompt before shutting down Kismet server - Don't kill servers without confirming

Kismet menus support shortcuts, for example '~W l' is the same as navigating to the 'Windows->Client List' menu o ption.

- Sound and Speech

The Kismet UI handles sound and speech playing for most users. Sound playing is straightforward (WAV files are insta lled, by default, to /usr/local/share/kismet/wav) and can be played with any sound player compatible with your install.

Speech is supported on Festival and Flite. Any other text-to-speech program should work as long as it accepts plain text on standard in. Speech text is encoded depending on the type of speech event, where %1, %2, etc are replaced with data by Kismet. The supp orted events and replacements are: New network:

1. Network SSID encoded to speech encod ing setting (spell, nato, plain) 2. Network channel 3. Network BSSID Alert: 1. Alert type GPS Lost, GPS Lock: No replacement options

- Tagging networks

Kismet can add custom data to a network in the form of tags. In the Kismet UI, networks and clients can both have t ags added to them. These tags are displayed in the UI under network deta ils, and logged to XML and TXT output.

Tags can be set as permanent; By checking the " Remember note when restarting Kismet" checkbox in the Network and Client Note windows, the note is saved and will be re-applied to network s every time Kismet loads.

Client tags are applied to a specific client in a specific network; Currently there is no mechanism for adding a no te to every instance of the client.

- Sorting

Kismet defaults to "autofit" mode, where it tri es to put as many of the currently active networks on the screen as poss ible. Because autofit mode is so variable, it doesn't make sense to t ry to allow selecting networks in autofit.

To select a network and view details, first sor t by another method (such as channel, time, etc) via the Sort menu, then select a network.

15. Kismet Drones

Kismet Drones are designed to turn Kismet into a distributed IDS system. Drones support all of the capture methods Kisme t normally supports, including multiple capture devices per drone. Drones capture wireless data and forward to a Kismet server over a seco ndary connection (ie, wired Ethernet). Drones do not do any decoding of packets and have minimal hardware requirements.

A Kismet server connects to the drones and will provide a single Kismet UI display, packet dump, and alert generation p oint. Capture sources on remote Kismet drones are forwarded to the Kisme t server and appear as independent capture devices which can be config ured for channel hopping, locking, etc.

Using the tun/tap export function, the central Kismet server can export the packets from all attached drones to a virtu al network interface for use with external IDS/packet capture systems (s uch as Snort).

To start using Drones, launch the kismet_drone process on a remote system (editing the kismet_drone.conf file to c ontrol what hosts are allowed to connect) or turn on drone capabiliti es in the Kismet server (by enabling the drone config options in kismet _server.conf). When running a kismet_server instance as a drone, lo cal logging will act as

usual and Kismet clients can be connected to th e server as normal; When running kismet_drone, Kismet clients cannot con nect directly to it, and it will not log, a Kismet server instance must be started to provide packet decoding, logging, and Kismet UI connect ivity.

16. Talking to Kismet

The Kismet client/server protocol is basic text . Communicating with Kismet can be as simple as using telnet or netc at, however writing a full protocol dissector is suggested for seriou s applications.

This documents a simple case of the Kismet prot ocol and the basics of communicating with a Kismet server, however for detailed information the source should be consulted. A more complete do cumentation of the protocol will be done at some point.

The Kismet protocol consists of commands and re sponse sentences. A command is of the form:

!ID COMMAND OPT1 OPT2 OPT3

Where ID is a number (which for proper erro r detection should be unique) and the remainder of the arguments are the command and any options it may take.

Options which contain spaces but should be treated as a single argument should wrap those options in "\001 ...\001"

And a response sentence is of the form: *HEADER: f1 f2 f3 f4

Where HEADER is the sentence type, and the remainder are fields requested by the client, in the order they were requested.

Fields are expected to be plain ASCII text, however a client should take precautions to be sure that the value is sane for the terminal before printing it.

Fields which may contain a space (used as t he separator character) are buffered with \001...\001. As this cou ld be any field, any protocol parser should be able to handle fi elds so buffered.

Basic Kismet commands include:

!{#} SHUTDOWN Shutdown Kismet instance

!{#} CAPABILITY {Sentence} Query the accept fields for a protocol. Returns the *CAPABILITY sentence

!{#} ENABLE {Sentence} {Fields}|{*} Enable a sentence, with either the prov ided fields and order, or all fields in the default order if * is specified.

!{#} REMOVE {Sentence} Remove a sentence. Stop sending a sent ence.

!{#} ADDNETTAG {BSSID} {Permanent} {Tag nam e} {Tag content} Add an arbitrary tag to a network. If permanent, it will be cached in ~/.kismet/tags.conf

!{#} DELNETTAG {BSSID} {Tag name} Remove a tag

!{#} ADDCLITAG {BSSID} {MAC} {Permanent} {T ag} {Content} Add tag to specified client in network

!{#} DELCLITAG {BSSID} {MAC} {Tag} Remove a tag

!{#} ADDSOURCE {source line} Add a source dynamically. Source line should be of the same format as a 'ncsource=' config line

Protocol sentences:

When a sentence is enabled, any existing se ntence data is sent (at the discretion of the protocol handlers). Additional data is sent in the form of deltas; To conserve bandwidt h and processing time, only instances where the data has changed a re sent. For example, when the *BSSID sentence is sent, a block o f *BSSID records are sent, for all networks previously detected by Kismet. Until the sentence is disabled, a record is sent once per second for each network which has changed in some fashion ( new packets).

Mandatory sentences:

Kismet expects a client to support AT LEAST the following mandatory protocols, which are enabled by default. A t the very least, any client should ignore these if it does not p rocess them. They may be disabled with the REMOVE command. In gener al, any client should ignore protocols it does not understand.

*KISMET Basic Kismet startup info *PROTOCOLS List of supported sentences *ACK Command response *ERROR Command failure *TIME Server timestamp

Example:

echo -e '\n!0 enable channel channel,networ ks' | nc localhost 2501

Enable the *CHANNEL sentence with the field s 'channel' and 'networks'. The output could look somethin g like:

*ACK: 0 OK *CHANNEL: 1 4 *CHANNEL: 3 1 *CHANNEL: 4 1 *TIME: 1245176426

17. Troubleshooting

Congratulations! You're actually reading the t roubleshooting section of the README! Many don't.

If you are having trouble getting Kismet to cap ture packets at all, launch kismet_server independently of the clien t and watch the output, it may be easier to spot problems then.

Some common problems with Kismet have easy solu tions:

PROBLEM: Fatal errors about old configuration files/missing config values Kismet has evolved over time, and has recently had a significant rewrite of the entire app lication, rendering many of the old configuration values obsol ete, and changing many others. FIX: Update your config files. If you are moving to the latest release of Kismet, it may be best to just remove your old config files, copy the new ones, and reconfigure.

PROBLEM: Kismet crashes immediately while star ting up FIX: If you are building Kismet from SVN r outinely, it's possible that the build system has gotten scre wed up with a recent change. Run 'make distclean' then '. /configure' and 'make' again. If the kismet_capture binary is out-of-sync with the kismet_server or kismet_drone binarie s, things will behave oddly.

PROBLEM: Kismet shows FATAL errors about permi ssion denied FIX: Are you trying to capture from a netw ork interface without root privileges? Kismet must either be installed as suid-root (and the user starting it must be in the kismet group) or it must be started as root, see the "Sui d Root & Security" section of the README.

PROBLEM: Kismet can not autodetect my card typ e or doesn't understand the "type=..." source option. FIX: Some drivers do not register with the /sys filesystem and can not be properly autodetected. Check the list of capture sources known to be problematic in th is README. Secondly, check the output of './conf igure' when building Kismet and make sure that support for your capture type is present, most commonly support for pc ap or wext is missing.

PROBLEM: Kismet warns about interfering proces ses while starting up. Many network services can interfere w ith Kismet (DHCP, networkmanager, etc) by reconfiguring or shutting down the network interface while Kismet is run ning. FIX: Only necessary if Kismet is not behav ing as expected, or encountering errors. Shutdown or kil l the offending processes. This can often be most qu ickly accomplished by stopping the networking services for your interface ('ifdown wlan0' for example). In some specifi c configurations, these alerts may be spurious (dhcp and wpa_ supplicant alerts on a multi-vap mac80211 interface doing st a+rfmon with a wpa_supplicant scanning option, for e xample).

PROBLEM: Kismet complains about multiple VAPs under madwifi-ng FIX: Destroy the other VAPs, or ignore thi s warning if there are no run-time failures. Madwifi-ng has hi storically had significant problems with multi-vap a nd rfmon (for example, a STA VAP and a RFMON VAP).

PROBLEM: Shortly after starting on madwifi-ng, Kismet stops reporting packets. FIX: There appears to be a race condition in madwifi-ng startup where an autocreated VAP causes error s in future VAPs. A temporary fix is to reload the madwif i-ng driver before starting Kismet, with the 'autocreate =none' modparm ('rmmod ath_pci; modprobe ath_pci autocreate= none'), a more permanent fix is to put this in the default mod ule parameters for ath_pci and make the necessary change s to your startup scripts to create a managed VAP on startup.

PROBLEM: './configure' is unable to find libpc ap, wext, ncurses, pcre, or some other library when building f rom source. FIX: Many distributions separate the runti me data from the data necessary to compile programs against a library. Install the '-dev' or '-devel' or 'devel-' packag es for each of the libraries ('apt-get install libpcap-d ev' for example)

PROBLEM: Kismet exits immediately on Cygwin wi th no output. FIX: Cygwin appears to have problems linki ng static libraries when they are not in a sub-directory of th e build. By default, './configure' will look in "Airpcap_D evpack" and "Winpcap_Devpack", you should probabl y just expand the devpack zips there.

PROBLEM: I can't capture on (some device that isn't an AirPCAP that I bought from CACE) on Windows! FIX: Buy an AirPCAP and read the docs.

PROBLEM: I can't see some parts of the Kismet UI FIX: Some terminals have bad default color assignments and render dark grey as black. Go into the Kism et color preferences and change the items.

PROBLEM: A plugin crashes Kismet (server or UI ) FIX: Recompile the plugin and make sure it 's build with the same code as the Kismet server/client. Th is is especially problematic if you are following Kism et development in SVN.

PROBLEM: Kismet makes the mouse slow or crashe s the whole system FIX: This isn't actually Kismet. Only the kernel layer should be able to cause the system to lockup or crash, or interfere with interrupts so badly that the mouse be comes unresponsive. Kismet may exacerbate this behavior b y changing the card configuration and exposing flaws in t he driver; This most often can happen while changing chann els, try disabling channel hopping (or slowing it down), and upgrade to the latest drivers for your device.

PROBLEM: Kismet cannot open a source, with the error: "can't get usb bus index" FIX: Some versions of LibPcap interpret an y interface with "USB" in the name as a USB device on Linux, and attempt to do USB

bus capture instead of packet capture . Rename the interface (with ifrename o r udev rules) to something that doesn't include 'usb'. A newer version of libpcap may also resolve this problem .

PROBLEM: configure cannot find libnl on Ubuntu , but libnl-dev is installed FIX: Some distributions (apparently, Ubunt u) require libnfnetlink-dev to be installed as w ell. Currently there is no good way to autodetect this.

18. Frequently Asked Questions

Q: Where did the name Kismet come from? A: 'Kismet' means 'Fate' or 'Destiny'; While I wish I could take credit for some plan about picking it for Kismets a bility to uncover any network in the area, I really just needed a name and clicked through a thesaurus until I found a word that wasn't used in any other OSS projects.

Q: Is there anything illegal about Kismet? A: In and of itself, there should be nothing il legal about Kismet (it's fundamentally no different than any other ca pture tool) but you should check your local laws first. Note, h owever: - Recording data from networks that you do not have permission to may be considered an illegal wiretap. - Using networks you do not have permission to use may be considered 'Theft of Service' and is illegal. - Don't be stupid. - If you are stupid, I'm not responsible.

Q: Can Kismet crack WEP? A: Yes, but also, no. The base Kismet code doe s not do any WEP cracking, however due to constant requests, there IS an Aircrack-PTW plugin which will do PASSIVE WEP cracking on ly. It will NOT do arp-replay, fragmentation, or other active a ttacks, however if enough packets are gathered it will attempt to crac k the WEP key and insert it into Kismet to decrypt that network. The PTW-WEP cracking plugin is in the Kismet source tree in the plugin-ptw/ directory.

Q: What's the deal with Newcore, and where did it go? A: Newcore was a total rewrite of Kismet, which lasted years longer in a development state than planned. If you're r eading this, you've got the release that Newcore became already.

Q: What happened to the version numbers? A: They stopped making sense. 3.0 to 3.1 was a 30,000 line change, but calling it 4.0 didn't make any sense either. I hate project perpetually in 0.1, 0.9 status, but I also h ate artificially expanding the version numbers. So, now, it' s versioned by the release date, YYYY-MM-RR.

Q: Can I use the old Kismet UI still? A: No, sorry, too much has changed in the proto cols, and the new UI is much more flexible anyhow

Q: Can I use the old drones still? A: No, again, too much has changed (however fro m now on it should be

possible to mix versions since the drone pro tocol has been expanded to be expandable)

Q: What is RFMON/Monitor mode? A: In the wired world, promiscuous mode turns o ff the filtering mechanism in the device and reports all pack ets on the Ethernet (or whatever) layer. With wireless drivers, this doesn't necessar ily mean anything (sometimes it causes different results, some times it doesn't). Wireless drivers present a fake Ethernet dev ice to the operating systems, which reports only 802.11 data fram es. When looking at WPA encrypted networks, this is even more limite d, because packets are encrypted for each client and only multicast /broadcast packets or packets destined to the capture device could be reported as valid data frames anyhow. Monitor/RFMON mode is a special mode for wir eless devices which reports all packets the card sees, with the 802.11 headers intact, including 802.11 management and control fram es.

Q: Does Kismet work differently than NetStumble r? A: Absolutely. Netstumbler (and Ministumbler, InSSIDer, etc) work by instructing the card to probe for networks a nd report the networks the card sees responses from. This method i s obviously competent at detecting networks in the area, however it c an't record data, find hidden networks, detect clients using networ ks, etc.

Q: Why are some probe SSIDs full of strange non sense characters? A: It appears with Windows Zero Config in many versions of Windows XP has an off-by-one error which leaks a little bit of memory into a probe request.

Q: Why is the range of a network sometimes tota lly bogus when using a GPS with Kismet? A: Doing real-time GPS averaging leads to incre asingly bad data due to floating-point accuracy and averaging. For more exact GPS data, process the gpsxml file.

Q: What happened to gpsmap? A: gpsmap was the old mapper code for Kismet. It stopped being useful a long time ago when the map sources it used w ent away. It's being replaced with a tile-based mapper, the begin nings of which are in the kismap/ directory in the source code. K ismap isn't quite finished for the RC1 release, but developmen t continues on it and it will be available hopefully soon.

Q: How can I merge multiple capture files? A: Use the 'mergecap' tool that comes with Wire shark.

Q: How can I support device X with Kismet on op erating system Y? A: Kismet is designed to be fairly modular (esp ecially the newest versions based on Newcore). So long as your environment is something like Posix and your device supports raw capt ure modes, it should be possible. Swing by IRC (#kismet on freenode ) and chat.

Q: Why does Kismet make a new interface named f oo-mon? A: When mac80211 is available, Kismet will use to create a new virtual interface, named after the existing interfac e (wlan0 for instance will cause a wlan0mon to be created). Kisme t will use this virtual interface for capture, so that it causes les s disruption to the

configuration of the existing interface.

Q: What happens when I ask a question already h ere? A: I'll probably be rude to you (or someone els e will). But that would never happen, because everyone reads the doc s all the way to the end, right? Right!?

Documents

Kismet