Client/Server Protocol The Kismet client/server protocol has evolved over time, but is finally (as of this writing) at a stable state. This new method of communication allows a client to request only the protocols which are of interest, AND to control the fields and field order that these protocols are sent with. This removes the disruption the addition of new protocols and new tracking data caused to independent clients. The basics of the protocol are as follows: The server->client protocol consists of one-line statements of the format: *{HEADER}: {Data} {HEADER} denotes the type of protocol, ie KISMET, NETWORK, TIME, etc. {Data} denotes the free-form data for this protocol. Multi-field data is seperated with spaces. Any data field that may contain spaces is buffered by \001{Field}\001. This buffering is not used for protocols such as STATUS which return only a single field. The client->server commands consist of one-line statements of the format: !{ID} {COMMAND} {Options} {ID} is a unique numerical identifier (timestamp is often used) which is used by the server to return an error condition for a specific command. If {ID} is set to 0, no ACK is returned. {COMMAND} is the command to be run (ie, ENABLE, REMOVE, CAPABILITY) {Options} are the options for that command. Basic client support: The server expects every client to handle the following basic protocols, and automatically enables them for that client at connect time. All other protocols must be specifically request. *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 server supports the following commands: !{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. !{ID} DELWEPKEY {bssid} Remove the WEP key for a give BSSID. An example session: Connected to localhost. Escape character is '^]'. KISMET: 2.7.1 1038236534 `"Gir"` 20021118101152 *PROTOCOLS: KISMET,ERROR,PROTOCOLS,CAPABILITY,TERMINATE,TIME,NETWORK,CLIENT,GPS,INFO,REMOVE,STATUS,PACKET,ALERT,STRING !1234 CAPABILITY NETWORK *ACK: 1234 *CAPABILITY: NETWORK bssid,type,ssid,beaconinfo,llcpackets,datapackets,cryptpackets,weakpackets,channel,wep,firsttime,lasttime,atype,rangeip,gpsfixed,minlat,minlon,minalt,minspd,maxlat,maxlon,maxalt,maxspd,octets,cloaked,beaconrate,maxrate,manufkey,manufscore,quality,signal,noise,bestquality,bestsignal,bestnoise,bestlat,bestlon,bestalt,agglat,agglon,aggalt,aggpoints !1235 ENABLE NETWORK bssid,type,ssid *ACK: 1235 *NETWORK: 00:40:96:55:A2:72 0 `p@thf1nd3r` *NETWORK: 00:A0:F8:41:3C:DD 0 `KrullNet1` ... PROTOCOL and CAPABILITY processing is left to the discretion of the client author - they may be ignored with the understanding that a request for an unknown protocol or an unknown field will result in an error, or they can be processed to verify that the server accepts all the desired fields.