New Server ModelRecently I've seen several questions about connecting to the Kismet server with scripting tools - while possible with the stable/old Kismet, it's so much easier under the git-master code that I strongly recommend anyone developing something new that draws from Kismet look at runnign the git-master version instead.
The new Kismet code uses an embedded webserver (libmicrohttpd) to serve data as a collection of REST-like endpoints.
Data is now stored in Kismet in introspectable (meaning they can be processed by the code automatically without having to know what they contain beforehand) dictionary-like (meaning they're usually structured as a collection of "key" = "value" records) objects.
The upshot of this is that they can be converted into interchange formats like JSON and exported as complete objects; Unlike the old Kismet protocol which was line-based and generally operated like a relational database: Nested data had to be represented with multiple different server sentences, with a common key to correlate them.
By exporting complete objects, we are able to use a single request to represent an entire complex, nested entity. By using introspectable objects, we're able to add new data to it without having to change the export code, which means plugins (and future Kismet code itself) can easily expand the data tracked for a device (or add whole new types of data), and by using a REST-like interface we can organize it simply and use common, standard protocols to access it.
Currently Kismet data can be exported as JSON or binary Msgpack. The format and field names on both should be identical - you can pick which you prefer by requesting a '.json' or a '.msgpack' field. In the future, XML export may be possible, but JSON solves nearly all the problems XML would, and has simpler parsers in most languages.
Kismet also has a few special interfaces which export other data - notably the /system/tracked_fields.html interface which shows a HTML-formatted table of every named field Kismet knows about & their descriptions (great for looking up how a field is used without digging into the code), and the /phy/phy80211/handshake/[device]/[device]-handshake.pcap interface, which allows downloading a dynamically-created PCAP file.
All the currently available interfaces are defined in the webui_rest document:
which documents how to reach them, what they do, and what parameters they take.
There is a python class for handling interacting with Kismet and a collection of code doing interesting things with it at:
Part 2 will focus on some of the specifics and provide some examples for doing interesting things, stay tuned!
A huge thanks to all who support Kismet on Patreon - if you'd like to help, you can become a patron here!