-{{ .Get 0 }} / --{{ .Get 1 }}{{ if gt (len .Params) 2 }}={ {{ .Get 2 }} }{{ range after 3 .Params}} / { {{.}} }{{end}}{{end}}
4 |
5 | {{ .Inner | markdownify }}
6 |
7 |
8 |
9 |
--------------------------------------------------------------------------------
/content/en/docs/api/gps.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-02T22:23:58-04:00
6 | lastmod: 2022-11-02T22:23:58-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps-d6174f067cbce4e11efde408e686af66"
12 | weight: 290
13 | toc: true
14 | ---
15 |
16 | {{< kismet_api gps >}}
17 |
--------------------------------------------------------------------------------
/content/en/docs/readme/configuring/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Configuring"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-26T13:22:38-04:00
6 | lastmod: 2022-08-26T13:22:38-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "configuring-785b6a212c899b796762881ca95329b7"
12 | weight: 30
13 | toc: true
14 | ---
15 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Datasources"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-26T12:03:39-04:00
6 | lastmod: 2022-08-26T12:03:39-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "datasources-6fed852bbd9d9556616eae3a1e6cf940"
12 | weight: 60
13 | toc: true
14 | ---
15 |
--------------------------------------------------------------------------------
/content/en/docs/api/adsb.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "ADSB"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-08T21:59:25-05:00
6 | lastmod: 2022-11-08T21:59:25-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "adsb-7f709927fd226622b98ff18671d2056a"
12 | weight: 400
13 | toc: true
14 | ---
15 |
16 | {{< kismet_api adsb >}}
17 |
--------------------------------------------------------------------------------
/content/en/docs/api/channels.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Channels"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-31T23:26:20-04:00
6 | lastmod: 2022-10-31T23:26:20-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "channels-b6fd2acb41ec9824ba6380fab205c8b2"
12 | weight: 270
13 | toc: true
14 | ---
15 |
16 | {{< kismet_api channels >}}
17 |
--------------------------------------------------------------------------------
/content/en/docs/api/eventbus.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Eventbus"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-24T20:28:04-04:00
6 | lastmod: 2022-10-24T20:28:04-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "eventbus-92a731cc3f27f9edffc9a84167bbb705"
12 | weight: 220
13 | toc: true
14 | ---
15 |
16 | {{< kismet_api eventbus >}}
17 |
--------------------------------------------------------------------------------
/content/en/docs/api/system.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "System status"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-23T22:05:47-04:00
6 | lastmod: 2022-10-23T22:05:47-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "system-0e915e184f3424058e8e737b372e6f5b"
12 | weight: 210
13 | toc: true
14 | ---
15 |
16 | {{< kismet_api system >}}
17 |
--------------------------------------------------------------------------------
/babel.config.js:
--------------------------------------------------------------------------------
1 | module.exports = {
2 | presets: [
3 | [
4 | '@babel/preset-env',
5 | {
6 | targets: {
7 | browsers: [
8 | // Best practice: https://github.com/babel/babel/issues/7789
9 | '>=1%',
10 | 'not ie 11',
11 | 'not op_mini all'
12 | ]
13 | }
14 | }
15 | ]
16 | ]
17 | };
--------------------------------------------------------------------------------
/i18n/nl.yaml:
--------------------------------------------------------------------------------
1 | - id: get-started
2 | translation: "Aan de slag"
3 |
4 | - id: on-this-page
5 | translation: "Op deze pagina"
6 |
7 | - id: search-text
8 | translation: "Zoeken..."
9 |
10 | - id: 404-title
11 | translation: "Pagina niet gevonden :("
12 |
13 | - id: 404-text
14 | translation: "De gezochte pagina bestaat niet of deze is verplaatst."
15 |
16 | - id: browse
17 | translation: "Browse"
18 |
--------------------------------------------------------------------------------
/archetypes/docs/lorem/ipsum/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Ipsum"
3 | description: ""
4 | lead: ""
5 | date: 2022-01-25T14:41:39+01:00
6 | lastmod: 2022-01-25T14:41:39+01:00
7 | draft: false
8 | images: []
9 | type: docs
10 | menu:
11 | {{ .Section }}:
12 | parent: "lorem"
13 | identifier: "{{ .Name }}-{{ delimit (shuffle (split (md5 .Name) "" )) "" }}"
14 | weight: 100
15 | toc: true
16 | ---
17 |
--------------------------------------------------------------------------------
/content/en/_index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title : "Kismet: Wi-Fi, Bluetooth, RF, and more"
3 | description: "Kismet is a sniffer, WIDS, and wardriving tool for Wi-Fi, Bluetooth, Zigbee, RF, and more, which runs on Linux and macOS"
4 | lead: "Kismet is a sniffer, WIDS, and wardriving tool for Wi-Fi, Bluetooth, Zigbee, RF, and more, which runs on Linux and macOS"
5 | date: 2022-08-07T00:00:00+00:00
6 | draft: false
7 | images: []
8 | ---
9 |
--------------------------------------------------------------------------------
/content/en/docs/api/wifi_dot11.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wi-Fi (phy80211)"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-07T09:43:44-05:00
6 | lastmod: 2022-11-07T09:43:44-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "wifi_dot11-f2095f481f6103fc1745af957df0d34d"
12 | weight: 370
13 | toc: true
14 | ---
15 |
16 | The Kismet `phy80211` layer processes Wi-Fi packets and devices.
17 |
18 | It provides additional APIs for Wi-Fi related data.
19 |
20 | {{< kismet_api phydot11 >}}
21 |
--------------------------------------------------------------------------------
/content/en/docs/api/plugins.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Plugins"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-06T15:16:09-05:00
6 | lastmod: 2022-11-06T15:16:09-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "plugins-61cc5a77b221106d7ad36c1ff49380b6"
12 | weight: 330
13 | toc: true
14 | ---
15 |
16 | Kismet plugins may be integrated C++ code (loaded as a shared object), external binaries communicating
17 | over IPC, or Javascript/HTML web UI extensions.
18 |
19 | {{< kismet_api plugins >}}
20 |
--------------------------------------------------------------------------------
/content/en/docs/api/uav_drone.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "UAV drones"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-08T21:52:53-05:00
6 | lastmod: 2022-11-08T21:52:53-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "uav_drone-761a97a5034a56ae216a8ca7c13d6788"
12 | weight: 390
13 | toc: true
14 | ---
15 |
16 | Kismet can identify UAVs and drones both by specific fingerprints (such as DJI DroneID elements in
17 | WiFi beacons) or by common SSIDs and manufacturers.
18 |
19 | {{< kismet_api uav_drone >}}
20 |
--------------------------------------------------------------------------------
/content/en/docs/api/logging.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Logging"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-06T20:09:25-05:00
6 | lastmod: 2022-11-06T20:09:25-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "logging-6ca587dafeaa29caf07782b84adaf715"
12 | weight: 350
13 | toc: true
14 | ---
15 |
16 | Kismet has a centralized logging engine which supports many formats of logs.
17 |
18 | Streaming logs like PCAP-NG also integrate with the [streams API](/docs/api/streams/)
19 |
20 | {{< kismet_api logging >}}
21 |
--------------------------------------------------------------------------------
/data/kismet/api/poi.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "Create a POI"
3 | uri: "/poi/create_poi"
4 | types: ["cmd"]
5 | roles: ["admin"]
6 | methods: ["POST"]
7 | added: "2019-03"
8 | jsonparameters:
9 | - {name: "note", type: "string", required: false, description: "Content to be attached to POI"}
10 | docs: |
11 | Create a POI entry.
12 |
13 | POI entries are tagged with the current timestamp and location (if present).
14 |
15 | Optionally include data with the POI event; this could be human readable notes,
16 | JSON data, or other.
17 |
--------------------------------------------------------------------------------
/static/tocbot.css:
--------------------------------------------------------------------------------
1 | .toc{overflow-y:auto}.toc>.toc-list{overflow:hidden;position:relative}.toc>.toc-list li{list-style:none}.toc-list{margin:0;padding-left:10px}a.toc-link{color:currentColor;height:100%}.is-collapsible{max-height:1000px;overflow:hidden;transition:all 300ms ease-in-out}.is-collapsed{max-height:0}.is-position-fixed{position:fixed !important;top:0}.is-active-link{font-weight:700}.toc-link::before{background-color:#EEE;content:' ';display:inline-block;height:inherit;left:0;margin-top:-1px;position:absolute;width:2px}.is-active-link::before{background-color:#54BC4B}
2 |
--------------------------------------------------------------------------------
/content/en/docs/api/kismetdb.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "KismetDB"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-06T21:01:20-05:00
6 | lastmod: 2022-11-06T21:01:20-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "kismetdb-67ce54a2a3b6a1082ad0ba62fc4d4962"
12 | weight: 360
13 | toc: true
14 | ---
15 |
16 | If the KismetDB log is enabled, Kismet exposes historic, searchable data.
17 |
18 | If KismetDB logging is not enabled, these endpoints will not be available and will return an error.
19 |
20 | {{< kismet_api kismetdb >}}
21 |
--------------------------------------------------------------------------------
/i18n/en.yaml:
--------------------------------------------------------------------------------
1 | - id: get-started
2 | translation: "Get Started"
3 |
4 | - id: on-this-page
5 | translation: "On this page"
6 |
7 | - id: search-text
8 | translation: "Search docs..."
9 |
10 | - id: 404-title
11 | translation: "Page not found :("
12 |
13 | - id: 404-text
14 | translation: |
15 | The page you are looking for doesn't exist or has been moved.
16 |
17 | The Kismet site recently underwent major changes to improve the site and documentation, so the link you're looking
18 | for may have changed.
19 |
20 | - id: browse
21 | translation: "Browse"
22 |
--------------------------------------------------------------------------------
/content/en/docs/api/wifi_ssidtracker.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wi-Fi SSIDs"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-08T14:13:50-05:00
6 | lastmod: 2022-11-08T14:13:50-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "wifi_ssidtracker-09b03f88cb154d87a46c138442adcb9c"
12 | weight: 380
13 | toc: true
14 | ---
15 |
16 | The phy80211 system in Kismet also tracks SSID broadcast, probe, and response.
17 |
18 | These endpoints give a direct method to find all devices related to a specific SSID.
19 |
20 | {{< kismet_api wifi_ssidtracker >}}
21 |
--------------------------------------------------------------------------------
/data/kismet/api/messages.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "All messages"
3 | uri: "/messagebus/all_messages"
4 | methods: ["GET"]
5 | roles: ["readonly"]
6 | types: ["anyjson"]
7 | docs: |
8 | Fetch the past 50 messages from the messagebus backlog.
9 |
10 | -
11 | name: "Recent messages"
12 | uri: "/messagebus/last-time/{TIMESTAMP}/messages"
13 | methods: ["GET"]
14 | roles: ["readonly"]
15 | types: ["anyjson"]
16 | uriparameters:
17 | - {auto: "timestamp"}
18 | docs: |
19 | Return all messages since `TIMESTAMP`.
20 | return: |
21 | JSON list of messages since `TIMESTAMP`.
22 |
--------------------------------------------------------------------------------
/content/en/docs/api/points_of_interest.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Points of interest"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-05T17:51:25-04:00
6 | lastmod: 2022-11-05T17:51:25-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "points_of_interest-bcd1117f09a66cba9ec6ebde4704368c"
12 | weight: 320
13 | toc: true
14 | ---
15 |
16 | An arbitrary time and location can be tagged as a "point of interest".
17 |
18 | Points of interest are logged in the `kismetdb` log file, and can be used as markers to
19 | retrieve information during post-processing.
20 |
21 | {{< kismet_api poi >}}
22 |
--------------------------------------------------------------------------------
/data/kismet/news.yml:
--------------------------------------------------------------------------------
1 | -
2 | date: "2025-09-04"
3 | title: "Kismet 2025-09-R1 is out!"
4 | content: |
5 | After far too long, a major release update with a large number of bugfixes, new
6 | features, improved CPU and memory, a new device view UI, and much more! Full
7 | [release notes here](/releases/kismet-2025-09-R1/)
8 | -
9 | date: "2023-07-21"
10 | title: "Kismet 2023-07-R1 is out!"
11 | content: |
12 | Kismet 2023-07-R1 is out! This brings a lot of speed boosts, memory improvements, bug fixes,
13 | and a new dark-mode UI, as well as improved 6ghz channel support, improved RF sensor and
14 | power meter support, and more.
15 |
--------------------------------------------------------------------------------
/layouts/partials/sidebar/docs-menu.html:
--------------------------------------------------------------------------------
1 | {{ if and .Site.Params.menu.section.auto .Site.Params.menu.section.collapsibleSidebar -}}
2 | {{ partial "sidebar/auto-collapsible-menu.html" . -}}
3 | {{ else if and .Site.Params.menu.section.auto (not .Site.Params.menu.section.collapsibleSidebar) -}}
4 | {{ partial "sidebar/auto-default-menu.html" . -}}
5 | {{ else if and (not .Site.Params.menu.section.auto) .Site.Params.menu.section.collapsibleSidebar -}}
6 | {{ partial "sidebar/manual-collapsible-menu.html" . -}}
7 | {{ else if and (not .Site.Params.menu.section.auto) (not .Site.Params.menu.section.collapsibleSidebar) -}}
8 | {{ partial "sidebar/manual-default-menu.html" . -}}
9 | {{ end -}}
--------------------------------------------------------------------------------
/config/_default/markup.toml:
--------------------------------------------------------------------------------
1 | defaultMarkdownHandler = "goldmark"
2 |
3 | [goldmark]
4 | [goldmark.extensions]
5 | linkify = false
6 | [goldmark.parser]
7 | autoHeadingID = true
8 | autoHeadingIDType = "github"
9 | [goldmark.parser.attribute]
10 | block = true
11 | title = true
12 | [goldmark.renderer]
13 | unsafe = true
14 |
15 | [highlight]
16 | codeFences = false
17 | guessSyntax = false
18 | hl_Lines = ""
19 | lineNoStart = 1
20 | lineNos = false
21 | lineNumbersInTable = true
22 | noClasses = false
23 | style = "dracula"
24 | tabWidth = 4
25 |
26 | [tableOfContents]
27 | endLevel = 3
28 | ordered = false
29 | startLevel = 2
30 |
--------------------------------------------------------------------------------
/layouts/partials/main/posts-meta.html:
--------------------------------------------------------------------------------
1 | {{ $last := sub (len .Params.contributors) 1 }}
2 |
Posted{{ if .Params.categories -}} in {{ range $index, $category := .Params.categories -}}{{ if gt $index 0 -}}, {{ end -}}{{ . }}{{ end -}}{{ end -}} on {{ .PublishDate.Format "January 2, 2006" }} by {{ if .Params.contributors -}}{{ range $index, $contributor := .Params.contributors }}{{ if gt $index 0 }}{{ if eq $index $last }} and {{ else }}, {{ end }}{{ end }}{{ . }}{{ end -}}{{ end -}} ‐
3 |
--------------------------------------------------------------------------------
/.eslintrc.json:
--------------------------------------------------------------------------------
1 | {
2 | "env": {
3 | "browser": true,
4 | "commonjs": true,
5 | "es6": true,
6 | "node": true
7 | },
8 | "extends": "eslint:recommended",
9 | "globals": {
10 | "Atomics": "readonly",
11 | "SharedArrayBuffer": "readonly"
12 | },
13 | "parserOptions": {
14 | "ecmaVersion": 2018,
15 | "sourceType": "module"
16 | },
17 | "rules": {
18 | "no-console": 0,
19 | "quotes": ["error", "single"],
20 | "comma-dangle": [
21 | "error",
22 | {
23 | "arrays": "always-multiline",
24 | "objects": "always-multiline",
25 | "imports": "always-multiline",
26 | "exports": "always-multiline",
27 | "functions": "ignore"
28 | }
29 | ]
30 | }
31 | }
--------------------------------------------------------------------------------
/content/en/docs/api/streams.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Streams"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-06T17:34:06-05:00
6 | lastmod: 2022-11-06T17:34:06-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "streams-64218d2acff7148c3f1f7768703f522f"
12 | weight: 340
13 | toc: true
14 | ---
15 |
16 | Kismet considers anything logging a continual egress of data to be a "stream".
17 |
18 | The primary set of streams includes packet logging to PCAP files or to web endpoints.
19 |
20 | Streams can be viewed and manipulated, for instance a client pulling a packet endpoint can
21 | either cancel the open connection, or issue a stream close command via the stream API.
22 |
23 | {{< kismet_api streams >}}
24 |
--------------------------------------------------------------------------------
/theme.toml:
--------------------------------------------------------------------------------
1 | name = "Doks child theme"
2 | license = "MIT"
3 | licenselink = "https://github.com/h-enk/doks/blob/master/LICENSE"
4 | description = "Hugo theme helping you build modern documentation websites that are secure, fast, and SEO-ready — by default."
5 |
6 | homepage = "https://github.com/h-enk/doks-child-theme"
7 | demosite = "https://doks-child-theme.netlify.app"
8 |
9 | tags = ["landing page", "documentation", "blog", "minimal", "modern", "customizable", "search", "dark mode", "bootstrap"]
10 | features = ["security aware", "fast by default", "seo-ready", "development tools", "bootstrap framework", "netlify-ready", "full text search", "page layouts", "dark mode"]
11 |
12 | [author]
13 | name = "Henk Verlinde"
14 | homepage = "https://henkverlinde.com"
15 |
--------------------------------------------------------------------------------
/content/en/docs/api/datasources.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Datasources"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-31T23:28:01-04:00
6 | lastmod: 2022-10-31T23:28:01-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "datasources-f5c3169d096545e69dbfee18e66a2bad"
12 | weight: 280
13 | toc: true
14 | ---
15 |
16 | Every source of packet and device data in Kismet is a datasource. Typically a datasource is
17 | analogous to a network interace, but may encompass other captures such as SDR, serially attached
18 | capture systems, or summarized scan data posted to an endpoint.
19 |
20 | Datasoruces are defined on startup in `kismet.conf` as a `source=...`, or on the command line
21 | with `-c {source definition}`
22 |
23 | {{< kismet_api datasources >}}
24 |
--------------------------------------------------------------------------------
/content/en/docs/docs.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Docs"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-22T17:01:39-05:00
6 | lastmod: 2022-11-22T17:01:39-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "docs-000d25318b82936ea102bfdba65f86e5"
12 | weight: 999
13 | toc: true
14 | ---
15 |
16 | ## Kismet user documentation
17 |
18 | [The Kismet README](/docs/readme/intro/kismet/) has the information you need about installing, compiling, configuring, and running Kismet.
19 |
20 | ## Kismet API documentation
21 |
22 | [Kismet has a rich REST-like API](/docs/api/rest_like/) with full JSON records, streamig pcap-ng, and websocket pub/sub endpoints.
23 |
24 | ## Kismet developer documentation
25 |
26 | [Additional docs](/docs/dev/plugins/) on developing for Kismet.
27 |
--------------------------------------------------------------------------------
/data/kismet/api/streams.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "List streams"
3 | uri: "/streams/all_streams"
4 | types: ["anyjson"]
5 | roles: ["readonly"]
6 | methods: ["GET"]
7 | docs: |
8 | Fetch a list of active streams.
9 |
10 | -
11 | name: "Stream details"
12 | uri: "/streams/by-id/{STREAMID}/stream_info"
13 | types: ["json"]
14 | roles: ["readonly"]
15 | methods: ["GET"]
16 | uriparameters:
17 | - {name: "STREAMID", type: "number", description: "Stream ID"}
18 | docs: |
19 | Fetch details of a single stream.
20 |
21 | -
22 | name: "Close a stream"
23 | uri: "/streams/by-id/{STREAMID}/close_stream"
24 | types: ["cmd"]
25 | roles: ["admin"]
26 | methods: ["GET"]
27 | uriparameters:
28 | - {name: "STREAMID", type: "number", description: "Stream ID"}
29 | docs: |
30 | Close an existing stream.
31 |
32 |
33 |
--------------------------------------------------------------------------------
/layouts/partials/head/stylesheet.html:
--------------------------------------------------------------------------------
1 | {{ if eq (hugo.Environment) "development" -}}
2 | {{ $options := (dict "targetPath" "main.css" "enableSourceMap" true "includePaths" (slice "node_modules")) -}}
3 | {{ $css := resources.Get "scss/app.scss" | toCSS $options -}}
4 |
5 | {{ else -}}
6 | {{ $options := (dict "targetPath" "main.css" "outputStyle" "compressed" "includePaths" (slice "node_modules")) -}}
7 | {{ $css := resources.Get "scss/app.scss" | toCSS $options | postCSS (dict "config" "config/postcss.config.js") -}}
8 | {{ $secureCSS := $css | resources.Fingerprint "sha512" -}}
9 |
10 | {{ end -}}
11 |
--------------------------------------------------------------------------------
/content/en/docs/api/messages.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Messages"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-31T16:58:20-04:00
6 | lastmod: 2022-10-31T16:58:20-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "messages-0de8b73ab596d4eb89dc319303b81247"
12 | weight: 250
13 | toc: true
14 | ---
15 |
16 | Kismet uses an internal `messagebus` system (an extension of the event bus) for communicating messages from various components to the UI.
17 |
18 | The messagebus is used to pass error, status, and debug messages, as well as notifications to the user about detected devices, alerts, etc.
19 |
20 | For real-time messges, see the [eventbus](/docs/api/eventbus). The Kismet UI uses a combination of the messages API to load previous content, and the eventbus to received pushed future messages immediately.
21 |
22 | {{< kismet_api messages >}}
23 |
--------------------------------------------------------------------------------
/content/en/posts/2022-11-11-new-site.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "New Kismet Site"
3 | description: ""
4 | excerpt: "Welcome to the new Kismet site"
5 | date: 2022-11-11T16:36:14-05:00
6 | lastmod: 2022-11-11T16:36:14-05:00
7 | weight: 50
8 | images: []
9 | categories: []
10 | tags: []
11 | contributors: ["Mike Kershaw / Dragorn"]
12 | pinned: false
13 | homepage: false
14 | ---
15 |
16 | Welcome to the new Kismet site!
17 |
18 | The new site design comes via [hugo](https://gohugo.io) and the [Doks](https://getdoks.org/) theme.
19 |
20 | There's also a pile of templating to make as much of the documentation consistent and clear, with all
21 | of the developer API documentation converted to YAML data and rendered through the template engine.
22 |
23 | The docs data files will be added to the [Kismetwireless github](https://github.com/kismetwireless/)
24 | mirrors soon.
25 |
26 |
27 |
--------------------------------------------------------------------------------
/layouts/docs/list.html:
--------------------------------------------------------------------------------
1 | {{ define "main" }}
2 |
3 |
4 |
5 |
{{ if eq .CurrentSection .FirstSection }}{{ .Section | humanize }}{{ else }}{{ .Title }}{{ end }}
6 |
{{ .Content }}
7 |
8 | {{ $currentSection := .CurrentSection }}
9 | {{ range where .Site.RegularPages.ByTitle "Section" .Section }}
10 | {{ if in (.RelPermalink | string) $currentSection.RelPermalink }}
11 |
22 | {{ end }}
--------------------------------------------------------------------------------
/content/en/docs/readme/intro/kismet.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Kismet"
3 | description: "Kismet basics"
4 | lead: ""
5 | date: 2022-08-09T14:49:48-04:00
6 | lastmod: 2022-08-09T14:49:48-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: "Foo"
11 | identifier: "kismet-5e9978006a4f93f6135c04bcbf464b23"
12 | weight: 10
13 |
14 | ---
15 |
16 | Kismet is an open source sniffer, WIDS, wardriver, and packet capture tool for Wi-Fi, Bluetooth, BTLE, wireless thermometers, airplanes, power meters, Zigbee, and more.
17 |
18 | Kismet runs on Linux, macOS, and Windows (via WSL).
19 |
20 | Kismet can operate both headless as a standalone capture and WIDS system, or with a full modern web-based UI.
21 |
22 | 
23 |
24 | Kismet can be run on a wide range of hardware, from the very small to large servers, depending on the amount of traffic you plan to capture.
25 |
--------------------------------------------------------------------------------
/layouts/shortcodes/kismet_release.html:
--------------------------------------------------------------------------------
1 | {{ with $.Site.Data.kismet.release.kismet }}
2 |
3 |
30 | {{ end }}
31 |
--------------------------------------------------------------------------------
/content/en/posts/kismet-2023-07-R2.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "2025 03 28 Release 202307R2"
3 | description: ""
4 | excerpt: ""
5 | weight: 50
6 | images: []
7 | categories: []
8 | tags: []
9 | contributors: ["Mike Kershaw / Dragorn"]
10 | pinned: false
11 | homepage: false
12 | aliases: [ "/releases/kismet-2023-07-R2/" ]
13 | ---
14 |
15 | ## Kismet 2023-07-R2
16 |
17 | This is a small update to the existing 2023-07-R1 release to address a HTML/JS injection bug in the web UI.
18 |
19 | Work continues on a major new release on the horizon in the git/nightly builds.
20 |
21 | ## Download
22 |
23 | You can get the 2023-07-R2 release from [the Kismet downloads page](/download/#kismet-release), where you can get both the source and packages for several distributions.
24 |
25 | # Changes and Updates
26 |
27 | * Fix HTML/JS injection in the web UI
28 |
29 | ## Packaging
30 |
31 | If you're looking to package Kismet, have a look at the [packaging guidelines](/docs/readme/packaging/).
32 |
33 | ## Thanks
34 |
35 | As always, a tremendous thank you to all the supporters on [Github Sponsors](https://github.com/sponsors/kismetwireless)!
36 |
37 |
--------------------------------------------------------------------------------
/DOKS-LICENSE:
--------------------------------------------------------------------------------
1 | MIT License
2 |
3 | Copyright (c) 2018-present, Gridsome
4 | Copyright (c) 2020-present, Henk Verlinde
5 |
6 | Permission is hereby granted, free of charge, to any person obtaining a copy
7 | of this software and associated documentation files (the "Software"), to deal
8 | in the Software without restriction, including without limitation the rights
9 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
10 | copies of the Software, and to permit persons to whom the Software is
11 | furnished to do so, subject to the following conditions:
12 |
13 | The above copyright notice and this permission notice shall be included in all
14 | copies or substantial portions of the Software.
15 |
16 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
17 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
18 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
19 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
20 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
21 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
22 | SOFTWARE.
--------------------------------------------------------------------------------
/content/en/docs/api/device_views.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Device views"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-30T09:45:10-04:00
6 | lastmod: 2022-10-30T09:45:10-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "device_views-266e5d0e082c8d800a65c26a0f2313b1"
12 | weight: 240
13 | toc: true
14 | ---
15 |
16 | Device views in Kismet are optimized subsets of the global device list.
17 |
18 | Device views can by defined by PHY handlers, plugins, as part of the Kismet basic code, or by user-supplied data.
19 |
20 | Kismet uses device views to organize devices by capture interface, phy type, specific device type (like the phy80211 access point view), and more.
21 |
22 | All clients are strongly encouraged to use the device view API going forwards.
23 |
24 | Device views are also designed to work with paginating user interfaces; as part of the request, a client can request a "page" of information; with each subsequent page (or scroll) the user interface fetches only the data it needs.
25 |
26 | The Kismet device views are written around the API of the [jquery-datatables](https://datatables.net/) web component API, but this API can easily be adapted for use with any pagination system.
27 |
28 | {{< kismet_api device_views >}}
29 |
--------------------------------------------------------------------------------
/content/en/docs/api/rest_like.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "REST-like API"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-10T19:53:38-04:00
6 | lastmod: 2022-10-10T19:53:38-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "rest_like-5edfafb37ea8541854db41cf9888d6e9"
12 | weight: 10
13 | toc: false
14 | ---
15 |
16 | Kismet uses a REST-like interface for the embedded webserver, which provides data and accepts commands.
17 |
18 | Kismet attempts to provide sane and consistent endpoints.
19 |
20 | Many Kismet endpoints support both a basic `GET` implementation, and a more complex `POST` inmplementation which accepts filtering, optimization, and more.
21 |
22 | Kismet can serialize the endpoint data to multiple formats; whenever possible, an endpoint will support all output formats.
23 |
24 | The default output format is basic JSON, but additional transformations of the JSON data are available, including optimization for streamed processing, field renaming, and human-readable formatting for learning and investigating data.
25 |
26 | As of `2019-04-git`, Kismet requires a login on ALL endpoints, excluding:
27 |
28 | * `/system/user_status`
29 | * `/session/check_login`
30 | * `/session/check_session`
31 | * `/session/check_setup_ok`
32 |
--------------------------------------------------------------------------------
/.stylelintrc.json:
--------------------------------------------------------------------------------
1 | {
2 | "extends": "stylelint-config-standard-scss",
3 | "rules": {
4 | "no-empty-source": null,
5 | "string-quotes": "double",
6 | "scss/comment-no-empty": null,
7 | "max-line-length": null,
8 | "scss/at-extend-no-missing-placeholder": null,
9 | "scss/dollar-variable-colon-space-after": null,
10 | "scss/dollar-variable-empty-line-before": null,
11 | "color-function-notation": null,
12 | "alpha-value-notation": null,
13 | "selector-id-pattern": null,
14 | "selector-class-pattern": null,
15 | "scss/no-global-function-names": null,
16 | "number-max-precision": null,
17 | "hue-degree-notation": null,
18 | "value-no-vendor-prefix": null,
19 | "property-no-vendor-prefix": null,
20 | "at-rule-no-unknown": [
21 | true,
22 | {
23 | "ignoreAtRules": [
24 | "extend",
25 | "at-root",
26 | "debug",
27 | "warn",
28 | "error",
29 | "if",
30 | "else",
31 | "for",
32 | "each",
33 | "while",
34 | "mixin",
35 | "include",
36 | "content",
37 | "return",
38 | "function",
39 | "tailwind",
40 | "apply",
41 | "responsive",
42 | "variants",
43 | "screen"
44 | ]
45 | }
46 | ]
47 | }
48 | }
--------------------------------------------------------------------------------
/config/postcss.config.js:
--------------------------------------------------------------------------------
1 | const autoprefixer = require('autoprefixer');
2 | const purgecss = require('@fullhuman/postcss-purgecss');
3 | const whitelister = require('purgecss-whitelister');
4 |
5 | module.exports = {
6 | plugins: [
7 | autoprefixer(),
8 | purgecss({
9 | content: [
10 | './node_modules/@hyas/doks/layouts/**/*.html',
11 | './node_modules/@hyas/doks/content/**/*.md',
12 | './layouts/**/*.html',
13 | './content/**/*.md',
14 | ],
15 | safelist: [
16 | 'lazyloaded',
17 | 'table',
18 | 'thead',
19 | 'tbody',
20 | 'tr',
21 | 'th',
22 | 'td',
23 | 'h5',
24 | 'alert-link',
25 | 'container-xxl',
26 | 'container-fluid',
27 | ...whitelister([
28 | './node_modules/@hyas/doks/assets/scss/common/_variables.scss',
29 | './node_modules/@hyas/doks/assets/scss/components/_alerts.scss',
30 | './node_modules/@hyas/doks/assets/scss/components/_buttons.scss',
31 | './node_modules/@hyas/doks/assets/scss/components/_code.scss',
32 | './node_modules/@hyas/doks/assets/scss/components/_syntax.scss',
33 | './node_modules/@hyas/doks/assets/scss/components/_search.scss',
34 | './node_modules/@hyas/doks/assets/scss/common/_dark.scss',
35 | './node_modules/katex/dist/katex.css',
36 | ]),
37 | ],
38 | }),
39 | ],
40 | }
41 |
--------------------------------------------------------------------------------
/content/en/docs/readme/gps/gps_tcp.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS - TCP"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-15T15:10:49-04:00
6 | lastmod: 2022-09-15T15:10:49-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps_tcp-b76cdf9dd27d2ff2af38df0e3293fcd1"
12 | weight: 70
13 | toc: true
14 | ---
15 |
16 | Kismet can connect to a basic NMEA GPS replicated over a TCP stream.
17 |
18 | Typically this would come from a smartphone app like `BlueNMEA` on Android or `NMEA GPS` on iPhone.
19 |
20 | For a network-based gpsd connection, use the `gpsd` GPS instead.
21 |
22 | ## Configuration
23 |
24 | ```
25 | gps=tcp:host={host},port={port}
26 | ```
27 |
28 | ## GPS options
29 |
30 | ### Common options
31 |
32 | {{}}
33 | Set an arbitrary human-readable name for the GPS. This will be used in the Kismet GPS logs.
34 | {{}}
35 |
36 |
37 | {{}}
38 | Automatically attempt to re-open the GPS if an error occurs or the connection is interrupted.
39 |
40 | This is enabled by default.
41 | {{}}
42 |
43 | ### TCP options
44 |
45 | {{}}
46 | *REQUIRED*
47 |
48 | Hostname of the system running a GPS TCP stream service.
49 | {{}}
50 |
51 |
52 | {{}}
53 | *REQUIRED*
54 |
55 | Port on which the NMEA stream is running
56 | {{}}
57 |
--------------------------------------------------------------------------------
/content/en/docs/readme/gps/gps_virtual.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS - Virtual"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-15T15:41:03-04:00
6 | lastmod: 2022-09-15T15:41:03-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps_virtual-c85dc85d8ba9dce50d63ae5e05fe3c13"
12 | weight: 90
13 | toc: true
14 | ---
15 |
16 | A virtual GPS always reports a single, fixed, static location.
17 |
18 | The virtual GPS can be helpful for injecting location data on a stationary Kismet server.
19 |
20 | ## Configuration
21 |
22 | ```
23 | gps=virtual:lat={xyz},lon={xyz},alt={xyz}
24 | ```
25 |
26 | ## GPS options
27 |
28 | ### Common options
29 |
30 | {{}}
31 | Set an arbitrary human-readable name for the GPS. This will be used in the Kismet GPS logs.
32 | {{}}
33 |
34 |
35 | {{}}
36 | Automatically attempt to re-open the GPS if an error occurs or the connection is interrupted.
37 |
38 | This is enabled by default.
39 | {{}}
40 |
41 | ### Virtual options
42 |
43 | {{}}
44 | *REQUIRED*
45 |
46 | Latitude to report, as decimal degrees
47 | {{}}
48 |
49 |
50 | {{}}
51 | *REQUIRED*
52 |
53 | Longitude to report, as decimal degrees
54 | {{}}
55 |
56 |
57 | {{}}
58 | Altitude to report, in meters
59 | {{}}
60 |
61 |
--------------------------------------------------------------------------------
/layouts/partials/kismet_alert.html:
--------------------------------------------------------------------------------
1 |
49 | {{ end -}}
50 |
51 | {{ end }}
52 |
53 |
54 |
--------------------------------------------------------------------------------
/data/kismet/api/logging.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "List available log types"
3 | uri: "/logging/drivers"
4 | types: ["anyjson"]
5 | roles: ["readonly"]
6 | methods: ["GET"]
7 | docs: |
8 | Fetch a list of all available log drivers.
9 |
10 | Each logging driver handles a log output format.
11 |
12 | -
13 | name: "List active logs"
14 | uri: "/logging/active"
15 | types: ["anyjson"]
16 | roles: ["readonly"]
17 | methods: ["GET"]
18 | docs: |
19 | List enabled and active logs
20 |
21 | -
22 | name: "Start a log"
23 | uri: "/logging/by-class/{LOGCLASS}/start"
24 | types: ["cmd"]
25 | methods: ["GET", "POST"]
26 | uriparameters:
27 | - {name: "LOGCLASS", type: "string", description: "Log class / type to start"}
28 | jsonparameters:
29 | - {name: "title", type: "string", required: false, description: "Alternate file name / log title"}
30 | docs: |
31 | Open a new log; if the same type of log is closed and opened multiple times in one session, it
32 | will have multipe log instances (such as `Kismet-foo-2022-10-03-1.pcap`,
33 | `kismet-foo-2022-10-03-2.pcap` )
34 | notes: |
35 | Some logs, like kismetdb, are only permitted a single logging instance.
36 | return: |
37 | Success or failure of log opening.
38 | responses:
39 | success:
40 | - [200, "Success"]
41 | failure:
42 | - [-1, "Request error, such as malformed log class or permissions error"]
43 |
44 | -
45 | name: "Stopping a log"
46 | uri: "/logging/by-uuid/{UUID}/stop"
47 | types: ["cmd"]
48 | methods: ["GET"]
49 | uriparameters:
50 | - {name: "UUID", type: "string", description: "Log UUID to stop"}
51 | docs: |
52 | Stop and close a current log.
53 |
54 |
55 |
--------------------------------------------------------------------------------
/content/en/docs/api/devices.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Devices"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-28T23:43:50-04:00
6 | lastmod: 2022-10-28T23:43:50-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "devices-a22253203ac73a2e6dec114e080ba1c0"
12 | weight: 230
13 | toc: true
14 | ---
15 |
16 | A device is the central record of a tracked entity in Kismet. Clients, bridges, access points, wireless sensors, and every other type of entity seen by Kismet will ultimately be a device.
17 |
18 | Each PHY layer will add fields to the device record and populate thec ommon fields.
19 |
20 | For complex relationships (such as 802.11 Wi-Fi), a list of related devices in the device record describes the access point-client relationship, shared hardware, etc.
21 |
22 | All devices will have a basic set of records (held in the `kismet.base.foo` group of fields, generally) and sub-trees of records attached by the phy-specific handlers. A device may have multiple phy-specific records, for instance a device may contain both a `device.dot11` record and a `device.uav` record if it is seen to be a Wi-Fi based UAV/Drone device.
23 |
24 | Some care must be taken when requesting large numbers of device records: Kismet may be tracking tens or hundreds of thousands of devices in a single session, and requesting *all* devices can run both the Kismet server and your UI out of resources.
25 |
26 | Whenever possible, use the pagination functions of the [device view](/docs/api/device_views/) API and request devices groups.
27 |
28 | Since the `2019-06` release, Kismet has migrated most device interactions to the device view api. Any new users of the API should use the device views.
29 |
30 | {{< kismet_api devices >}}
31 |
--------------------------------------------------------------------------------
/content/en/docs/readme/gps/gps_gpsd.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS - GPSD"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-15T14:45:27-04:00
6 | lastmod: 2022-09-15T14:45:27-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps_gpsd-29ba7e51391f912fea79f516e8da1457"
12 | weight: 40
13 | toc: true
14 | ---
15 |
16 | [GPSD](https://gpsd.gitlab.io/gpsd/index.html) is a service which parses GPS data from a wide range of GPS vendors, including several binary protocols which normal NMEA parsers cannot decode.
17 |
18 | Modern GPSD is a solid option for controlling most GPS receivers.
19 |
20 | Extremely old distributions or versions of GPSD (prior to 2015 or so) may have various issues. Kismet still supports the now-ancient GPSD text protocol, but will default to the modern JSON protocol.
21 |
22 | ## Configuration
23 |
24 | ```
25 | gps=gpsd:host=localhost,port=2947
26 | ```
27 |
28 | To determine the proper path to your GPS unit, look below in the `device` options.
29 |
30 | ## GPS options
31 |
32 | ### Common options
33 |
34 | {{}}
35 | Set an arbitrary human-readable name for the GPS. This will be used in the Kismet GPS logs.
36 | {{}}
37 |
38 | {{}}
39 | Automatically attempt to re-open the GPS if an error occurs or the connection is interrupted.
40 |
41 | This is enabled by default.
42 | {{}}
43 |
44 | ### GPSD options
45 |
46 | {{}}
47 | *REQUIRED*
48 |
49 | Hostname to connect to; typically this will be `localhost`
50 | {{}}
51 |
52 |
53 | {{}}
54 | *REQUIRED*
55 |
56 | Port number for GPSD. Typically this will be `2947`
57 | {{}}
58 |
59 |
--------------------------------------------------------------------------------
/content/en/docs/readme/installing/windows.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Windows"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-12T11:27:15-04:00
6 | lastmod: 2022-08-12T11:27:15-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "windows-bb74ddc0002303f8a452e4258156a155"
12 | weight: 100
13 | ---
14 |
15 | ## Virtual Machines
16 |
17 | It may be possible to run Kismet in Linux inside a virtual machine, however this typically depends on the VM being used and the hardware being used.
18 |
19 | If it works, you will need a USB WiFi card for capture, and a VM solution which allows USB passthrough (such as VMWare). Hyper-V does not support USB passthrough, and Virtualbox may or may not work.
20 |
21 | It is not possible to pass an internal PCI Wi-Fi card to a VM under Windows.
22 |
23 | Not all USB Wi-Fi cards work on Windows with USB passthrough.
24 |
25 | ## Kismet on WSL
26 |
27 | Kismet has deep dependencies on the Posix (ie, Unix-based) libraries and environment, and as such, does not run *directly* on Windows platforms.
28 |
29 | It is possible to run Kismet inside the WSL (Windows Subsystem for Linux) environment, either in WSL1 or WSL2.
30 |
31 | ## Limits
32 |
33 | The WSL environment (and the WSL2 HyperV environment) do not have direct access to USB, PCI, or other hardware interfaces. It is not possible to capture packets directly in Kismet in WSL from a local device.
34 |
35 | However, it *IS* possible to capture packets using the Kismet remote capture system.
36 |
37 | For more info on remote capture, see the Kismet [remote capture docs](/docs/readme/remotecap/remotecap/).
38 |
39 | ## Compiling
40 |
41 | Since WSL is Linux, follow the compile directions for the Linux distribution you have installed (typically Ubuntu or Kali) under the [Linux documentation](/docs/readme/installing/linux/#installing-from-source).
42 |
--------------------------------------------------------------------------------
/content/en/docs/api/bluetooth_scanningmode.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Scanning mode: Bluetooth"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-10T23:56:19-05:00
6 | lastmod: 2022-11-10T23:56:19-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "bluetooth_scanningmode-a6d5a2d1288a733e75ffe098427d6ff2"
12 | weight: 420
13 | toc: true
14 | ---
15 |
16 | The design of Bluetooth makes capturing packets very difficult, but performing active
17 | scans for discoverable Bluetooth and BTLE devices can still yeild results.
18 |
19 | ### Scanning mode data sources
20 |
21 | The scan report API is designed to be as simple as possible, and to automate as
22 | much of the process as possible.
23 |
24 | To assist with automation, scanning mode datasources are created dynamically by
25 | Kismet when scan reports are submitted; there is no need to define a specific
26 | datasource before sending a scanning mode report.
27 |
28 | To create the scanning mode datasource, a scanning report must include:
29 |
30 | 1. A datasource UUID. This UUID must be unique within Kismet, and consistent for
31 | all reports from this datasource. Scanning software should cache this UUID for
32 | consistent reporting between instances.
33 |
34 | 2. A human-readable name. This wil be assigned as the name of the datasource,
35 | and will be updated automatically if the name changes in subsequent reports.
36 |
37 | ### Cache and burst mode reporting
38 |
39 | Scanning mode assumes that the device doing scanning may not be able to maintain a
40 | constant connection to the Kismet server.
41 |
42 | Reports can be cached in sent in groups using the report endpoint; each report
43 | contains a timestamp, GPS location, and signal information. Multiple reports for
44 | the same AP reflecting information over time can be sent in a single connection.
45 |
46 | {{< kismet_api bluetooth_scanningmode >}}
47 |
--------------------------------------------------------------------------------
/content/en/docs/api/keys_and_macs.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Keys and MAC addresses"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-30T09:22:57-04:00
6 | lastmod: 2022-10-30T09:22:57-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "keys_and_macs-b8c9c2626c2239dd37ce571e2c0b1c78"
12 | weight: 50
13 | toc: true
14 | ---
15 |
16 | Devices are indexed two primary ways in Kismet:
17 |
18 | 1. Keys
19 |
20 | A key is unique for each device. The key is derived *from* the MAC address, but contains additional information about the PHY type.
21 |
22 | This allows multiple devices to have the same MAC under different PHY types; this can be particularly important when using non-traditional PHY types like those derived from SDR captures, when the devices do not have an actual MAC address.
23 |
24 | 2. MAC addresses
25 |
26 | The MAC address is a (theoretically) unique identifier given to each device at manufacture time. It is used to identify the device uniquely on a network.
27 |
28 | Typically, the the IEEE assigns each manufacturer a block of addresses with a common header (the OUI) and the manufacturer is responsible for creating unique identifiers within that block.
29 |
30 | For datasources without a defined MAC address, Kismet will attempt to synthesize a MAC address from the unique data available.
31 |
32 |
33 | ## MAC address masking
34 |
35 | On queries and filters affecting MAC addresses, Kismet supports complete addresses or partial addresses with masking.
36 |
37 | A masked address resembles the syntax typically used for IP network masking: `[MAC]/[MASK]`.
38 |
39 | For instance, to match only the OUI, a masked MAC of:
40 |
41 | ```json
42 | "aa:bb:cc:00:00:00/ff:ff:ff:00:00:00"
43 | ```
44 |
45 | This would match any MAC address where the OUI, or first three bytes, are "aa:bb:cc". A similar feature to match on the first *four* bytes would be:
46 |
47 | ```json
48 | "aa:bb:cc:dd:00:00/ff:ff:ff:ff:00:00"
49 | ```
50 |
51 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/kismetdb.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Replay: Kismetdb"
3 | description: ""
4 | lead: ""
5 | date: 2023-06-17T12:29:21-04:00
6 | lastmod: 2023-06-17T12:29:21-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "kismetdb-56ba4d9cb60613c227d40fe6aa482a2a"
12 | weight: 999
13 | toc: true
14 | ---
15 |
16 | Kismet can replay previously recorded data in a kismetdb log.
17 |
18 | Kismet replay is useful for testing, debugging, demo, or reprocessing previous sessions (with some caveats).
19 |
20 | ### Example source
21 |
22 | Typically a kismetdb replay would be done as a command line option rather than a hard coded source:
23 |
24 | ```bash
25 | $ kismet -c /path/to/file.kismet
26 | ```
27 | ### Warnings
28 |
29 | Not all data in a kismetdb log is currently replayed: Non-packet data such as JSON records is not loaded.
30 |
31 | When replaying a kismetdb log, all packets will appear to originate from a single datasource (the kisemtdb source), not the orignial interfaces.
32 |
33 | When processing logfiles, it is easy to send packets faster than the Kismet server can process. It's always a good idea to use the `pps` source option to limit the packets per second.
34 |
35 | ### Naming and description options
36 |
37 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
38 |
39 | ### Kismetdb options
40 |
41 | {{}}
42 | Limit the replay to a packets-per-second maximum. Without this option, packets are streamed to Kismet as fast as possible, which may outrun the processing queue on the Kismet server. Kismetdb replays should always be throttled to a rate your server hardware can support to prevent lose packets during the replay; often 1000 to 10000 packets per second is a reasonable starting point.
43 | {{}}
44 |
45 | {{}}
46 | Replay a kismetdb log in real time, using the time offsets between packets in the original log.
47 | {{}}
48 |
49 |
--------------------------------------------------------------------------------
/content/en/docs/readme/kismetdb/kismetdb_strip_packets.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Kismetdb packet stripping"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-10T15:17:49-04:00
6 | lastmod: 2022-10-10T15:17:49-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "kismetdb_strip_packets-131c6669cb25adffc02a441fc835d102"
12 | weight: 50
13 | toc: true
14 | ---
15 |
16 | The `kismetdb_strip_packets` tool processes the unified [kismetdb](/docs/readme/logging/kismetdb/) log and deletes the stored packets.
17 |
18 | This tool is available as part of Kismet when built from source, or in the kismet-logtools package, as of `2019-02`.
19 |
20 | ## Packet data
21 |
22 | Kismet stores packets as binary data in the [kismetdb log file](/docs/readme/logging/logging/).
23 |
24 | Packet data is invaluable for analyzing results, replaying data, capturing handshakes, and more; It can also be large, take a lot of room, and contain personally identifiable or private information gathered during a capture.
25 |
26 | Before sharing a packet log (for instance with sites which may accept kismetdb logs directly), the packet data can be stripped.
27 |
28 | The `kismetdb_strip_packets` tool will retain all metadata - MAC addresses, signal, and location - but will erase the contents of the packets.
29 |
30 | ```bash
31 | $ kismetdb_strip_packets --in some-kismet-file.kismet --out some-other-file.kismet
32 | ```
33 |
34 | ## Arguments
35 |
36 | {{}}
37 | Add more status output to the console while `kismetdb_strip_packets` runs.
38 | {{}}
39 |
40 | {{}}
41 | By default, `kismetdb_strip_packets` will not overwrite the target file if it exists already. `--force` will cause it to clobber the destination.
42 | {{}}
43 |
44 | {{}}
45 | By default, `kismetdb_strip_packets` runs a SQL Vacuum command to optimize the database and clean up any journal files. Skipping this process will save time on larger captures.
46 | {{}}
47 |
48 |
--------------------------------------------------------------------------------
/config/_default/config.toml:
--------------------------------------------------------------------------------
1 | baseurl = "/"
2 | title = "Kismet"
3 | canonifyURLs = false
4 | disableAliases = false
5 | disableHugoGeneratorInject = true
6 | enableEmoji = true
7 | enableGitInfo = false
8 | enableRobotsTXT = true
9 | paginate = 7
10 | rssLimit = 10
11 |
12 | # Multilingual
13 | defaultContentLanguage = "en"
14 | disableLanguages = ["de", "nl"]
15 | # defaultContentLanguageInSubdir = true
16 |
17 | # add redirects/headers
18 | [outputs]
19 | home = ["HTML", "RSS", "REDIRECTS", "HEADERS"]
20 | section = ["HTML", "RSS", "SITEMAP"]
21 |
22 | #[minify]
23 | #disableJS = true
24 |
25 | # remove .{ext} from text/netlify
26 | [mediaTypes."text/netlify"]
27 | suffixes = [""]
28 | delimiter = ""
29 |
30 | # add output format for netlify _redirects
31 | [outputFormats.REDIRECTS]
32 | mediaType = "text/netlify"
33 | baseName = "_redirects"
34 | isPlainText = true
35 | notAlternative = true
36 |
37 | # add output format for netlify _headers
38 | [outputFormats.HEADERS]
39 | mediaType = "text/netlify"
40 | baseName = "_headers"
41 | isPlainText = true
42 | notAlternative = true
43 |
44 | # add output format for section sitemap.xml
45 | [outputFormats.SITEMAP]
46 | mediaType = "application/xml"
47 | baseName = "sitemap"
48 | isHTML = false
49 | isPlainText = true
50 | noUgly = true
51 | rel = "sitemap"
52 |
53 | [caches]
54 | [caches.getjson]
55 | dir = ":cacheDir/:project"
56 | maxAge = "10s"
57 |
58 | [sitemap]
59 | changefreq = "weekly"
60 | filename = "sitemap.xml"
61 | priority = 0.5
62 |
63 | [taxonomies]
64 | contributor = "contributors"
65 | category = "categories"
66 | tag = "tags"
67 |
68 | [permalinks]
69 | blog = "/blog/:title/"
70 | # docs = "/docs/1.0/:sections[1:]/:title/"
71 |
72 | [minify.tdewolff.html]
73 | keepWhitespace = false
74 |
75 | [related]
76 | threshold = 80
77 | includeNewer = true
78 | toLower = false
79 | [[related.indices]]
80 | name = "categories"
81 | weight = 100
82 | [[related.indices]]
83 | name = "tags"
84 | weight = 80
85 | [[related.indices]]
86 | name = "date"
87 | weight = 10
88 |
--------------------------------------------------------------------------------
/data/kismet/packages.yml:
--------------------------------------------------------------------------------
1 | -
2 | distro: "Kali"
3 | platforms: ["amd64", "armhf", "arm64"]
4 | key: "kali"
5 | name: "Kali Linux"
6 | builds: ["release", "git"]
7 |
8 | -
9 | distro: "Debian Bookworm"
10 | platforms: ["amd64", "arm64"]
11 | name: "Debian Bookworm"
12 | key: "bookworm"
13 | builds: ["release", "git"]
14 |
15 | -
16 | distro: "Debian Trixie"
17 | platforms: ["amd64", "arm64"]
18 | name: "Debian Trixie"
19 | key: "trixie"
20 | builds: ["release", git"]
21 |
22 | -
23 | distro: "Ubuntu Bionic (18.04)"
24 | platforms: ["i386", "amd64"]
25 | name: "Ubuntu Bionic (18.04)"
26 | key: "bionic"
27 | builds: ["release", "git"]
28 | notes: |
29 | Due to limitations in the packages and versions of libraries in Ubuntu Bionic,
30 | these packages do not contain all features. You may be able to manually install
31 | new versions of the required libraries and compile from source, instead.
32 |
33 | The following features are not available in Bionic packages:
34 |
35 | * Remote capture via websockets
36 |
37 | A Bionic install cannot function as a remote capture node feeding a Kismet server
38 | over websockets.
39 |
40 | TCP mode is still available.
41 |
42 | A Bionic Kismet server supports receiving remote captures over websockets, only
43 | client-mode websockets are impacted.
44 |
45 | -
46 | distro: "Ubuntu Focal (20.04)"
47 | platforms: ["amd64", "armhf", "arm64"]
48 | name: "Ubuntu Focal (20.04)"
49 | key: "focal"
50 | builds: ["release", "git"]
51 |
52 | -
53 | distro: "Ubuntu Jammy (22.04)"
54 | platforms: ["amd64", "armhf", "arm64"]
55 | name: "Ubuntu Jammy (22.04)"
56 | key: "jammy"
57 | builds: ["release", "git"]
58 |
59 | -
60 | distro: "Ubuntu Noble (24.04)"
61 | platforms: ["amd64", "arm64"]
62 | name: "Ubuntu Noble (23.10)"
63 | key: "noble"
64 | builds: ["release", "git"]
65 |
66 | -
67 | distro: "Ubuntu Plucky (25.04)"
68 | platforms: ["amd64", "arm64"]
69 | name: "Ubuntu Plucky (25.04)"
70 | key: "plucky"
71 | builds: ["release", "git"]
72 |
73 |
--------------------------------------------------------------------------------
/data/kismet/api/packet_capture.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "All packets"
3 | uri: "/pcap/all_packets"
4 | types: ["pcapng"]
5 | methods: ["GET"]
6 | roles: ["readonly"]
7 | docs: |
8 | A live stream of packets seen by all datasources, served in PCAP-NG format.
9 |
10 | This stream will return all packets seen since the stream was initiated, and will
11 | continue streaming packets until the connection is terminated.
12 |
13 | To access packets *previosuly seen* by Kismet, use the [kismetdb endpoints](/docs/api/kismetdb).
14 | notes: |
15 | This endpoint will return packets forever, until disconnected.
16 |
17 | -
18 | name: "Packets by datasource"
19 | uri: "/datasource/pcap/by-uuid/{UUID}/packets"
20 | types: ["pcapng"]
21 | methods: ["GET"]
22 | roles: ["readonly"]
23 | uriparameters:
24 | - {name: "UUID", type: "string", description: "Datasource UUID"}
25 | docs: |
26 | A live stream of packets from a single datasource, served in PCAP-NG format.
27 |
28 | This stream will return all packets seen since the stream was initiated, and will
29 | continue streaming packets until the connection is terminated.
30 |
31 | To access packets *previosuly seen* by Kismet, use the [kismetdb endpoints](/docs/api/kismetdb).
32 | notes: |
33 | This endpoint will return packets forever, until disconnected.
34 |
35 | -
36 | name: "Packets by device"
37 | uri: "devices/pcap/by-key/{KEY}/packets"
38 | types: ["pcapng"]
39 | roles: ["readonly"]
40 | methods: ["GET"]
41 | uriparameters:
42 | - {name: "KEY", type: "string", description: "Device key"}
43 | docs: |
44 | A live stream of packets to, from, or otherwise associated with a specific device,
45 | served in PCAP-NG format.
46 |
47 | This stream will return all packets seen since the stream was initiated, and will
48 | continue streaming packets until the connection is terminated.
49 |
50 | To access packets *previosuly seen* by Kismet, use the [kismetdb endpoints](/docs/api/kismetdb).
51 | notes: |
52 | This endpoint will return packets forever, until disconnected.
53 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/wifi-bladerf2-wiphy.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wi-Fi: Bladerf2 Wiphy"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-29T17:10:56-04:00
6 | lastmod: 2022-08-29T17:10:56-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "sdr-bladerf2-wiphy-162a6334803713f73bbeda9a8a974c88"
12 | weight: 130
13 | toc: true
14 | ---
15 |
16 | The BladeRF2 WiPhy source works with the [Nuand BladeRF2 A9](https://www.nuand.com/product/bladerf-xa9/) with the [WiPhy](https://www.nuand.com/bladerf-wiphy/) FPGA image.
17 |
18 | Kismet will auto-detect BladeRF2 devices as `bladerf-wiphy`, or you may manually specify the type:
19 |
20 | ```
21 | source=bladerf-wiphy-0:type=bladerf-wiphy
22 | ```
23 |
24 | ## Supported hardware
25 |
26 | The BladeRF2 WiPhy source requires a BladeRF2 (aka BladeRF Micro), with the larger FPGA (the A9 variant).
27 |
28 | It requires the WiPhy FPGA image.
29 |
30 | ## Compiling WiPhy support
31 |
32 | WiPhy support in Kismet requires the latest versions of LibBladeRF2; as these are not available in many distributions, Kismet does not enable it by default.
33 |
34 | You will need to enable WiPhy support at compile time by passing `--enable-bladerf` to `./configure` during the compile stage.
35 |
36 | WiPhy support is also built into packages from the main Kismet repositories for Kali and Ubuntu Jammy.
37 |
38 | Kismet WiPhy support will also work on macOS!
39 |
40 | ## Kismet WiPhy support
41 |
42 | BladeRF2 WiPhy integrates with the Linux mac80211hwsim virtual 802.11 driver layer. Kismet can use this as a normal Wi-Fi interface in Linux with no additional support, using the Linux Wi-Fi datasource.
43 |
44 | The Kismet WiPhy support will directly communicate with the BladeRF2 SDR using libBladeRF2, and will work without the mac80211hwsim layer and on macOS.
45 |
46 | ## BladeRF WiPhy source parameters
47 |
48 | ### Naming and description options
49 |
50 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
51 |
52 |
53 |
--------------------------------------------------------------------------------
/data/kismet/api/alerts.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "Alert configuration"
3 | uri: "/alerts/definitions"
4 | methods: ["GET"]
5 | roles: ["readonly"]
6 | types: ["anyjson"]
7 | docs: |
8 | Ksimet exposes the full alert system configuration, including currently support alert types,
9 | descriptions of alert content, severity of alerts, and time and burst-rate delivery limiting.
10 | return: |
11 | JSON list of all alert definition and configuration records.
12 |
13 | -
14 | name: "All alerts"
15 | uri: "/alerts/all_alerts"
16 | methods: ["GET"]
17 | roles: ["readonly"]
18 | types: ["anyjson"]
19 | docs: |
20 | Kismet retains the past *N* alerts, as defiend by `alertbacklog` in `kismet_memory.conf`.
21 |
22 | By default, Kismet retains 50 alert records.
23 | return: |
24 | JSON list of all currently stored alerts.
25 |
26 | -
27 | name: "Recent alerts"
28 | uri: "/alerts/last-time/{TIMESTAMP}/alerts"
29 | methods: ["GET"]
30 | roles: ["readonly"]
31 | types: ["anyjson"]
32 | uriparameters:
33 | - {auto: "timestampms"}
34 | docs: |
35 | This endpoint returns alerts since the exact timestamp of seconds and milliseconds.
36 |
37 | A more efficient and reliable method is to use the [eventbus websocket](/docs/api/eventbus).
38 | return: |
39 | JSON list of alerts since `TIMESTAMP.UTIMESTAMP`
40 |
41 | -
42 | name: "Recent alerts (wrapped)"
43 | uri: "/alerts/wrapped/last-time/{TIMESTAMP}/alerts"
44 | methods: ["GET"]
45 | roles: ["readonly"]
46 | types: ["anyjson"]
47 | uriparameters:
48 | - {auto: "timestampms"}
49 | docs: |
50 | This endpoint functions identically to the recent alerts endpoint, but wraps the return in
51 | a JSON object including the timestamp when the server generated the report.
52 |
53 | This can be used for polling UI implementations to know the exact time pass in the next
54 | alert query.
55 |
56 | A more efficient and reliable method is to use the [eventbus websocket](/docs/api/eventbus).
57 | return: |
58 | JSON object containing a list of alerts since `TIMESTAMP.UTIMESTAMP` and the exact timestamp
59 | of the return generation.
60 |
--------------------------------------------------------------------------------
/content/en/docs/readme/installing/intro_compiling.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Introduction"
3 | excerpt: "Kismet has many many configuration knobs and options, but check here for the quickest way to get Kismet working with the latest release (or git version) and what you need to compile and do the initial configuration."
4 | weight: 25
5 | toc: true
6 | ---
7 |
8 | ## Getting current versions
9 |
10 | Often distributions lag behind the latest versions of tools - sometimes significantly so. Several distributions are still shipping the 2016 Kismet code!
11 |
12 | When installing from packages, make sure that your distribution is installing a *current* version of Kismet - and if it isn't, continue on for how to install from the official Kismet package repositories or build it from git!
13 |
14 | ## Official Kismet respositories
15 |
16 | Kismet provides official packages - release and nightly - for many common distributions including Ubuntu, Kali, and Raspbian.
17 |
18 | Learn more about the Kismet packages [here](/packages/)!
19 |
20 | ## Compiling or packages?
21 |
22 | If you are on a distribution which does not provide packages, and is not part of the official Kismet packages, or are working on developing contributions to Kismet, you can always compile from source!
23 |
24 | If you're using a very resource constrained system, like a Raspberry Pi, you may want to consider either the packages, or making a cross compiling environment - modern C++ can be very resource intensive to compile, and a Raspberry Pi 3 or Raspberry Pi Zero is unlikely to be able to successfully compile natively.
25 |
26 | You can modify the Docker-based build environments used by Kismet for package building as a starting point, [hosted on Github](https://github.com/kismetwireless/kismet-packages)
27 |
28 | ## Git code
29 |
30 | The git versions of Kismet are the latest, bleeding-edge development. While *typically* the git code is expected to work, it is often in flux and features may not be fully implemented, may not work, and there may be crashes and unexpected behavior.
31 |
32 | The git version of the code may require different options to compile or run, and may not be fully documented until merged into a release.
33 |
--------------------------------------------------------------------------------
/content/en/docs/readme/gps/gps_serial.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS - Serial"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-14T22:57:44-04:00
6 | lastmod: 2022-09-14T22:57:44-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps_serial-b76b4c3c264f0a1352b1b7eda0ab140a"
12 | weight: 50
13 | toc: true
14 | ---
15 |
16 | Kismet can directly use NMEA serial GPS devices, either on a physical serial port or more commonly on a USB-based serial connector.
17 |
18 | Kismet can *only* use serial devices which communicate in standard NMEA. For binary devices, use the `gpsd` GPS driver.
19 |
20 | Modern gpsd (a GPS management daemon) typically works well with all GPS units, making the serial driver less important; generally, the `gpsd` GPS type will be more effective.
21 |
22 | ## Configuration
23 |
24 | ```
25 | gps=serial:device=/path/to/device
26 | ```
27 |
28 | To determine the proper path to your GPS unit, look below in the `device` options.
29 |
30 | ## GPS options
31 |
32 | ### Common options
33 |
34 | {{}}
35 | Set an arbitrary human-readable name for the GPS. This will be used in the Kismet GPS logs.
36 | {{}}
37 |
38 |
39 | {{}}
40 | Automatically attempt to re-open the GPS if an error occurs or the connection is interrupted.
41 |
42 | This is enabled by default.
43 | {{}}
44 |
45 | ### Serial options
46 |
47 | {{}}
48 | Set the path to the serial device the GPS is on. This is *required*.
49 |
50 | The path will vary based on the operating system and type of GPS. Common paths on Linux may be `/dev/ttyUSB0` or `/dev/ttyACM0`. Common paths on macOS may be `/dev/cu.usbserial`.
51 |
52 | If you are unsure of the USB device for your GPS, consult the output of `dmesg` or `lshw` after plugging it in (Linux), or `ls /dev/cu.*` on macOS.
53 | {{}}
54 |
55 |
56 | {{}}
57 | Set the serial port data rate for the GPS.
58 |
59 | By default, this is set to 4800 which is common for most NMEA GPS units.
60 |
61 | Many USB serial adapters do not obey the speed rate and silently ignore it.
62 | {{}}
63 |
64 |
65 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/pcapfile.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Replay: Pcapfile"
3 | description: ""
4 | lead: ""
5 | date: 2023-06-17T12:29:12-04:00
6 | lastmod: 2023-06-17T12:29:12-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "pcapfile-da13abe07ac4439c5848f6c85af24b98"
12 | weight: 999
13 | toc: true
14 | ---
15 |
16 | Kismet can replay previously recorded data in `pcap` and `pcap-ng` formats, including capture files with the `ppi` headers.
17 |
18 | Kismet replay is useful for testing, debugging, demo, or reprocessing previous sessions (with some caveats).
19 |
20 | ### Example source
21 |
22 | Typically a pcap replay would be done as a command line option rather than a hard coded source:
23 |
24 | ```bash
25 | $ kismet -c /path/to/file.pcap
26 | ```
27 |
28 | ### Supported formats
29 |
30 | Kismet supports any format loadable by libpcap, primarily `pcap` and `pcap-ng` formats.
31 |
32 | When using a `pcap-ng` file, due to how the packets are processed and loaded by libpcap, Kismet will only support `pcap-ng` logs of a single phy type (ie only Wi-Fi, or only Zigbee, but not mixed). Additionally, all packets will appear to come from a single data source (the pcapfile source), not the original interfaces.
33 |
34 | ### Warnings
35 |
36 | When processing pcap logfiles, it is easy to send packets faster than the Kismet server can process. It's always a good idea to use the `pps` source option to limit the packets per second.
37 |
38 | ### Naming and description options
39 |
40 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
41 |
42 | ### Pcapfile options
43 |
44 | {{}}
45 | Limit the replay to a packets-per-second maximum. Without this option, pcapfiles are streamed to Kismet as fast as possible, which may outrun the processing queue on the Kismet server. Pcapfile replays should always be throttled to a rate your server hardware can support to prevent lose packets during the replay; often 1000 to 10000 packets per second is a reasonable starting point.
46 | {{}}
47 |
48 | {{}}
49 | Replay a pcapfile in real time, using the time offsets between packets in the original log.
50 | {{}}
51 |
52 |
--------------------------------------------------------------------------------
/static/styles.css:
--------------------------------------------------------------------------------
1 | body{background-color:#FFF}.transition--300{transition:all 300ms ease-in-out}.toc{height:100%;width:280px;transform:translateX(0)}.content{position:relative}.content h1:first-child,.content h2:first-child{padding-top:0;margin-top:0}.title{font-size:3em}.content{margin-bottom:95vh}.content ul,.content ol{list-style:inherit}.content a{color:#0977c3;text-decoration:none;border-bottom:1px solid #EEE;transition:all 300ms ease}.content a.no-decoration{border-bottom:0}.content a:hover{border-bottom:1px solid #0977c3}.content a:hover.no-decoration{border-bottom:0}a.toc-link{text-decoration:none}.try-it-container{transform:translateY(84%)}.try-it-container.is-open{transform:translateY(0%)}.page-content{display:block !important}.hljs{display:block;background:white;padding:0.5em;color:#333333;overflow-x:auto}.hljs-comment,.hljs-meta{color:#969896}.hljs-string,.hljs-variable,.hljs-template-variable,.hljs-strong,.hljs-emphasis,.hljs-quote{color:#df5000}.hljs-keyword,.hljs-selector-tag,.hljs-type{color:#a71d5d}.hljs-literal,.hljs-symbol,.hljs-bullet,.hljs-attribute{color:#0086b3}.hljs-section,.hljs-name{color:#63a35c}.hljs-tag{color:#333333}.hljs-title,.hljs-attr,.hljs-selector-id,.hljs-selector-class,.hljs-selector-attr,.hljs-selector-pseudo{color:#795da3}.hljs-addition{color:#55a532;background-color:#eaffea}.hljs-deletion{color:#bd2c00;background-color:#ffecec}.hljs-link{text-decoration:underline}.toc-icon{position:fixed;top:0;right:0}#toc:checked ~ .toc{box-shadow:0 0 5px #c8c8c8;transform:translateX(0)}.toc{background-color:rgba(255,255,255,0.9);transform:translateX(-100%)}.toc.toc-right{transform:translateX(100%);right:0}@media (min-width: 52em){.toc{transform:translateX(0)}.toc.toc-right{transform:translateX(0);right:calc((100% - 48rem - 4rem) / 2)}.toc-icon{display:none}.try-it-container{display:block}.content{margin-left:280px}.toc-right ~ .content{margin-left:0;margin-right:280px}}*{box-sizing:border-box}body{font-size:1.2rem;font-family:-apple-system, BlinkMacSystemFont, "Segoe UI", "Roboto", "Oxygen", "Ubuntu", "Cantarell", "Fira Sans", "Droid Sans", "Helvetica Neue", sans-serif}h1,h2,h3,h4,h5,h6{padding-top:0.5em}h1:focus,h2:focus,h3:focus,h4:focus,h5:focus,h6:focus{outline:0}p{margin-top:0.25rem}pre{display:block;background:#f7f7f7;border-radius:2px;border:1px solid #e0e0e0;padding:2px;line-height:1.2;margin-bottom:10px;overflow:auto;white-space:pre-wrap}code{display:inline;font-size:.8em;max-width:100%}
2 |
--------------------------------------------------------------------------------
/content/en/docs/api/alerts.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Alerts"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-31T17:14:05-04:00
6 | lastmod: 2022-10-31T17:14:05-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "alerts-9b88a9f4860a1f3fa27c1bb5f25ce79a"
12 | weight: 260
13 | toc: true
14 | ---
15 |
16 | Kismet uses alerts to communicate wireless intrusion events and critical Kismet server events.
17 |
18 | Alerts are generated both as text messages on [the messagebus](/docs/api/messages/) and as dedicated alert records.
19 |
20 | For real-time monitoring of alerts, see the [eventbus API](/docs/api/eventbus/).
21 |
22 | ### Alert severities
23 |
24 | Alerts severities are categorized by numerical value; a higher number is more severe.
25 |
26 | | Severity | Defintion | Use |
27 | | -------: | --------- | --- |
28 | | 0 | INFO | Informational alerts, such as datasource errors, Kismet state changes, etc |
29 | | 5 | LOW | Low-risk events such as probe fingerprints |
30 | | 10 | MEDIUM | Medium-risk events such as denial of service attempts |
31 | | 15 | HIGH | High-risk events such as fingerprinted watched devices, denial of service attacks, and similar |
32 | | 20 | CRITICAL | Critical errors such as fingerprinted known exploits |
33 |
34 | ### Alert types
35 |
36 | Alerts are categorized by type; alert types are free-form strings, but include:
37 |
38 | | Type | Use |
39 | | ---- | --- |
40 | | DENIAL | Possible denial of service attack |
41 | | EXPLOIT | Known fingerprinted exploit attempt against a vulnerability |
42 | | OTHER | General category for alerts which don't fit in any existing bucket |
43 | | PROBE | Probe by known tools |
44 | | SPOOF | Attempt to spoof an existing device |
45 | | SYSTEM | System events, such as log changes, datasource errors, etc |
46 |
47 | {{< kismet_api alerts >}}
48 |
--------------------------------------------------------------------------------
/layouts/docs/single.html:
--------------------------------------------------------------------------------
1 | {{ define "main" }}
2 |
3 | {{ if ne .Params.category false -}}
4 |
5 |
8 |
9 | {{end -}}
10 | {{ if ne .Params.toc false -}}
11 |
14 | {{ end -}}
15 | {{ if .Params.toc -}}
16 |
17 | {{ else -}}
18 |
19 | {{ end -}}
20 | {{ if .Site.Params.options.breadCrumb -}}
21 |
22 |
28 | {{ end }}
29 |
{{ .Title }}
30 |
{{ .Params.lead | safeHTML }}
31 | {{ if ne .Params.toc false -}}
32 |
35 | {{ end -}}
36 |
9 | {{end -}}
10 | {{ if ne .Params.toc false -}}
11 |
14 | {{ end -}}
15 | {{ if .Params.toc -}}
16 |
17 | {{ else -}}
18 |
19 | {{ end -}}
20 | {{ if .Site.Params.options.breadCrumb -}}
21 |
22 |
28 | {{ end }}
29 |
{{ .Title }}
30 |
{{ .Params.lead | safeHTML }}
31 | {{ if ne .Params.toc false -}}
32 |
35 | {{ end -}}
36 |
37 | {{ .Content }}
38 |
39 |
47 |
55 |
56 |
57 |
58 | {{ end }}
59 |
--------------------------------------------------------------------------------
/content/en/docs/api/packet_filter.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Packet filters"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-03T22:52:15-04:00
6 | lastmod: 2022-11-03T22:52:15-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "packet_filter-72f6ca0ed29c3d0aeb16c86a13678f52"
12 | weight: 310
13 | toc: true
14 | ---
15 |
16 | Packet filtering in Kismet can be used to limit the packets; typically to prevent the packets
17 | from being logged, returned in packet streams, and similar functions.
18 |
19 | The packet filtering system uses a common endpoint layout mapped to different components.
20 |
21 | ### Filter logic
22 |
23 | Kismet filters *block* packets when active. A *positive* match on a filter will *exclude* the packet.
24 |
25 | Filter terms may match on packet attributes, dependent on the type of filter. Matches can operate
26 | as `filter` or `pass` to explicitly allow or block a match.
27 |
28 | Packets which do not match any filter terms are handled by the filter default behavior, which can
29 | be used to accept or reject all non-matching packets.
30 |
31 | The filter engine recognizes several terms when setting filtering: `true`, `reject`, `deny`,
32 | `filter`, and `block` are synonymous and tell the filtering system to exclude a matching packet.
33 | `false`, `allow`, `pass`, and `accept` are synonymous for allowing a packet to pass the filter and
34 | be processed.
35 |
36 | ### MAC address filters
37 |
38 | MAC address filters use the filter type `mac_filter`, and filter (perhaps obviosuly) on MAC addresses.
39 |
40 | MAC filters can be applied to:
41 | * *source* - Original source device. In Wi-Fi networks, equivalent to the source MAC; in other phy types, typically the originating device.
42 | * *destination* - Target device. In Wi-Fi networks, the destination MAC; in other phy types, if present, the equivalent destination address.
43 | * *network* - Associated network. In Wi-Fi, this is the BSSID.
44 | * *other* - Other address; in Wi-Fi this is the fourth MAC found in WDS; in other phy types it represents some form of alternate address.
45 | * *any* - Matching any of the address fields.
46 |
47 | Address filters are applied in the order: `source`, `destination`, `network`, `other`, `any`, `default`. If an address is accepted by the `source` stage and would be rejected by the `destination` stage, the filter will *accept* the packet, as this is the first operation.
48 |
49 | {{< kismet_api packet_filters >}}
50 |
51 |
--------------------------------------------------------------------------------
/content/en/docs/readme/kismetdb/kismetdb_kml.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Kismetdb to KML"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-10T14:58:53-04:00
6 | lastmod: 2022-10-10T14:58:53-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "kismetdb_kml-bfab5368eaa9336056656ed0c6196529"
12 | weight: 40
13 | toc: true
14 | ---
15 |
16 | The `kismetdb_to_kml` tool processes the unified [kismetdb](/docs/readme/logging/kismetdb/) log and exports the positional data as a basic KML.
17 |
18 | This tool is available as part of Kismet when built from source, or in the kismet-logtools package, as of `2019-02`.
19 |
20 | ```bash
21 | kismetdb_to_kml --in some-kismet-file.kismet --out some-file.kml
22 | ```
23 |
24 | ## KML
25 |
26 | KML is an XML-based markup language for use with Google Earth, or other utilities designed to process the Google Earth formats.
27 |
28 | The output KML from `kismetdb_to_kml` is quite basic; for more complex needs, we suggest either editing the `kismetdb_to_kml` source to extend it (patches welcome!) or creating a custom processor to meet your needs.
29 |
30 | ## Arguments
31 |
32 | {{}}
33 | Path to the kismetdb file to process
34 | {{}}
35 |
36 | {{}}
37 | Path to the pcap or pcapng file that will be written
38 | {{}}
39 |
40 | {{}}
41 | By default, `kismetdb_strip_packets` runs a SQL Vacuum command to optimize the database and clean up any journal files. Skipping this process will save time on larger captures.
42 | {{}}
43 |
44 | {{}}
45 | Add status output to the console.
46 | {{}}
47 |
48 | {{}}
49 | Force overwriting any existing files, by default `kismetdb_to_pcap` will refuse to erase existing output files.
50 | {{}}
51 |
52 | {{}}
53 | By default, `kismetdb_to_kml` computes a final average across all the packets seen; this can be more precise than the running average Kismet computes.
54 |
55 | If packets were not logged, or to save time and processing, passing `--basic-location` will use the average location stored in the device record instead.
56 | {{}}
57 |
58 | {{}}
59 | Exclude records within `dist` *meters* of the location provided.
60 |
61 | This can be used to exclude packets close to your home, or other sensitive locations.
62 | {{}}
63 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/bluetooth-hci-bluetooth.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Bluetooth: Linux HCI"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-29T16:48:14-04:00
6 | lastmod: 2022-08-29T16:48:14-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "linux-hci-bluetooth-5227740391f1e9f8ae2c01b4ced99737"
12 | weight: 200
13 | toc: true
14 | ---
15 |
16 | Kismet can use the generic Linux HCI interface for Bluetooth discovery; this uses a normal Bluetooth adapter to perform *active scans* for discoverable Bluetooth classic and BTLE devices.
17 |
18 | This is an **active scan**, not passive monitoring, and reports attributes and advertised information, not packets.
19 |
20 | The Linux Bluetooth source will auto-detect supported interfaces by querying the bluetooth interface list. It can be manually specified with `type=linuxbluetooth`.
21 |
22 | The Linux Bluetooth capture uses the 'kismet_cap_linux_bluetooth' tool, and should typically be installed suid-root: Linux requires root to manipulate the `rfkill` state and the management socket of the Bluetooth interface.
23 |
24 | ### Example source
25 | ```
26 | source=hci0:name=linuxbt
27 | ```
28 |
29 | ## Bluetooth
30 |
31 | Bluetooth uses a frequency-hopping system with dynamic MAC addresses and other oddities - this makes sniffing it not as straightforward as capturing Wi-Fi.
32 |
33 | ## Supported hardware
34 |
35 | For simply identifying Bluetooth (and BTLE) devices, the Linux Bluetooth datasource can use any standard Bluetooth interface supported by Linux.
36 |
37 | This includes almost any built-in Bluetooth interface, as well as external USB interfaces such as the Sena UD100.
38 |
39 | This datasource is available *only* on Linux.
40 |
41 | ## Service Scanning
42 |
43 | By default, the Kismet Linux Bluetooth data source turns on the Bluetooth interface and enables scanning mode. This allows it to see broadcasting Bluetooth (and BTLE) devices and some basic information such as the device name, but does not allow it to index services on the device.
44 |
45 | Complex service scanning and enumeration will be coming in a future revision.
46 |
47 | ## Linux HCI Bluetooth source parameters
48 |
49 | Linux Bluetooth sources support all the common configuration options such as name, information elements, and UUID.
50 |
51 | ### Naming and description options
52 |
53 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
54 |
55 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/wifi-hak5-coconut.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wi-Fi: Hak5 Wifi Coconut"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-29T21:57:37-04:00
6 | lastmod: 2022-08-29T21:57:37-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "hak5-coconut-wifi-2333df0294d60eb6ad8883534e73f805"
12 | weight: 140
13 | toc: true
14 | ---
15 |
16 | The WiFi Coconut source works with the [Hak5 WiFi Coconut](https://shop.hak5.org/products/wifi-coconut), a USB device with 14 2.4GHz Wi-Fi radios.
17 |
18 | Kismet will auto-detect Coconut devices as `hak5_coconut`, or you may manually specify the type:
19 |
20 | ```
21 | source=coconut:type=hak5_coconut
22 | ```
23 |
24 | ## Supported hardware
25 |
26 | The WiFi Coconut source works with the Hak5 WiFi hardware.
27 |
28 | ## Compiling Coconut support
29 |
30 | WiFi Coconut requires libUSB support, and you will need to enable Coconut support at compile time by passing `--enable-wifi-coconut` to `./configure`.
31 |
32 | WiFi Coconut support is also built into packages from the main Kismet repositories for Kali, Debian Bullseye, Debian Bookworm, Ubuntu Focal, and Ubuntu Jammy.
33 |
34 | Kismet Hak5 WiFi Coconut support will also work on macOS!
35 |
36 | ## Kismet WiFi Coconut support
37 |
38 | The WiFi Coconut presents as 14 Wi-Fi radios. Under Linux, these can either be configured as 14 independent sources in Kismet, or as the WiFi Coconut source.
39 |
40 | When configured with Coconut support, Kismet will load the userspace driver from the WiFi Coconut tool, configure each radio on a channel, and report packets from all 14 2.4GHz channels simultaneously in Kismet.
41 |
42 | Under macOS, there is no monitor-mode capable USB driver for the Wi-Fi card used in the Coconut, and the Kismet datasource is required.
43 |
44 | ## BladeRF WiPhy source parameters
45 |
46 | ### Interfaces
47 |
48 | The WiFi Coconut is addressed as `coconut-X` where `X` is the position on the USB topology that the Coconut was found.
49 |
50 | If there is only one Coconut, it can be configured as `coconut`; for multiple Coconut devices on a single system you will need to configure as the USB position, such as `coconut-8`.
51 |
52 | ### Naming and description options
53 |
54 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
55 |
56 | ### Coconut options
57 |
58 | {{}}
59 | Once the WiFi Coconut is opened and enabled, disable the LEDs.
60 | {{}}
61 |
62 |
--------------------------------------------------------------------------------
/content/en/docs/api/serialization.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Serialization"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-23T17:54:50-04:00
6 | lastmod: 2022-10-23T17:54:50-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "serialization-fbfdbed25d0374092c87ad0e92f60577"
12 | weight: 50
13 | toc: true
14 | ---
15 |
16 | Kismet can export data as several different formats; generally these formats are indicated by the type of endpoint being requested (such as foo.json)
17 |
18 | ## JSON
19 |
20 | Kismet will export objects in traditional JSON format suitable for consumption in javascript or any other language with a JSON interpreter.
21 |
22 | ## TJSON
23 |
24 | Some JSON processing systems use the period (`.`) as a separator for trees and paths, while Kismet uses it as part of the name space of the field.
25 |
26 | Using the `.tjson` extension on any REST endpoint will return normal JSON records, but all field names will be changed so that the `.` separator is swapped for `_`; for example `kismet.device.base` will become `kismet_device_base`, and `sensor.device.last_record` would become `sensor_device_last_record`.
27 |
28 | ## EKJSON
29 |
30 | "EK" JSON is modeled after the Elastic Search JSON format, where a complete JSON object is found on each line of the output.
31 |
32 | Kismet supports ekjson on any REST endpoint which returns a vector/list/array of results.
33 |
34 | *Added 2019-10*
35 | To be compatible with the ELK interpretation of field names, Kismet now permutes all field names in `ekjson` output, replacing all instances of `.` with `_`.
36 |
37 | ## ITJSON
38 |
39 | *Added 2019-10*
40 |
41 | "IT" or "Iterative" JSON is a variant of JSON optimized for large vector/array data sets. Instead of containing the entire output in a JSON array, each element of the array is sent on its own newline.
42 |
43 | *All non-ELK use of previous ekjson endpoints should now use itjson endpoints*. The ekjson serialization now modifies field names.
44 |
45 | Kismet supports itjson on any REST endpoint which returns a vector/list/array of results.
46 |
47 | The itjson results must be parsed *as a stream* instead of *as a traditional JSON object*. Attempting to parse an itjson response as traditional JSON will result in syntax errors.
48 |
49 | ## PRETTYJSON
50 |
51 | "Pretty" JSON is optimized for human readability and includes metadata fields describing what Kismet knows about each field in the JSON response. For more information, see the previous section, `Exploring the REST system`.
52 |
53 | "Pretty" JSON should only be used for learning about Kismet and developing; for actual use of the REST API standard "JSON" or "EKJSON" endpoints should be used as they are significantly faster and optimized.
54 |
--------------------------------------------------------------------------------
/content/en/docs/api/wifi_scanningmode.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Scanning mode: Wi-Fi"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-10T00:11:53-05:00
6 | lastmod: 2022-11-10T00:11:53-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "phy80211_scanningmode-efcc3df7e5072d608d4fcc4dcf5130ec"
12 | weight: 410
13 | toc: true
14 | ---
15 |
16 | Capturing raw packets in Wi-Fi requires a monitor-mode capable interface and either
17 | local capture or a high-bandwidth connection to the remote capture device.
18 |
19 | Scanning mode utilizing the normal network detection mode present in essentially
20 | all Wi-Fi cards to collect information about nearby networks for Kismet to use,
21 | but comes with some significant limitations:
22 |
23 | * Clients will not be visible.
24 |
25 | Scanning mode cannot detect clients, only advertising access points.
26 |
27 | * Scanning mode transmits packets
28 |
29 | Often, scanning for nearby networks generates probe requests from the device
30 | which is scanning.
31 |
32 | * Full beacon information may not be available
33 |
34 | Often only the basic content of the beacons is available.
35 |
36 | * Packet data will not be available
37 |
38 | Data packets, retransmissions, and other information will not be available.
39 |
40 | ### Scanning mode data sources
41 |
42 | The scan report API is designed to be as simple as possible, and to automate as
43 | much of the process as possible.
44 |
45 | To assist with automation, scanning mode datasources are created dynamically by
46 | Kismet when scan reports are submitted; there is no need to define a specific
47 | datasource before sending a scanning mode report.
48 |
49 | To create the scanning mode datasource, a scanning report must include:
50 |
51 | 1. A datasource UUID. This UUID must be unique within Kismet, and consistent for
52 | all reports from this datasource. Scanning software should cache this UUID for
53 | consistent reporting between instances.
54 |
55 | 2. A human-readable name. This wil be assigned as the name of the datasource,
56 | and will be updated automatically if the name changes in subsequent reports.
57 |
58 | ### Cache and burst mode reporting
59 |
60 | Scanning mode assumes that the device doing scanning may not be able to maintain a
61 | constant connection to the Kismet server.
62 |
63 | Reports can be cached in sent in groups using the report endpoint; each report
64 | contains a timestamp, GPS location, and signal information. Multiple reports for
65 | the same AP reflecting information over time can be sent in a single connection.
66 |
67 | {{< kismet_api wifi_scanningmode >}}
68 |
--------------------------------------------------------------------------------
/package.json:
--------------------------------------------------------------------------------
1 | {
2 | "name": "doks-child-theme",
3 | "description": "Doks child theme",
4 | "version": "0.5.0",
5 | "engines": {
6 | "node": ">=16.16.0"
7 | },
8 | "browserslist": [
9 | "defaults"
10 | ],
11 | "repository": "https://github.com/h-enk/doks",
12 | "license": "MIT",
13 | "publishConfig": {
14 | "access": "public"
15 | },
16 | "scripts": {
17 | "init": "shx rm -rf .git && git init -b main",
18 | "create": "exec-bin node_modules/.bin/hugo/hugo new",
19 | "prestart": "npm run clean",
20 | "start": "exec-bin node_modules/.bin/hugo/hugo server --bind=0.0.0.0 --disableFastRender",
21 | "prebuild": "npm run clean",
22 | "build": "exec-bin node_modules/.bin/hugo/hugo --gc --minify",
23 | "build:preview": "npm run build -D -F",
24 | "clean": "shx rm -rf public resources",
25 | "clean:install": "shx rm -rf package-lock.json node_modules ",
26 | "lint": "npm run -s lint:scripts && npm run -s lint:styles && npm run -s lint:markdown",
27 | "lint:scripts": "eslint assets/js config functions",
28 | "lint:styles": "stylelint \"assets/scss/**/*.{css,sass,scss,sss,less}\"",
29 | "lint:markdown": "markdownlint-cli2 \"*.md\" \"content/**/*.md\"",
30 | "lint:markdown-fix": "markdownlint-cli2-fix \"*.md\" \"content/**/*.md\"",
31 | "server": "exec-bin node_modules/.bin/hugo/hugo server",
32 | "test": "npm run -s lint",
33 | "env": "env",
34 | "precheck": "npm version",
35 | "check": "exec-bin node_modules/.bin/hugo/hugo version",
36 | "copy:katex-fonts": "shx cp ./node_modules/katex/dist/fonts/* ./static/fonts/",
37 | "postinstall": "hugo-installer --version otherDependencies.hugo --extended --destination node_modules/.bin/hugo",
38 | "version": "auto-changelog -p && git add CHANGELOG.md"
39 | },
40 | "devDependencies": {
41 | "@babel/cli": "^7.18",
42 | "@babel/core": "^7.18",
43 | "@babel/preset-env": "^7.18",
44 | "@fullhuman/postcss-purgecss": "^4.1",
45 | "@hyas/doks": "^0.5",
46 | "@hyas/images": "^0.2.1",
47 | "auto-changelog": "^2.4.0",
48 | "autoprefixer": "^10.4",
49 | "bootstrap": "^5.1",
50 | "clipboard": "^2.0",
51 | "eslint": "^8.19",
52 | "exec-bin": "^1.0.0",
53 | "flexsearch": "^0.7.21",
54 | "highlight.js": "^11.5",
55 | "hugo-installer": "^3.1",
56 | "instant.page": "^5.1",
57 | "katex": "^0.16",
58 | "lazysizes": "^5.3",
59 | "markdownlint-cli2": "^0.4.0",
60 | "netlify-plugin-submit-sitemap": "^0.4.0",
61 | "postcss": "^8.4",
62 | "postcss-cli": "^10.0",
63 | "purgecss-whitelister": "^2.4",
64 | "shx": "^0.3",
65 | "stylelint": "^14.9",
66 | "stylelint-config-standard-scss": "^4.0"
67 | },
68 | "otherDependencies": {
69 | "hugo": "0.101.0"
70 | }
71 | }
72 |
--------------------------------------------------------------------------------
/content/en/docs/readme/starting/commandline.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Command line options"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-23T13:29:59-04:00
6 | lastmod: 2022-08-23T13:29:59-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "commandline-10f0db5095bd24cd6c4ba502ef4b73d5"
12 | weight: 20
13 | toc: true
14 | ---
15 |
16 | Kismet loads the bulk of configuration from the configuration files, however it also accepts a number of command line options which take precedence and allow for speedy changes to common configuration options.
17 |
18 | ## Kismet command line options
19 |
20 | ### Core Kismet options
21 |
22 | {{}}
23 | By default, Kismet uses a small ncurses-based wrapper to remind users to visit the web-based UI. When running Kismet in a script or as a service, it's probably desireable to disable this and use pure text output.
24 | {{}}
25 |
26 |
27 | {{}}
28 | Enable debug mode, primarily for running under GDB. Debug mode disables the internal crash and backtrace code, turns off the ncurses wrapper, and sets up some other state for easier debugging.
29 | {{}}
30 |
31 |
32 | {{}}
33 | Kismet line-wraps messages on the terminal to make them more readable. When running in a script or as a service, it may be more useful to have a complete status message on a single line.
34 | {{}}
35 |
36 |
37 | {{}}
38 | Turn off loading plugins. Mostly useful when debugging if a plugin is causing a crash.
39 | {{}}
40 |
41 | ### Logging options
42 |
43 | {{}}
44 | Turn off all logging for this run.
45 | {{}}
46 |
47 |
48 | {{}}
49 | Set the log title for this run; this populates the title field of the log template.
50 | {{}}
51 |
52 |
53 | {{}}
54 | Use an alternate log prefix for this run, this logs files to a different location.
55 | {{}}
56 |
57 |
58 | {{}}
59 | Set what type of logs are generated for this run.
60 | {{}}
61 |
62 | ### Configuration options
63 |
64 | {{}}
65 | Use an alternate home directory path instead of the users `${HOME}`.
66 | {{}}
67 |
68 |
69 | {{}}
70 | Use an alternative configuration directory instead of the value Kismet was compiled with.
71 | {{}}
72 |
73 |
74 | {{}}
75 | Use an override config file. [Learn about config overrides here](/docs/readme/configuring/configfiles/#configuration-override-and-flavors).
76 | {{}}
77 |
--------------------------------------------------------------------------------
/content/en/posts/2022-08-01-release-202208R1.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Release 2022-08-R1"
3 | description: ""
4 | excerpt: "It's hacker summer camp season again, and that means squeezing out a new release just in time"
5 | date: 2022-11-12T09:17:04-05:00
6 | lastmod: 2022-11-12T09:17:04-05:00
7 | weight: 50
8 | images: []
9 | categories: []
10 | tags: []
11 | aliases: [ "/releases/kismet-2022-08-R1/" ]
12 | contributors: ["Mike Kershaw / Dragorn"]
13 | pinned: false
14 | homepage: false
15 | ---
16 |
17 | ## Kismet 2022-08-R1
18 |
19 | It's summer camp season again, and that means squeezing a new release out just in time.
20 |
21 | Kismet 2022-08-R1 is live!
22 |
23 | ## Download
24 |
25 | You can get the 2022-08-R1 release from [the Kismet downloads page](/download/#kismet-release), where you can get both the source and packages for several distributions.
26 |
27 | # Changes and Updates
28 |
29 | This release is mostly focused on speed and stability improvements, including some significant speed fixes to regressions in creating new device records in busy environments. There are a few new features though:
30 |
31 | * Initial support for Wi-Fi 6e support
32 |
33 | 6GHz channels now have initial support, and can be captured from. 6e APs will show up in Kismet, but currently the UI won't classify them quite right.
34 |
35 | For Intel based 6e cards, you *must* run `iw dev scan` *before* starting Kismet! Intel ignores the regdb and will only enable 6GHz channels after a scan!
36 |
37 | For other cards, you must set the regdomain to US via `iw reg set US`.
38 |
39 | * GPS magnetic heading support on hardware which provides it
40 |
41 | * New graph line in packets UI showing the packets per second *processed*
42 |
43 | * New BPF filter programs for wardrive and remote capture mode
44 |
45 | Greatly reduce the CPU load for capturing only AP records (and not data / clients)
46 |
47 | * Fix 802.11r records not being initialized which could cause a crash
48 |
49 | * Initial support for modern droneID v2 data
50 |
51 | Optimizations include:
52 |
53 | * Significant reduction in temporary smart-pointer objects which aren't needed
54 |
55 | * Significant speed improvrements to creating new fields and components
56 |
57 | * Shifting more operations to compile-time constants
58 |
59 | * Parallel sort algorithms on C++17 systems
60 |
61 | * New, optimized packet chains
62 |
63 | * RAM optimizations by reducing number of empty records created
64 |
65 | * Many many more death-by-a-thousand-cuts improvements to performance
66 |
67 | ## Packaging
68 |
69 | If you're looking to package Kismet, have a look at the [packaging guidelines](/docs/readme/packaging/).
70 |
71 | ## Thanks
72 |
73 | As always, a tremendous thank you to all the supporters on [Github Sponsors](https://github.com/sponsors/kismetwireless) and [Patreon](https://www.patreon.com/kismetwireless)
74 |
75 |
--------------------------------------------------------------------------------
/layouts/shortcodes/kismet_packages.html:
--------------------------------------------------------------------------------
1 |
32 |
33 | {{ range $.Site.Data.kismet.packages }}
34 |
84 | {{ end }}
85 |
86 |
87 |
--------------------------------------------------------------------------------
/content/en/docs/readme/kismetdb/kismetdb_device_json.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Kismetdb to device JSON"
3 | description: ""
4 | lead: ""
5 | date: 2022-10-06T22:12:21-04:00
6 | lastmod: 2022-10-06T22:12:21-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "kismetdb_device_json-c99c861fec8b11a7ade72bde88e02296"
12 | weight: 30
13 | toc: true
14 | ---
15 |
16 | The `kismetdb_dump_devices` tool processes the unified [kismetdb](/docs/readme/logging/kismetdb/) log and exports the device records as JSON for use with other tools.
17 |
18 | This tool is available as part of Kismet when built from source, or in the kismet-logtools package, as of `2019-02`.
19 |
20 | ```bash
21 | kismetdb_dump_devices --in some-kismet-file.kismet --out some-json-file.json
22 | ```
23 |
24 | ## Streaming via `stdout`
25 |
26 | Like many other command line tools, specifying `-` as the output file will cause `kismetdb_dump_devices` to stream the output to the console, making it simple to pipe it to other tools:
27 |
28 | ```bash
29 | kismetdb_dump_devices --in some-kismetdb.kismet --out - | python -mjson.tool
30 | ```
31 |
32 | ## Arguments
33 |
34 | {{}}
35 | Path to the kismetdb file to process
36 | {{}}
37 |
38 | {{}}
39 | Path to the pcap or pcapng file that will be written
40 | {{}}
41 |
42 | {{}}
43 | By default, `kismetdb_strip_packets` runs a SQL Vacuum command to optimize the database and clean up any journal files. Skipping this process will save time on larger captures.
44 | {{}}
45 |
46 | {{}}
47 | Output as a JSON file; useful when using the `kismetdb_statistics` tool to populate an index of log files or similar.
48 | {{}}
49 |
50 | {{}}
51 | Add status output to the console.
52 | {{}}
53 |
54 | {{}}
55 | Force overwriting any existing files, by default `kismetdb_to_pcap` will refuse to erase existing output files.
56 | {{}}
57 |
58 | {{}}
59 | Reformat field names to be compatible with JSON path searching and ELK by rewriting all `.` to `_`; For example, `kismet.base.key` becomes `kismet_base_key`.
60 |
61 | This is turned on automatically when ELK mode is enabled.
62 | {{}}
63 |
64 | {{}}
65 | Export as an `ekjson` format; Instead of exporting a JSON array of the devices, instead export each device as an object on a single line.
66 |
67 | While not technically valid JSON, this format can be used to stream processing or inserting into other tools (such as ELK), and can be processed line-by-line with far fewer resources than a single array of all options.
68 |
69 | This will automatically enable JSON path mode.
70 | {{}}
71 |
72 |
73 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/bluetooth-ubertooth.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Bluetooth: Ubertooth"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-29T16:57:24-04:00
6 | lastmod: 2022-08-29T16:57:24-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "ubertooth-35c8f95aede066448b4dd0420f7612c4"
12 | weight: 210
13 | toc: true
14 | ---
15 |
16 | The Ubertooth One is an open-source hardware Bluetooth and BTLE sniffer by Great Scott Gadgets.
17 |
18 | Kismet must be compiled with support for `libusb`, `libubertooth`, and `libbtbb`; you will need `libusb-1.0-dev`, `libubertooth-dev`, and `libbtbb-dev` (or the equivalents for your distribution), and you will need to make sure that the `Ubertooth` option is enabled in the output from `./configure`.
19 |
20 | ## Bluetooth
21 |
22 | Bluetooth uses a frequency-hopping system with dynamic MAC addresses and other oddities - this makes sniffing it not as straightforward as capturing Wi-Fi.
23 |
24 | ## Supported hardware
25 |
26 | This datasource works with the [Ubertooth One by Great Scott Gadgets](https://greatscottgadgets.com/ubertoothone/).
27 |
28 | The Ubertooth datasource works on Linux and macOS via libUSB and libUbertooth.
29 |
30 |
31 | ## Ubertooth interfaces
32 |
33 | The Ubertooth One in Kismet can be referred to as simply `ubertooth`:
34 |
35 | ```bash
36 | kismet -c ubertooth
37 | ```
38 |
39 | When using multiple Ubertooth (Uberteeth?) devices, each device is numbered, starting from 0. The Ubertooth library indexes the devices automatically, and so is dependent on the order the devices were detected.
40 |
41 | ```bash
42 | kismet -c ubertooth-1
43 | ```
44 |
45 | Kismet will list available Ubertooth devices automatically in the datasources list.
46 |
47 | ## Ubertooth source parameters
48 |
49 | ### Naming and description options
50 |
51 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
52 |
53 | ## Limitations
54 |
55 | The Ubertooth One truncates all packets to a maximum of 50 bytes; packets larger than 50 bytes will be discarded and ignored because it is not possible to validate the checksum.
56 |
57 | The Ubertooth One firmware (as of 2019-12) appears to have issues setting channels in BTLE mode, leading to frequent firmware crashes which require the USB device to be removed and re-inserted. Kismet currently disables channel hopping on the Ubertooth One, and defaults to advertising channel 37.
58 |
59 | Alternate channels can be set with the `channel=` source option;
60 |
61 | ```bash
62 | kismet -c ubertooth:channel=39
63 | ```
64 |
65 | To try to mitigate firmware hangs, Kismet will reset the U1 device periodically, which will reboot the U1. This does not prevent all firmware hangs, however, and you may find it necessary to remove and re-insert the Ubertooth One periodically.
66 |
67 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/bluetooth-nrf51822.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Bluetooth: nRF 51822"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-03T13:39:27-04:00
6 | lastmod: 2022-09-03T13:39:27-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "nrf51822-da3645542063d1b12b931cad2044213c"
12 | weight: 230
13 | toc: true
14 | ---
15 |
16 | The nRF 51822 is a chip used for Bluetooth LE communications. To use it with Kismet, it must be flashed with sniffer firmware provided by NordicRF. A pre-flashed version is available from [Adafruit](https://www.adafruit.com/product/2269) and other online retailers.
17 |
18 | The nRF 51822 utilizes serial communications so no special libraries are needed for use with Kismet, *however* not all platforms have working serial port drivers (see below).
19 |
20 | ## Bluetooth
21 |
22 | Bluetooth uses a frequency-hopping system with dynamic MAC addresses and other oddities - this makes sniffing it not as straightforward as capturing Wi-Fi.
23 |
24 | ## nRF 51822 interfaces
25 |
26 | nRF 51822 datasources in Kismet can be referred to as simply `nrf51822`. These devices appear as serial ports, so cannot be auto-detected. Each nrf51822 source must have a `device` option:
27 |
28 | ```
29 | source=nrf51822:device=/dev/ttyUSB0
30 | ```
31 |
32 | Because there is no unique information available for the nrf51822 source, if you have multiple devices on a single system, or are using remote capture, be sure to set a unique UUID for each source!
33 |
34 | ## Channel Hopping
35 |
36 | The firmware does it's own channel hopping so no selections are available.
37 |
38 | ## Limitations
39 |
40 | You must specify a `device=` configuration pointing to the serial port this device has been assigned by the kernel; it can not be automatically detected, and will not appear in the datasource list.
41 |
42 | Multiple versions of the Adafruit BLE device are sold, and not all have the sniffer firmware. Make sure you have a V2 or newer device, *with the sniffer firmware*.
43 |
44 | Devices without sniffer firmware *may* be flashable, but may require an external programmer.
45 |
46 | ### macOS limitations
47 |
48 | The nRF 51822 uses a CP2104 serial chip; testing with the [latest drivers](https://www.silabs.com/products/development-tools/software/usb-to-uart-bridge-vcp-drivers) under MacOS Catalina has been unsuccessful; however a driver update may fix that in the future.
49 |
50 | ## Source parameters
51 |
52 | ### Naming and description options
53 |
54 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
55 |
56 | ### Device selection
57 |
58 | {{}}
59 | The nRF 518222 devices appear as USB serial devices, and serial devices can not be auto-discovered.
60 |
61 | You *must* provide the path to the serial device associated with the nRF 51822 sniffer.
62 | {{}}
63 |
64 |
--------------------------------------------------------------------------------
/data/kismet/api/packet_filters.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "Packet filter status"
3 | uri: "/filters/packet/{FILTERID}/filter"
4 | methods: ["GET", "POST"]
5 | roles: ["readoly"]
6 | types: ["anyjson"]
7 | uriparameters:
8 | - {name: "FILTERID", type: "string", description: "Filter ID"}
9 | jsonparameters:
10 | - {auto: "fields"}
11 | docs: |
12 | Fetch the filter status, including description, default behavior, and type, of the given
13 | filter ID.
14 |
15 | -
16 | name: "Packet filter default behavior"
17 | uri: "/filters/packet/{FILTERID}/set_default"
18 | types: ["cmd"]
19 | roles: ["admin"]
20 | methods: ["POST"]
21 | uriparameters:
22 | - {name: "FILTERID", type: "string", description: "Filter ID"}
23 | jsonparameters:
24 | - {name: "default", type: "string", description: "Default behavior, such as `reject` or `allow`"}
25 | docs: |
26 | Configure the default behavior of the specified filter.
27 |
28 | -
29 | name: "Adding a MAC filter"
30 | uri: "/filters/packet/{FILTERID}/{PHYNAME}/{BLOCKNAME}/set_filter"
31 | types: ["cmd"]
32 | roles: ["admin"]
33 | methods: ["POST"]
34 | uriparameters:
35 | - {name: "FILTERID", type: "string", description: "Filter ID"}
36 | - {name: "PHYNAME", type: "string", description: "Target phy to filter. MAC filters are phy specific."}
37 | - {name: "BLOCKNAME", type: "string", description: "Name of filter group (source, destination, network, other, or any)"}
38 | jsonparameters:
39 | -
40 | name: "filter"
41 | type: "JSON object"
42 | description: |
43 | Dictionary object where the MAC address is the key and a boolean filter term is the value.
44 | These filters will be added to the block identified by the blockname.
45 |
46 | A value of `true` indicates the matching MAC address *will be blocked*, while a value
47 | of `false` indicates the matching MAC address *will be passed*.
48 | docs: |
49 | MAC address filters use the type `mac_filter`.
50 |
51 | MAC filters are phy-specific, because the same MAC could be used across multiple PHYs.
52 | example: |
53 | ```json
54 | {
55 | "filter": {
56 | "AA:BB:CC:DD:EE:FF": true,
57 | "00:11:22:00:00:00/FF:FF:FF:00:00:00": false
58 | }
59 | }
60 | ```
61 |
62 | -
63 | name: "Removing a MAC filter"
64 | uri: "/filters/{FILTERID}/{PHYNAME}/{BLOCKNAME}/remove_filter"
65 | types: ["json"]
66 | methods: ["POST"]
67 | roles: ["admin"]
68 | uriparameters:
69 | - {name: "FILTERID", type: "string", description: "Filter ID"}
70 | - {name: "PHYNAME", type: "string", description: "Target phy to filter. MAC filters are phy specific."}
71 | - {name: "BLOCKNAME", type: "string", description: "Name of filter group (source, destination, network, other, or any)"}
72 | jsonparameters:
73 | -
74 | name: "addresses"
75 | type: "JSON list"
76 | description: |
77 | List of MAC addresses to be removed from the target filter.
78 |
--------------------------------------------------------------------------------
/layouts/_default/baseof.html:
--------------------------------------------------------------------------------
1 |
2 |
3 | {{ partial "head/head.html" . }}
4 | {{ if eq .Kind "home" -}}
5 | {{ .Scratch.Set "class" "home" -}}
6 | {{ else if eq .Kind "404" -}}
7 | {{ .Scratch.Set "class" "error404" -}}
8 | {{ else if eq .Kind "page" -}}
9 | {{ .Scratch.Set "class" .Type -}}
10 | {{ .Scratch.Add "class" " single" -}}
11 | {{ else -}}
12 | {{ .Scratch.Set "class" .Type -}}
13 | {{ .Scratch.Add "class" " list" -}}
14 | {{ end -}}
15 |
16 | {{ partial "header/header.html" . }}
17 |
30 |
31 | {{ end }}
32 |
33 |
34 |
62 |
63 |
64 |
--------------------------------------------------------------------------------
/content/en/docs/dev/debugging.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Debugging"
3 | description: ""
4 | lead: ""
5 | date: 2023-04-15T10:06:22-04:00
6 | lastmod: 2023-04-15T10:06:22-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "debugging-3c5bbcc29239559f6d5ad34187b8f3c2"
12 | weight: 10
13 | toc: true
14 | ---
15 |
16 | Kismet (especially in beta) is in a state of rapid development - this means that bad things can creep into the code. Sorry about that!
17 |
18 | If you're interested in helping debug problems with Kismet, here's the most useful way to do so:
19 |
20 | 1. Compile Kismet from source (per the quick start guide above)
21 |
22 | 2. Install Kismet (typically via `sudo make suidinstall`)
23 |
24 | 3. Run Kismet, *FROM THE SOURCE DIRECTORY*, in `gdb`:
25 |
26 | ```bash
27 | $ gdb ./kismet
28 | ```
29 |
30 | This loads a copy of Kismet with all the debugging info intact; the copy of Kismet which is installed system-wide usually has this info removed; the installed version is 1/10th the size, but also lacks a lot of useful information which we need for proper debugging.
31 |
32 | 4. Tell GDB to ignore the PIPE signal
33 |
34 | ```
35 | (gdb) handle SIGPIPE nostop noprint pass
36 | ```
37 |
38 | This tells GDB not to intercept the SIGPIPE signal (which can be generated, among other times, when a data source has a problem)
39 |
40 | 5. Configure GDB to log to a file
41 |
42 | ```
43 | (gdb) set logging on
44 | ```
45 |
46 | This saves all the output to `gdb.txt`
47 |
48 | 5. Run Kismet - *in debug mode*
49 |
50 | ```
51 | (gdb) run --debug [any other options]
52 | ```
53 |
54 | This turns off the internal error handlers in Kismet; they'd block gdb from seeing what happened. You can specify any other command line options after --debug; for instance:
55 |
56 | ````
57 | (gdb) run --debug -n -c wlan1
58 | ````
59 |
60 | 6. Wait for Kismet to crash
61 |
62 | 7. Collect a backtrace
63 | ```
64 | (gdb) bt
65 | ```
66 |
67 | This shows where Kismet crashed.
68 |
69 | 8. Collect thread info
70 | ```
71 | (gdb) info threads
72 | ```
73 |
74 | This shows what other threads were doing, which is often critical for debugging.
75 |
76 | 9. Collect per-thread backtraces
77 | ```
78 | (gdb) thread apply all bt full
79 | ```
80 |
81 | This generates a dump of all the thread states
82 |
83 | 10. Send us the gdb log and any info you have about when the crash occurred; dragorn@kismetwireless.net or swing by IRC or the Discord channel (info available about these on the website, https://www.kismetwireless.net)
84 |
85 | ## Advanced debugging
86 |
87 | If you're familiar with C++ development and want to help debug even further, Kismet can be compiled using the ASAN memory analyzer; to rebuild it with the analyser options:
88 |
89 | ```
90 | $ make clean
91 | $ CC=clang CXX=clang++ ./configure --enable-asan
92 | ```
93 |
94 | ASAN has a performance impact and uses significantly more RAM, but if you are able to recreate a memory error inside an ASAN instrumented Kismet, that will be very helpful.
95 |
96 |
--------------------------------------------------------------------------------
/content/en/hak5-mk7-led/index.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Hak5 WiFi Pineapple MK7 LED mod"
3 | description: ""
4 | date: 2022-11-12T10:40:45-05:00
5 | lastmod: 2022-11-12T10:40:45-05:00
6 | images: []
7 | aliases: ["/mk7-led-mod"]
8 | layout: docs
9 | ---
10 |
11 | ## Wi-Fi Pineapple Mk 7 LED Mod
12 |
13 | The MK7 LED mod is an add-on board for the [Hak5 Wi-Fi Pineapple MK7](https://shop.hak5.org/products/wifi-pineapple) which adds some bling and fun LEDs. Proceeds from the case help support Kismet development, too!
14 |
15 | The LED mod is designed to work best with the [Kismet MK7 case](/mk7-kismet-case); with the normal black opaque case the LEDs won't be visible.
16 |
17 | Installation of the LED mod requires very basic soldering skills.
18 |
19 | ## Assembly Directions
20 |
21 | This assumes you've already disassembled the MK7 and have the board accessible.
22 |
23 | 1. Place the LED board so that the LEDs are facing up, and the 4 holes fit over the debug header on the MK7 PCB.
24 |
25 | {:width="300px"} [Zoom](ledmod.jpg)
26 |
27 | 2. Slightly tack down the board by soldering the 4 pins on the debug header.
28 |
29 | I recommend using a very small amount of solder to make it easier to remove the board in the future if so desired.
30 |
31 | ## Controlling the LEDs
32 |
33 | The LEDs are controlled with the `LEDMK7` tool on the Pineapple.
34 |
35 | You can:
36 |
37 | * Change the speed of the pulsing of the LEDs
38 |
39 | ```
40 | # LEDMK7 -p 255
41 | ```
42 |
43 | To set the pulse speed even faster:
44 |
45 | ```
46 | # LEDMK7 -p 255,5
47 | ```
48 |
49 | * Change the color of the pulsing LEDs
50 |
51 | The LED colors are defined as HSV (hue, saturation, value). You can experiment with the values, or use colors from the [HSV color wheel](http://colorizer.org/).
52 |
53 | To pulse from a dim red to bright green:
54 |
55 | ```
56 | # LEDMK7 -a 30,200 -b 120,255
57 | ```
58 |
59 | To pulse bright green and only change the brightness:
60 |
61 | ```
62 | # LEDMK7 -a 120,255 -b 120,255
63 | ```
64 |
65 | Each pattern is set as a Hue (color, 0-360) and saturation (0-255).
66 |
67 | * Set each LED to a specific color
68 |
69 | Each LED can be set to its own color and brightness. Each LED is set to a Hue (color, 0-360), Saturation (0-255), and brightness (0-255).
70 |
71 | ```
72 | # LEDMK7 -0 30,255,255 -1 120,255,255 -2 300,255,255 -3 0,0,255
73 | ```
74 |
75 | You can find more examples and detailed info with:
76 |
77 | ```
78 | # LEDMK7 --help
79 | ```
80 |
81 | ## Reflashing the LED mod
82 |
83 | The LED mod uses an attiny841, flashed with an Arduino bootloader. It has a standard 6-pin AVR ISP header for programming.
84 |
85 | Because of how the board is connected to the MK7, you *must* use a programmer which can be configured to flash without power. You should *never* feed power into the MK7 via a programmer. A [programmer like this](https://amzn.to/3ceBA0k) (Amazon affiliate link) will work fine.
86 |
87 |
--------------------------------------------------------------------------------
/data/kismet/api/system.yml:
--------------------------------------------------------------------------------
1 |
2 | -
3 | name: "System status"
4 | uri: "/system/status"
5 | methods: ["GET", "POST"]
6 | types: ["anyjson"]
7 | roles: ["readonly"]
8 | docs: |
9 | The status endpoint returns almost all data around the current system status,
10 | load, system health, thermal and fan sensors (if any), memory use, battery state,
11 | runtime, and more.
12 | jsonparameters:
13 | -
14 | auto: "fields"
15 | return: |
16 | JSON object of system status snapshot.
17 | responses:
18 | success:
19 | - [200, "Basic success and JSON object"]
20 | failure:
21 | - [-1, "On error (typically for malformed simplification)"]
22 |
23 | -
24 | name: "Timestamp"
25 | uri: "/system/timestamp"
26 | methods: ["GET"]
27 | types: ["anyjson"]
28 | roles: ["readonly"]
29 | docs: |
30 | Fetch the system timestamp as a second and microsecond; this can be used
31 | to synchronize timestamps with the UI or as a keep-alive check.
32 | return: |
33 | JSON object of the timestamp as second and microsecond.
34 | responses:
35 | success:
36 | - [200, "JSON object"]
37 |
38 | -
39 | name: "Tracked fields"
40 | uri: "/system/tracked_fields"
41 | methods: ["GET"]
42 | types: ["html"]
43 | roles: ["readonly"]
44 | docs: |
45 | To aid in development, Kismet maintains a list of all known field names,
46 | data types, and descriptions.
47 |
48 | This endpoint returns a human-readable HTML page of all fields.
49 | return: |
50 | HTML document
51 | responses:
52 | success:
53 | - [200, "HTML document"]
54 |
55 | -
56 | name: "Packet statistics"
57 | uri: "/packetchain/packet_stats"
58 | types: ["anyjson"]
59 | methods: ["GET", "POST"]
60 | roles: ["readonly"]
61 | jsonparameters:
62 | -
63 | auto: "fields"
64 | docs: |
65 | Kismet exposes the packet processing statistics as RRD (round robin database)
66 | collections for incoming packet rate, packet proessing rates, data size,
67 | and more.
68 |
69 | The RRD format encodes long-running data as collections of decreasing accuracy,
70 | reporting the past 60 seconds, past hour as 60 second averages, and past
71 | day as 1 hour averages.
72 | return: |
73 | JSON object of RRD packet stats.
74 | responses:
75 | success:
76 | - [200, "JSON object"]
77 | failure:
78 | - [-1, "On error (typically for malformed simplification)"]
79 |
80 | -
81 | name: "Dynamic Javascript import"
82 | uri: "/dynamic"
83 | types: ["js"]
84 | roles: ["readonly"]
85 | methods: ["GET"]
86 | docs: |
87 | Kismet creates a dynamically generated javascript file for the UI to
88 | load the core system and JS plugin modules into the global JS namespace.
89 |
90 | This endpoint is meant to be used by a web-based UI and included as a
91 | script import, such as:
92 |
93 | ```html
94 |
95 | ```
96 | result: |
97 | A Javascript file suitable for import.
98 | responses:
99 | success:
100 | - [200, "Success"]
101 |
102 |
--------------------------------------------------------------------------------
/content/en/docs/readme/gps/gps_intro.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "GPS"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-14T21:06:55-04:00
6 | lastmod: 2022-09-14T21:06:55-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "gps_intro-c40e26be2ccf2ca9ed202f595ad59863"
12 | weight: 10
13 | toc: true
14 | ---
15 |
16 | ## GPS in Kismet
17 |
18 | Kismet can integrate with a GPS device to provide geolocation coordinates for devices.
19 |
20 | *Remember*: Kismet uses the GPS to determin the location *where a packet was seen*. This is not necessarily the *location of the transmitter*, but can be used to determine where the transmitter is likely located.
21 |
22 | The quality of the location estimates is determined in part by the quality of the sampling methods. Passing a transmitter once in a straight line (such as driving past) limites the possible location to that single path. By circling the area of the suspected transmitter, or navigating in a grid around it, the data available to deduce the transmitter location is greatly increased.
23 |
24 | GPS data is included in the log files, in PPI pcap files, and exported over the REST interface.
25 |
26 | Some datasources (such as ADSB) are able to self-source locational data; when absolute location information is available, Kismet will prefer that data.
27 |
28 | Remote datasources can be configured with static GPS coordinates, or paired with a remote GPS tool.
29 |
30 | In addition to logging GPS data on a per-packet basis, Kismet maintains a running average of device locations which are exported as the average location in the Kismet UI and in device summaries. Kismet attempts to keep the running average location as accurate as possible by factoring speed into the location counts.
31 |
32 | ## GPS reception
33 |
34 | Modern cell phones use a fusion of GPS, cellular, Wi-Fi, and Bluetooth locational data to generate locational information under almost any condition. This can lead to a false sense of GPS reception in an area. USB GPS receivers typically only provide *true* GPS processing without fusion of other locational services. They typically require a clear view of the sky, and may be unable to obtain a GPS lock inside a building, or even when placed in a window, depending on orientation.
35 |
36 | Some GPS units support multiple GPS variants implemented by different countries; these "multi-constellation" receivers may be able to obtain a stronger location signal in more locations, but typically are more expensive.
37 |
38 | When testing GPS, be sure to give the receiver as much a view of the sky as possible.
39 |
40 |
41 | ## Configuring GPS in Kismet
42 |
43 | Kismet can handle multiple GPS types. Generally, you will only want to define a single GPS per Kismet instance, however if multiple GPS devices are defined, Kismet will use the lcoation of the GPS with the most recent valid location report.
44 |
45 | GPS definitions take the form of:
46 |
47 | ```
48 | gps=[gpstype]:option1=value1,option2=value2
49 | ```
50 |
51 | GPS is configured in the [kismet.conf](/docs/readme/configuring/configfiles/) configuration file, or preferably, the [kismet_site.conf](/docs/readme/configuring/configfiles/#customizing-configs-with-kismet_siteconf) configuration override.
52 |
53 |
54 |
--------------------------------------------------------------------------------
/content/en/docs/readme/intro/passive_capture.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Passive Capture"
3 | description: "Passive signal capture and how it works"
4 | lead: ""
5 | date: 2022-08-09T23:15:55-04:00
6 | lastmod: 2022-08-09T23:15:55-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "wifi_capture-f3936341f5d128cc84e2e84875ddd756"
12 | weight: 100
13 | toc: true
14 | ---
15 |
16 | ## Passive monitoring
17 |
18 | Kismet operates almost entirely passively, with a few exceptions (such as Bluetooth scanning mode) noted in the documentation for those capture types.
19 |
20 | Kismet is *not* an attack tool (generally) - to test your Wi-Fi security check out tools like [Aircrack-NG](https://www.aircrack-ng.org) or the [Wi-Fi Pineapple](https://shop.hak5.org/).
21 |
22 | Kismet is largely focused on collecting, collating, and sorting wireless data. The logs generated by Kismet can be fed into other tools (the pcap, handshakes, and other data) like hashcat, aircrack, and more.
23 |
24 | ## Wireless vs Wired monitoring
25 |
26 | Wireless capture is often more difficult than wired capture, at several levels:
27 |
28 | * Different physical characteristics
29 |
30 | When connected to a wired network and capturing packets, you will always capture all packets available on that connection (assuming you have sufficient processing power and storage speed to log them, of course).
31 |
32 | When capturing packets from a wireless network, things are very different; your receiver may not be in a position to even see the packets that the legitimate destination can receive fine, you may not be on the correct channel or part of the spectrum when the packets are sent, there may be localized interference, or you may be in the center of reflected signals that cancel each other out.
33 |
34 | * Drivers
35 |
36 | To capture raw packets from a Wi-Fi device, a mode called "monitor mode" or "rfmon" is required - this mode turns off packet filtering in the Wi-Fi card itself and passes raw data up to the operating system.
37 |
38 | While most drivers in the Linux kernel support this, not all do. Mobile chipsets (such as those found in Android phones or Raspberry Pi devices) typically do not have the code in the device firmware *at all* and either cannot be used, or require special driver hacks to re-enable it.
39 |
40 | Windows has nearly no monitor-mode capable public drivers, and macOS can enter monitor mode for the internal Airport cards, but typically not on any other type of Wi-Fi.
41 |
42 | Other non-Wi-Fi protocols often have no radio support, or lack drivers. Sometimes this is solved with special hardware and drivers, sometimes it can be solved with software defined radios.
43 |
44 | * Many protocols
45 |
46 | Wi-Fi alone has at least 6 major revisions, each of which is largely invisible to hardware of the previous generation, combined with 3 major spectrum bands. Each revision increases speed (decreasing effective signal) and complexity of the signal (MIMO, sub-channels, etc) which make capturing data harder.
47 |
48 | That's just Wi-Fi - add in Bluetooth, Zigbee, arbitrary RF protocols, and the amount of hardware and software needed to capture what is flying around in the air explodes.
49 |
50 |
--------------------------------------------------------------------------------
/config/_default/menus/menus.en.toml:
--------------------------------------------------------------------------------
1 | [[main]]
2 | name = "Download"
3 | url = "/download/"
4 | identifier = "download"
5 | weight = 10
6 |
7 | [[main]]
8 | name = "Docs"
9 | url = "/docs/"
10 | identifier = "docs"
11 | weight = 50
12 |
13 | [[main]]
14 | name = "Readme"
15 | weight = 10
16 | identifier = "readme"
17 | url = "/docs/readme/intro/kismet/"
18 | parent = "docs"
19 |
20 | [[main]]
21 | name = "API"
22 | weight = 25
23 | identifier = "API"
24 | url = "/docs/api/rest_like/"
25 | parent = "docs"
26 |
27 | [[main]]
28 | name = "Development"
29 | weight = 50
30 | identifier = "development"
31 | url = "/docs/dev/plugins/"
32 | parent = "docs"
33 |
34 | [[main]]
35 | name = "Projects"
36 | url = "/projects/"
37 | weight = 75
38 |
39 | [[main]]
40 | name = "Posts"
41 | url = "/posts/"
42 | weight = 100
43 |
44 |
45 |
46 | [[social]]
47 | name = "GitHub"
48 | pre = ""
49 | url = "https://github.com/kismetwireless"
50 | post = "v0.1.0"
51 | weight = 10
52 |
53 | [[social]]
54 | name = "Mastodon"
55 | pre = ""
56 | url = "https://infosec.exchange/@kismetwireless"
57 | weight = 20
58 |
59 | #[[social]]
60 | # name = "Twitter"
61 | # pre = ""
62 | # url = "https://twitter.com/kismetwireless"
63 | # weight = 20
64 |
65 | # [[footer]]
66 | # name = "Privacy"
67 | # url = "/privacy-policy/"
68 | # weight = 10
69 |
--------------------------------------------------------------------------------
/content/en/docs/readme/alerts/alerts.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Alerts"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-18T23:09:56-04:00
6 | lastmod: 2022-09-18T23:09:56-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "alerts-a1fa807b249b9356aec185f87f9abcf2"
12 | weight: 10
13 | toc: true
14 | ---
15 |
16 | Kismet can function as a WIDS (Wireless Intrusion Detection System) with alerts for stateless and stateful fingerprint and trend based monitoring. Kismet fingerprint alerts can trigger on known-hostile specific behavior such as attacks against wireless drivers, and trend-based monitors can detect unusual behavior over time, such as flooding and denial of service attacks.
17 |
18 | Kismet can integrate with other tools via the live packet export REST API, the Kismet alert REST API, and via syslog and some SIEM tools.
19 |
20 | Kismet is most effective as an IDS in stationary (ie, non-wardriving) capacity. Kismet WIDS functionality can be used in mobile and channel-hopping installations, but accuracy and coverage may suffer.
21 |
22 | ## Configuring alerts
23 |
24 | ### Alert rates
25 |
26 | Alerts are configured with the `alert=` configuration option, and the defaults are defined in `kismet_alerts.conf`. Alerts are configured by name, with `throttle` and `burst` options. They can be overridden with `kismet_site.conf` (preferred) or by editing `kismet_alerts.conf` directly (discouraged).
27 |
28 | The throttle option controls how many alerts are allowed per time unit (seconds and minutes), and burst controls how many alerts are allowed in quick succession. For instance:
29 |
30 | ```
31 | alert=NETSTUMBLER,5/min,1/sec
32 | ```
33 |
34 | Will allow at most one alert per second, and at most 5 alerts per minute. Excess alerts will not be reported.
35 |
36 | ### Disabling alerts
37 |
38 | An alert can be disabled by setting the maximum throttle and burst to 0.
39 |
40 | ```
41 | alert=NOCLIENTMFP,0/min,0/sec
42 | ```
43 |
44 | Some critical system alerts, such as those raised while loading configuration files, can not be disabled.
45 |
46 | ### Complex alert configuration
47 |
48 | Some alerts, such as `APSPOOF`, have additional configuration options. These options are documented in the description of each alert.
49 |
50 | ## False positives
51 |
52 | Kismet includes alerts for many theoretical attacks reported in research, as CVEs, etc.
53 |
54 | Many of these attacks rely on a combination of specific chipsets and drivers, and specific abuses of the Wi-Fi standard; as Wi-Fi evolves, what was previously an over-long packet element used to exploit a driver may become a commonly used field which needs extra data.
55 |
56 | Deprecated attacks in Kismet are typically disabled by default in the config file, but at times a new evolution or use of Wi-Fi will trigger an alert with a false positive.
57 |
58 | *Generally* speaking, it is unlikely that most users will encounter cutting edge attacks in the wild. Many things are possible - which is why Kismet provides the alerts - but often unlikely. When given an usual alert, consider taking the step of examining the PCAP log directly with a tool like [Wireshark](https://wireshark.org).
59 |
60 | ## Alerts
61 |
62 | {{< kismet_alert_list >}}
63 |
64 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/bluetooth-ticc2540.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Bluetooth: TI-CC-2540"
3 | description: ""
4 | lead: ""
5 | date: 2022-09-03T10:48:10-04:00
6 | lastmod: 2022-09-03T10:48:10-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "ticc2540-557c20d2cd7d44af315bee89e28dee85"
12 | weight: 220
13 | toc: true
14 | ---
15 |
16 | The Texas Instruments CC2540 is a chip used for Bluetooth communications. To use it with Kismet, it must be flashed with the sniffer firmware [provided by TI](http://www.ti.com/tool/PACKET-SNIFFER). Often the devices are available with the sniffer firmware pre-flashed.
17 |
18 | Kismet must be compiled with support for `libusb` to use TICC2540; you will need `libusb-1.0-dev` (or the equivalent for your distribution), and you will need to make sure that the `TI CC 2540` option is enabled in the output from `./configure`.
19 |
20 | To use the TI CC2540 capture, you must have a TI CC2540 dongle flashed with the sniffer firmware. You can flash this yourself with a CC-Debugger or purchase one online from many retailers.
21 |
22 | *Note*: It seems that while many CC2540 devices are *advertised* as pre-flashed with the sniffer firmware, they appear not to be!
23 |
24 | ## Bluetooth
25 | Bluetooth uses a frequency-hopping system with dynamic MAC addresses and other oddities - this makes sniffing it not as straightforward as capturing Wi-Fi.
26 |
27 | ## Supported hardware
28 |
29 | Any USB device based on the CC2540 chip, and flashed with the TI sniffer firmware, should work. Beware! Many online vendors sell identical-looking devices based on the CC2531 chip, which is *not* the same thing!
30 |
31 | The TI-CC-2540 source works on Linux and macOS via the libUSB library.
32 |
33 | ## TI CC2540 interfaces
34 |
35 | TI CC2540 datasources in Kismet can be referred to as simply `ticc2540-...`:
36 |
37 | ```bash
38 | kismet -c ticc2540-0
39 | ```
40 |
41 | When using multiple TICC devices, they can be specified either in order discovered by the system (`ticc2540-0`, `ticc2540-1`, etc), or by USB path. If you need to know which specific device is being configured, use the USB path - however, this path may be subject to change if USB devices are moved, new USB devices added, etc.
42 |
43 | To find available TICC devices, use:
44 |
45 | ```bash
46 | kismet_cap_ti_cc_2540 --list
47 | ```
48 |
49 | Kismet will also list available TI CC2540 devices automatically in the datasources list.
50 |
51 | The position of USB devices may change if more devices are added or if devices are removed.
52 |
53 | ## TI CC2540 concerns
54 |
55 | The sniffer firmware in the TI CC2540 sometimes goes into a permanent error state until the device is physically re-initialized - by disconnecting it from USB and reconnecting it.
56 |
57 | Unfortunately, there does not seem to be any way to automate this process, as once the device enters an error state, it will remain in that state and cannot be reinitialized over USB.
58 |
59 | Connecting the CC2540 device to a USB port with programmable power control may provide a way to power it off without physically disconnecting it.
60 |
61 | ## Source parameters
62 |
63 | ### Naming and description options
64 |
65 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
66 |
67 |
--------------------------------------------------------------------------------
/data/kismet/api/wifi_ssidtracker.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "SSID view"
3 | docs: |
4 | Mirroring the [device view](/docs/api/device_views/) api, the SSID summarization endpoint is the primary interface for clients to access the SSID list and for scripts to retrieve lists of SSIDs.
5 |
6 | The SSID summarization is best utilized when applying a view window via the start and length variables.
7 | uri: "/phy/phy80211/ssids/views/ssids"
8 | types: ["anyjson"]
9 | methods: ["POST"]
10 | roles: ["readonly"]
11 | jsonparameters:
12 | - {auto: "fields"}
13 | - {auto: "regex" }
14 | -
15 | name: "colmap"
16 | type: "list"
17 | required: false
18 | description: |
19 | Column map information generated by the Kismet UI for mapping
20 | jquery-datatable column information for sorting and ordering.
21 | -
22 | name: "datatable"
23 | type: "boolean"
24 | required: false
25 | description: |
26 | Wrap output in a container suitable for connecting to a jquery-datatable
27 | container in the web UI.
28 | parameters:
29 | -
30 | name: "start"
31 | type: "number"
32 | required: false
33 | description: |
34 | When in datatables mode, the start of the windowed view.
35 | -
36 | name: "length"
37 | type: "number"
38 | required: false
39 | description: |
40 | When in datatables mode, the length of the windowed view.
41 | -
42 | name: "draw"
43 | type: "number"
44 | required: false
45 | description: |
46 | When in datatables mode, the datatable draw sequence number.
47 | -
48 | name: "search[value]"
49 | type: "string"
50 | required: false
51 | description: |
52 | When in datatables mode, the search term to be applied to all fields in the
53 | summary list.
54 | -
55 | name: "order[0][column]"
56 | type: "string"
57 | required: false
58 | description: |
59 | When in datatables mode, the display column number for shorting, indexed by
60 | the colmap JSON data parameter.
61 | -
62 | name: "order[0][dir]"
63 | type: "string"
64 | required: false
65 | description: |
66 | When in datatables mode, the sort direction sent by jquery-datatables.
67 | notes: |
68 | In datatables mode, this endpoint takes both a `json=...` command dictionary *and* typical
69 | FORM post variables. This is necessary to work within the datatables request structure.
70 | return: |
71 | JSON object containing the list of SSIDs and metadata for jquery-datatables.
72 | responses:
73 | success:
74 | - [200, "Basic success and JSON object"]
75 | failure:
76 | - [-1, "On error (typically for malformed simplification)"]
77 |
78 | -
79 | name: "SSID details"
80 | uri: "/phy/phy80211/ssids/by-hash/{HASH}/ssid"
81 | types: ["anyjson"]
82 | methods: ["GET", "POST"]
83 | roles: ["readonly"]
84 | added: "2020-08"
85 | uriparameters:
86 | - {name: "HASH", type: "string", description: "SSID hash"}
87 | jsonparameters:
88 | - {auto: "fields"}
89 | docs: |
90 | Fetch a detailed SSID object including all related device keys.
91 |
92 | Keyed by the SSID hash (a semi-random value calculated by Kismet from the SSID content, length,
93 | and encryption options).
94 |
--------------------------------------------------------------------------------
/content/en/docs/readme/logging/pcap.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "PCAP"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-24T16:05:05-04:00
6 | lastmod: 2022-08-24T16:05:05-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "pcap-e5320013c0567a6de791ded9a3ee86d0"
12 | weight: 30
13 | toc: true
14 | ---
15 |
16 | PCAP (and PCAP-NG) are standard formats for recording packets, which most tools which manipulate packets accept, including Tcpdump and Wireshark.
17 |
18 | A kismetdb log can be converted to PCAP-NG, or Kismet can write the packet logs directly.
19 |
20 | There are two main flavors of PCAP supported by Kismet:
21 |
22 | 1. `pcapppi`
23 |
24 | `pcapppi` is the legacy PCAP format, which uses PPI packet headers. This version of the pcap log can only handle Wi-Fi packets, and manipulates the packet headers to fit the PPI standard (only one antenna signal value and other limitations). Generally the `pcapng` format should be used, but not all tools understand the new format.
25 |
26 | 2. `pcapng`
27 |
28 | `pcapng` is the modern pcap standard supported by Wireshark, Tshark, and other tools.
29 |
30 | PCAP-NG allows for mixing packet types (such as Wi-Fi, BTLE, and Zigbee) as well as retaining the original capture interface (which datasource in Kismet saw the packet), the original headers (pure radiotap packet headers with more complete signal info, timestamps, etc). It also allows Kismet to log the packet without manipulation (such as header translation to PPI), allows for annotations, other data, and more.
31 |
32 | Whenever possible, the PCAP-NG log file will have richer content.
33 |
34 | ## When to enable PCAP
35 |
36 | Typically there is no need to enable both the `kismet` log type and the PCAP log types at the same time, since the PCAP log can be created using the `kismetdb_to_pcap` tool which is part of Kismet.
37 |
38 | ### Log type
39 |
40 | ```
41 | log_types=pcapppi
42 | ```
43 |
44 | and
45 |
46 | ```
47 | log_types=pcapng
48 | ```
49 |
50 | ## Rotating logs
51 |
52 | As of `kismet-2023-12-git`, the `pcapng` log supports rotating the log file based on size. When enabled, a new `pcapng` log will be made once the existing log exceeds the specified size.
53 |
54 | ```
55 | pcapng_log_max_mb=1024
56 | ```
57 |
58 | Log size is specified in megabytes. Logs are rotated when the size *exceeds* the configured maximum, and may be up to 4kb larger than the maximum specified size (in other words, if logging to a filesystem with a maximum file size, do not set the maximum `pcapng` log to the exact maximum as it may exceed the filesystem maximum by a small amount).
59 |
60 | Logs are rotated so that no packets should be lost during the creation of the new log file.
61 |
62 | ## Filtering
63 |
64 | ### Duplicate packets
65 |
66 | Kismet can record duplicate packets when multiple datasources capture the same data. In some instances, keeping duplicate packets is desirable (such as remote captures used for device location), while in others, logging duplicates may be a waste of space.
67 |
68 | ```
69 | pcapng_log_duplicate_packets=false
70 | ```
71 |
72 | and
73 |
74 | ```
75 | ppi_log_duplicate_packets=false
76 | ```
77 |
78 | ### Data packets
79 |
80 | Kismet typically logs all types of packets. To discard data packets, retaining only management frames:
81 |
82 | ```
83 | pcapng_log_data_packets=false
84 | ```
85 |
86 | and
87 |
88 | ```
89 | ppi_log_data_packets=false
90 | ```
91 |
92 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/channelhop.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Channels & Hopping"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-26T13:29:04-04:00
6 | lastmod: 2022-08-26T13:29:04-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "channelhop-8ab5dd335aa7e3f0b47d2c5998cd56b1"
12 | weight: 20
13 | toc: true
14 | ---
15 |
16 | Typically, a wireless device can only tune to one part of the available spectrum at a time.
17 |
18 | For Wi-Fi and many related sources, these are called *channels*.
19 |
20 | ## Channel hopping
21 |
22 | There is always a trade-off between channel coverage and complete capture of a single channel: Either you remain on a single channel and capture as much data as possible, while missing events on other channels, or you change channels frequently and gather more information about the environment as a whole, but risk missing specific events on individual channels.
23 |
24 | By default, Kismet will enable channel hopping on all datasources which support it.
25 |
26 | Most commonly, channel hopping is discussed in relationship with Wi-Fi, but some other datasource types also hop channels.
27 |
28 | ## Hop speeds
29 |
30 | Picking a channel hopping speed is a balance between several factors:
31 |
32 | 1. The tuning speed of the device.
33 |
34 | Some devices are able to re-tune very quickly, others are not.
35 |
36 | 2. The frequency of data in the target protocol.
37 |
38 | Changing channel more frequently than devices are likely to transmit means the chances of losing data is significantly higher.
39 |
40 | 3. Ability of the drivers to tune rapidly
41 |
42 | Some device drivers do not gracefully handle tuning at high speeds.
43 |
44 | ### Kismet defaults
45 |
46 | Kismet defaults to changing channels 5 times a second. This rate is chosen as a compromise for WiFi devices - an Access Point typically beacons at 10 times a second, so a hop rate of 5Hz nicely fits the [Nyquist](https://en.wikipedia.org/wiki/Nyquist_frequency) calculations to have the best chance of capturing a packet.
47 |
48 | Channel hopping rates can be configured per-source in the source definition.
49 |
50 | ## Channel splitting
51 |
52 | When channel hopping, Kismet will automatically split the list of channels between all the datasources of the same type. There is little benefit to hopping to the *same* channels at the same time with multiple interfaces!
53 |
54 | Kismet will automatically divide the list so that the maximum number of unique channels are covered by the devices available.
55 |
56 | ## Configuration
57 |
58 | The global channel hopping controls affect all datasources, unless a source specifically changes the values.
59 |
60 | Global hopping options can be overridden in `kismet_site.conf` [override config file](/docs/readme/configuring/configfiles/#customizing-configs-with-kismet_siteconf):
61 |
62 | {{}}
63 | Control if any source channel hops by default.
64 | {{}}
65 |
66 |
67 | {{}}
68 | Set the default channel hop speed. Rate can be expressed in hops per second or hops per minute, and defaults to `5/sec`.
69 |
70 | ```
71 | channel_hop_speed=5/sec
72 | ```
73 |
74 | or
75 |
76 | ```
77 | channel_hop_speed=10/min
78 | ```
79 | {{}}
80 |
81 | For more esoteric datasource configuration options, check `kismet.conf`
82 |
--------------------------------------------------------------------------------
/layouts/shortcodes/kismet_api_param.html:
--------------------------------------------------------------------------------
1 |
2 | {{ if ne (default "" (.Get "auto")) "" }}
3 | {{ if eq (.Get "auto") "timestamp" }}
4 | TIMESTAMP
5 | number
6 | REQUIRED
7 |
8 |
9 |
Timestamps can be absolute (UNIX epochal) timestamps, or they
10 | can be relative negativ numbers, indiciating "number of seconds
11 | before now".
12 |
13 |
Kismet can reduce the amount of information being processed and returned by an API by simplifying the
24 | fields to only return the data needed by the caller.
65 |
--------------------------------------------------------------------------------
/content/en/docs/dev/capframework.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Capture framework"
3 | description: ""
4 | lead: ""
5 | date: 2022-11-11T00:53:43-05:00
6 | lastmod: 2022-11-11T00:53:43-05:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "capframework-5338b4e350d0f440a7c7fc5373615a27"
12 | weight: 999
13 | toc: true
14 | ---
15 |
16 | ## Extending Kismet: Datasource Capture Framework Pure-C API
17 |
18 | Kismet supports capturing from any binary capable of talking a simple IPC/network protocol.
19 |
20 | To minimize the requirements and simplify embedding capture code in small embedded systems without a C++ runtime, `capture_framework.h` and `capture_framework.c` implement the protocol and main communications loops in a pure-c helper library.
21 |
22 | ## Pure-C
23 |
24 | Capture-Framework is written in pure-c which should be compatible with C99 and does not require any C++ runtimes. The Kismet plugins and decoders still require C++.
25 |
26 | ## Communication
27 |
28 | Kismet capture binaries communicate over IPC on a shared pipe, or via a TCP network connection to the Kismet server. When using piped IPC, the pipe pairs are passed to the exec()'d capture binary in the --in-fd and --out-fd command line options.
29 |
30 | Data is buffered in generic, simplistic ring buffer structures and dispatched via a standard select() loop.
31 |
32 | ## Threads
33 |
34 | Capture-Framework uses pthreads to spawn two threads, in addition to the primary main thread:
35 |
36 | ### Capture Thread
37 |
38 | The capture callback (more on these soon) is run in an independent, cancelable thread. This allows the capture calls on a binary to block without interfering with the standard select() loop and communication with the Kismet server.
39 |
40 | ### Channel Hopping Thread
41 |
42 | If channel hopping is enabled in the capture binary, an independent thread performs the timing and channel set commands.
43 |
44 | ## Callbacks
45 |
46 | All expandable functions in Capture-Framework are handled by passing callback functions; listing devices, probing, opening, setting channels, etc, are handled by callback functions and can be trivially customized.
47 |
48 | # Order of Operations
49 |
50 | Kismet will launch a capture binary and perform one of several actions:
51 |
52 | ## List devices
53 |
54 | This is called on all capture drivers to create a list of devices the user could pick. The capture binary is responsible for enumerating any devices it can support via any mechanism; for instance the Linux Wi-Fi capture binary enumerates devices by processing the /sys/class/net/ pseudofilesystem.
55 |
56 | After listing devices, a capture binary should go into a spindown/pending state and wait to be closed; no other action will be taken this execution.
57 |
58 | ## Probe definition
59 |
60 | This is called to determine the driver which can handle a definition, when no type is explicitly specified. The capture binary is responsible for determining if this looks like a source that can be opened. For example, the pcapfile capture will attempt to open the definition as a pcap; the Linux Wi-Fi capture will attempt to retrieve the interface channel via SIOCGIWCHAN to determine if it looks to be a Wi-Fi device.
61 |
62 | After returning a probe response, a capture binary should go into a spindown/pending state and wait to be closed; no other action will be taken this execution.
63 |
64 | ## Open definition
65 |
66 | This is called to actually open and begin capturing from an interface.
67 |
68 |
--------------------------------------------------------------------------------
/content/en/images/kismet-web.svg:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 |
68 |
--------------------------------------------------------------------------------
/content/en/docs/readme/datasources/radiacode.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Radiation: Radiacode"
3 | description: ""
4 | lead: ""
5 | date: 2024-04-21T20:05:49-04:00
6 | lastmod: 2024-04-21T20:05:49-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "radiacode-f7aafe045d2e0320c3d31bd930c25078"
12 | weight: 999
13 | toc: true
14 | ---
15 |
16 | Added: `2024-04`
17 |
18 | Kismet can collect environmental radiation data for display and logging from the [Radiacode](https://radiacode.com) Geiger counter.
19 |
20 | The Radiacode is capable of reporting counts-per-second (CPS), dosage (sieverts), and an energy spectrogram which may be useful in identifying the elements involved.
21 |
22 | ## !! WARNING !!!
23 |
24 | Kismet interfaces with environmental sensors, including Geiger Counter / Radiation detection devices because they are interesting. **NEVER** rely on the radiation exposure data presented by Kismet for personal safety!
25 |
26 | **Always** consult the documentation for your Geiger counter. Different Geiger counter hardware is sensitive to different energy levels of radiation.
27 |
28 | The location of your detector, the type of detection hardware, and the speed at which you are travelling can all impact
29 |
30 | ## Compiling Radiacode support
31 |
32 | Radiacode support in Kismet requires libUSB. The Radiacode sources will be compiled when libUSB is available at configure time.
33 |
34 | ## Radiacode sources
35 |
36 | The Radiacode device is identified `radiacode-usb-#`; for a single Radiacode it can be identified simply as `radiacode-usb-0`:
37 |
38 | ```bash
39 | kismet -c radiacode-usb-0:name=radiacode
40 | ```
41 |
42 | If using multiple Radiacode devices, they can be specified either in the order they were enumerated by the system, (`radiacode-usb-0`, `radiacode-usb-1`, etc) or by the USB path based on bus and port number (`radiacode-usb-1-8` for example). Please note that the USB path identification may be subject to change if USB devices are moved, new devices added, etc.
43 |
44 | For finding the USB location, consult the output of `kismet_cap_radiacode_usb --list`.
45 |
46 | Kismet will automatically list Radiacode devices in the datasources list.
47 |
48 | ## Supported hardware
49 |
50 | The Radiacode source requires the Radiacode Geiger counter hardware, connected via USB.
51 |
52 | The Radiacode is a modern Geiger counter which can report counts per second and dosage rates.
53 |
54 | ## Viewing
55 |
56 | Realtime radiation data can be viewed in the Web UI in the `Radiation` panel, or enabled in the top status bar via the `Settings` panel.
57 |
58 | ## Logging
59 |
60 | Radiation data is logged in the [kismetdb](/docs/readme/logging/kismetdb/) log as JSON records in the `snapshots` and `data` tables. Once development is complete, it will be logged in [pcapng](/docs/readme/logging/pcap/) as a custom packet block.
61 |
62 | ## Stability
63 |
64 | The Radiacode hardware appears to have a slightly fragile USB implementation. While *typically* this is not a problem, on some occaisons, initializing the device over USB can cause the USB implementation on the Radiacode to crash.
65 |
66 | If this happens, the Radiacode will no longer respond on USB; to fix this, disconnect the Radiacode from USB, power the device off using the buttons and LCD interface, then power it back on and connect to USB again.
67 |
68 | ## Radiacode source parameters
69 |
70 | ### Naming and description options
71 |
72 | All data sources accept the [common naming and description](/docs/readme/datasources/datasources/#naming-and-describing-datasources) options.
73 |
74 |
--------------------------------------------------------------------------------
/data/kismet/api/bluetooth_scanningmode.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "Bluetooth scanning report"
3 | uri: "/phy/phybluetooth/scan/scan_report"
4 | types: ["cmd"]
5 | methods: ["POST"]
6 | roles: ["admin", "scanreport"]
7 | jsonparameters:
8 | - {name: "reports", type: "list", description: "List of report objects"}
9 | - {name: "source_name", type: "string", description: "Source name"}
10 | - {name: "source_uuid", type: "string", description: "Source UUID"}
11 | added: "2020-07"
12 | docs: |
13 | Submit a scanning report.
14 |
15 | A scanning report consists of a datasource name and UUID, and a list of
16 | report objects.
17 | apinotes: |
18 | Each report object should contain:
19 |
20 | {{< kismet_api_param name="timestamp" type="number" required="false">}}
21 | Unix timestamp with second precision.
22 |
23 | If no timestmap is provided, the time the report is received is used.
24 |
25 | Due to lack of high-precision packet data in scanning mode, timestamps
26 | are second precision only.
27 | {{< /kismet_api_param >}}
28 |
29 | {{< kismet_api_param name="btaddr" type="string" required="true">}}
30 | Bluetooth device address
31 | {{< /kismet_api_param >}}
32 |
33 | {{< kismet_api_param name="devicetype" type="string" required="false">}}
34 | Device type, if known
35 | {{< /kismet_api_param >}}
36 |
37 | {{< kismet_api_param name="txpowerlevel" type="number" required="false">}}
38 | Advertised transmission power level
39 | {{< /kismet_api_param >}}
40 |
41 | {{< kismet_api_param name="pathloss" type="number" required="false">}}
42 | Reported path loss
43 | {{< /kismet_api_param >}}
44 |
45 | {{< kismet_api_param name="scan_data" type="string" required="false">}}
46 | Binary scan data, as hex string
47 | {{< /kismet_api_param >}}
48 |
49 | {{< kismet_api_param name="service_data" type="dictionary" required="false">}}
50 | Dictionary of UUID to service scan data, as binary hex strings
51 | {{< /kismet_api_param >}}
52 |
53 | {{< kismet_api_param name="signal" type="number" required="false">}}
54 | Signal level, in dBm
55 | {{< /kismet_api_param >}}
56 |
57 | {{< kismet_api_param name="lat" type="number" required="false">}}
58 | GPS latitude of detection, in decimal degrees
59 | {{< /kismet_api_param >}}
60 |
61 | {{< kismet_api_param name="lon" type="number" required="false">}}
62 | GPS longitude of detection, in decimal degrees
63 | {{< /kismet_api_param >}}
64 |
65 | {{< kismet_api_param name="alt" type="number" required="false">}}
66 | GPS altitude of detection, in meters
67 | {{< /kismet_api_param >}}
68 |
69 | {{< kismet_api_param name="spd" type="number" required="false">}}
70 | GPS speed of motion of sensor during detection, in kilometers/hour
71 | {{< /kismet_api_param >}}
72 |
73 | {{}}
74 | Object/Map of [device tags](/docs/api/devices/#editing-device-tags) which will be
75 | applied to the device created by this scan.
76 |
77 | Tagged scans should be used with caution: Tags will be applied to the device and will override
78 | any existing tags, so care must be taken with tags that overlap those editable by the user interface.
79 |
80 | Submitting a user name or description tag, for instance, may be valuable if the user can enter
81 | that data in the scanning app, but the user should be advised that they can't also edit that user name
82 | in the normal Kismet UI.
83 | {{< /kismet_api_param >}}
84 |
--------------------------------------------------------------------------------
/content/en/docs/readme/logging/wiglecsv.md:
--------------------------------------------------------------------------------
1 | ---
2 | title: "Wiglecsv"
3 | description: ""
4 | lead: ""
5 | date: 2022-08-24T20:03:08-04:00
6 | lastmod: 2022-08-24T20:03:08-04:00
7 | images: []
8 | menu:
9 | docs:
10 | parent: ""
11 | identifier: "wiglecsv-7c369bce9c4baf95050e8c7a9bd0a2d4"
12 | weight: 40
13 | toc: true
14 | aliases:
15 | - /docs/readme/wigle/
16 | ---
17 |
18 | [Wigle](https://wigle.net) is a community for wardriving and mapping WiFi networks.
19 |
20 | Kismet log files (kismetdb) can be converted to the Wigle CSV format, but Kismet can also directly log to the Wigle format with the `wiglecsv` log.
21 |
22 | Wigle does not collect packet contents, so a `wiglecsv` log does not contain packets - it is a simplified CSV text file of WiFi Access Points and Bluetooth devices, and their locations. If you want to save packet contents, be sure to also turn on `kismet` or `pcapng` logs!
23 |
24 | Since Wigle is designed for mapping wireless, Kismet will only create entries in the `wiglecsv` log when a GPS is connected and a location is available. If you have no GPS location, the `wiglecsv` will be empty.
25 |
26 |
27 | ## Log type
28 |
29 | ```
30 | log_types=wiglecsv
31 | ```
32 |
33 | Kismet will automatically create a wiglecsv file while running. This can be combined with other log types like `kismet` and `pcapng`, but does not need to be. *Remember* you can't recover packet data from a `wiglecsv` log, so if you want to process the packets later, be sure to log another format too!
34 |
35 | ## Converting kismetdb to wiglecsv
36 |
37 | The `kismetdb` log can be converted to Wigle format using the `kismetdb_to_wiglecsv` tool included as part of Kismet or in the `kismet-logtools` package.
38 |
39 | The simplest way to convert a kismetdb log to a wiglecsv is to simply run the conversion tool:
40 |
41 | ```
42 | kismetdb_to_wiglecsv --in some-kismet-log-file.kismet --out some-wigle-file.csv
43 | ```
44 |
45 | ## Conversion options
46 |
47 | Converting a kismetdb log can take a lot of space and time, because each packet is examined and the coordinates written to the CSV file. This can be sped up with various options to the `kismetdb_to_wiglecsv` tool:
48 |
49 | {{}}
50 | Add more status output to the console while running, useful for long files that take a significant amount of time to process.
51 | {{}}
52 |
53 |
54 | {{}}
55 | By default, `kismetdb_to_wiglecsv` performs a database cleanup and optimization stage (optimizing existing data, cleaning up stray journal files, etc). If you are running multiple passes on a file, or have already cleaned it using `kismetdb_clean`, you can save time by skipping this stage.
56 | {{}}
57 |
58 |
59 | {{}}
60 | By default, `kismetdb_to_wiglecsv` will only emit one record per second per access point. This prevents overloading the Wigle servers with insane quantities of data with no useful positional updates. If you find you are generating extremely large data sets, you can increase this time.
61 | {{}}
62 |
63 |
64 | {{}}
65 | `kismetdb_to_wiglecsv` will cache device information from the database to speed up looking up SSIDs and other device data. By default, the last 1000 devices are cached, but if you have a very large number of devices, or a very small amount of ram, increasing or decreasing this cache may speed up processing.
66 | {{}}
67 |
68 | ## Uploading to Wigle
69 |
70 | Once your log is converted, you can upload it to [Wigle](https://www.wigle.net) by creating an account there and choosing the file from your computer.
71 |
72 |
--------------------------------------------------------------------------------
/data/kismet/api/wifi_scanningmode.yml:
--------------------------------------------------------------------------------
1 | -
2 | name: "Wi-Fi scanning report"
3 | uri: "/phy/phy80211/scan/scan_report"
4 | types: ["cmd"]
5 | methods: ["POST"]
6 | roles: ["admin", "scanreport"]
7 | jsonparameters:
8 | - {name: "reports", type: "list", description: "List of report objects"}
9 | - {name: "source_name", type: "string", description: "Source name", required: true}
10 | - {name: "source_uuid", type: "string", description: "Source UUID", required: true}
11 | added: "2020-06"
12 | docs: |
13 | Submit a scanning report.
14 |
15 | A scanning report consists of a datasource name and UUID, and a list of
16 | report objects.
17 | apinotes: |
18 | Each report object should contain:
19 |
20 | {{< kismet_api_param name="timestamp" type="number" required="false">}}
21 | Unix timestamp with second precision.
22 |
23 | If no timestmap is provided, the time the report is received is used.
24 |
25 | Due to lack of high-precision packet data in scanning mode, timestamps
26 | are second precision only.
27 | {{< /kismet_api_param >}}
28 |
29 | {{< kismet_api_param name="ssid" type="string" required="false">}}
30 | Network SSID, if known.
31 | {{< /kismet_api_param >}}
32 |
33 | {{< kismet_api_param name="bssid" type="string" required="true">}}
34 | Access point BSSID
35 | {{< /kismet_api_param >}}
36 |
37 | {{< kismet_api_param name="capabilities" type="string" required="false">}}
38 | An Android or Wigle style string of encryption options and other AP
39 | attributes, such as `[WPS]`, `[WPA-PSK-TKIP+CCMP]`, and so on.
40 |
41 | If no capabilities field is provided, the device is assumed to be an AP
42 | with no encryption options set.
43 | {{< /kismet_api_param >}}
44 |
45 | {{< kismet_api_param name="channel" type="string" required="false">}}
46 | Channel string, such as `6` or `42HT40P`
47 | {{< /kismet_api_param >}}
48 |
49 | {{< kismet_api_param name="freqkhz" type="number" required="false">}}
50 | Frequency of device, in KHz
51 | {{< /kismet_api_param >}}
52 |
53 | {{< kismet_api_param name="signal" type="number" required="false">}}
54 | Signal level, in dBm
55 | {{< /kismet_api_param >}}
56 |
57 | {{< kismet_api_param name="lat" type="number" required="false">}}
58 | GPS latitude of detection, in decimal degrees
59 | {{< /kismet_api_param >}}
60 |
61 | {{< kismet_api_param name="lon" type="number" required="false">}}
62 | GPS longitude of detection, in decimal degrees
63 | {{< /kismet_api_param >}}
64 |
65 | {{< kismet_api_param name="alt" type="number" required="false">}}
66 | GPS altitude of detection, in meters
67 | {{< /kismet_api_param >}}
68 |
69 | {{< kismet_api_param name="spd" type="number" required="false">}}
70 | GPS speed of motion of sensor during detection, in kilometers/hour
71 | {{< /kismet_api_param >}}
72 |
73 | {{}}
74 | Object/Map of [device tags](/docs/api/devices/#editing-device-tags) which will be
75 | applied to the device created by this scan.
76 |
77 | Tagged scans should be used with caution: Tags will be applied to the device and will override
78 | any existing tags, so care must be taken with tags that overlap those editable by the user interface.
79 |
80 | Submitting a user name or description tag, for instance, may be valuable if the user can enter
81 | that data in the scanning app, but the user should be advised that they can't also edit that user name
82 | in the normal Kismet UI.
83 | {{< /kismet_api_param >}}
84 |
85 |
--------------------------------------------------------------------------------