Kismet Protocol Tutorial

(Note that this tutorial applies to the old version of Kismet only, now deprecated, and not the Newcore version.)


The protocol is a simple line-by-line text-based exchange of messages. You can explore it by connecting to port 2501 on the server machine using telnet, e.g.


$telnet localhost 2501


All messages from client to server are of the form:


!<id> <command>


where <id> is a serial number used in corresponding acknowledgements, and <command> must always be upper case. In a single-threaded implementation it’s fine to make <id> always the same, e.g. “1”. N.B. if you make it “0”, you won’t get acknowledgements!


All messages from server to client are of the form:


*<header>: <data>


In particular:


*ACK 1


acknowledges acceptance of command id 1, and:




says the last command was not understood.


On initial connection, kismet will send:


*KISMET <Version> <Start time> <Server name> <Build Revision>


(Not that <Start time> and all other times are in seconds since 1/1/1970.)

Capabilities and Protocols

The protocol is meant to be extensible. Thus, following the “*KISMET” line, the server will report:


*PROTOCOLS <protocol list>


where <protocol list> is a comma-separated list of the server messages (i.e. values of <header>) that this Kismet server can send. Those you don’t want can be turned off, for example to turn off *TIME messages, use the command:




(If you’re exploring with Telnet, you’ll want to do this immediately to switch off time stamps which are otherwise sent every second.)


Others, not enabled by default, can be enabled. However, some of the messages from the server contain data, which might vary from version to version. In order to find out what can be returned by a response (e.g. ALERT), send:




This will solicit a response such as:


*CAPABILITY: ALERT sec,usec,header,bssid,source,dest,other,channel,text


You can turn alerts on with a command such as:




Alternatively, you can turn on alerts with specific data returned by replacing the “*” with a list of required fields selected from the capability list.


The following protocols (server message types) are enabled by default, but may be switched off with REMOVE:


*KISMET: {Version} {Start time} {Server name} {Build Revision}

  Initial identifier

*ACK: {Command ID}

  Acknowledgement that a command was processed.  If your client doesn't care

  about acknowledgements, this can be ignored or commands can be sent with an

  ID of 0.

*ERROR: {String}

  Error response for an invalid request.  The simplest way to handle this is to

  print it as a status message.  More advanced handling can be added at your


*PROTOCOLS: {Comma-delimited string of supported protocols}

  List of protocols this server supports

*CAPABILITY: {Protocol} {Comma-delimited string of fields}

  Capability of a specific protocol

*TERMINATE: {String}

  Server termination

*TIME: {Current time}

  Current server time in seconds since the epoch


The *PROTOCOLS server message lists the above, and additional server messages that can be requested with ENABLE, specifically (in the current version):




The following commands are accepted (some already discussed, and all preceded, of course, with “!{id} ”.)


!{ID} CAPABILITY {Protocol}

  Request that a *CAPABILITY line be sent for the protocol

!{ID} ENABLE {Protocol} {Comma-delimited string of requested fields}|{*}

  Enable sending a protocol with the requested field order.  * enables all

  fields in the default order.

!{ID} REMOVE {Protocol}

  Stop sending a protocol


  Pause the packet sources


  Resume capturing from the packet sources


  Lists WEP decryption keys if the server allows this.

!{ID} ADDWEPKEY {bssid},{hex key}

  Add a WEP decryption key for the given BSSID. (Space, not comma between args?)

!{ID} DELWEPKEY {bssid}

  Remove the WEP key for a give BSSID.

!{ID} CHANLOCK {src} {chan}

  Lock source {src} (0 <= {src} <= number of wireless cards - 1) to given channel. (Note: space not comma between parameters.)

!{ID} CHANHOP {src}

  Allow source {src} to hop.

Bugs and quirks

Some (all) of these may be limitations in my understanding.

·        I’ve never got ADDWEPKEY (and hence DELWEPKEY) to work.

·        Having done ENABLE TERMINATE * I still get nothing when the server terminates.



Return to the kismetaclient page.