nexmon has one release from 2017 and commits nine years later

The warning sits above the device table, where it belongs

The structure of the file is deliberate. What the project is comes first, then a warning, then the device matrix.

The warning says the software may damage your hardware and may void the hardware's warranty, that the tools are used at your own risk and responsibility, and that if those terms are unacceptable then do not use the project. No softening, no legal padding.

That placement matters for what this software does. The opening paragraph describes a framework for writing firmware patches, and gives two examples: enabling monitor mode with radiotap headers, and frame injection. Both operate below the operating system's driver layer, on the chip's own firmware, which is why the consequence of getting it wrong is a device that does not come back rather than an application that fails to start.

The rest of the file is careful in the same way. It says the repository focuses on monitor mode and frame injection, and that if you want other features there are sibling projects, which is an honest boundary rather than a feature list.

One release from 2017, commits nine years after it

The release list holds a single entry, version 2.2.2, dated 2017-09-29.

The last push to the default branch is dated 2026-09-24, and the repository is not archived.

So the published artifact and the current source are about nine years apart. For a project whose output is a firmware image tied to one chip and one firmware version, that gap has a specific meaning: the single release is a snapshot for whatever devices existed then, and everything since then has been commits rather than tagged builds.

Two files in the tree explain what the recent work has been about without needing a changelog. One is a revision information document and one is a statistics document, and both sit at the repository root next to a devices document and a security document.

A separate citation file and a citation metadata file sit alongside them, which is the clearest signal of how the project expects its output to be used: as the artefact of published research, cited rather than silently vendored.

The newest phones in the table get the least capability

The matrix runs about thirty rows, and reading it end to end shows capability shrinking as the hardware gets newer.

The oldest rows are the broadest. A Galaxy S2 on a 2014 custom Android build, a Galaxy S4, a Nexus 5, a Raspberry Pi 3 and Zero W: those have monitor mode, radiotap headers and injection marked. A Raspberry Pi B3+, B4 and B5 gets the same set, across four different Raspberry Pi OS kernel versions.

The newest rows are not. A Galaxy S22 Plus, a Pixel 7 and 7 Pro, a Pixel 8 and a Pixel 9 all appear with only two columns marked, and neither of them is monitor mode or injection. The Pixel rows are also qualified: rooted with a specific rooting tool, rather than merely rooted.

Two other requirements appear as you move down. The Galaxy S10 and S20 rows specify rooted with SELinux disabled, which is a different ask from rooting alone, because a security module that blocks the write will stop the patch.

And the one iPhone row, an iPhone 6 on a specific 2016 iOS build, carries two marked columns and no more.

A router, a chip enabled for nothing, and six unexplained letters

Two rows are worth reading closely because they do not fit the pattern.

One is a router rather than a phone or a board: an Asus unit on a named stock firmware build. It has one capability marked and, in another column, a slash rather than a letter. A firmware patch that works on a router is a different proposition from one that works on a handset, because the device is usually the thing providing connectivity to everything else in the building.

The other is a Qualcomm chip in a high-end adapter, on a custom router firmware image, with every capability column empty. The chip is listed, the firmware version is given, and nothing is enabled. That row tells you the project tracks the hardware without claiming to support it, which is more useful than leaving the row out.

The columns themselves are two-letter initials, six of them, and two are identifiable from the opening paragraph. The other four are not spelled out in the part of the file the table appears in. They are defined in footnotes, and the footnotes that are visible number at least nine, keyed to specific chips in the superscript markers beside the chip names.

One footnote is a correction rather than a requirement: one chip was wrongly labelled as a different one in the past.

The build compiles the tools and the firmware blobs and stops

The top-level build file has two real targets and one that exists only to force them to run:

all: buildtools firmwares

firmwares: buildtools FORCE
	$(Q)make -C $@

buildtools: FORCE
	$(Q)make -C $@

FORCE:

Two details are visible in those lines. The forcing target has no prerequisites and an empty recipe, and it is not marked phony, so its purpose is to defeat make's timestamp check and rebuild both directories on every invocation rather than to do any work.

And the recursion is into a subdirectory per stage, with the quiet prefix in front of each sub-make and a coloured banner printed before it, so the top-level file does nothing except sequence two nested builds.

What the top-level file does not contain is the part that would matter most to a newcomer. There is no install target, no flashing step, and no device selection anywhere in it. The Makefile produces binaries and firmware files; anything that writes them to a chip is elsewhere, and per device.

The tree around it explains the scope: a tools directory, a firmware directory holding the blobs, a patches directory, an application directory, a graphics directory, an iOS utilities directory, a general utilities directory, and an environment setup script.

Five sibling projects, and one of them is explicitly incomplete

The file names five related projects and says this repository mainly focuses on monitor mode and frame injection, so the others are for people who need something else.

Two are extraction. One pulls channel state information out of transmissions, described as handling up to four by four MIMO at 80 MHz bandwidth. Another gives low-level access to microcontroller debugging registers without a JTAG connection, allowing breakpoints, watchpoints and single stepping.

Two are transmission-side, and they are the ones the file describes in the most detail. One overlays ongoing frame transmissions with an arbitrary jamming signal, using the chip as a software-defined radio, allowing non-standard channel widths and arbitrary transmission powers, and patching the chip's real-time MAC implementation. The other hides information inside Wi-Fi signals and is described as having more advanced software-defined radio capabilities than the jamming project.

The fifth is a general software-defined radio project, and it carries the most honest limitation in the file: only transmissions are working, in both the 2.4 and 5 GHz bands.

So the family is a lab's research output rather than a product line, and each project states its own completeness.

The repository asks to be cited

Two files at the root do something most firmware projects do not. One is a bibliography file, and the other is a citation metadata file in the format that indexes and registries read.

A framework whose output is a patched firmware image ends up embedded in other people's research, in course material and in hardware analysis write-ups, and citation files are how the authors keep track of that. It is also a reasonable signal about the intended audience: the matrix, the security document and the citation machinery all point at people doing authorised work with hardware they control, rather than at people looking for a download.

The tree reinforces that. Beyond the build directories there is a directory for device information, one for revision information, one for statistics, one for patches, and a security document at the root rather than buried in a contributor guide.

What is absent is as telling. There is no changelog file, no continuous integration configuration and no contribution guide in the visible listing, on a project whose only release is nine years old and whose device coverage is the thing that actually changes.

Editorial conclusion

nexmon belongs on a spare adapter you own, on hardware you can afford to write to, and inside a lab that already has the legal position sorted out for the transmissions it will make. Three things to settle first. Accept that this is firmware patching rather than a driver install, because the warning above the device table says the software may damage the hardware and void the warranty, and a wrong firmware version for a chip is a bricked adapter rather than a failed command. Match your exact firmware build rather than your device model, since the matrix is keyed on chip and firmware version and several rows exist for the same phone with different builds. And read the capability columns before planning anything, because the newest chips listed get the least functionality and one row is enabled for nothing at all.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. Releases
5. seemoo-lab/nexmon on GitHub