Kismet 2005-08-R1
Mike Kershaw <dragorn@kismetwireless.net>
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.
2. 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
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 2005-08-R1:
Upgrading from 2005-06-R1 or 2005-07-R1 should have no major changes.
See the config file for new settings pertaining to waypoint export.
For upgrading from previous versions, see the section on upgrading to
2005-06-R1 from older releases.
Upgrading to Kismet 2005-06-R1 from previous versions:
Kismet now supports the ipw2200 card with monitor mode. If you use this
card, make sure you add the ipw2200 source to the 'fuzzycrypt' line
in your config file. (The same applies to ipw2915)
Alternately, you can enable the "netfuzzycrypt" option to force fuzzy
packet detection based on the network encryption.
Kismet also now supports limiting alert burst rate time units, new
default alert values are in the example kismet.conf and alerts may
now be of the form:
alert=NAME,limit/unit,burst/unit
alert=FOO,10/min,1/sec
Upgrading to Kismet 3.1+:
Kismet 3.1 has significantly changed how Kismet operates again. There
have been config file changes, changes to the names of capture types,
and various other mayhem. Be sure to upgrade your config file or things
will definitely not work how you expect them to.
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.
- 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
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 and ural), Realtek RTL8180L (rtw),
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. For best results OpenBSD -current is recommended.
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. The prism2_openbsd and cisco_openbsd capture
sources will soon be deprecated, if possible use the radiotap_bsd_x
capture sources.
There have been some reports of the OpenBSD gcc toolchain failing when
debugging symbols and optimization are turned on (-g and -O#). If you
experience problems compiling Kismet on OpenBSD where GCC runs out of
memory, either edit the Makefile and remove the -Ox and -g options from
CPPFLAGS and CXXFLAGS, or run configure with the --disable-optimization
parameter, run gmake clean, and then gmake again.
- 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, wtapfile, pcapfile
Win32 ONLY works with remote captures. There are no public rfmon drivers
for win32, and no reports of any in development. Kismet on Win32
requires cygwin for the POSIX layer.
Don't use win32 if you want to capture data natively.
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.
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.
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.
cisco_openbsd Aironet 340,350 OpenBSD Kernel
Capture interface: 'anX'
OpenBSD cisco drivers are not fully supported currently,
but may become so. Packet capture probably will not
work correctly.
For current OpenBSD releases you should try the
radiotap_bsd_b capture source, NOT this one.
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.
THIS IS NOT FOR WINDOWS OR FOR LINUX SYSTEMS USING
NDISWRAPPER OR LINUXANT.
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.
THIS IS NOT FOR WINDOWS OR FOR LINUX SYSTEMS USING
NDISWRAPPER OR LINUXANT.
ipw2915 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.
This is the same as ipw2200 but defaults to scanning the
802.11a channel range in addition to 802.11b/g.
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'
Madwifi drivers in 802.11a-only mode.
madwifi_b Atheros Linux madwifi
http://sourceforge.net/projects/madwifi/
Capture interface: 'athX'
Madwifi drivers in 802.11b-only mode.
madwifi_g Atheros Linux madwifi
http://sourceforge.net/projects/madwifi/
Capture interface: 'athX'
Madwifi drivers in 802.11g-only mode. This will,
obviously, also see 11b networks.
madwifi_ab Atheros Linux madwifi
http://sourceforge.net/projects/madwifi/
Capture interface: 'athX'
Madwifi drivers in 802.11a and 802.11b combo mode. This
will seamlessly switch between bands during channel
hopping.
madwifi_ag Atheros Linux madwifi
http://sourceforge.net/projects/madwifi/
Capture interface: 'athX'
Madwifi drivers in 802.11a and 802.11g combo mode. This
will seamlessly switch between bands during channel
hopping.
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: 'athX'
Madwifi-ng drivers on 802.11a channels.
The interface MUST be brought up first via:
wlanconfig athX create wlandev wifiX wlanmode monitor
Multiple types for a, ab, ag, etc exist only for
naming consistency and channel selection, as the
drivers can hop seamlessly between channels.
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 older OpenBSD releases.
This should soon be deprecated, if possible use the
radiotap_bsd_b capture type.
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.
Chipsets known to NOT WORK:
Broadcom - No linux drivers, only useable with ndiswrapper or
linuxant wrappers around windows drivers.
Airport Extreme - Really a Broadcom, with no rfmon in the OSX drivers.
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
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
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
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
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
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'
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'.
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 desireable in some
installations.
Alert name: DISASSOCTRAFFIC
Alert type: Trend
Alert on: Traffic from a source within 10 seconds of a
disassociation
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
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.
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.
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.
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: 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?