Docker Reference - oshri-almog/esp32c5-kismet-wifi-interface GitHub Wiki

This page lists everything about the project's Docker image in reference form: images and tags, Dockerfile targets and build arguments, the entrypoint's roles, every environment variable, the Compose services, volumes, ports, capabilities, the CI workflow that publishes the images, and the smoke test. For step-by-step installation, read Install with Docker first.

The files described here are docker/Dockerfile, docker/entrypoint.sh, docker/kismet_site.conf, compose.yaml, .github/workflows/docker.yml and tests/docker_smoke.sh.

• Architectures: linux/amd64 and linux/arm64, in one multi-arch tag, so a Raspberry Pi 4 or 5 with a 64-bit OS pulls the arm64 image. No 32-bit ARM image is built.
• Published since v0.1.0, and pulled without a login. A pull downloads about 48 MB for the Kismet image and about 60 MB for the demo. On Docker Desktop (amd64), docker pull of both worked, and Compose pulled the demo instead of building it. The arm64 images were read from the registry on the Raspberry Pi, but not yet pulled there with Docker.
• Local names when you build by hand, as in the Dockerfile's header: esp32c5-kismet (that is, esp32c5-kismet:latest) and esp32c5-kismet:demo. docker compose build tags its build with the ghcr.io names above instead. To run your own build, use the local names in place of the ghcr.io ones in the docker run commands on this page, or give your build both names (-t esp32c5-kismet -t ghcr.io/oshri-almog/esp32c5-kismet:latest) so that Compose uses it too. Compose uses an image of the ghcr.io name that is already on the machine without pulling, until docker compose pull replaces it with the published one.
• Licence: the image is Kismet, so it is GPL-2.0-or-later (label org.opencontainers.image.licenses=GPL-2.0-or-later), although the rest of the repository is MIT. kismet/ is GPL-2.0-or-later as well.
• Labels: org.opencontainers.image.title=esp32c5-kismet, and the description "Kismet with the ESP32-C5 capture source: Wi-Fi 2.4/5 GHz, Zigbee/Thread and BLE advertising from ESP32-C5 boards".

The CI workflow (see CI workflow) publishes these tags:

demo moves only where latest moves. Use full version tags (v1.2.3, v1.2.3-rc.1): a tag that is not a full version, such as v1.3, does not start the workflow.

The tag v0.1.0 made exactly the release-tag row: 0.1.0, 0.1, latest and sha-b5fa22a, and 0.1.0-demo, demo and sha-b5fa22a-demo. Each holds the linux/amd64 and linux/arm64 images.

kismet --version prints Kismet <year>.<month>.0-<commit>: Kismet builds its version from the build date and the short commit hash. An image built on 2 October 2026 prints Kismet 2026.10.0-cfe42707, and its kismet_cap_esp32c5 --version prints 2026.10.0-cfe42707; one built in September printed 2026.09.0-cfe42707. So two images of the same Kismet commit can show different versions. The Kismet commit is cfe427074 (cfe427074b7ffcfcbc055a123c1df3b3cde60d59, 16 September 2026), because no Kismet release includes this source yet.

Not in the image: the Python remote helper (esp32c5_kismet/), the firmware, esptool or any other flashing tool, and the tests. The build context holds only kismet/, docker/ and tools/fake_board.py (.dockerignore). The Kismet image has no Python at all; the demo image adds python3 for the fake board.

Everything runs as root: the image sets no USER. Kismet raises its ROOTUSER alert about that at every start.

docker build -f docker/Dockerfile -t esp32c5-kismet .                        # target kismet (default)
docker build -f docker/Dockerfile --target demo -t esp32c5-kismet:demo .     # target demo

Run both from the repository root: the build context is the whole repository, filtered by .dockerignore.

Pass them with --build-arg, for example --build-arg JOBS=2.

JOBS when empty. The build counts on about 1.5 GB of memory per compiler for Kismet's C++, so it uses MemAvailable (in kB) divided by 1,500,000, then caps it at the number of cores and at 4, with a minimum of 1. An 8 GB Raspberry Pi 4 got 4; a 2 GB Pi gets 1. The build prints building with -j<N>.

Some files need more than 1.5 GB. On the 8 GB Pi, one Kismet file (phy_80211.cc) needed about 2.4 GB for its own compiler, more than a 2 GB Pi has in all, so a 2 GB Pi probably needs swap even at -j1. This is untested.

Build arguments and the cache. Changing JOBS, KISMET_REF, KISMET_REPO or DEBIAN from one build to the next misses Docker's cache from that point, so Kismet compiles again (Docker's build cache works this way; not tried with this Dockerfile). Keep JOBS at one value, or unset.

• Build stage (Debian, --no-install-recommends): ca-certificates git build-essential pkg-config autoconf automake python3 libwebsockets-dev zlib1g-dev libnl-3-dev libnl-genl-3-dev libcap-dev libpcap-dev libsqlite3-dev libpcre2-dev libssl-dev libusb-1.0-0-dev libdw-dev.
• Kismet's configure options: --prefix=/usr --sysconfdir=/etc/kismet --localstatedir=/var --disable-python-tools --disable-librtlsdr --disable-ubertooth --disable-bladerf --disable-btgeiger --disable-libnm --disable-lmsensors --disable-mosquitto. The parts left out are hardware the image is not for (SDRs, Ubertooth, bladeRF) or host services a container does not have (NetworkManager, lm-sensors, MQTT).
• Install: make install DESTDIR=/out INSTUSR=root INSTGRP=root SUIDGROUP=root, then strip --strip-debug on every ELF program. That keeps the symbol table, so a crash backtrace still names functions, and shrinks /usr/bin/kismet from about 470 MB to under 15 MB.
• Run-time stage: the packages that hold the libraries the installed programs link against (found with ldd and dpkg -S), plus ca-certificates. On amd64 that was libbz2-1.0 libc6 libcap2 libdbus-1-3 libdw1t64 libelf1t64 libgcc-s1 liblzma5 libnl-3-200 libnl-genl-3-200 libpcap0.8t64 libpcre2-8-0 libsqlite3-0 libssl3t64 libstdc++6 libsystemd0 libudev1 libusb-1.0-0 libwebsockets19t64 libzstd1 zlib1g. The demo adds python3.

Kismet is built first with a stand-in for the helper's source, so that the long Kismet layer stays cached while only the helper changes.

Other files under kismet/, such as kismet/COPYING.md, are not copied into the build, so a change to them rebuilds nothing. The demo stage is built on the run-time stage, so it is rebuilt whenever that stage is, and its apt-get install python3 then needs the network again.

On the Raspberry Pi 4, a helper-only change rebuilt in about a minute, with Kismet taken from the cache.

The build needs internet access: Debian's package servers, GitHub for the Kismet clone, and Docker Hub for the base image and the docker/dockerfile:1 syntax image.

A Windows checkout is safe to build: .gitattributes (* text=auto eol=lf) keeps LF line ends even with core.autocrlf=true, and the Dockerfile strips carriage returns from the scripts it copies as well.

The entrypoint is /usr/local/bin/esp32c5-kismet, a POSIX sh script. The first argument after the image name picks its role; the default, from CMD, is kismet. Its own messages start with [esp32c5-kismet] and go to standard error.

To pass options to Kismet, keep the word kismet first: docker run ... IMAGE kismet --no-logging. docker run ... IMAGE --no-logging would try to run --no-logging as a command.

1. If any argument is -v, --version, -h or --help, run kismet with the arguments straight away: no login, boards or demo.
2. Set the web login (see Web login).
3. Keep the device nodes in sync (see Device access): once now, then every second in the background.
4. Demo image only, when ESP32C5_DEMO is not empty: start the fake board on /tmp/esp32c5-demo in that radio, wait 1 s, log demo: a fake board on /tmp/esp32c5-demo, and add the source esp32c5:device=/tmp/esp32c5-demo,mode=<ESP32C5_DEMO>,name=demo. With the fake board running, the entrypoint does not look for boards; sources in KISMET_SOURCES are still added.
5. Work out the sources: KISMET_SOURCES as given, or else one esp32c5-<tty>:mode=<ESP32C5_MODE> for each board found.
6. If there is no demo board, no source and no Espressif board in sysfs at all (one the container may not use does not become usable by waiting), and ESP32C5_WAIT is above 0: log waiting up to <n> s for an ESP32-C5 board, and look again every 2 s for up to ESP32C5_WAIT seconds.
7. If the boards were found by themselves (no KISMET_SOURCES) and ESP32C5_WAIT is above 0, whether they were there at start or turned up in step 6: keep looking every 2 s until two looks in a row agree, so that boards on a hub that come up one after another are all taken, for at most 10 s. After a wait, that ends by ESP32C5_WAIT + 10 s from its start (40 s with the default).
8. Log source: <definition> for each source and add -c <definition> after your own arguments.
9. With no source at all, log the no-board message and start Kismet anyway, so that remote helpers can still connect. Otherwise log Kismet starts with <n> source(s).
10. Run kismet --no-ncurses <your arguments> -c <definition> ....

The sources are worked out once. A board plugged in later gets its device node but is not added as a source.

1. Require KISMET_SERVER, the HOST:PORT of the Kismet to feed, on its web port.
2. Hand the credentials to the helper through its environment, not its command line, where every account on the host could read them in the process list: KISMET_APIKEY becomes KISMET_CAP_APIKEY; otherwise KISMET_USER and KISMET_PASSWORD become KISMET_CAP_USER and KISMET_CAP_PASSWORD, unless the user name holds : and the user name or password holds &, a login the role refuses (see Exit status of the helper role). Then unset KISMET_APIKEY and KISMET_PASSWORD.
3. Keep the device nodes in sync, as in the kismet role.
4. Work out the sources as in the kismet role. There is no wait for a first board, but when boards were found by themselves (no KISMET_SOURCES) and ESP32C5_WAIT is not 0, the list is checked again every 2 s until two checks agree, at most 10 s.
5. For each source, loop forever: log helper: <definition> -> <KISMET_SERVER>, run kismet_cap_esp32c5 --connect "$KISMET_SERVER" --source "<definition>", and when it exits, wait 5 s and start it again. It seldom exits: it tries again by itself 5 s after a capture ends (INFO: Sleeping 5 seconds before attempting to reconnect to remote server), whether the board stayed away for 15 s, the server could not be reached, or a definition that names no port found no board, or more than one, before it connected (Could not probe local source prior to connecting to the remote host: <reason>). It exits after a command-line error (status 255, for example a KISMET_SERVER without :PORT) or when it is killed. A definition that names a port (esp32c5-ttyACM0, device=, a by-id link) connects even while that port is missing; the open fails, Kismet logs Error connecting new remote source <name> (<uuid>) - cannot open /dev/ttyACM9: No such file or directory and does not list the source, and the helper tries again every 5 s until the board is there.
6. On SIGINT or SIGTERM (docker stop), stop every loop and helper and exit 0. In a test, docker stop took about 1 s.

The entrypoint keeps the device nodes in sync, then runs the command. Examples:

docker run --rm ghcr.io/oshri-almog/esp32c5-kismet:latest kismet_cap_esp32c5 --list
docker run --rm -it ghcr.io/oshri-almog/esp32c5-kismet:latest sh

kismet_cap_esp32c5 --list reads sysfs and /proc/locks and never opens a port, so it lists the boards even without the device rules. It prints its list on standard error and exits 2 whether or not it found a board, by Kismet's design; with no board the list reads esp32c5 - No supported data sources found.... It leaves out a board whose port is held by a capture it can see, but a new container sees none of another container's captures and lists their boards as free; a capture of one of them is still refused, with ... is already in use by another capture ... (see Device access). To see which boards are free inside the running kismet service, run it there:

docker compose exec kismet kismet_cap_esp32c5 --list

A capture started with a command of your own needs the device rules, as the services have; the entrypoint makes the device nodes for it as it does for them.

The texts are those of the current entrypoint. The source:, Kismet starts with, demo:, found <tty> in sysfs ..., Kismet starts with no source and helper: lines appeared as above with the current image on the Raspberry Pi with real boards.

On the Raspberry Pi with real boards, the helper role refused a user name with : and a password with & with status 2 and the message above. With a user name with : and no &, with a password holding &, a space and %41, and with an API key, it logged in and captured.

Compose takes each value from the shell's environment or from a .env file next to compose.yaml; the shell's value wins. Each service passes on only the variables listed for it, so a variable not listed for a service has no effect there under Compose.

Use each value of KISMET_USER and KISMET_PASSWORD in .env with care: every service that passes them on uses them. The demo's demo / demo applies only while they are unset.

The project name is esp32c5-kismet. Every service has both image: and build: (context ., docker/Dockerfile), so Compose builds the image when it cannot pull it.

The kismet and helper services get the device rules from a shared block (x-serial). No service adds a capability (see Capabilities). The demo service has no device rules, runs Kismet without logging (Kismet then raises ALERT: LOGDISABLED), and does not look for boards: on the Raspberry Pi with four boards plugged in, it started with the demo source only, and its list of interfaces answered.

docker compose up -d                            # Kismet, one Wi-Fi source per board plugged in
docker compose --profile demo up demo           # no hardware needed: Kismet and a fake board
docker compose --profile helper up -d helper    # no Kismet here: feed the boards to one elsewhere
docker compose logs kismet | grep "web login"   # the made-up login

Name the service when you use a profile: docker compose --profile demo up on its own also starts the kismet service, which then clashes on the port or competes for the boards. What matters is the name, not the profile: Compose acts on a service named on the command line whatever its profile, so --profile beside the name does no harm but is not needed, and a command with no service name acts on the kismet service as well (Docker's page on profiles). The same goes for the other commands on a machine that runs only the helper service: docker compose --profile helper pull helper, build helper, logs -f helper, restart helper and stop helper. A plain docker compose up -d there would start the kismet service beside the helper (a plain pull is harmless: it fetches the same image). On Linux without the docker group, put sudo in front.

Derived from compose.yaml. The demo command is the Dockerfile's own example; the other two have not been run as written. The second command is the helper service's: change its server address and API key to yours.

docker run -d --name esp32c5-kismet --restart unless-stopped --init \
    --device-cgroup-rule 'c 166:* rmw' --device-cgroup-rule 'c 188:* rmw' \
    -p 2501:2501 -v kismet-data:/data -v kismet-home:/root/.kismet \
    ghcr.io/oshri-almog/esp32c5-kismet:latest
docker run -d --name esp32c5-helper --restart unless-stopped --init \
    --device-cgroup-rule 'c 166:* rmw' --device-cgroup-rule 'c 188:* rmw' \
    -e KISMET_SERVER=192.168.1.50:2501 -e KISMET_APIKEY=3F9A6C1E07B24D58A1C9E2F4608B7D35 \
    ghcr.io/oshri-almog/esp32c5-kismet:latest helper
docker run --rm -p 127.0.0.1:2501:2501 \
    -e KISMET_USER=demo -e KISMET_PASSWORD=demo ghcr.io/oshri-almog/esp32c5-kismet:demo

For the demo in the other radios, add -e ESP32C5_DEMO=zigbee or -e ESP32C5_DEMO=btle.

To run your own build (Dockerfile), write esp32c5-kismet and esp32c5-kismet:demo in place of ghcr.io/oshri-almog/esp32c5-kismet:latest and ghcr.io/oshri-almog/esp32c5-kismet:demo, here and in Other commands.

• Both volume paths are declared in the image (VOLUME ["/data", "/root/.kismet"]). The demo and helper services, and a docker run without -v, therefore get two unnamed volumes per container; docker rm -v removes them with the container.
• docker compose down -v deletes the named volumes, and with them the login, the API keys and every log. An API key survived docker restart in a test; it survives re-creating the container only because /root/.kismet is a named volume.
• Never clean up with docker volume prune or docker system prune --volumes: they delete every unused unnamed volume on the machine, not only this project's, and docker volume prune -a deletes unused named volumes as well. Remove containers and volumes by name (docker rm -f -v esp32c5-helper, docker volume rm esp32c5-kismet_kismet-home).

• To use the legacy port anyway, mount your own site configuration with remote_capture_listen=0.0.0.0 and publish 3501 only on a network you trust. See Remote Capture.

• Keeping the kismet service on the host's loopback. Do not put an address in KISMET_PORT. The demo service puts 127.0.0.1: in front of the same variable, and Compose reads every service's ports when it loads the file, so KISMET_PORT=127.0.0.1:2501 makes every Compose command fail with invalid IP address: 127.0.0.1:127.0.0.1, even docker compose up -d for the kismet service alone (checked with docker compose config, Compose 5.5.1). Replace the service's port list in a compose.override.yaml next to compose.yaml instead. The !override tag makes the list replace the one in compose.yaml; without it, Compose adds the new entry to the old one and publishes both:

  services:
    kismet:
      ports: !override
        - "127.0.0.1:2501:2501"

  With docker run, use -p 127.0.0.1:2501:2501.

• Ports that Docker publishes are opened by Docker's own firewall rules, which bypass front ends such as ufw (Docker documents this; not tried here). Publish on loopback, or on a trusted network only, if that matters.

• The Compose services are on Compose's default bridge network, esp32c5-kismet_default, not the host's network.

No service adds a capability, and docker run needs no --cap-add: every container runs with Docker's default set.

• kismet_cap_esp32c5 drops every capability it has, and sets no_new_privs, as soon as it starts. It needs none to read a serial port.
• Kismet's other capture helpers, which the image also holds, keep NET_ADMIN and NET_RAW when they start as root. Docker's default set lacks NET_ADMIN, and without it they crash (signal 11) as soon as they start. The image's kismet_site.conf masks their source types, so Kismet does not start them (see Kismet configuration in the image).
• The smoke test runs every container with Docker's default capabilities, so CI checks both points on every build. On the Raspberry Pi, with the current image, the kismet service captured from four real boards with no capability added and without --privileged. There, every kismet_cap_esp32c5 in the kismet and helper containers showed CapEff 0 and NoNewPrivs 1 in its /proc/<pid>/status.

• Nodes. The container does not share the host's /dev. The entrypoint reads /sys/class/tty/ttyACM*/dev and ttyUSB*/dev (a container sees the host's sysfs) and makes each node with mknod -m 660. It replaces a node whose device number changed, removes nodes whose device has gone, and repeats every second, so a board plugged in again, or back under another number, gets its node within about a second.
• by-id links. It also makes /dev/serial/by-id/usb-<manufacturer>_<product>_<serial>-if<interface> links, as udev does on the host; for these boards that is usb-Espressif_USB_JTAG_serial_debug_unit_<MAC>-if00. It leaves an existing /dev/serial/by-id alone.
• Which classes may be opened. Docker lets a container make any device node; only opening it is refused by the device rules. So at start the entrypoint opens one node per class on a device number that no device uses (never a board's own port, since opening a board's port moves DTR and RTS, its reset lines). A board whose class is refused is logged and left out.
• Nodes given by Docker. Nodes already in /dev before the entrypoint made any, such as those from docker run --device /dev/ttyACM0, are used as they are and left alone. A fixed --device entry does not follow a board that comes back under another number.
• Discovery. A tty is a board when its USB device has vendor 303a and product 1001. The port is not opened to check. The ESP32-C3, C6, H2, S3 and P4 share this ID; with any of them plugged in, list the sources in KISMET_SOURCES.
• Why not /dev:/dev. It would hand the container every device node on the host: terminals, /dev/shm, disks.

On the Raspberry Pi with four real boards and the current image, the container made the nodes and the by-id links, captured from the boards it found by itself and from boards named by those links, and, run without the device rules, left the boards out with the found <tty> in sysfs ... message.

Warning: Stop the service before you flash its boards or use them elsewhere. The helpers lock a board's port in two ways. The flock on the device node does not reach past the container, since each container makes its own node. The tty's exclusive mode (TIOCEXCL) does: the kernel keeps it with the device, whichever node opens it. So while the kismet service captures from a board, a capture from the host or from another container is refused with ... is already in use by another capture ..., and esptool cannot open the port; on the Pi, an open from the host failed with Device or resource busy while the container's sources kept running. A process with the CAP_SYS_ADMIN capability, such as esptool run with sudo, is let in all the same. --list, of either helper, on the host or in another container cannot see the container's lock and still lists such a board: on the Pi, the Python remote helper's --list on the host listed the boards the kismet service was capturing from. A board in that list is not proof that it is free.

The kismet role always sets a login before Kismet starts, because Kismet without one lets the first visitor to port 2501 choose it. The login file is /root/.kismet/kismet_httpd.conf, with httpd_username= and httpd_password= lines, written with mode 0600 (Kismet's logs in /data stay 0644).

• Find the printed login: docker compose logs kismet | grep "web login", or docker logs <container> 2>&1 | grep "web login".
• After the container is recreated, read the file: docker compose exec kismet cat /root/.kismet/kismet_httpd.conf.
• Reset: set both variables, or, with neither set, delete the kismet-home volume, which also deletes the API keys and sessions but keeps the logs. Docker does not delete a volume that a container still uses, even a stopped one, so remove the container first. With Compose: docker compose down, then docker volume rm esp32c5-kismet_kismet-home, then docker compose up -d. With docker run: docker rm -f esp32c5-kismet, then docker volume rm kismet-home, then the docker run command again. Not docker compose down -v, which deletes the logs too.
• A password with a space and # worked for the web login and the REST API in a test, and the smoke test's password, which holds &, a space and %41, works for the REST API and for remote capture from the helper role; such a password also worked from the helper role with real boards on the Pi. The one login the helper role refuses is in Exit status of the helper role.

docker/kismet_site.conf is installed as /etc/kismet/kismet_site.conf. Kismet loads it after every other configuration file, so its settings win. It sets two things:

• log_prefix=/data/, so that the logs go to the /data volume.
• 15 mask_datasource_type= lines, one per source type of Kismet's other capture helpers: linuxwifi, linuxbluetooth, nrfmousejack, radiacode-usb, rzkillerbee, ticc2531, ticc2540, wch-ble-pro, antsdr-droneid, catsniffer_zigbee, freaklabszigbee, nrf51822, nrf52840, nxp_kw41z and radview. These helpers crash without NET_ADMIN, which the container does not have (see Capabilities), so Kismet must not start them, whether to list interfaces or to probe a source given without type=, as the entrypoint's sources are. Kismet's list of interfaces (/datasource/list_interfaces.json, which the web UI's Data Sources window shows) waits for every helper's answer, so a single crashed helper keeps it from ever answering; the smoke test checks that it answers. Not masked: pcapfile, kismetdb and sniffle_ble, which start without NET_ADMIN, and the helpers the image does not build (SDRs, Ubertooth, bladeRF), which Kismet skips at once.

The file's comments also explain why port 3501 stays on loopback, and say that a masked type still works with type= in its source (for example wlan0:type=linuxwifi) in a container given NET_ADMIN (cap_add: [NET_ADMIN] on the service in a compose.override.yaml, or docker run --cap-add NET_ADMIN) and the hardware it is for. That has not been tried.

To change more, mount your own file over it, and keep both parts in it: log_prefix=/data/, so that the logs stay in the volume, and the mask_datasource_type= lines, or the Data Sources list never loads. With Compose, in a compose.override.yaml next to compose.yaml:

services:
  kismet:
    volumes:
      - ./kismet_site.conf:/etc/kismet/kismet_site.conf:ro

With docker run, add -v "$PWD/kismet_site.conf:/etc/kismet/kismet_site.conf:ro". Save the file with LF line ends: a mounted file is not cleaned of carriage returns the way the image's own copy is.

Kismet's defaults, as seen in a container's log: channel hopping at 5 channels per second, channel lists split and shuffled among sources of one type, and sources re-opened after an error. Kismet Configuration lists the options.

.github/workflows/docker.yml, named "Docker image". It has run for the first push to main, for pull requests and for the tag v0.1.0: each time, both architectures built the images and passed the smoke test (22 of 22 checks on the first push; times in Build times and sizes). The v0.1.0 run, started by the tag push, published the images under the tags in Tags, each with linux/amd64 and linux/arm64, labelled with version v0.1.0 and revision b5fa22a. It took 3 minutes 20 seconds, with both builds taken from the cache. No manual run has been made.

Build job, once per architecture, each on a native runner, since under QEMU emulation the Kismet build would take hours:

Steps: check out (without keeping credentials); lower-case the image name, as ghcr.io requires; set up Buildx; build the demo target into the runner's Docker, with the GitHub Actions cache (type=gha, mode=max, one scope per platform); run the smoke test on it; when publishing, log in to ghcr.io with GITHUB_TOKEN; set the labels (again, so that the repository's MIT licence does not replace the image's GPL); build the Kismet target and push it by digest (the push only when publishing); push the demo by digest and upload the digests as the artifact digests-<platform> (kept 1 day), both only when publishing. The two platforms run independently (fail-fast: false).

Publish job, only for version tags and manual runs: download the digests, join the two architectures into one multi-arch image per tag list with docker buildx imagetools create, and inspect the result. The tags are in Tags.

Other details:

• Image name ghcr.io/<repository owner>/esp32c5-kismet, lower-cased: ghcr.io/oshri-almog/esp32c5-kismet.
• Permissions: contents: read for the workflow, packages: write for the two jobs.
• Actions are pinned to commit SHAs: actions/checkout v4.4.0, docker/setup-buildx-action v3.12.0, docker/build-push-action v6.19.2, docker/login-action v3.7.0, docker/metadata-action v5.10.0, actions/upload-artifact v4.6.2, actions/download-artifact v4.3.0. .github/dependabot.yml updates them monthly.
• The arm64 runner is free in public repositories and, since 29 January 2026, also runs in private ones on the plan's minutes.

tests/docker_smoke.sh checks a demo image without hardware: the fake board feeds Kismet in each radio, then the helper role feeds a Kismet in a second container over remote capture. CI runs it on both architectures.

docker build -f docker/Dockerfile --target demo -t esp32c5-kismet:demo .
sh tests/docker_smoke.sh esp32c5-kismet:demo

From Git Bash on Windows:

PYTHON=python sh tests/docker_smoke.sh esp32c5-kismet:demo

It needs docker, curl and Python on the host. It removes its containers, their volumes and its network when it ends, and switches off Git Bash's path rewriting for its own docker commands. It logs in to Kismet as smoke with the password smoke &pass%41word, which holds &, a space and %41: the helper role has to carry it to Kismet for remote capture. Every container runs with Docker's default capabilities.

The 22 checks:

"The interface list answers" means /datasource/list_interfaces.json answers with a JSON list. It never answers when one of Kismet's own capture helpers crashes on start, so this check fails if a new Kismet commit (KISMET_REF) brings a helper that kismet_site.conf does not mask.

It prints a PASS or FAIL line per check, the container logs when something failed, and ALL OK at the end. The exit status is 0 when every check passed, 1 otherwise.

Result: 22 of 22 passed, ALL OK, in about 2 minutes on each of GitHub's amd64 and arm64 runners, on images built from the current files (CI's first push to main). It passed again in the run that published v0.1.0. It has not been run on the Raspberry Pi.

These come from Kismet at commit cfe427074, not from this project:

• ERROR: Tried to re-register duplicate alert FLIPPERZERO at every start. Harmless; do not treat "ERROR" lines alone as a failure.
• ALERT: ROOTUSER Kismet is running as root: the container runs as root.
• INFO: (HTTPD) Could not read session data file, skipping loading saved sessions. on a new kismet-home volume.
• Launching remote capture server on 127.0.0.1 3501: the legacy port, on loopback.
• Loading optional sub-config file: /etc/kismet/kismet_site.conf: the image's settings are in use.

In the helper role's log, the libwebsockets library can add W: lws_create_context: unreasonable ulimit -n workaround after a time stamp, once for each helper as it starts (on the Pi, every helper did): it finds the container's limit on open files unreasonably high and works around it. Harmless.

More in Troubleshooting.