(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:
*ERROR
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.)
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:
!0 REMOVE TIME
(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:
!0 CAPABILITY ALERT
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:
!0 ENABLE ALERT *
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
discretion.
*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):
ALERT,NETWORK,CLIENT,GPS,INFO,REMOVE,STATUS,PACKET,STRING,WEPKEY,CARD
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
!{ID} PAUSE
Pause the packet sources
!{ID} RESUME
Resume capturing from the packet sources
!{ID} LISTWEPKEYS
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.
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.