Newer Older
Kismet 2016-01-R1
2 3 4 5
Mike Kershaw <>

1.  What is Kismet
6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
2.  Upgrading from earlier versions
3.  Quick start
4.  Suidroot & security
5.  Capture sources
6.  Caveats & quirks for specific drivers
7.  Supported capture sources
8.  Plugins
9.  GPS
10. Logging
11. Filtering
12. Alerts & IDS
13. Server configuration options
14. Kismet UI
15. Kismet drones
16. Talking to Kismet
17. Troubleshooting
18. Frequently asked questions
23 24 25

1.  What is Kismet

26 27 28 29 30 31 32
    Kismet is an 802.11 wireless network detector, sniffer, and intrusion
    detection system.  Kismet will work with any wireless card which
    supports raw monitoring mode, and can sniff 802.11b, 802.11a, 802.11g,
    and 802.11n traffic (devices and drivers permitting).

    Kismet also sports a plugin architecture allowing for additional
    non-802.11 protocols to be decoded.
33 34

    Kismet identifies networks by passively collecting packets and detecting
35 36
    networks, which allows it to detect (and given time, expose the names
    of) hidden networks and the presence of non-beaconing networks via data
37 38

2a. Upgrading from recent versions

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

47 48 49 50 51
2b. Upgrading from Kismet-old versions

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

53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72
    To take advantage of the new features, replace your existing
    configuration files with the latest configuration data.
    Most notably:
     * Sources are defined differently.  See the "Capture Sources" section.
     * All UI configuration is handled inside the Kismet client and stored
       in the users home directory in ~/.kismet/kismet_ui.conf
     * Most situations which were previously fatal conditions which caused
       Kismet to exit can now be recovered from.
     * New filtering options
     * New alert options
     * Completely new UI
     * Revamped network protocol
     * Significantly less CPU used for high numbers of networks
     * Plugins

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

3.  Quick start
73 74

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

77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119
    * Download Kismet from
    * Run "./configure".  Pay attention to the output!  If Kismet cannot
      find all the headers and libraries it needs, major functionality may
      be missing.  Most notably, compiling Kismet yourself will require
      the development packages and headers, usually called foo-dev or
    * Make sure that all the functionality you need was enabled properly in
      configure.  Almost all users will need pcap and libnl support for
      proper operation.
    * Compile Kismet with "make".
    * Install Kismet with either "make install" or "make suidinstall".
    * If you have installed Kismet as suid-root, add your user to the
      "kismet" group

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

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

3b.  Windows quick start

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

    Using the CACE Package:

    * Download the Win32/Cygwin installer created by CACE and linked from
      the download page (
120 121 122 123
    * Run the installer
    * Start Kismet
    * Pick your AirPcap or Kismet Drone sources


    Compiling it yourself:

128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152
    * Download the Cygwin setup tool (
    * Install Cygwin with make, GCC, libncurses, libncurses-dev
    * Download the Airpcap_Devpack from CACE Support
    * Put Airpcap_Devpack and Libpcap_Devpack in the kismet source directory
    * Run "./configure", adding the options:
        --with-airpcap-devpack=... --with-winpcap-devpack=...
      The airpcap/winpcap devpack is available from the CACE website.
      Due to bugs in Cygwin, it appears that the airpcap and winpcap
      directories must be inside the kismet source directory.  If they are
      not, the Kismet binary will immediately exit with no output.
    * Compile Kismet with "make".
    * Install Kismet with "make install"


3c.  OSX/Darwin quick start

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

    * Download Kismet from
155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195
    * Run "./configure".  Pay attention to the output!  If Kismet cannot
      find all the headers and libraries it needs, major functionality may
      be missing.  Notably, you may need to install libpcap manually.

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

      Configure will automatically detect OSX and default to the group
      "staff" for OSX suidinstall.  This may be overridden with the
      '--with-suidgroup' configure option.

    * Compile Kismet with "make".
    * Install Kismet with either "make install" or "make suidinstall".
    * If you have installed Kismet as suid-root, add your user to the
      "staff" group if it is not already.

    * Run "kismet".  If you did not install Kismet with suid-root support,
      you need to start it as root in nearly all situations.  This is not
      recommended as it is less secure than privsep mode, where packet
      processing is segregated from admin rights.
    * When prompted to start the Kismet server, choose "Yes"
    * When prompted to add a capture interface, add your wireless interface.
      In nearly all cases, Kismet will autodetect the device type and
      supported channels.  If it does not, you will have to manually define
      the capture type (as explained later in this README)

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

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

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

196 197

198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288
4.  Suidroot & Security

    In order to configure the wireless card for monitor mode and start
    capturing packets, Kismet needs root access.  There are two ways to
    accomplish this:  Start Kismet as root, or install it so that the
    control components are set to start as root.

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

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

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

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

    Under no situation should the kismet_server binary itself be set
    suidroot as this will bypass any security checks.

5.  Capture sources

    All packets in Kismet come from a capture source.  Capture sources are
    typically network cards on the local system, however they can also be a
    previously recorded file or a remote capture system running a Kismet

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

    Kismet captures packets at the 802.11 layer.  This requires changing the
    mode of the network interface, making it unavailable for normal use.  In
    most cases it is not possible to remain associated to a wireless network
    while running Kismet on the same interface.

    Capture sources may be added via the Kismet UI under the "Add Source"
    option, in which case the options may be added under the "Options:"
    field, comma separated.  They may also be defined in the kismet.conf
    configuration file as the "ncsource=" option, such as:

    Source options:
      name=foo          Custom name for the source (otherwise it will be
                         named the same as the capture interface).  This is
                         completely arbitrary and meaningful only to the
      type=foo          Sources which can not autodetect the type must have
                         the type specified.  This is rarely necessary.
                         Additional information on supported source types
      uuid=foo          Users wishing a static unique identifier on sources
                         may specify one here.  This is not necessary for
                         most users.  UUID is of the format:
      hop=true|false    Disable channel hopping on this source.  Default
                         behavior is for channel sources to hop channels to
                         cover the entire spectrum.  
      velocity=#        Channel hop velocity (number of channels per
                         second), Kismet can hop 1-10 channels per second.
      dwell=#           Channel dwell time, the number of seconds Kismet
                         will wait on each channel.  If hopping is enabled
                         and a channel dwell time is specified, Kismet will
                         hop at N seconds per channel, instead of N channels
                         per second.
      channellist=name  Use an alternate channel list instead of the
                         autodetected list of channels supported by this
                         interface.  The channellist must be defined.
      split=true|false  When multiple sources use the same channel list
                         (either autodetected or by the channellist= option)
                         Kismet will split them so that they do not cover the
                         same channels at the same time.  Sources can be 
                         forced to ignore this and begin hopping at the
                         beginning of the channel list regardless of overlap.
      retry=true|false  Kismet will attempt to re-open a capture source
                         which has encountered an error.  This behavior can
                         be disabled if the user wants the source to remain
      vif=interface     Create a secondary named interface for capture
290 291 292 293
                         instead of trying to change the mode of the
                         existing interface.  This is primarily only for use
                         by drivers using the mac80211 interface under
                         Linux.  Users wishing to do Kismet+Managed or
294 295
                         Kismet+Injection should create a VIF.
      forcevif=t|f      True/False.  Force creation of a monitor-mode VIF
                         when possible (all Linux mac80211 based drivers
                         support this).  Default is "true", a VIF will be
                         made of the name '<interface>mon', ie 'wlan0mon',
                         'wlan1mon' and capture will be done with this VIF.
                         This behavior can be forced OFF with
301 302
      wpa_scan=time     When using a mac80211 VIF, Kismet can use
303 304 305
                         wpa_supplicant on a managed interface to trigger
                         hardware assisted scans, enabling some view of the
                         rest of the spectrum without significantly
                         disrupting operation of the managed VIF.  Suggested
                         time for scan intervals is 15 seconds.
308 309 310 311 312
      validatefcs=t|f   True/False.  Kismet will normally attempt to validate
                         checksums to ensure the frames received are valid.
                         Many drivers return bogus frames in monitor mode.
                         If you want to process all packets regardless of
                         apparent validity, set validatefcs=false.
313 314 315 316 317 318 319 320
      fcs=true|false    Force handling of FCS bytes on a packet source.
                         Default is "false", which implies "native FCS
                         handling".  Packet sources which include per-packet
                         headers like radiotap or PPI will ignore this value
                         as the FCS is encoded in the radio header.  Packet
                         sources such as pcapfile, reading raw 802.11 pcap
                         files with no headers, may need this turned on for
                         proper behavior.
      fcsfail=true      Force a mac80211 VIF to report packets with a known
322 323
                         bad FCS (packet checksum).  This is only available
                         on Linux and only when using mac80211 drivers.
                         This MUST come after a 'vif=' option or it will be
325 326 327 328 329 330 331 332 333 334
                         ignored.  Enabling 'fcsfail' will enable
                         'validatefcs' automatically.  The 'fcsfail' option 
                         should only be enabled when logging to PPI; Logging
                         to normal PCAP will not preserve the FCS data and
                         will produce unreadable output.
                         WARNING:  With some driver versions, enabling this
                         seems to cause kernel OOPS warnings and the
                         interface will become unresponsive if capture is
                         stopped and resume.  This option is for specific
                         expert use only, when in doubt, leave it alone.
      plcpfail=true     Force a mac80211 VIF to report packets which do not
336 337 338 339
                         pass the PLCP check (if possible on that
                         interface).  The same warnings and conditions as
                         'fcsfail' apply.  This option is for specific,
                         expert use only, when in doubt, leave it alone.
340 341 342 343
      ignoreprimary=t   Ignore the state of the primary interface on
                         mac80211.  Normally, Kismet will shut down the
                         main interface (ie wlan0, wlan1) to prevent wpasupp
                         or NetworkManager from changing the channel, etc.
344 345 346 347 348 349 350 351 352

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

      Capture on wlan0, 802.11b channels only even if it supports 5GHz

      Create a VIF on wlan0 named wlan0mon and use wpa_supplicant to
354 355
      give us some view of other channels, while remaining associated to a
357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424

      Read from a pre-recorded pcap file:

      Capture using the first Airpcap device on Windows

      Capture using a remote capture drone

    Channel lists:

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

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

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


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


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

    Ranges may consist of channels or of frequencies.


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


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


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

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


6.  Caveats and quirks for specific drivers:

    Mac80211 General (Linux):

428 429 430 431 432
      At the time of this release, the mac80211 drivers in Linux are
      undergoing significant development, which means at any given time they
      can exhibit extremely odd behavior or be outright broken.  Users are
      encouraged to upgrade to the latest kernel, and to consider installing
      the compat-wireless backport package, if problems are experienced.

434 435 436
    Madwifi (Linux):

      Madwifi-ng has been largely deprecated by ath5k/ath9k for normal
      usage.  These drivers support multi-VIF more cleanly via the mac80211
438 439
      layer and do not, typically, have the same problems historically
      present in madwifi.  
      Madwifi-ng sources can be specified as either the VIF (ath0, mon0,
442 443 444
      etc) or as the control interface (wifi0, wifi1).  However, IF THE
      CONTROL INTERFACE IS SPECIFIED, Kismet cannot extract the list of
      supported channels, and will default to IEEE80211b channels.

446 447
      Madwifi-ng continues to have problems with multi-VIF and initial VIF
      creation.  It is recommended that the initial VIF creation be turned off
      by the module parameter "autocreate=none" when loading ath_pci.  If the
      madwifi monitor VIF stops reporting packets soon after being created,
      this is often the cause.

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

    RT28xx (Linux)

456 457 458 459 460
      There are 2 drivers for the RT28xx chipsets.  The in-kernel driver
      available as of Linux-2.6.31 works properly with Kismet.  This is by
      far the preferred driver to use.  Be sure to enable the RT28xx driver
      in the wireless drivers section, NOT the staging driver.  The staging
      driver is not mac80211 based and will not necessarily behave.

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

467 468 469
      This driver defaults to the name 'rausbX' which exposes a bug in some
      versions of libpcap and may require the device be renamed (See
      'Troubleshooting' section)

    rt73-k2wrlz (Linux)

473 474
      An out-of-tree rt73 driver similar to rt2870sta.  It may be necessary
      to specify a type of 'rt73' manually when using this driver.

476 477 478
      This driver defaults to the name 'rausbX' which exposes a bug in some
      versions of libpcap and may require the device be renamed (See
      'Troubleshooting' section)

    WL (Linux, Intel)

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

    OTUS (Linux)

490 491 492 493 494 495
      Atheros released a driver for the 802.11n USB devices; however, this
      does not have support for monitor mode and cannot be used with Kismet.
      The ar9170 driver project is providing mac80211 kernel support for
      this card, and works with Kismet.  ar9170 has been merged with the
      wireless-git development kernel and should be present in the
      compat-wireless packages.

    Nokia ITT (Linux)

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

504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662
      The Nokia drivers often return FCS-invalid packets.  The Nokia source
      line should include 'fcs=true,validatefcs=true' to prevent these from
      creating multiple false networks out of invalid packets.

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

    Orinoco (Linux)

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

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

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

    NDISWrapper (Linux)

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

      Note:  The rndis drivers are NOT the same as ndiswrapper.  rndis
      drivers are for a specific USB chipset and are not related to
      ndiswrapper, rndis will work.

    BSD (BSD Generic)

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


    Windows (Generic)


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

    AirPcap (Windows)

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

    USB Devices (OSX)

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

7.  Supported capture source types

    Capture source types are only required in specific situations where
    Kismet cannot detect the capture source type automatically.

    Linux Capture Sources:

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

      adm8211           Kernel adm8211 driver
      acx100            Kernel acx100 driver
      hostap            Kernel prism2 driver
      ipw2100           Kernel Intel 2100 driver
      ipw2200           Kernel Intel 2200 driver
      ipw2915           Kernel Intel 2915 driver
      ipw3945           Kernel intel 3945 driver
      mac80211          Generic mac80211 catch-all source for any mac80211
      madwifi           Madwifi/Madwifi-ng
      madwifi_a         Alias for madwifi, default 802.11a channels
      madwifi_b         Alias for madwifi, default 802.11b/g channels
      madwifi_g         Alias for madwifi, default 802.11b/g channels
      madwifi_ag        Alias for madwifi, default 802.11abg channels
      nokia770          Conexant-based driver in Nokia Maemo tablets
      nokia800          Alias for nokia770
      nokia810          Alias for nokia770
      nokiaitt          Alias for nokia770

      pcapfile          Pcap-formatted previously recorded file
      rt2870sta         Out-of-kernel/Staging rt2870 11n driver (use
                         in-kernel instead)
      wl12xx            Patched wl12xx drivers for the N900, must use
                         patched drivers from,
                         otherwise autodetected.
      drone             Remote Kismet packet capture, source options
                        "host=..." and "port=..." are required.

    BSD Capture Sources:

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

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

      Patches/Additional BSD support welcome.

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

      pcapfile          Pcap-formatted previously recorded file
      drone             Remote Kismet packet capture, source options
                        "host=..." and "port=..." are required.

    Windows Capture Sources:

      SUPPORTED PLATFORM are supported under Windows.  NO OTHER DEVICES CAN

      airpcap           Airpcap generic source.  Will autodetect the channel
                        ranges.  Interface 'airpcap' will detect the first
                        airpcap device (ncsource=airpcap), interface paths
                        may be used to specify specific devices
      airpcap_ask       List available sources and ask which one to use.
                        Should NOT be used when launched by the Kismet UI.

      pcapfile          Pcap-formatted previously recorded file
      drone             Remote Kismet packet capture, source options
                        "host=..." and "port=..." are required.

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

      pcapfile          Pcap-formatted previously recorded file
      drone             Remote Kismet packet capture, source options
                        "host=..." and "port=..." are required.
8.  Plugins

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

    Plugins need access to the Kismet source (and configuration
    information) to compile, and should ALWAYS be recompiled when the 
    Kismet version changes (for those using Kismet Git development code, 
664 665 666 667 668 669 670 671 672 673 674 675
    this may require rebuilding plugins every time a checkout is done).

    Plugins bundled with Kismet (and third-party plugins extracted into the
    Kismet source dir) can be built with 'make plugins' and installed with
    'make plugins-install' or 'make plugins-userinstall'.  These commands
    will automatically configure the plugin to compile using the current
    Kismet source directory, for third-party plugins compiled outside of the
    tree (or for manually compiling plugins), the KIS_SRC_DIR variable must
    be set or the symlinks to the Kismet source must be set up properly (see
    the README for the plugin you are trying to compile for more

676 677 678 679 680 681 682 683
    "Restricted" plugins, which provide potentially invasive behavior such
    as auto-guessing WEP based by the SSID or automatically running the PTW
    WEP attack against captured data can be compiled and installed with:
        make restricted-plugins
        make restricted-plugins-install
        make restricted-plugins-userinstall

684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829
    Plugins for the Kismet server (capture and logging process) are loaded
    from the system-wide plugin directory (/usr/local/lib/kismet/ by
    default) or from the users Kismet settings directory

    When running Kismet with privilege separation enabled (installed
    kismet_capture as root), plugins are only loaded by the Kismet server
    process and not the root-level Kismet capture process, and plugins
    cannot perform tasks that require root privileges.

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

    Server plugins are only loaded when kismet.conf contains:

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

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

    Once a Kismet UI plugin is loaded, it cannot be unloaded.  To unload a
    Kismet plugin, go to the Plugins window, configure the plugin to not
    load on start, and restart Kismet.  To configure plugin loading in the
    UI, select the plugin (the list is automatically generated from plugins
    installed in the system and user plugin directories) and press enter.
    Plugins will be loaded when the plugin window is closed.

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

    If a plugin causes startup problems (most likely because it was compiled
    for a different Kismet binary), Kismet will exit and explain which
    plugin caused the crash during startup.  Plugins may also cause
    instability during runtime; if runtime crashes occur while plugins are
    loaded, remove them and re-test.  Often, recompiling the plugins against
    the running Kismet source will help resolve these issues.

9.  GPS

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

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

    The GPS is controlled with the Kismet server config, kismet.conf.  For
    using gpsd with gpsd running on the local system:


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

    For using a GPS device without gpsd:


    The gpsdevice parameter should be set to the proper serial device for
    your GPS.  For USB GPS devices this will typically be /dev/ttyUSB0, and 
    for bluetooth devices this will often by /dev/rfcomm0 or similar.  Check
    the output of "dmesg" after plugging in your device.

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

    Kismet keeps running averages of the network location, however this is
    not incredibly accurate, due to averaging and imprecision in
    floating point math.  For plotting network locations, the GPSXML file
    should be used.

10. Logging

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

    By default, Kismet will try to log to pcapfiles using the PPI per-packet
    header.  The PPI header is a well-documented header supported by
    Wireshark and other tools, which can contain spectrum data, radio data
    such as signal and noise levels, and GPS data.

    PPI is only available with recent libpcap versions.  When it is not
    available, Kismet will fall back to standard 802.11 format with no extra

    The pcap logging format is controlled by:

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

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

    The default log template with a --log-prefix of /tmp and a --log-title
    of Kismet would expand from:
    to (for example):

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

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

11. Filtering

    Kismet supports basic filtering; networks can be excluded from tracking,
    pcap logging, or general logging, based on BSSID, source, or destination
    MAC addresses.

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

831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276
    This behavior can be inverted by using the '!' operator.  To exclude
    packets to or from the BSSID AA:BB:CC:DD:EE:FF:


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


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


    Similarly, SOURCE(...), DEST(...), and ANY(...) may be used to filter
    packets.  To process only packets FROM the MAC address


12. Alerts & IDS

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

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

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

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


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

    Kismet supports the following alerts, where applicable the WVE (Wireless
    Vulnerability and Exploits, ID is included:

        AIRJACKSSID         Fingerprint         Deprecated
            The original 802.11 hacking tools, Airjack, set the initial SSID
            to 'airjack' when starting up.  This alert is no longer relevant
            as the Airjack tools have long since been discontinued.

        APSPOOF             Fingerprint
            A list of valid MAC addresses for a SSID may be given via the
            'apspoof=' configuration file option.  If a beacon or probe
            response for that SSID is seen from a MAC address not in that
            list, this alert will be raised.  This can be used to detect
            conflicting access points, spoofed access points, or attacks
            such as Karma/Airbase which respond to all probe requests.

            The 'apspoof=' configuration option can specific exact SSID
            matches, regular expressions (if Kismet is compiled with PCRE
            support), and single, multiple, or masked MAC addresses:


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

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

        BSSTIMESTAMP        Trend/Stateful
            Invalid/Out-of-sequence BSS Timestamps can indicate AP spoofing.
            APs with fluctuating BSS timestamps could be suffering an "evil
            twin" spoofing attack, as many tools do not attempt to sync the
            BSS timestamp at all, and the fine-grained nature of the BSS
            timestamp field makes it difficult to spoof accurately.  Some
            APs may reset the BSS timestamp regularly, leading to a


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


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

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

                WVE-2005-0019, WVE-2005-0045, WVE-2005-0046, WVE-2005-0061

        DHCPCLIENTID        Fingerprint
            A client which sends a DHCP DISCOVER packet containing a
            Client-ID tag (Tag 61) which doesn't match the source MAC of the
            packet may be doing a DHCP denial-of-service to exhaust the DHCP

        DHCPCONFLICT        Trend/Stateful
            Clients which receive a DHCP address and continue to use a
            different IP address may indicate a misconfigured or spoofed

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

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

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

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

        LUCENTTEST          Fingerprint         Deprecated
            Old Lucent Orinoco cards in certain scanning test modes generate
            identifiable packets.

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


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


        MSFNETGEARBEACON    Fingerprint
            Some versions of the Windows netgear wireless drivers do not
            properly handle over-sized beacon frames, leading to system
            compromise and code execution.  This vulnerability is exploited
            by the Metasploit framework.

        NETSTUMBLER         Fingerprint         Deprecated
            Older versions of Netstumbler (3.22, 3.23, 3.30) generate, in
            certain conditions, specific packets.

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


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

13. Other Configuration

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

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

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

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

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

    listen=tcp://ip:port     Define the IP and port Kismet listens on.  By 
                              default, for security reasons, Kismet will 
                              listen only on, the loopback interface.  
                              To listen on any interface, use the IP
    allowedhosts=...         Comma-separated list of IP addresses allowed to 
                              connect to the Kismet server.  IP ranges may be 
                              specified with netmasks (ie
    maxclients=N             Maximum number of clients allowed to simultaneously
                              connect to the Kismet server.
    maxbacklog=5000          Maximum number of backlogged "lines" the server
                              keeps for clients which are not keeping up
                              with the network protocol.  This also affects
                              the amount of RAM potentially used by the
                              Kismet server process, and may need to be
                              lowered on extremely RAM-limited systems.

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

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

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

    tuntap_export=true       Enable tuntap export
    tuntap_device=kistap0    Virtual network interface created

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


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

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

        enablesound=true|false  Play sound
        soundbin=...            Path and options for sound player binary
        sound=xxx,true|false    Enable playing sound trigger xxx

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

    The OUI file (used by Kismet to determine the manufacturer of a device)
    can be shared with other tools (such as Wireshark), so long as they use 
    a compatible format.  By default, Kismet searches:
    Additional search paths can be added with the 'ouifile=' configuration

14. Kismet UI

    The default Kismet UI uses the text-based ncurses library.  Additional
    UIs may be available from the Links page on the Kismet website

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

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

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

    - Preferences

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

    By default, the Kismet UI will prompt on startup to launch the Kismet
    server, this behavior (as well as auto-connection and server setup) can 
    be changed via the Startup and Shutdown preferences
    (Kismet->Preferences->Startup and Shutdown):

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

    Kismet menus support shortcuts, for example '~Wl' is the same as
    navigating to the 'Windows->Client List' menu option.

    - Sound and Speech

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

    Speech is supported on Festival and Flite.  Any other text-to-speech
    program should work as long as it accepts plain text on standard in.
    Speech text is encoded depending on the type of speech event, where %1, %2,
    etc are replaced with data by Kismet.  The supported events and
    replacements are:
        New network:
            1. Network SSID encoded to speech encoding setting (spell, nato,
            2. Network channel
            3. Network BSSID
            1. Alert type
        GPS Lost, GPS Lock:
            No replacement options

    - Tagging networks

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

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

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

    - Sorting

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

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

15. Kismet Drones

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

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

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

    To start using Drones, launch the kismet_drone process on a remote
    system (editing the kismet_drone.conf file to control what hosts are
    allowed to connect) or turn on drone capabilities in the Kismet server
    (by enabling the drone config options in kismet_server.conf).  When
    running a kismet_server instance as a drone, local logging will act as
    usual and Kismet clients can be connected to the server as normal; When
    running kismet_drone, Kismet clients cannot connect directly to it, and
    it will not log, a Kismet server instance must be started to provide
    packet decoding, logging, and Kismet UI connectivity.

16. Talking to Kismet

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

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

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


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

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

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

1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305
        Where HEADER is the sentence type, and the remainder are fields
        requested by the client, in the order they were requested.

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

        Fields which may contain a space (used as the separator character)
        are buffered with \001...\001.  As this could be any field, any
        protocol parser should be able to handle fields so buffered.

    Basic Kismet commands include:

        !{#} SHUTDOWN
            Shutdown Kismet instance

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

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

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

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

1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365
        !{#} DELNETTAG {BSSID} {Tag name}
            Remove a tag

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

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

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

    Protocol sentences:

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

    Mandatory sentences:

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

                Basic Kismet startup info
                List of supported sentences
                Command response
                Command failure
                Server timestamp


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

        Enable the *CHANNEL sentence with the fields 'channel' and
        'networks'.  The output could look something like:

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

17. Troubleshooting
1368 1369 1370 1371 1372 1373 1374 1375

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

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

1376 1377
    Some common problems with Kismet have easy solutions:

1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421
    PROBLEM:  Fatal errors about old configuration files/missing config
              Kismet has evolved over time, and has recently had a
              significant rewrite of the entire application, rendering many
              of the old configuration values obsolete, and changing many
    FIX:      Update your config files.  If you are moving to the latest
              release of Kismet, it may be best to just remove your old
              config files, copy the new ones, and reconfigure.

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

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

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

    PROBLEM:  Kismet warns about interfering processes while starting up.
              Many network services can interfere with Kismet (DHCP,
              networkmanager, etc) by reconfiguring or shutting down the
              network interface while Kismet is running.
    FIX:      Only necessary if Kismet is not behaving as expected, or
              encountering errors.  Shutdown or kill the offending
              processes.  This can often be most quickly accomplished by
              stopping the networking services for your interface ('ifdown
              wlan0' for example).  In some specific configurations, these
              alerts may be spurious (dhcp and wpa_supplicant alerts on a
              multi-VIF mac80211 interface doing sta+rfmon with a
1423 1424
              wpa_supplicant scanning option, for example).

1425 1426
    PROBLEM:  Kismet complains about multiple VIFs under madwifi-ng
    FIX:      Destroy the other VIFs, or ignore this warning if there are no
              run-time failures.  Madwifi-ng has historically had
1428 1429
              significant problems with multi-VIF and rfmon (for example, a
              STA VIF and a RFMON VIF).
1430 1431 1432 1433

    PROBLEM:  Shortly after starting on madwifi-ng, Kismet stops reporting
    FIX:      There appears to be a race condition in madwifi-ng startup
              where an autocreated VIF causes errors in future VIFs.  A
1435 1436 1437 1438 1439
              temporary fix is to reload the madwifi-ng driver before
              starting Kismet, with the 'autocreate=none' modparm ('rmmod
              ath_pci; modprobe ath_pci autocreate=none'), a more permanent
              fix is to put this in the default module parameters for
              ath_pci and make the necessary changes to your startup scripts
              to create a managed VIF on startup.
1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493

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

    PROBLEM:  Kismet exits immediately on Cygwin with no output.
    FIX:      Cygwin appears to have problems linking static libraries when
              they are not in a sub-directory of the build.  By default,
              './configure' will look in "Airpcap_Devpack" and
              "Winpcap_Devpack", you should probably just expand the devpack
              zips there.

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

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

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

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

    PROBLEM:  Kismet cannot open a source, with the error:
              "can't get usb bus index"
    FIX:      Some versions of LibPcap interpret any interface with "USB"
              in the name as a USB device on Linux, and attempt to do USB
              bus capture instead of packet capture.
              Rename the interface (with ifrename or udev rules) to
              something that doesn't include 'usb'.  A newer version of
              libpcap may also resolve this problem.

    PROBLEM:  configure cannot find libnl on Ubuntu, but libnl-dev is
    FIX:      Some distributions (apparently, Ubuntu) require
              libnfnetlink-dev to be installed as well.  Currently there is
              no good way to autodetect this.
1494 1495 1496 1497

18. Frequently Asked Questions

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

    Q: Is there anything illegal about Kismet?
1505 1506 1507 1508 1509
    A: In and of itself, there should be nothing illegal about Kismet (it's
       fundamentally no different than any other capture tool) but you
       should check your local laws first.  Note, however:
        - Recording data from networks that you do not have permission to
          may be considered an illegal wiretap.
        - Using networks you do not have permission to use may be considered
1511 1512
          'Theft of Service' and is illegal.
        - Don't be stupid.
1513 1514
        - If you are stupid, I'm not responsible.

1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529
    Q: Can Kismet crack WEP?
    A: Yes, but also, no.  The base Kismet code does not do any WEP
       cracking, however due to constant requests, there IS an Aircrack-PTW
       plugin which will do PASSIVE WEP cracking only.  It will NOT do
       arp-replay, fragmentation, or other active attacks, however if enough
       packets are gathered it will attempt to crack the WEP key and insert
       it into Kismet to decrypt that network.
       The PTW-WEP cracking plugin is in the Kismet source tree in the
       plugin-ptw/ directory.

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

    Q: What happened to the version numbers?
1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560
    A: They stopped making sense.  3.0 to 3.1 was a 30,000 line change, but
       calling it 4.0 didn't make any sense either.  I hate project
       perpetually in 0.1, 0.9 status, but I also hate artificially
       expanding the version numbers.  So, now, it's versioned by the
       release date, YYYY-MM-RR.

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

    Q: Can I use the old drones still?
    A: No, again, too much has changed (however from now on it should be 
       possible to mix versions since the drone protocol has been expanded
       to be expandable)

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

    Q: Does Kismet work differently than NetStumbler?
1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608
    A: Absolutely.  Netstumbler (and Ministumbler, InSSIDer, etc) work by
       instructing the card to probe for networks and report the networks
       the card sees responses from.  This method is obviously competent at
       detecting networks in the area, however it can't record data, find
       hidden networks, detect clients using networks, etc.

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

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

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

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

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

    Q: Why does Kismet make a new interface named foo-mon?
    A: When mac80211 is available, Kismet will use to create a new virtual
       interface, named after the existing interface (wlan0 for instance
       will cause a wlan0mon to be created).  Kismet will use this virtual
       interface for capture, so that it causes less disruption to the
       configuration of the existing interface.

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