<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Plugins on Kismet</title><link>/docs/dev/plugins/</link><description>Recent content in Plugins on Kismet</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Sun, 01 Nov 2026 01:00:00 -0400</lastBuildDate><atom:link href="/docs/dev/plugins/index.xml" rel="self" type="application/rss+xml"/><item><title>Plugins</title><link>/docs/dev/plugins/plugins/</link><pubDate>Fri, 11 Nov 2022 14:04:57 -0500</pubDate><guid>/docs/dev/plugins/plugins/</guid><description>Kismet can load additional code dynamically at runtime in the form of a plugin.
Plugins are a double-edged sword: In their current implementation, plugins are full first-class citizens in the Kismet ecosystem; a plugin can perform any action Kismet native code can perform, and are given a direct reference to the internal Kismet module system.
C++ plugin code #
Kismet has long supported C++ plugins which load as .so shared object files.</description></item><item><title>Plugins Manifest</title><link>/docs/dev/plugins/plugins_manifest/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/plugins_manifest/</guid><description>Every plugin has a manifest, manifest.conf, in its directory. The manifest says what the plugin is and what it loads: a shared object, an external helper, web UI modules, and device rules. A plugin with no native code, such as one which only adds to the web UI or ships device rules, needs nothing but the manifest and its files.
Plugin directory #
A plugin is a directory in one of the plugin locations, named for the plugin:</description></item><item><title>Writing UI plugins</title><link>/docs/dev/plugins/uiplugins_intro/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_intro/</guid><description>Added: after 2026-10-R1
⚠️ The new Kismet UI, and its plugin interface, are changing quickly in the nightly builds. The registries and options described here may change before they are in a Kismet release. Come talk to us on the Kismet Discord server if you&amp;rsquo;re writing a UI plugin!
The new Kismet web UI is built from plain JavaScript modules, with no build step. Everything in it, from the device list columns to the Wi-Fi details, is added by a module through the same interface a plugin uses: the built-in parts of the UI (in http_data/js/base/) and each phy&amp;rsquo;s module (in http_data/js/phy/) are the best examples of how to write one.</description></item><item><title>The device list</title><link>/docs/dev/plugins/uiplugins_devicelist/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_devicelist/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
The device list is built from the columns, icons, and row highlights modules register. It asks the server only for the fields the visible columns, icon, and highlights list, so each of them says what it reads in fields (see fields).
Columns #
kismet.ui.deviceColumns holds the columns users can pick from.</description></item><item><title>Device details</title><link>/docs/dev/plugins/uiplugins_details/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_details/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
Clicking a device opens its details panel, which is made of sections registered by modules: the common details from js/base/details.js, and a section from each phy for its own devices.
Sections #
kismet.ui.deviceDetails holds the sections.
Option id, title, priority The section match(device) Whether the section applies to a device fields The section&amp;rsquo;s rows, as a list of field entries (below) render(device, el) Or draw the section yourself; called again with fresh data each time the device changes open Start expanded (default true); the user&amp;rsquo;s choice is remembered A section has fields, render, or both; render draws into its own space below the fields.</description></item><item><title>Tabs, menus, and settings</title><link>/docs/dev/plugins/uiplugins_page/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_page/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
The parts of the page around the device list, the tabs, the main menu, the stats across the top, and the settings dialog, are registries too.
Tabs #
kismet.ui.panes holds the tabs in the page&amp;rsquo;s two tabbed areas: 'main' (Overview, Devices, SSIDs, Alerts, Map, and so on) and 'bottom' (Messages).</description></item><item><title>Overview and map</title><link>/docs/dev/plugins/uiplugins_overview_map/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_overview_map/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
Overview cards #
The Overview tab is a grid of cards from kismet.ui.dashboardCards. Users arrange, resize, hide, and add back cards with Edit layout; the layout is kept per browser.
Option id, title, priority The card w, h Its starting size on the 12-column grid, in columns and rows (3 × 5 if not given) needs The shared data it reads (below) loading The outline shown until that data arrives: one or a list of 'stat', 'tabs', 'graph', 'histogram', 'bars', 'list', 'table', 'donut', 'text' (the default), stacked top to bottom create(body, { actions }) Builds the card; returns { update(data), destroy() } onClick(actions) Optional: called when the card is clicked (anywhere but its own buttons and links) actions.</description></item><item><title>Data sources and channels</title><link>/docs/dev/plugins/uiplugins_sources/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_sources/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
The Data sources window shows a card for each source, built from sections like the device panel. The standard sections (js/base/sources.js) work for every source; a phy module adds its own for the capture drivers it knows, such as the Wi-Fi channel layout or a cell modem&amp;rsquo;s DIAG capture (js/phy/cell.</description></item><item><title>Insights</title><link>/docs/dev/plugins/uiplugins_insights/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_insights/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
The Insights tab draws a graph of how devices relate, their activity over time, and a list of unusual things. The base code only knows devices; each phy module adds what it knows about how its devices relate (a Wi-Fi client and its access point, a network name and the devices which advertise or probe for it) and what it finds unusual.</description></item><item><title>The kismet object</title><link>/docs/dev/plugins/uiplugins_core/</link><pubDate>Sun, 01 Nov 2026 01:00:00 -0400</pubDate><guid>/docs/dev/plugins/uiplugins_core/</guid><description>Added: after 2026-10-R1
⚠️ The UI plugin interface is changing quickly in the nightly builds, and may change before it is in a Kismet release.
Besides the registries in kismet.ui, the kismet object a module&amp;rsquo;s register() gets holds what modules use to talk to the server and draw their own UI. Each part is a module in http_data/js/core/ or http_data/js/widgets/, and the comments at the top of each file describe it in full.</description></item></channel></rss>