Kismet 2007-01-R1 Mike Kershaw http://www.kismetwireless.net Licensed under the GPL 1. What is Kismet 2. Quick Start 3. Feature Overview 4. Typical Uses 5. Upgrading From Previous Versions 6. Suidroot & Security 7. Required Libraries & Utilities 8. Compiling 9. Configuration 10. Panels Interface 11. Operating Systems 12. Capture Sources 13. Graphical Network Mapping 14. Drone Remotes 15. Intrusion Detection 16. Reporting Bugs 17. Troubleshooting 18. Frequently Asked Questions 1. What is Kismet Kismet is an 802.11 layer2 wireless network detector, sniffer, and intrusion detection system. Kismet will work with any wireless card which supports raw monitoring (rfmon) mode, and can sniff 802.11b, 802.11a, and 802.11g traffic. Kismet identifies networks by passively collecting packets and detecting standard named networks, detecting (and given time, decloaking) hidden networks, and infering the presence of nonbeaconing networks via data traffic. 2a. Quick Start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM needed to get Kismet working: * Download Kismet from http://www.kismetwireless.net/download.shtml * Run ``./configure''. Pay attention to the output! If Kismet cannot find all the headers and libraries it needs, it won't be able to do many things. * Compile Kismet with ``make'' * Install Kismet with either ``make install'' or ``make suidinstall''. YOU MUST READ THE SECTION OF THIS README NAMED "SUID INSTALLATION & SECURITY" OR YOUR SYSTEM MAY BE MADE VULNERABLE!! * Edit the config file (standardly in "/usr/local/etc/kismet.conf") * Set the user Kismet will drop privileges to by changing the "suiduser" configuration option. * Set the capture source by changing the "source" configuration option. FOR A LIST OF VALID CAPTURE SOURCES, SEE THE SECTION OF THIS README CALLED "CAPTURE SOURCES". The capture source you should use depends on the operating system and driver that your wireless card uses. USE THE PROPER CAPTURE SOURCE. No permanent harm will come from using the wrong one, but you won't get the optimal behavior. * Add an absolute path to the "logtemplate" configuration option if you want Kismet to always log to the same directory instead of the directory you start it in. * Run ``kismet''. You may need to start Kismet as root. * READ THE REST OF THIS README 2b. Windows Quick Start PLEASE read the full manual, but for the impatient, here is the BARE MINIMUM method to get Kismet running: * Download the Win32/Cygwin Installer created by CACE * Run the installer * Start Kismet * Pick your AirPcap or Kismet Drone sources * READ THE REST OF THIS README KISMET WILL ONLY WORK WITH THE CACE AIRPCAP DEVICE OR REMOTE KISMET DRONES IN WINDOWS. NO OTHER CARDS ARE SUPPORTED, PERIOD. DO NOT ASK IF KISMET WILL WORK WITH THEM ON WINDOWS, IT WILL NOT. THIS LIMITATION IS CAUSED BY THE LACK OF SNIFFER-MODE CAPABLE DRIVERS ON WINDOWS. 3. Feature Overview Kismet has many features useful in different situations for monitoring wireless networks: - Ethereal/Tcpdump compatible data logging - Airsnort compatible weak-iv packet logging - Network IP range detection - Built-in channel hopping and multicard split channel hopping - Hidden network SSID decloaking - Graphical mapping of networks - Client/Server architecture allows multiple clients to view a single Kismet server simultaneously - Manufacturer and model identification of access points and clients - Detection of known default access point configurations - Runtime decoding of WEP packets for known networks - Named pipe output for integration with other tools, such as a layer3 IDS like Snort - Multiplexing of multiple simultaneous capture sources on a single Kismet instance - Distributed remote drone sniffing - XML output - Over 20 supported card types 4. Typical Uses Common applications Kismet is useful for: - Wardriving: Mobile detection of wireless networks, logging and mapping of network location, WEP, etc. - Site survey: Monitoring and graphing signal strength and location. - Distributed IDS: Multiple Remote Drone sniffers distributed throughout an installation monitored by a single server, possibly combined with a layer3 IDS like Snort. - Rogue AP Detection: Stationary or mobile sniffers to enforce site policy against rogue access points. 5. Upgrading from Previous Versions Upgrading to Kismet 2007-01-R1: Make sure to either update your kismet.conf file from the one included in the distribution, or to copy the new ALERT enable lines. If you do not copy the ALERT setup from the new config, new IDS alerts will not be enabled. 6. Suidroot & Security In order to configure the wireless card for rfmon and start the packet capture, Kismet needs root access. As soon as root access is no longer required, Kismet drops to a designated user so that potentially hostile remote data isn't processed as root. When priv dropping is enabled, Kismet forks and leaves a single process as root. This process is used for channel control and for restoring card settings on exit. The root process performs no interaction with user input, and only communicates with the base kismet_server via IPC pipes. For Kismet to have root access, it can be installed two different ways: - Normal installation via 'make install' requires Kismet be started as root. - Suid-root installation via 'make suidinstall'. DO NOT INSTALL KISMET SUID-ROOT IF YOU HAVE OTHER USERS ON YOUR SYSTEM. Suid-root installation will allow unprivileged users to set the wireless card to rfmon (breaking any connections using wireless) and capture data. REMEMBER: Installing Kismet suid-root is NOT SECURE ON MULTIUSER SYSTEMS. Most users of Kismet are likely using single-user laptops or handhelds, where suidroot is very convenient. If you have ANY OTHER USERS ON YOUR SYSTEM, suidroot Kismet can be used to shut down the wireless and put files where you don't want to allow them to be put. If you have other users on your system, install kismet normally and 'su' to root before starting it. 7. Required Libraries & Utilities Kismet is primary self-contained, however for some features it requires some external libraries or utilities. For distributions which provide split library packages of somelib and somelib-devel, you will need both installed for Kismet to compile. - LibPcap (0.9+ preferred): http://tcpdump.org/ REQUIRED for the majority of packet capturing systems LibPcap provides the common capture system Kismet uses to read from most Posix-style interfaces. Without LibPcap, Kismet will be all but useless on most platforms. - GPSD (any version): http://russnelson.com/gpsd/ REQUIRED for GPS support GPSD is a daemon which listens on a serial port for GPS data, parses it, and makes it available via a TCP socket. Kismet can use a GPSD on the local system, or if there is a wired ethernet connection available it can use a GPS on a remote host. The latest versions of GPSD fix compile issues which occurred on some systems and it's highly reccomended you get the latest. GPSDrive distributes an alternate version of GPSD, which should work with Kismet. - Imagemagick (5.4.7+): http://www.imagemagick.org/ REQUIRED for gpsmap map generation Imagemagick is a graphics generation library which can read and write in almost any format. Kismet requires a recent version of Imagemagick due to IM's frequently changing API. If you do not plan to use gpsmap, you can skip this library. - Expat (1.95+): http://expat.sourceforge.net/ REQUIRED for gpsmap map generation Expat is an XML processing library. Kismet requires this for parsing netxml and gpsxml output logs. If you do not plan to use gpsmap, you can skip this library. Some versions of Expat included in distributions or other system utilities (ie, XFree86-cvs) contain errors that make it impossible to compile expat.h. Make sure you have the latest stable Expat version, and remove offending duplicate headers if necessary. - GMP: http://www.swox.com/gmp/ REQUIRED for gpsmap map generation GMP is an arbitrary-precision math library. Kismet needs this for high precision math functions when calculating graphics in gpsmap. If you do not plan to use gpsmap, you can skip this. - Ethereal (any): http://www.ethereal.com REQUIRED for wtapfile capture replay Ethereal is the premier packet dissector. The packet dump logs Kismet creates can be opened in Ethereal for further examination. Kismet uses libwiretap from Ethereal for saving packet dump files and replaying stored dumps, however Kismet has a builtin dump writer and can replay pcap files using libpcap. Kismet requires a compiled copy of the Ethereal source available to link the libwiretap library. By default the configure script will look in /usr/src/ for this. If you do not need to replay compressed dumps or dumps with other encodings (such as Airopeek), you don't need wtapfile. 8. Compiling Compiling should be fairly straightforward. It uses the normal configure scripts found in most open-source projects, and should build with any modern version of gcc. 1. Download any libraries and external utilities needed 2. Run './configure' with any special options you want (see './configure --help') 3. Run 'make' or 'gmake' 4. Run 'make install' or 'make suidinstall' - SEE THE SECURITY SECTION OF THE README BEFORE INSTALLING KISMET SUIDROOT! IF YOU INSTALL SUIDROOT ON A SYSTEM WITH UNTRUSTED USERS, BAD THINGS CAN HAPPEN. Crosscompiling Kismet can sometimes have problems with the libpcap autoconf scripts not being able to detect the kernel type and version of the target system. Overriding the configuration script variables and passing extra configuration options can fix this: 'ac_cv_linux_vers=foo ./configure --with-pcap=linux ...' FreeBSD users should configure kismet to use the systemwide pcap, which supports multiple DLT types, with --enable-syspcap 9. Configuration Kismet is controlled by 2 primary configuration files: kismet.conf controls the server backend, and kismet_ui.conf controls the panels user interface. By default, these files are in /usr/local/etc/. Remote drone servers use a third file, kismet_drone.conf. Kismet configuration files are a simple 'directive=value' format. Basic server configuration: 1. Set up the target suiduser. This is the user that Kismet will drop to after it sets the cards in monitor mode and attaches to them. See the section 'Suidroot & Security' for more information. If this is not set correctly, Kismet won't start. This is controlled by the 'suiduser' directive. 2. Set up the capture sources. Most users will only need one, but it is possible to have any number of sources defined which will be combined into a single packet log. Sources are defined with the 'source' directive. Source lines are defined with 'source=type,interface,name[,channel]'. See the section 'Capture Sources' for a list of source types. The name can be anything that is useful for you to identify what source it is. The initial channel is optional. If an initial channel is requested on the command line it will take precedence. 3. Set up channel hopping. The default channel hopping values will probably be fine for most, but the speed of channel hopping can be set with the 'channelvelocity' directive and the lists of channels to be hopped can be set with 'defaultchannels'. Additional per-source fine-grained channel hopping control is available via the 'sourcechannels' directives, which are explained in the configuration file comments. Channel dwelling (similar to hopping) can be set with the channeldwell option. Setting a channel dwell time controls the number of seconds between channel change, compared to the tenths of a second defined by channelvelocity. Most users will want to use channel hopping, but remember - just like it's impossible to see all of a program while channel surfing on TV, channel hopping means missing some of the data on the network. 4. Set up what clients are allowed to connect. By default this is limited to 'localhost', which is fine for most users. 5. Set the log template. By default, Kismet writes logs to the directory it is started in. By putting a full path into the 'logtemplate' directive you can force it to write them to another location (such as a directory guaranteed to be writeable by the target suiduser). Client configuration: 1. Set the host and port. By default, Kismet is configured to connect to the localhost and standard port. 2. Set columns to be displayed. The default set should be fine for most but it can be changed/expanded. Columns can be scrolled in the client with the arrow keys. 3. Set a sound player. For most, 'play' from Sox (the default) should be fine. If you use a sound daemon such as esd or ksd you will need to change the play command to call esdplay or similar. 4. Configure speech (or not). Kismet can write to Festival for speaking information about networks. 5. Customize colors. Most components of the Kismet panels UI can be colorized. The annoying popup window that opens every time you start the client can be disabled by setting 'showintro' to 'false' in your kismet_ui.conf. More advanced server configuration: * To allow Kismet clients from remote hosts to connect, comment out the bind_addr field to default to INADDR_ANY (all network interfaces). * IDS alert rates can be controlled via the 'alert' directive, which specifies the alert type, rate per timeframe (ie, 5/min), and the burst rate per timeframe (ie, 1/sec). These controls are similar to the iptables limit controls. * Networks with known WEP keys can be decrypted in realtime with the 'wepkey' directive, which specifies a BSSID (or bssid mask) and the WEP key. * Runtime filtering of packets is controlled by the 'filter_tracker', 'filter_dump', and 'filter_export' directives, which influence which packets are processed at all, logged to dump files, and logged to xml/csv/etc files, respectively. See the sub-section "Filtering Syntax" in this section for more information on filtering. * Including subconfig files. By using 'include=...' other files can be included into the Kismet config, with filtering, WEP keys, etc. * MAC address masking. Nearly any directive which takes a MAC address (such as filters, WEP keys, etc) can take a masked address. MAC masking works the same as netmask in TCP/IP, for example '00:11:22:00:00:00/FF:FF:FF:00:00:00' would match all addresses beginning with 00:11:22. Masks do not have to break on whole pairs ('FF:FF:FF:F0:00:00' is a valid mask). * Log tuning. The types of packets that make it into the logfiles can be controlled via the 'noiselog', 'beaconlog', 'phylog, 'mangledatalog', and other options. * Probe tracking. By default, Kismet tracks probe requests and responses, and attempts to combine a probe request network with the network that responds to it. Sometimes this isn't the desired behavior, by setting 'trackprobenets' to 'false', probe requests will always remain separate. * Channel delays. Currently the easiest way to get Kismet to spend more time on part of the channel hop list is to include that channel multiple times. A hop list of "1,3,6,6,6,9,11" would spend 3 times as long on channel 6 as on the other channels. Channels can be repeated throughout the list, as well, for example "6,1,6,3,6,9,6,11" would have a similar effect while providing more frequent monitoring of other channels. * Fuzzy encryption detection. Not all drivers properly set the WEP flag on encrypted packets. As of 2005-06-R1, Kismet automatically attempts to manually determine if a packet contains encrypted data if it is part of a network which advertises encryption. This behavior can be turned off via the "netfuzzycrypt" option, and it can be enabled for specific capture types via the "fuzzycrypt" config option. Filtering syntax: Filters are "positive-pass": anything matched by the filter is passed and all else is excluded. Filtering can be done on address types (ANY, SOURCE, DEST, and BSSID). To exclude a network with the BSSID AA:BB:CC:DD:EE:FF, the filter would be: filter_tracker=BSSID(!AA:BB:CC:DD:EE:FF) MAC addresses can be masked in the same fashion as IP netmasks. To match all networks of a certian manufacturer, restrict to the OUI: filter_tracker=BSSID(AA:BB:CC:00:00:00/FF:FF:FF:00:00:00) Multiple MAC addresses can be used on the same filter line. To filter out two known networks from being considered: filter_tracker=BSSID(!00:11:22:33:44:55,!00:11:22:33:44:66) Which is to say, all traffic not from 00..55 and not from 00..66 will be considered. 10. Ncurses/Panels Interface The ncurses/panels interface is the default frontend provided with Kismet. The panels interface is fairly intuitive, and has integrated help. 'h' will open the main help window showing all the options available. Primary functions: * Auto-fit and sorted network lists * Client lists for each network * Detailed network information * Packet rate graphs * Channel allocation graphs * Realtime packet type display * Compass-display of network locations * 'Locking' channel hopping to a specific network Other clients for Kismet are available from the links page on the Kismet website. All information about a network is contained in the network details window, and the following columns can be turned on in the main display: bssid BSSID (MAC address) of the network channel Last-advertised channel for network clients Number of clients (unique MACs) seen on network crypt Number of encrypted packets data Number of data packets decay Displays '!' or '.' or blank, based on network activity in the last 'decay' seconds (controlled by the 'decay' variable in the config file) dupeiv Number of packets with duplicate IVs seen flags Network status flags (Address size, decrypted, etc) info Extra AP info included by some manufacturers ip Detected/guessed IP of the network llc Number of LLC packets manuf Manufacturer, if matched maxrate Maximum supported rate as advertised by AP name Name of the network or group noise Last seen noise level packets Total number of packets shortname Shortened name of the network or group for small displays shortssid Shortened SSID for small displays signal Last seen signal level signalbar Graphical representation of signal level size Amount of data transfered on network ssid SSID/ESSID of the network or group type Network type (Probe, Adhoc, Infra, etc) weak Number of packets which appear to have weak IVs wep WEP status (does network indicate it uses WEP) The clients window has a similar selection of columns which can be enabled: crypt Number of encrypted data packets transfered by client data Number of data packets transfered by client decay Displays '!', '.', or ' ' based on network activity ip Last seen IP used by client mac MAC address of client manuf Manufacturer of client (if known) maxrate Maximum rate client seen transfering noise Last seen noise level of client signal Last seen signal level of client size Amount of data transfered by client type Type of client (Established, To-DS, From-DS, etc) weak Number of packets which appear to have weak IVs 11. Operating Systems Kismet will work (at some level) on any operating system which has POSIX compatibility, however for it to do native packet capturing it needs drivers which are capable of reporting packets in rfmon. Remote sources such as WSP100 or Drones can be used on any platform you can get Kismet to compile on. - Linux (Intel, PPC, MIPS, X-Scale, Arm, etc) Known supported cards: Atmel_USB, ACX100, ADMTek, Atheros, Cisco, Prism2, Orinoco, WSP100, Drone, wtapfile, pcapfile, wrt54g, ipw2100, rt2400, rt2500, rt8180, ipw2200, ipw2915, ipw3945, Broadcom 43xx Kismet will work with any distribution of Linux. Currently, Linux is the recommended platform for running Kismet because it has the largest selection of rfmon capable drivers. - OpenBSD Known supported cards: Prism2 (wi), Atheros (ath), Intel 2200/2225/2915 (iwi), Intel 2100 (ipw), Ralink (ral, ural and rum), Realtek RTL8180L (rtw), ZyDAS ZD1211/ZD1211B (zyd), Prism GT Full-MAC (pgt), Cisco 35x (an), WSP100, Drone, wtapfile, pcapfile. OpenBSD 3.7 and newer includes a software 802.11 stack and the Radiotap packet header format. Any cards that use the 802.11 stack and support monitor mode should work with Kismet via the radiotap_bsd_x capture sources. OpenBSD 3.2 and newer report standard frames from the Prism2 drivers. Thanks to the efforts of Pedro la Peu, Kismet works fully with prism2 cards under OpenBSD. - FreeBSD Known supported cards: Atheros, Prism2, WSP100, Drone, wtapfile, pcapfile FreeBSD-current adds a common Radiotap packet header format. Thanks to Sam Leffler, Kismet supports the radiotap headers and should work with current FreeBSD systems. FreeBSD users should configure with the --enable-syspcap option to get multidlt support from the system-wide libpcap library instead of the bundled one. - NetBSD Known supported cards: WSP100, Drone, wtapfile, pcapfile There have been no reports positive or negative about NetBSD drivers. Please email if you have them working. NetBSD is moving towards (or already has) Radiotap header support. If your card is supported under a current NetBSD version with radiotap, it should work with the radiotap_bsd_x sources. - MacOSX Known supported cards: Airport, WSP100, Drone, wtapfile, pcapfile MacOSX is supported for Airport (classic) cards only, using the Viha drivers at http://www.dopesquad.net/security/. There are no rfmon drivers available for Airport Extreme cards currently. Other third-party drivers may support rfmon for other PCMCIA and USB cards under OSX - let me know if your drivers support rfmon, and I'll add support in Kismet. - Win32 (Cygwin) Known supported cards: WSP100, Drone, airpcap, wtapfile, pcapfile Win32 local packet capture is possible ONLY with the CACE Airpcap device. http://www.cacetech.com/products/airpcap.htm Thanks to Loris Degioanni for doing the bulk of the work adding airpcap support under cygwin. When compiling with AirPcap on Cygwin, it is necessary to pass both --enable-airpcap and --with-airpcap-devpack=Path, where Path is the CACE devpack containing winpcap and airpcap. Cygwin appears to have a bug which prevents proper linking if the devpack is not in the same directory as Kismet is compiled in. If kismet_server.exe instantly exits with no output, it is typically indicative of a linkage path problem. NO OTHER WIRELESS CARDS CAN CURRENTLY BE USED TO CAPTURE DATA NATIVELY IN WINDOWS. CACE has released a public API for their drivers to allow third-party programs to interface with them. Standard Windows wireless drivers are not rfmon capable. Due to interactions with Cygwin, users of the kismet_client ncurses frontend should disable sound in kismet_client.conf Win32 is also usable with REMOTE captures such as the Kismet drone running on a platform which supports native capture. 12. Capture Sources A capture source in Kismet is anything which provides packets to the Kismet engine. Capture sources define the underlying engine needed to capture data from the interface, how to change channel, and how to enter rfmon mode. It is necessary to tell Kismet what specific type of card you use because different drivers often use different methods to report information and enter monitor mode. Source type Cards OS Driver --------------- ------------------- ----------- ------------------------- acx100 TI ACX100 Linux ACX100 http://acx100.sourceforge.net/ Capture interface: 'ethX' ACX100 drivers handle the 22mbit cards branded by D-Link and others. admtek ADMTek Linux ADMTek http://www.latinsud.com/adm8211/ (Patches) http://aluminum.sourmilk.net/adm8211/ (GPL driver) ADMTek drivers used in many consumer 802.11b cards. With the patches above, quasi-rfmon is possible - these cards appear to be almost entirely software controlled and always in a rfmon-like state. This card WILL BROADCAST while in rfmon, rendering the sniffer visible. The fully GPL drivers are supported, in addition to the hacks to the non-free drivers. airpcap Airpcap USB cygwin CACE Tech http://www.cacetech.com/products/airpcap.htm Capture interface: Win32 device path The CACE AirPcap USB device allows native capture on Win32/Cygwin. The explicit airpcap source expects the Win32/Cygwin interface name. This should be used once the source is identified via airpcap_ask or if multiple simultaneous sources are required. airpcap_ask Airpcap USB cygwin CACE Tech http://www.cacetech.com/products/airpcap.htm Capture interface: dummy The CACE AirPcap USB device allows native capture on Win32/Cygwin. The airpcap_ask source lists available airpcap devices and allows the user to pick interactively. atmel_usb Atmel-USB Linux Berlios-Atmel http://at76c503a.berlios.de/ Capture interface: 'wlanX' These drivers work ONLY on USB cards (Sorry, no PCMCIA support). Monitor mode support is limited and "faked" by bypassing part of the firmware and parsing packets directly, and is likely to not report all of the frames. This card MAY BROADCAST while in rfmon, rendering the sniffer visible. It appears that this card may be only formatting the beacons as an 802.11 stream, which means you likely will not see data frames, rendering most IDS functions, IP discovery, and data logging unavailable. bcm43xx Broadcom Linux Berlios-BCM43XX http://bcm43xx.berlios.de Capture interface: 'ethX' *Very experimental* drivers with *experimental* Kismet support. These reverse-engineered drivers support a range of Broadcom based wireless cards. At the time of this writing, they support ONLY monitor mode, normal mode is not functional. These drivers are in a state of high development, and support is only added because of demand. If it doesn't work, I wouldn't be too surprised. cisco Aironet 340,350 Linux Kernel 2.4.10 - 2.4.19 Capture interface: 'ethX' Standard Cisco cards in Linux. Works only with the Linux kernel drivers, not the drivers found in pcmcia-cs. The drivers found on the cisco.com site can be patched with the files from the Kismet download site to add monitor mode with channel control, HOWEVER these drivers are extremely buggy for normal use and work only with the 2.4 kernel tree. The cisco drivers currently do not enter rfmon mode correctly, so channel control is not available. The firmware will hop to whatever channel it feels like hopping to, when it feels like hopping. cisco_wifix Aironet 340,350 Linux Kernel 2.4.20+, CVS http://sourceforge.net/projects/airo-linux/ Capture interface: 'ethX:wifiX' Kernel 2.4.20+ and CVS drivers use ethX for normal mode and wifiX for monitor mode. Kismet needs to know both devices, which may not necessarily be the same number, for example 'eth1:wifi0'. Linux kernel 2.4.20 and 2.4.21 have highly unstable cisco drivers and should be avoided. The cisco drivers currently do not enter rfmon mode correctly, so channel control is not available. The firmware will hop to whatever channel it feels like hopping to, when it feels like hopping. hostap Prism/2 Linux HostAP 0.4 http://hostap.epitest.fi/ Capture interface: 'wlanX' HostAP drivers drive the Prism/2 chipset in access point mode, but also can drive the cards in client and monitor modes. The HostAP drivers seem to change how they go into monitor mode fairly often, but this source should manage to get them going. ipw2100 Intel/Centrino Linux ipw2100-0.44+ http://ipw2100.sourceforge.net/ Capture interface: 'ethX' The Linux IPW2100/Centrino drivers for 802.11b cards now support rfmon, so here's support for them. They act more or less like any other wireless interface would. ipw2200 Intel/Centrino Linux ipw2200-1.0.4+ http://ipw2200.sourceforge.net/ Capture interface: 'ethX' The Linux IPW2200/Centrino drivers for 802.11bg cards support rfmon as of 1.0.4 and firmware 2.3. Signal level reporting requires radiotap be turned on in the makefile while compiling the driver. Noise levels are not reported. ipw2915 Intel/Centrino Linux ipw2200-1.0.4+ Capture interface: 'ethX' http://ipw2200.sourceforge.net/ The Linux IPW2200/Centrino drivers for 802.11bga cards support rfmon as of 1.0.4 and firmware 2.3. This is the same as ipw2200 but defaults to scanning the 802.11a channel range in addition to 802.11b/g. Signal level reporting requires radiotap be turned on in the makefile while compiling the driver. Noise levels are not reported. ipw3945 Intel/Centrino Linux ipw3945 Capture interface: 'ethX' http://ipw3945.sourceforge.net/ The Linux IPW3945/Centrino drivers for Intel Core 802.11bga cards. ipwlivetap Intel/Centrino Linux ipw2200/3945 Capture interface: 'ethX' http://ipw2200.sourceforge.net/ http://ipw3945.sourceforge.net/ The ipw3945 and patched ipw2200 drivers support a special mode which allows monitor-mode style sniffing while remaining associated. Channel hopping is not possible, as the card is still associated to a specific AP, but single-channel IDS and sniffing can be accomplished. See the ipw driver mailing list archives for information about patching your drivers. kismet_drone n/a Any n/a Capture interface: 'dronehost:port' The remote drone capture source connects to a Kismet drone and proceses the packets. Refer to the Remote Drone section of the README for more details about how to set up a drone. madwifi_a Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a-only mode. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifi_b Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11b-only mode. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifi_g Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11g-only mode. This will, obviously, also see 11b networks. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifi_ab Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a and 802.11b combo mode. This will seamlessly switch between bands during channel hopping. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifi_ag Atheros Linux madwifi http://sourceforge.net/projects/madwifi/ Capture interface: 'athX' Capture interface: 'wifiX' (Madwifi-NG) Madwifi drivers in 802.11a and 802.11g combo mode. This will seamlessly switch between bands during channel hopping. When using madwifi-ng, be sure all non-monitor VAPs have been removed, otherwise madwifi will not properly report most traffic. madwifing_a Atheros Linux madwifi-ng madwifing_ab Atheros Linux madwifi-ng madwifing_ag Atheros Linux madwifi-ng madwifing_g Atheros Linux madwifi-ng madwifing_b Atheros Linux madwifi-ng http://sourceforge.net/projects/madwifi/ Capture interface: 'wifiX' *Deprecated*. Detection for madwifi-ng is built into the standard madwifi sources. The _ng source names have been kept to allow old configs to continue functioning. nokia770 Nokia/TI Linux Nokies/TI http://maemo.org/ Capture interface: 'wlan0' Nokia770 capture interface. Includes support for validating frame checksums to screen out junk packets, since the drivers pass us all data. orinoco Lucent, Orinoco Linux Patched orinoco_cs http://airsnort.shmoo.com/orinocoinfo.html Capture interface: 'ethX' The orinoco-cs drivers do not support monitor mode as-is, but patches are on the Kismet download site for standalone drivers, Linux 2.6 kernel drivers, and Linux 2.6.9+ kernel drivers. These expanded patches fix several performance issues with previous monitor mode patches. orinoco_14 Lucent, Orinoco Linux Orinoco 0.14+ https://savannah.nongnu.org/projects/orinoco/ Capture interface: 'ethX' The new orinoco_cs drivers changed things subtly, but at least they include rfmon without patching. Patches to enable signal level reporting are available on the kismet download site. These drivers are NOT CURRENTLY RECCOMENDED. Once the new Orinoco drivers have solidified, final patches for per-packet stats will be made and this source changed. pcapfile n/a Any n/a Capture interface: '/path/to/file' The pcapfile capture source feeds a stored 802.11-encap dump file through the Kismet engine again. This can be useful for debugging or rescanning old logs for alert conditions. Pcapfile sources are only available if Kismet was compiled with libpcap support. prism2_openbsd Prism/2 OpenBSD Kernel Capture interface: 'wiX' Full support for Prism2 under OpenBSD. prism54g PrismGT Linux prism54 http://www.prism54.org Capture interface: 'ethX' PrismGT 802.11g drivers supporting monitor mode. radiotap_bsd_ab Radiotap BSD Kernel Capture interface: various Dual-band cards with radiotap headers. radiotap_bsd_a Radiotap BSD Kernel Capture interface: various 802.11a cards (or dual-band on 11a channels only) with radiotap headers. radiotap_bsd_b Radiotap BSD Kernel Capture interface: various 802.11b/g cards (or dual-band on 11b channels only) with radiotap headers. rt2400 Ralink 2400 11b Linux rt2400-gpl Capture interface: 'ethX' http://rt2x00.serialmonkey.com/ Ralink 2400 802.11b cards using the serialmonkey GPL'd rt2x00 drivers. Must use 1.2.2 beta 2 or newer drivers. rt2500 Ralink 2500 11g Linux rt2500-gpl Capture interface: 'ethX' http://rt2x00.serialmonkey.com/ Ralink 2500 802.11g cards using the serialmonkey GPL'd rt2x00 drivers. Must use 1.1.0 beta 2 or newer drivers. rt8180 Realtek 8180 11b Linux rtl8180-sa2400 Capture interface: 'ethX' http://rtl8180-sa2400.sourceforge.net/ Realtek 8180 based cards (there seem to be an awful lot of them) using the GPL drivers. viha Airport OSX viha http://www.dopesquad.net/security/ Capture interface: 'enX' Monitor mode support for Airport under OSX. Does not support Airport Extreme. vtar5k Atheros 802.11a Linux vtar5k http://team.vantronix.net/ar5k/ vtar5k drivers handle some Atheros 802.11a cards. Chances are you'll have better luck with madwifi drivers. wlanng_legacy Prism/2 Linux wlan-ng 0.1.3 and earlier http://www.linux-wlan.com/ Capture interface: 'wlanX' Old wlan-ng drivers didn't support pcap capturing and use a netlink socket to the kernel. These are still in use on some embedded systems (like the Zaurus). wlanng Prism/2 Linux wlan-ng 0.1.4 - 0.1.9 http://www.linux-wlan.com/ Capture interface: 'wlanX' Wlan-ng prism2 drivers prior to the AVS headers. wlanng_avs Prism/2 Linux wlan-ng 0.2.0+ http://www.linux-wlan.com/ Capture interface: 'wlanX' Newer wlan-ng drivers support a new header type and slightly different monitor commands to report wepped packets. wrt54g Linksys WRT54G Linux linksys http://seattlewireless.net/index.cgi/LinksysWrt54g Capture interface: 'ethX' Capture interface: 'ethX:prismX' Support for the drivers found in the embedded Linux inside the Linksys WRT54G (and probably other APs using the same firmware). Newer firmwares (such as OpenWRT) use the prism0 device for monitor mode data. On these firmwares, specify both interfaces (wrt54g,eth1:prism0,foo) wsp100 NetChem WSP100 Any n/a http://networkchemistry.com/ Capture interface: 'host:port' The WSP100 is an embedded device which reports 802.11 packets over UDP. The wsp100 capture source is (generally) system agnostic, however over time it has been less maintained than others. If you'd like to send me patches for this, please let me know. wtapfile n/a Any n/a Capture interface: '/path/to/file' Wtapfile sources are the same as pcapfile sources but they use the Ethereal libwiretap loader. libwiretap can automatically decompress gzipped files, etc. Wtapfile sources are only available if Kismet was compiled with libwiretap support. zd1211 ZyDAS USB Linux zd1211 http://zd1211.ath.cx Capture interface: 'wlanX' At the time of this writing, the ZD1211 drivers have significant data corruption while changing channel, and often while receiving data frames. Until these problems are addressed in the driver, it is not reccomended. Chipsets known to NOT WORK: Broadcom - No linux drivers, only useable with ndiswrapper or linuxant wrappers around windows drivers. *** UPDATE *** See the bcm43xx source type entry. There are experimental reverse-engineered drivers which have monitor mode support now under Linux! If they don't work, however, then too bad. Airport Extreme - Really a Broadcom, with no rfmon in the OSX drivers. *** UPDATE *** See the bcm source for linux on ppc, it MAY work, it may not. Currently theres no solution for OSX but I'm looking for OSX hackers interested in redoing the Kismet port and looking into adding more support. Atmel - There is a hack for pseudo-monitor in USB. There is currently no equivalent hack for PCMCIA. HermesII - Proxim successor to the Orinoco/HermesI. No support yet in the drivers, may be available in the future. ndiswrapper - Anything using ndiswrapper is using WINDOWS drivers AND CAN NOT BE USED WITH KISMET. 13. Graphical Network Mapping Kismet provides a tool for drawing networks overlaid on downloaded maps called 'gpsmap'. Gpsmap reads the netxml and gpsxml files, sanitizes the data, GPSMap can download maps from several online sources (MapBlast, Tiger, Terraserver, Earthamaps, and more) as well as use user-provided graphics, provided you know the scale and center coordinates. Main features: * Travel path/track * Approximate network circular range * Approximate network center * Convex hull of all network sample points * Interpolated (weathermap-style) graphing of power and range * Labeling of network centers * Scatterplot of all detected packets * Legend showing total sample networks, visible networks, colors, power ranges, network center, etc. 'gpsmap --help' lists all of the switches for enabling different map overlays, map sources, and coloring options. The default map source is a blank image. GPSMap currently can use maps from: NullMap (Blank white background) MapBlast (Vector) (Broken) MapPoint (Vector) (Broken, read warning) Terraserver (Satellite Photo) Tiger (Vector) (US Census data) Earthamap (Vector) (Requires perl) (Broken) Terraserver Topo (Vector-ish) Due to changes in the map websites (or their removal by vendors or corporate buyouts), many map sources no longer work. These mapsources are marked as "Broken" or "Unavailable". They have been left in GPSMap solely to enable easy plotting on previously saved map images. These will FAIL if they are selected and a user map is not also provided. All of these map sources rely on external data. By using them, you agree to whatever terms and conditions the map provider requires. Visit the map providers website for these conditions. It is highly probable that re-use of maps from vendors, in noncommercial or commercial situations, is against the terms of service. Plotting against non-vendor maps is possible by determining the equivalent scaling mechanism and setting the appropriate map type. Typically this must be done via trial and error. The extras/ directory contains an additional utility, 'gpsxml-sanitize', for cleaning invalid sample points out of the gpsxml data files for use in other programs. GPSMap cleans the data set automatically, reprocessing the gpsxml files is only needed if they are to be used in third-party programs. 14. Drone Remotes Remote Kismet drones are designed to turn Kismet into a stationary, distibuted IDS system. Drones support all of the capture sources Kismet supports, and can have multiple cards per drone. Drones capture wireless data and report it over a secondary connection (typically wired ethernet), and have very minimal hardware requirements. Each drone in the network can be configured for independent channel hopping, and even different 802.11 standards (such as one drone monitoring 802.11a and one monitoring 802.11b). A kismet server can be connected to all the drones in the network and will provide a single dump file and alert system. Using wep decrpytion and a named pipe output ('fifo' config file option), wireless traffic from around an installation can be sent to snort (or other layer3 IDS). To start using drones, set up a kismet_drone on the system with a wireless card, using the kismet_drone.conf file. Then configure Kismet to have a kismet_drone capsource pointing to that host, start kismet_server, and use whatever client you like to connect to Kismet. If a GPS is enabled on the drone, packets recieved from the drone will use that GPS for positioning information. If the GPS is not enabled, then the GPS connected to the Kismet server will be used. 15. Alerts and Intrusion Detection Kismet will provide alerts based on fingerprints (specific netstumbler versions, other specific attacks) and trends (unusual probes, excessive disassociation, etc). Kismet focuses on the 802.11 (layer 2) network layer, and provides integration via named pipes with layer3+ IDS systems such as Snort. Alerts are primarily meant to be used in a stationary IDS situation. Some are potentially useful in a mobile/wardriving setup, but others may generate false or useless information. Alert name: NETSTUMBLER Alert type: Fingerprint Alert on: Netstumbler probe requests WVE: WVE-2005-0025 Alert message: "Netstumbler ($version) probe detected from ($macsource)" Tool-specific: Yes (Netstumbler 3.22, 3.23, 3.30) References: http://www.netstumbler.com Details: In an attempt to disclose the SSID of a network, Netstumbler sends out unique packets. This is not done in all situations, but when it is detected the potential for false positives is very low. Alert name: DEAUTHFLOOD Alert type: Trend Alert on: Deauthenticate/Disassociate Flood WVE: WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 Alert message: "Deassociate/Deauthenticate flood on $targetbssid" Tool-specific: No References: http://802.11ninja.net http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf Details: By spoofing disassociate or deauthenticate packets, arbitrary (or all) clients can be disconnected from a network. This attack lasts only as long as the attacker maintains the flood. Alert name: LUCENTTEST Alert type: Fingerprint Alert on: Lucent link test Alert message: "Lucent link test detected from $sourcemac" Tool-specific: Yes (Lucent/Orinoco site survey software) References: http://www.agere.com/wlan/customercare/ (requires login) Details: Lucent/Orinoco/Proxim/Agere provide site survey software. This rule will generate an alert when it is in use. Alert name: WELLENREITER Alert type: Fingerprint Alert on: Wellenreiter SSID brute force attempt WVE: WVE-2006-0058 Alert message: "Wellenteiter probe detected from $sourcemac" Tool-specific: Yes (Wellenreiter 1.5, 1.6) References: http://home.jwu.edu/jwright/papers/l2-wlan-ids.pdf http://home.jwu.edu/jwright/papers/wlan-mac-spoof.pdf Details: Wellenreiter attempts to use a dictionary to brute-force a hidden SSID. Between each probe attempt it resets the card to probe for 'this_is_used_for_wellenreiter'. Alert name: CHANCHANGE Alert type: Trend Alert on: Previously detected AP changing to a new channel WVE: WVE-2005-0019 Alert message: "Beacon on $bssid ($ssid) for channel $newchannel, previously detected on $oldchannel" Tool-specific: No Details: Man-in-the-middle attacks attempt to direct users to a fake AP on another channel. If Kismet sees an AP change to a new channel, this is often suspicious behavior. Alert name: BCASTDISCON Alert type: Fingerprint Alert on: Broadcast disconnect/deauthenticate WVE: WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 Alert message: "Broadcast [disassociation|deathentication] on $bssid" Tool-specific: No Details: Many attacks use a broadcast disassociate or deauthenticate to disconnect all users on a network, either to redirect them to a new fake network or do cause a denial of service or disclose a cloaked SSID. Broadcast disassociations are rarely, if ever, legitimate. Alert name: AIRJACKSSID Alert type: Fingerprint Alert on: SSID of 'airjack' WVE: WVE-2005-0018 Alert message: "Beacon for SSID 'airjack' from $sourcemac" Tool-specific: Yes (airjack) References: http://802.11ninja.net/airjack/ Details: The AirJack tools set the initial SSID to 'airjack'. This alert is no longer highly relevant as the AirJack tool has long been discontinued. Alert name: PROBENOJOIN Alert type: Trend Alert on: Clients probing for networks, being accepted by that network, and continuing to probe for networks. Alert message: "Suspicious client $sourcemac - probing networks but never joining." Tool-specific: No Details: 'Active' or 'Firmware' network scanning tools work by letting the card probe for any network and recording those that respond. These tools include NetStumbler, PocketStumbler, and many others. Kismet raises this alert when a client is seen to be probing for networks but never joins any of the networks which respond. False positives are possible in noisy/lossy situations, disabling this alert may be desirable in some installations. Alert name: DISASSOCTRAFFIC Alert type: Trend Alert on: Traffic from a source within 10 seconds of a disassociation WVE: WVE-2005-0019 WVE-2005-0045 WVE-2005-0046 WVE-2005-0061 Alert message: "Suspicious traffic on $sourcemac: Data traffic within 10 seconds of a disassociate." Tool-specific: No References: "802.11 Denial-of-Service Attacks: Real Vulnerabilities and Practical Solutions" Details: As discussed in the above research paper by Bellardo, J. and Savage, S., a host which legitimately disassociates or deauthenticates from a network should not be exchanging data immediately thereafter. Any client which DOES exchange data within 10 seconds of disassociating from the network should be considered a likely victim of a disassociate attack. Alert name: NOPROBERESP Alert type: Fingerprint Alert on: Probe response packet with 0-length SSID tagged parameter WVE: WVE-2006-0064 Alert message: "Probe response with 0-length SSID detected from $sourcemac" Tool-specific: No Details: Many firmware versions from different manufacturers have a fatal error when they receive a probe response with a 0-length SSID tagged parameter. Alert name: BSSTIMESTAMP Alert type: Trend Alert on: Invalid BSS timestamps indicative of an access point being spoofed. WVE: WVE-2005-0019 Alert message: "Out-of-sequence timestamp on $bssid got $timestamp expected $timestamp - this could indicate AP spoofing" Tool-specific: No Details: The BSS timestamp sent with beacons and some probe frames cannot be spoofed with standard firmware or drivers even when forging raw frames. A BSS mismatch is likely an indication of an attempt to spoof the SSID and BSSID of an access point. This alert contains flap-detection to minimise false positives caused by random bogons and AP recycling. Alert name: MSFBCOMSSID Alert type: Signature Alert on: MAC src address used as CPU instructions by MSF when exploiting the Broadcom SSID overflow WVE: WVE-2006-0071 Alert message: "MSF-style poisoned exploit packet for Broadcom drivers" Tool-specific: Yes Details: Some versions of the Windows Broadcom wireless drivers do not properly handle over-long SSIDs, leading to code execution. Alert name: LONGSSID Alert type: Signature Alert on: SSID advertised as greater than IEEE spec of 32 bytes Alert message: "Illegal SSID length ($len > 32) from $srcmac" Tool-specific: No Details: The IEEE 802.11 spec allows a maximum of 32 bytes for the SSID, however the IE tag structure allows for 256. Oversized SSIDs are indicative of an attack attempting to exploit SSID handling. Alert name: MSFDLINKRATE Alert type: Signature Alert on: Beacon frame with over-long 802.11 rates tag containing exploit opcodes WVE: WVE-2006-0072 Alert message: "MSF-style poisoned 802.11 rate field in beacon $srcmac for D-Link driver attack" Tool-specific: Yes Details: Some versions of the Windows D-Link wireless drivers do not properly handle over-long 802.11 accepted rate fields, leading to code execution. Alert name: MSFNETGEARBEACON Alert type: Signature Alert on: Large beacon frame containing exploit opcodes Alert message: "MSF-style poisoned 802.11 over-sized options beacon $srcmac for Netgear driver attack" Tool-specific: Yes Details: Some versions of the Windows Netgear wireless drivers do not properly handle over-sized beacon frames, leading to remote code execution Alert name: DISCONCODEINVALID | DEAUTHCODEINVALID Alert type: Signature Alert on: Unknown / reserved / invalid reason codes in deauth and disassoc packets Alert message: "Unknown {disassociation | deauthentication } reason code 0x$rc from $sourcemac" Tool-specific: No Details: Various drivers and access points have been reported to improperly handle unknown/invalid reason codes. 16. Reporting Bugs Bugs happen, and I'm sure some are still in the code. To make a useful bug report: * Check the "Troubleshooting" section to make sure it's not a known user error * Check the development CHANGELOG to make sure it hasn't already been fixed in -devel. http://svn.kismetwireless.net/code/trunk/CHANGELOG If the bug appears to be tied to specific packets: * Start Kismet * Use TCPDump to get a capture of the packets outside of Kismet, until Kismet crashes. (``tcpdump -i foo0 -w crashlog.dump'') * Run the capture through Kismet: Does it still crash? (use the pcapfile capture type) ``kismet_server -c pcapfile,/path/to/dump,foo'' * Send me the dump file and the info If the bug happens otherwise: * Recompile Kismet from source and don't use ``make install''. The install scripts strip debugging info from the binaries that we need. * Run Kismet inside gdb (``gdb ./kismet_server'' or ``gdb ./kismet_client'') * When it crashes, get a backtrace: ``bt'' in gdb * Send me the info 17. Troubleshooting Some common problems with Kismet have easy solutions: PROBLEM: Fatal errors about old configuration file values Kismet has evolved over time. This has made changes to the config files necessary, and obsoleted old options. Kismet will automatically detect old config files and alert on them. FIX: Upgrade your config files. 'make forceinstall' or 'forcesuidinstall' will replace old files, or you can copy the config file from the conf/ directory manually and update it for your configuration. PROBLEM: Fatal error about being unable to find the suiduser Kismet drops the privileges of the main packet processor to a specified user for security - handling hostile remote data as root is just a bad idea. If a nonexistent user is specified, Kismet will bail. FIX: Set a valid user as the suiduser config variable. If you're sure you don't want privilege dropping, you can run configure with the '--disable-setuid' option, but this is NOT reccomended for most users. PROBLEM: Fatal error about specifying a uid-0 target for suiduser Kismet needs to drop out of root for security purposes. If you tell it that the user to switch to is 'root' (or another uid-0 user, if you happened to make one), it can't do this. FIX: See fix above for errors about finding the suiduser. PROBLEM: Fatal error enabling monitor mode, 'monitor' ioctl not available Some capture sources use a private ioctl, 'monitor', to enable rfmon. If Kismet is unable to find this ioctl, it means that the wrong interface was specified, the wrong capture type is being used, or most commonly, the drivers you are using have not been patched or the patched drivers are not being loaded. Be sure to download any patches needed for the drivers you are using, and make sure that no other copies of those drivers exist in your /lib/modules/kern-version/ directory. You may need to restart pcmcia-cs if your wireless card was already running when you installed the patched drivers. FIX: Provide the correct interface and ensure that the patched drivers are loaded. PROBLEM: Fatal error about a Cisco card not reporting the correct link type in Linux FIX: Use the correct Cisco card drivers. The ones from cisco.com and the ones in pcmcia-cs don't support rfmon, but act as if they do. PROBLEM: Fatal error about being unable to open a file for writing The most common cause of this problem is that the suiduser you specified for Kismet to drop to does not have rights to write to the directory Kismet is trying to log to. If you did not modify the 'logtemplate' configuration file variable, Kismet defaults to the current directory for saving logs. You can set an explicit path in the logtemplate variable to put your logs in the same place every time. FIX: Start Kismet from a directory that the suiduser can write to, or set the logtemplate variable to always put the logs in a directory the suiduser can write to. PROBLEM: Fatal error about being unable to open the pidfile FIX: By default Kismet writes the pid to /var/run/. If you didn't install Kismet as suidroot, you need to start it as root so it can write to this directory and bind interfaces. If you're only using capture sources that don't require root, you can change this in kismet.conf to put pidfiles in /tmp (or any other directory). This isn't reccomended if you use Kismet as root on a system with untrusted users. PROBLEM: Fatal error about interface no longer available, and DHCP FIX: Many distributions turn on DHCP for wireless interfaces. When DHCP is turned on and rfmon is used, one of two things happens: 1. rfmon is entered before DHCP gets an address. After approximately a minute, DHCP times out, and turns off the interface. 2. DHCP gets an address, but when the address expires, it is unable to renew it, and turns off the interface. MAKE SURE YOU DISABLE DHCP before starting Kismet - either turn it off entirely for that interface, or kill the client (usually dhclient, dhcpcd, or pump) before starting Kismet. PROBLEM: Configure is unable to find libncurses or other libraries, but they're installed. FIX: If you are running a RPM-based distribution, you will need the foo-devel.rpm packages for each library. These packages contain the headers needed to compile against the libraries. PROBLEM: The panels client fails with the error 'unable to open terminal xyz'. FIX: Set your TERM environment variable to something libcurses has support for. 'vt100' is usually a good choice. PROBLEM: My GPS hardware claims to have a signal lock, but Kismet shows a fix of 0 and does not log any GPS inforation. FIX: Some GPS units have invalid NMEA streams which gpsd doesn't understand correctly. Set the "gpsmodelock" option to "true" in kismet.conf PROBLEM: I can't lock Kismet onto a single channel in the panels client, it says the server doesn't support channel hopping. FIX: You need to start Kismet with channel hopping enabled to be able to lock a source to a specific channel. Kismet will automatically disable channel hopping if none of the enabled sources support setting the channel. PROBLEM: Kismet says it couldn't take the card out of monitor mode on exiting. FIX: The source you're using won't come cleanly out of rfmon, or I didn't implement it for some reason. You'll need to reconfigure (or restart) the interfaces manually. PROBLEM: Kismet says it took the card out of monitor mode, but it still doesn't work. FIX: Sometimes cards don't come out of monitor mode cleanly. If it doesn't work, you'll need to manually restart your card, sorry. PROBLEM: I get 'invalid mode: monitor' or similar errors trying to go into rfmon with madwifi FIX: First, make sure you have madwifi-cvs. Second, make sure you're running a recent kernel. You need wireless extensions >= 15. To be safe, upgrade to the latest stable kernel. PROBLEM: I get 'Could not set SSID, I/O error' going into monitor mode on prism54 cards FIX: Update to the latest CVS release of the prism54 driver. PROBLEM: Kismet can't enter monitor mode using MadWifi FIX: The CVS version of the MadWifi drivers are needed for rfmon. Additonally, you need kernel 2.4.23 or newer because of wireless extension dependencies. Make sure to upgrade your drivers and kernel. PROBLEM: Kismet can't compile, there are errors about pcap_parse FIX: Your flex/lex/bison/yacc tools are broken or missing. Make sure you install them. libpcap cannot compile without them. Newer releases of Kismet patch libpcap to not generate filter code at all. PROBLEM: Kismet can't compile, there are errors about not finding libpcap FIX: Kismet no longer includes libpcap source, and expects your system to have a relatively modern (0.9+ preferred) libpcap install. Install libpcap, and if your distribution provides it, libpcap-devel. PROBLEM: Kismet immediately exits on Cygwin with no output FIX: Cygwin appears to have a problem in the linker. If Kismet is linked to the CASE airpcap/winpcap libraries, they MUST be inside a sub-directory of the Kismet source for compilation. Recompile Kismet with the airpcap devpack inside the source directory. 18. Frequently Asked Questions Q: Where did the name Kismet come from? A: The word itself means Fate or Destiny. While I wish I could make up some smart comment about picking it because Kismet will ultimately uncover every active wireless network in the area, really I just needed a name and was clicking through a thesaurus and liked the sound. Q: Is there anything illegal about Kismet? A: In and of itself, there should be nothing illegal about Kismet, and it's no different than any other network capture tool. Note, however: - Recording data from networks for which you do not have permission may be considered an illegal wiretap. - Using networks you do not have permission to use may be considered theft of service. - Don't be stupid using Kismet. - If you are stupid, I'm not responsible. Q: What happened to the version numbers? A: They stopped making sense. 3.0 to 3.1 was a 30,000 line diff, but calling it 4.0 doesn't make sense either. So, it's getting versioned by the release date, which should also help keep stable releases coming in a timely manner. Q: Why is rfmon different from promiscuous mode, and why can't you just use promisc? A: In the wired world, promiscuous mode turns off the filtering mechanism in your network card, causing it to pass all packets to the operating system. With most drivers, it means the same thing in the wireless world, -BUT- it only applies to the network you are currently associated with, and it only passes the packets as 802.3/Ethernet-II. This means no 802.11 headers, no 802.11 management frames, and nothing from networks other than the one you're associated with. Rfmon is a special mode that reports all packets the wireless card sees, including management packets and packets from any network the radio can see. Kismet can't just use promisc mode because it won't be able to gather information about the networks, and would only be able to get data from the network you've already joined. Q: Does Kismet work differently than NetStumbler? A: Absolutely. Netstumbler (and MiniStumbler, and others) work by querying the firmware of the card for networks the card has seen. While this method is obviously able to detect networks in the area, it is noisy (people can see you're running NetStumbler), it can't decloak hidden networks, and it can't record data. Q: Will Kismet work with Linuxant or NDISwrapper drivers? A: No. These wrappers use the Windows drivers, which don't support rfmon. Until there are native drivers with rfmon support, Kismet won't work with these cards. Q: What can I do to get you to support card 'xyz'? A: Kismet support of a card is largely dependant on available drivers with rfmon support. I'll be happy to get in touch with driver authors about support. Q: My distro loads the orinoco drivers for my prism2 card, is this OK? A: No, not really. The orinoco and prism chipsets are based off the same reference design, but there are subtle differences, especially in the firmware timings. Using the orinoco drivers may work for a while, but you're likely going to have problems with lost frames, corrupt frames, and system hangs. Plus, if you ever have problems and mention you're using the orinoco drivers, I'll yell at you. Q: Why am I not seeing all the traffic on a network? A: You're most likely channel hopping. You can't see all the traffic on a channel if you're hopping, just like you can't see all of a show on TV if you're channel surfing. If you need to see all of the data from a single network, you'll need to disable hopping or lock Kismet onto the network you want to watch. Q: Why do I get a lot of nonsense networks, or lots of networks that only have one data packet? A: Some drivers (currently the worst offenders are wrt54g, madwifi, and some versions of prism54) toss up garbage packets sometimes. Usually these are chunks of valid frames, several valid frames mangled together, valid frames with extra noise before them, etc. Kismet does the best it can to screen these out, but if the packet headers look like a data frame it will usually get past - management frames can be rigorously validated, but data frames could contain anything so they slip past. There isn't a really good solution to this, but you can turn on the 'autogroup_data' option in kismet_ui.conf to make them less intrusive. Q: What are the signal and noise levels measured in? A: Depends on the drivers. Firmware. Modes. In other words, who knows. Most cards and drivers don't do very well measuring signal levels in rfmon. Some, like Cisco, don't even give us a per-packet signal level. To make matters worse, signal levels are often quite binary - rarely will a signal dwindle to 10 or 20 as you travel away from the source. Beyond a certain point the radio is unable to assemble a packet out of the weak signal, and it will simply disappear. Generally speaking, a signal level of 200 is better than a signal level of 100, but individually the numbers don't have much relevance. They can be useful for coloring the maps as "better" and "worse", but thats about the most you should use them for. Q: Can Kismet be used in a commercial product? A: As long as you follow the requirements of the GPL, I can't stop you. It would certainly be nice if you're using Kismet to make a profit to take a look at my wishlist or make a donation though. Q: What about plugins? A: Yeah, I know, I'm working on them. Q: 'configure' says it can't find libncurses/libcurses A: First, did you install ncurses-devel? Kismet needs the development headers. Second, run 'ldconfig'. Some distributions (Fedora) seem to have an out-of-date library cache that means ld can't find the library. Third, make sure you installed the libstdc++/g++ packages. Configure will erroneously blame libncurses if the linkage with libstdc++ fails. Q: Configure failed on something else A: Look at config.log and see why it failed. Sometimes packages don't properly define all their dependencies and linking fails. Q: Compiling fails on OSX with undefined variables in pcapsource.cc A: Re-run configure with --without-pcap to bypass this. Viha doesn't use pcap, so you won't lose functionality. Q: When channel hopping, the orinoco keeps going to channel -1 and not working. A: Apply the latest patches available on the Kismet download page, these fix a number of issues with the orinoco drivers and seem to alleviate this problem for most users. Q: What are the SSIDs full of strange characters, like ^A^B^J^J^K^H? A: WindowsXP leaks bits of memory into the probe requests. These are legit packets, and thats whats really in them. Q: Why is the range of a network sometimes hundreds of miles inside Kismet, but normal in GPSMap? A: GPSMap does some moderately advanced filtering on data points which allows it to sift the data collected and clean out invalid samples. These methods require all of the sample points to be available, however, and won't work during a live capture. If the GPS reports a momentary invalid, but not wholly invalid, sample then Kismet will get confused. Q: How can I merge multiple capture files into one? A: Use ``mergecap'' that comes with Ethereal to combine dump files. Q: How can I include all the standard known manufacturers in the manuf identification? A: There is a script in the extras/ directory that will convert the standard OUI list (such as that provided with Ethereal) into the format Kismet uses. This will make Kismet take a LOT more ram and a moderate increase in CPU to store and search the expanded list. If your hardware can handle it, by all means, but not recommended for lowpower systems. Q: What if configure can't find the linux wireless headers? A: Make sure you installed the kernel-headers package for your distro. Barring that, find the location of your kernel headers, and pass configure the directory with: ./configure --with-linuxheaders=/path/to/headers Q: Do I need wiretap support? A: Not really. Wiretap is only for specific situations (reading compressed packets, or reading packets captured by some different system like aironet. Generally speaking, you can just use the pcapfile capture type which is included with libpcap. Q: What cards work in *BSD? A: Any card with radiotap support should work in any of the BSD variants (Net, Open, or Free). Check your kernel docs and consider upgrading to the latest release to get more radiotap. With the exclusion of OpenBSD, non-radiotap devices are not supported. If you want to add support for a non-radiotap card, contact me over email or IRC and I can help explain it. Q: I want to port Kismet to (X) or I want to support card (Y) A: Kismet is designed to be fairly modular. Contact me over IRC or email and I can explain what parts need to be changed. Q: Why do you include your own libpcap? A: Originally it was because the version included with distributions was not up to date and couldn't handle the 802.11 linktypes. Now it is because Kismet patches libpcap to not generate filter code, resulting in a significant reduction in the size of the compiled binaries. Q: Why won't Kismet work on Windows? A: Because there are few legally unencumbered drivers for Windows. I am unwilling to risk the legal repercussions of attempting to leverage the commercial drivers from sniffer demos. Thanks to the efforts of CACE Tech, the AirPcap device is available for Windows with drivers designed to let OSS projects use the device legally. Kismet will now work with this device on Windows, however this is the ONLY local capture device which will work. Q: What happens when I ask a question thats already answered here? A: I'll probably be rude to you and tell you to go read the docs. But of course everyone already read the docs all the way to the end, right? Right?