Kismet 2020-12-R3 is live!
You can get the 2020-12-R3 release from the Kismet downloads page, where you can get both the source and packages for several distributions.
Changes and Updates
Kismet 2020-12 brings with it some tremendous changes, with quite a lot of work on performance, memory use, and compatibility while also bringing in some significant new features.
The 2020-12-R2 update fixes two minor issues discovered with the initial 2020-12-R1 release (improper assignment of system endpoints to the logon role instead of read-only, and a broken implementation of legacy TCP remote capture on python-based sources).
The 2020-12-R3 update fixes another issue with datasources built on systems w/out modern libwebsockets support (buster, etc) where the datasource would not launch properly.
All new ASIO networking model
Kismet now uses the C++ ASIO networking library. This is a huge change under the covers which brings some improved performance and enhanced options across platforms. This new code affects data sources, gps, remote capture, serial port interfaces, etc.
All new web server implementation
Libmicrohttpd was showing issues, from library changes breaking C++ builds to MacOS compatibility issues and missing features. Kismet now has an entirely new webserver implementation based on the C++ Beast library.
The new webserver core also brings a proper URL router, more consistent internal APIs for defining endpoints, websocket support, and pipelined request support.
New role based REST API
All endpoints now implement a basic role system and support API tokens for authentication. Roles allow for simple restrictions, and include unrestricted admin, read only, and data capture.
Remote capture over websockets
While the old TCP socket is still supported for remote capture, data sources can now connect to the Kismet server via a websocket endpoint on the standard webserver port (2501).
The remote capture can now be protected with the admin login or be given an API key with the ‘datasource’ role. Remote capture can be wrapped in SSL when Kismet is behind a proxy, and remote capture websockets can be routed through a proxy like nginx, enabling exposing the remote capture target of an internal server.
For legacy TCP based remote capture, you will now need to pass the
--tcpoption to the remote capture tool during startup.
For more info about setting up remote packet capture, (check the remote capture docs)[/docs/readme/datasources_remote_capture/#websockets].
Huge RAM savings
Testing of the new device records, MAC address handling, changes to the field layout, and new location storage methods show the total RAM usage to be about 20% of previous releases.
Real world testing has shown around 40,000 devices in around 400MB of RAM on a 32 bit pi4.
Changes to how kismetdb logging is prepared and locked, how datasources are launched, improved locking semantics, and improved IO paths should decrease the chance of deadlocks under busy environments.
Higher performance web UI
The web UI now takes advantage of the websockets support and new websocket APIs to provide push-style real-time updates instead of the older polling methods.
Graphs, messages, alerts, and most other portions of the web UI are now pushed via a websocket.
New websocket APIs
The internal Kismet event bus is now exposed as a websocket with a subscription API. Consumers can subscribe to event topics with an optional list of simplified fields to get real-time updates. Topics include messages, alerts, GPS, memory and system statistics, new detected devices, source errors and reopening events, and more.
There is also a new device monitoring websocket which allows a consumer to request a pushed device record, with optional simplified fields, at an arbitrary interval, for one or more devices.
There are two new ADSB websocket endpoints which provide raw ADSB packets as a hex stream or as an adsb-beast binary stream to connect other ADSB tools.
Better location averaging
Real-time location averaging now uses combined vectors instead of simple raw averages.
Improved channel and signal mapping
Signal and channel data is now applied to the source of a packet but not the other related devices such as the destination or bssid.
Improved 802.11 WDS handling
Handle 802.11 WDS frames more correctly, breaking apart the addressing scheme in a more consistent manner without creating spurious linkages as clients.
General improvements and changes to the REST API
Check here for a full list of changes and improvements to the REST API!
If you’re looking to package Kismet, have a look at the packaging guidelines.