Kismet 2004-04-01
Mike Kershaw <dragorn@kismetwireless.net>
http://www.kismetwireless.net
Licensed under the GPL

1.  What is Kismet
2.  Feature Overview
3.  Typical Uses
4.  Upgrading From Previous Versions
5.  Suidroot & Security
6.  Required Libraries & Utilities
7.  Compiling
8.  Configuration
9.  Panels Interface
10. Operating Systems
11. Capture Sources
12. Graphical Network Mapping
13. Drone Remotes
14. Intrusion Detection
15. Troubleshooting
16. 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.  Feature Overview

    Kismet has many features useful in different situations for monitoring
    wireless networks:

    - Ethereal/Tcpdump compatable 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

3.  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.

4.  Upgrading from Previous Versions

    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.

5.  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 convienent.  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.

6.  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 occured 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 IMs 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.

7.  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

8.  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 'variable=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 Types' 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:

    * IDS alert rates can be controlled via the 'alert' directive, which 
      specifies the alert type, rate per timeframe (ie, 5/min), and the burst
      limits.  These controls are similar to the iptables limit controls.

    * Networks with known WEP keys can be decrypted 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.

      Once filters are enabled they control what packets are allowed through.
      To allow all packets NOT specified, invert the filter with '!'.

      Filtering can be done on address types (ANY, SOURCE, DEST, and BSSID),
      and can be inverted.  For example, to exclude all packets from a given
      MAC, 'filter_tracker=ANY(!00:11:22:33:44:55)'.  To include only one 
      network, filter by BSSID - 'filter_tracker=BSSID(00:11:22:33:44:55)'

      Multiple filters can be chained together on one line with a ','.
      'filter_tracker=ANY(..),BSSID(!...)'

    * 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.

9.  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 '.' based on network activity
      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     Manufactuer 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
      
10. 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: ACX100, ADMTek, Atheros, Cisco, Prism2, Orinoco, 
      WSP100, Drone, wtapfile, pcapfile, wrt54g, ipw2100

      Kismet will work with any distribution of Linux.  Currently, Linux is the
      reccomended platform for running Kismet because it has the largest
      selection of rfmon capable drivers.

    - OpenBSD
      Known supported cards: Prism2, WSP100, Drone, wtapfile, pcapfile
   
      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.  Performance with other cards may be varied.

    - 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 to get mutlidlt
      support.

    - 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.

    - 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.

11. 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.

    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 DLink
                     and others.

    admtek          ADMTek              Linux       ADMTek
                    http://www.latinsud.com/adm8211/
                    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.

    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 on
                     cisco.com or pcmcia-cs.
                    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.

    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 heres support for them.  They act
                    more or less like any other wireless interface would.
                    THIS IS NOT FOR WINDOWS OR FOR SYSTEMS USING NDISWRAPPER
                    OR LINUXANT.

    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-cvs
                    http://sourceforge.net/projects/madwifi/
                    Capture interface:  'athX'
                    Madwifi drivers in 802.11a-only mode. 

    madwifi_b       Atheros             Linux       madwifi-cvs
                    http://sourceforge.net/projects/madwifi/
                    Capture interface:  'athX'
                    Madwifi drivers in 802.11b-only mode. 

    madwifi_g       Atheros             Linux       madwifi-cvs
                    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-cvs
                    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-cvs
                    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.

    orinoco         Lucent, Orinoco     Linux       Patched orinoco_cs
                    http://airsnort.shmoo.com/orinocoinfo.html
                    Capture interface:  'ethX'
                    The standard orinoco_cs drivers do not support monitor mode
                     but they work well after being patched with the above.
                    As of Feb, 2004, the CVS tree and 2.6 kernels include 
                     monitor mode, but require the new orinoco source.

    orinoco_14      Lucent, Orinoco     Linux       Orinoco 0.14+, Kernel 2.6+
                    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.

    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.

    prism_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_fbsd_ab Atheros             FreeBSD     Kernel
                     Capture interface:  'athX'
                     FreeBSD dual-band cards with radiotap headers (currently
                      only Atheros)

    radiotap_fbsd_a Atheros             FreeBSD     Kernel
                    Capture interface:  'athX'
                    FreeBSD 802.11a cards (or dual-band on 11a channels only)
                     with radiotap headers (currently only Atheros)

    radiotap_fbsd_b Atheros             FreeBSD     Kernel
                    Capture interface:  'athX'
                    Capture interface:  'wiX'
                    FreeBSD 802.11b cards (or dual-band on 11b channels only)
                     with radiotap headers (Currently Atheros or Prism2)

    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'
                    Support for the drivers found in the embedded Linux 
                     inside the Linksys WRT54G (and probably other APs using
                     the same firmware).

    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.

    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              - The USB firmware has no rfmon feature.  The pcmcia
                          firmware -may-, but the drivers don't support it.
     Realtek            - Cards seem to be primarily software-driven, no
                          support in the drivers.
     HermesII           - Proxim successor to the Orinoco/HermesI.  No support
                          yet in the drivers, may be available in the future.

12. 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.

    GPSMap currently can use maps from:
        NullMap     (Blank white background)
        MapBlast    (Vector) 
        MapPoint    (Vector) (Broken, read warning)
        Terraserver (Satellite Photo)
        Tiger       (Vector) (US Census data)
        Earthamap   (Vector) (Requires perl)
        Terraserver Topo (Vector-ish) 
       
    Due to changes in the map websites, MapPoint cannot be used with new maps.  
    These sources are left in GPSMap only for plotting previously kept map 
    images, and they will fail if they are selected and a user map is not 
    available.

    Earthamap map fetching requires prefetching a cookie from the website. This
    is automated through the gpsmap-helper-earthamaps script, which requires
    Perl, HTTP::Cookies, and Perl::LWP to be installed.

    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.
    
    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.

13. 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 cardsource pointing to that host, start kismet_server, and
    use whatever client you like to connect to it.

14. 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.netstumber.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.
    
15. 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 extention
     dependencies.  Make sure to upgrade your drivers and kernel.

16. 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 its
       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 tavel away from the source.
       Beyond a certian point the radio is unable to assemble a packet out of 
       the weak signal, and it will simply dissapear.
       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 certianly 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: 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 reccomended for lowpower systems.

    Q: What happens when I ask a question thats already answered here?
    A: I'll probably be rude to you and tell you go to go read the docs. 
       But of course everyone already read the docs all the way to the end,
       right?  Right?
       
