Nexmon: Patching Broadcom and Cypress Wi-Fi Firmware in C
The C-based Firmware Patching Framework for Broadcom/Cypress WiFi Chips that enables Monitor Mode, Frame Injection and much more
At a glance
- What is it?
- Nexmon is a C firmware patching framework for Broadcom and Cypress Wi-Fi chips, used to enable monitor mode, radiotap headers and frame injection on a fixed list of devices. Here is what the repository actually supports, how the build works, and where it stops being the right tool.
- Who is it for?
- Adopt Nexmon if your exact chip and firmware version appear in the supported devices table, you can build from source, and you accept that a bad patch may damage hardware or void a warranty. Do not adopt it if your device is not listed, if you need a maintained release artifact (the newest tagged release is 2.2.2 from 2017), or if you only want monitor mode on a chip whose stock driver already provides it.
- Can I use it commercially?
- Yes, with conditions. GPL-3.0 is a copyleft licence: if you distribute software that includes it, you must release that software's source code under the same licence. Running it internally without distributing it does not trigger that obligation.
- Is it still maintained?
- Yes. The repository last received commits 15 days ago.
- What is it written in?
- Mainly C, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 24, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What Nexmon Is For, and Who It Is Actually For
Nexmon is a C-based firmware patching framework for Broadcom and Cypress Wi-Fi chips. The README states its purpose plainly: it lets you write your own firmware patches, for example to enable monitor mode with radiotap headers and frame injection. That is a narrower claim than the project's reputation suggests. The repository itself concentrates on monitor mode and frame injection; the README points elsewhere (nexmon.org/jammer, nexmon.org/csi, nexmon.org/debugger, nexmon.org/covert_channel, nexmon.org/sdr) for jamming signals, channel state information extraction, JTAG-free debugging and software-defined radio transmission.
The audience is therefore not general Wi-Fi users. It is researchers and engineers who need frames from a specific chip that the stock driver will not hand over, or who need to modify behaviour inside the chip's own firmware. The supported devices table is the real gate. It lists individual Wi-Fi chips against individual firmware versions and the devices they ship in: bcm4339 on the Nexus 5 with firmware 6_37_34_43, bcm43455c0 on the Raspberry Pi B3+/B4 with 7_45_206, bcm43436b0 on the Raspberry Pi Zero 2 W with 9_88_4_65, and so on. A chip that is not in that table is not a target. The table also carries footnote markers and per-row capability columns (M, RT, I, FP, UC, CT), which means even within the supported set, features are not uniform: some rows show a blank where monitor mode or frame injection is unavailable.
This is the first thing to internalise. Nexmon is not a driver you install and forget. It is a patch you compile against a firmware image that must match your hardware exactly.
How the Patching Mechanism Works
The top-level Makefile is short and shows the two-stage build. The default target depends on buildtools and firmwares; the firmwares target depends on buildtools and then runs make in the firmwares directory after printing a banner; the buildtools target runs make in the buildtools directory. Both are marked FORCE, so they always re-run.
That ordering reflects the data flow. The buildtools directory produces the host-side tools that manipulate firmware images. The firmwares directory then uses them to extract flashpatches and ucode from the firmware binaries. The repository layout backs this up: firmwares/ holds the firmware images, patches/ holds the patch sources, utilities/ and app/ hold supporting code, and ios_utilities/ covers the iOS side. The README's device table columns (M for monitor mode, RT for radiotap, I for injection, FP for flashpatches, UC for ucode, CT for something the README does not spell out) map onto what a patch can change once it is loaded into the chip.
What you are editing is not a Linux driver. You are editing the firmware that runs on the Wi-Fi chip itself, which is why the firmware version string matters as much as the chip model. A patch written against 7_45_206 on a bcm43455c0 is written against that binary. The README does not document a rollback path, and it does not describe how to recover a device whose patched firmware fails to boot the radio. That silence is worth taking seriously before you start.
Building Nexmon and Loading a First Patch
The repository has no installable package. The README gives no pip, npm or apt instruction; the entry point is the source tree and its Makefile. Clone the repository, then run the default target from the root. The Makefile prints a red banner for each stage, first BUILDING BUILDTOOLS, then EXTRACTING FLASHPATCHES AND UCODE.
git clone https://github.com/seemoo-lab/nexmon.git
cd nexmon
makeIf your toolchain is not already in place, the repository ships a setup script at the root, setup_env.sh. The README does not describe what it installs, so read it before running it.
./setup_env.shAfter the build, the practical question is which firmware image applies to your hardware. That is answered by the supported devices table in the README, not by the build output. Find your chip and firmware version there first, then work in the corresponding firmware and patch directories. The README does not walk through a per-device flashing procedure for every row; the Android rows assume a rooted device, and several rows name Magisk explicitly (bcm4389c1 on the Galaxy S22 Plus, Pixel 7 and 7 Pro, and bcm4398d0 on the Pixel 8, all marked root with Magisk).
One warning is stated in the README in its own section, in capitals: the software may damage your hardware and may void your hardware's warranty, and you use the tools at your own risk. Treat that as a build instruction, not boilerplate.
The Supported Devices Table Is the Whole Contract
Most of the friction people hit with Nexmon comes from treating it as a general monitor-mode tool. It is not. The README's table binds three things together: Wi-Fi chip, firmware version, and operating system. bcm43430a1 appears twice, once for firmware 7_45_41_26 on Raspbian 8 and once for 7_45_41_46 on Raspbian Stretch. bcm43455c0 appears four times, against Raspbian Kernel 4.9/14/19, 4.14/19 and 5.4, Raspberry Pi OS Kernel 5.4, and Raspberry Pi OS. The same physical board can land in different rows depending on which OS image and kernel you booted.
That means "does Nexmon support my Raspberry Pi" is the wrong question. The right question is whether the firmware version your running system reports matches a row. If it does not, the patch is not written for your binary. The README does not describe a general fallback, a version-agnostic patch, or an automatic compatibility check.
The capability columns cut the same way. On bcm43455c0 with firmware 7_45_234 (4ca95bb CY) on Raspberry Pi B3+/B4/5 with Raspberry Pi OS, the M, RT and I columns are blank while FP and UC are marked. Monitor mode and frame injection are not available on that row. Reading the table as a list of devices rather than a list of chip, firmware and OS triples with per-row capabilities will send you down a path the project never claimed to support.
Where Nexmon Is the Wrong Tool
If you want monitor mode on hardware whose stock driver already exposes it, Nexmon adds risk for no gain. The build compiles firmware patches, and the README's own warning says the software may damage hardware and void a warranty. A chipset with an in-kernel monitor-mode path does not need that exposure.
If you are on an unrooted Android device, most of the Android rows are out of reach. The README lists Android 6 Stock, Android 7 Stock, Android 7.1.2, Android 8.0.0 Stock, LineageOS 14.1 and Cyanogenmod 13.0 for older phones, and the newest Android entries (Galaxy S22 Plus on Android 14, Pixel 7 and 7 Pro, Pixel 8) are explicitly marked as rooted with Magisk. There is no row for a stock, unrooted modern phone.
If you need a supported release artifact rather than a source build, note that the newest tagged release in the repository is 2.2.2, dated 2017-09-29. Development has continued on the master branch since then, but the release page does not reflect it. Anyone expecting a versioned, packaged download matching current device support will not find one.
Finally, if your goal is channel state information, jamming or SDR transmission, the README routes you to separate projects at nexmon.org rather than to this repository. The README states that this repository mainly focuses on enabling monitor mode and frame injection on many chips.
Nexmon Against a Mainline Monitor-Mode Driver
The natural alternative is a mainline driver that already supports monitor mode, such as the mac80211-based drivers shipped with Linux for chips that expose it. The difference is architectural. A mainline driver asks the existing firmware to deliver frames to the host and formats them in software. Nexmon changes what the firmware itself does, which is why it can reach chips and behaviours the stock firmware does not expose, and also why it is bound to exact firmware versions.
That trade-off is the whole story. Mainline drivers update with the kernel, work across many devices, and do not carry a hardware-damage warning. Nexmon works on a fixed, enumerated set of chip and firmware combinations and requires you to build and flash a patch. If your chip is in the table and the stock driver will not give you radiotap frames, that narrowness is the point. If your chip is not in the table, the narrowness is the wall.
A second, more distant alternative is the family of related projects the README links to. They are not drop-in replacements; they are separate tools built on the same patching approach for jamming, CSI extraction, debugging and SDR transmission. Choosing between them is choosing which capability you need, not which is better maintained.
Maintenance, Licence and Upgrade Cost
The repository is not archived, and the last push was on 2026-09-14, so the master branch is being touched. The release history tells a different story: the newest tagged release is 2.2.2 from 2017-09-29. If you track tags, you are tracking something nine years old. If you track master, you are tracking unreleased code. Neither is a comfortable default, and the repository does not present a middle option.
The upgrade cost follows from the device table. Moving to a new kernel or OS image on the same board can move you to a different firmware version, and therefore a different row, and therefore possibly a different patch with a different feature set. The bcm43455c0 rows on Raspberry Pi illustrate the pattern: four firmware versions across several kernel and OS combinations, not all with the same capabilities marked. Budget for re-checking the table on every OS upgrade, not just on every Nexmon update.
Nexmon is licensed GPL-3.0, with LICENSE.txt at the repository root. Because the project patches proprietary Wi-Fi firmware images and the README's device table spans Android, iOS, Raspberry Pi OS and vendor router firmware, the interaction between the GPL-3.0 licence on the framework and the terms attached to the firmware you patch is a question for your own legal review. This article does not give legal advice. The repository also carries SECURITY.md and CITATION.cff, which are the right starting points for disclosure and for citing the work.
Editorial conclusion
Adopt Nexmon if your exact chip and firmware version appear in the supported devices table, you can build from source, and you accept that a bad patch may damage hardware or void a warranty. Do not adopt it if your device is not listed, if you need a maintained release artifact (the newest tagged release is 2.2.2 from 2017), or if you only want monitor mode on a chip whose stock driver already provides it. Before you flash anything, verify the firmware version string reported by your device against the table, and read SECURITY.md and LICENSE.txt in the repository root.
Frequently asked questions
What is Nexmon?
Nexmon is a C-based firmware patching framework for Broadcom and Cypress Wi-Fi chips. According to the README, it lets you write your own firmware patches, for example to enable monitor mode with radiotap headers and frame injection.
How do I install Nexmon?
There is no package to install. The repository is built from source: clone it, then run make at the root, which builds the tools in buildtools and then extracts flashpatches and ucode from the images in firmwares. A setup script, setup_env.sh, sits at the repository root.
How do I install Nexmon firmware?
The README does not give a single flashing procedure for all devices. Which firmware applies to you depends on the chip, firmware version and operating system combination in the supported devices table, and several Android rows assume a rooted device, with the newest ones naming Magisk explicitly.
How do I use Nexmon?
You build the framework with make, locate the row in the supported devices table that matches your chip and firmware version, and work in the corresponding firmware and patch directories. The README states that this repository mainly focuses on enabling monitor mode and frame injection on many chips.
What is a Nexmon alternative?
A mainline mac80211-based driver that already supports monitor mode is the closest alternative, and the difference is architectural: it asks the existing firmware to deliver frames to the host, while Nexmon changes what the firmware itself does. The README also links to separate projects at nexmon.org for jamming, CSI extraction, debugging and SDR.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/seemoo-lab-nexmon)