Nexmon Turns Nexus 5 (and RPi3!) Into WiFi Toolkit

Most retired gadgets die one of two deaths: they become a dusty drawer fossil, or they get “repurposed” into a
glorified alarm clock that still can’t wake you up on time. Nexmon suggests a third optionturning familiar
hardware like the Nexus 5 and the Raspberry Pi 3 into a practical Wi-Fi research toolkit by
extending what the Wi-Fi chip itself can do.

That last part matters. Lots of Wi-Fi “tools” live in user space (apps) or at the driver level. Nexmon goes deeper:
it’s a firmware patching framework for Broadcom/Cypress Wi-Fi chips, letting researchers and tinkerers add
capabilities that closed firmware normally hides. Done responsibly, it’s a powerful way to learn how 802.11 really
behavesnot just how your router marketing brochure wishes it behaved.

Before we nerd out: this topic has obvious security implications. The ethical line is simple and non-negotiable:
only experiment on networks and devices you own or have explicit permission to test. If your “lab” includes
your neighbors, your employer’s Wi-Fi, or the coffee shop down the street… that’s not a lab. That’s a bad decision
with a great Wi-Fi signal.

What Nexmon actually is (and why it got Hackaday excited)

The original Hackaday write-up framed Nexmon as a standout because it didn’t just drop a ready-made trickit showed
a method: reverse the Wi-Fi firmware on a Nexus 5, demonstrate what’s possible, and then apply similar techniques to
the Raspberry Pi 3. That’s the maker DNA: share the path, not just the punchline.

On the technical side, Nexmon is a C-based firmware patching framework for Broadcom/Cypress chips. It’s designed
to let you write patches in C, link them against known firmware functions, and produce a modified firmware image
that enables features researchers often needespecially deeper visibility into Wi-Fi frames and metadata.

If you’ve ever tried to do serious Wi-Fi measurement with hardware that “sort of” supports monitor mode, you know the
pain: missing metadata, inconsistent headers, or firmware that simply refuses to expose what’s happening on-air.
Nexmon’s goal is to make that visibility more consistent by extending the firmware itself, not just poking it from the outside.

Why the Nexus 5 and Raspberry Pi 3 are such perfect targets

The Nexus 5: a smartphone with a surprisingly interesting Wi-Fi heart

The Nexus 5 isn’t famous today for cutting-edge speed; it’s famous for being plentiful, hackable, and
built around a Broadcom combo Wi-Fi chip. Teardown documentation identifies the Nexus 5’s Wi-Fi hardware as a
Broadcom BCM4339 combo chipexactly the sort of widely deployed silicon where better firmware insight is valuable.

From a “lab gear” perspective, that makes the Nexus 5 a funny kind of bargain: a compact Linux-ish computing platform,
a battery, a screen, and a Wi-Fi chipset that’s common enough to attract serious reverse engineering attention.
In other words: it’s a pocket-sized test bench that happens to make phone calls (or at least, it used to).

The Raspberry Pi 3: the tiny computer that accidentally became a Wi-Fi playground

The Raspberry Pi 3 Model B brought built-in wireless via the Broadcom BCM43438. That one design choice made the Pi
dramatically more convenientand also turned it into a popular platform for wireless experimentation, because it’s cheap,
portable, and easy to dedicate to a single purpose.

Nexmon’s Raspberry Pi story is particularly interesting because it meets the Pi where it lives: Linux drivers and firmware blobs.
Rather than pretending the closed firmware problem doesn’t exist, Nexmon treats it as the central puzzle and patches the system
accordingly.

FullMAC vs. SoftMAC: the “why can’t my driver just do that?” problem

To understand why firmware patching is such a big deal, it helps to know the difference between SoftMAC and
FullMAC Wi-Fi designs.

In a SoftMAC approach, more of the MAC-layer logic (the “rules of polite Wi-Fi conversation”) is handled in the host driver.
In a FullMAC approach, the Wi-Fi chip runs a lot more of that logic internally, and the host driver exchanges higher-level frames
rather than exposing every low-level detail.

That’s convenient for device makers and power budgetsbut frustrating for researchers, because many behaviors are buried inside
closed firmware. Nexmon’s published demo work describes FullMAC chips as implementing the complete MAC layer on the chip and only
exchanging Ethernet frames with the driver, which is exactly why adding new low-level capabilities often requires firmware changes,
not just driver tweaks.

Radiotap: the “metadata backpack” that makes captures actually useful

If you’ve ever looked at a Wi-Fi capture and wondered why one file is rich with signal strength, channel details, and data rates
while another looks like it’s missing half the story, you’ve bumped into radiotap.

Radiotap headers are a flexible way to attach additional information about 802.11 framesmetadata passed between the
driver and user space tools (and sometimes the other direction for transmissions). The radiotap format was designed to be extensible:
it uses a “presence bitmap” so parsers can understand which fields are included, and new fields can be added without breaking old tooling.

Nexmon’s GitHub documentation explicitly calls out enabling monitor mode with radiotap headers as a core capability.
This is a subtle but important point: monitor mode alone isn’t the whole win. Monitor mode with consistent metadata is what turns
packet capture from “mystery confetti” into something you can analyze, measure, and reproduce.

So what does Nexmon enableat a high level?

Nexmon is often described online in the same breath as “monitor mode” and “injection,” because those are the flashy features that
most people recognize. But the deeper story is about capability: a repeatable way to extend firmware behavior in C.

1) Better visibility for Wi-Fi research and troubleshooting

In legitimate settings, monitor-mode capture can help you answer questions that normal networking tools can’t:
Why do smart home devices roam badly? Why does one AP “feel” slow even when throughput tests look fine? Are clients spending too much time
retrying frames? Is the environment saturated with management frames from chatty devices?

With radiotap metadata, you can correlate what users experience (“the video call stutters”) with on-air details (signal quality,
rates, channel occupancy patterns) without guessing.

2) Reproducible experiments on commodity hardware

Academic and engineering work often struggles with reproducibility when critical behavior lives behind a vendor firmware wall.
Nexmon’s approachpatching firmware in a structured waymakes it easier to document exactly what changed, share patches, and rerun tests.
That’s a big deal for Wi-Fi measurement and testbed work, where small timing or MAC-layer differences can change outcomes.

3) A bridge between “black box Wi-Fi” and “I can actually learn this”

For many curious builders, the most valuable part is educational: Nexmon turns the Wi-Fi chip from a sealed appliance into something
you can reason about. Even if you never write a patch yourself, reading how the project maps firmware functions, links code, and integrates
with drivers teaches you how modern wireless stacks are layered.

How this fits into the Linux driver reality

On Linux systems using Broadcom FullMAC chips, the host driver you’ll hear about is brcmfmac. In plain terms, brcmfmac is part of the
ecosystem that talks to the Wi-Fi hardware while relying on external firmware files for the chip’s internal logic.

The modern Nexmon story acknowledges that reality instead of fighting it: firmware changes alone aren’t always enough; you also need
driver-side support so the system can expose the new capabilities cleanly. Recent Kali documentation on Raspberry Pi Wi-Fi improvements
explicitly notes that Nexmon works by modifying firmware binaries and providing patches for the Linux driver to support the required modes.

This is also why Nexmon can feel “version picky.” When your solution touches firmware binaries and driver behavior, details matter:
kernel versions, firmware versions, and chip revisions can all change the shape of what’s possible.

Real-world, responsible use cases (the boring stuff that’s actually useful)

The internet loves dramatic demos, but most legitimate Wi-Fi work is beautifully unglamorous. Here are examples where a Nexmon-style toolkit
can be genuinely helpful without drifting into questionable territory:

• Home network debugging: confirming whether congestion, weak signal, or excessive retries are behind spotty streaming and
  smart device disconnectson your own equipment.
• IoT lab validation: measuring how often battery devices beacon, probe, or roam, then tuning AP settings to reduce chatter.
• Classroom and training labs: teaching 802.11 concepts with real captures that include metadata students can interpret.
• Wireless testbeds: repeating experiments across identical hardware, with firmware behavior controlled and documented.
• Protocol research: exploring MAC-layer behavior, timing, and frame formats in a way that’s hard to do when everything is hidden.

Safety, legality, and basic grown-up rules

Two realities can be true at once: Nexmon enables legitimate research, and the same capabilities can be misused.
If you’re building anything described as a “Wi-Fi toolkit,” bake in the same discipline you’d expect in a professional environment:
written permission for tests, clear scope, and a plan to protect captured data.

Even general wireless security guidance emphasizes designing WLANs with strong security objectives (confidentiality, integrity, availability)
and recommends practical steps like thoughtful AP placement and physical security to reduce risk. The spirit of those recommendations applies
to labs, too: control your environment, isolate test networks, and keep experiments from spilling into spaces you don’t own.

What made Nexmon a “Hackaday-worthy” moment

The Hackaday angle isn’t just “look, a new trick.” It’s the combination of:
a well-known phone, a beloved maker computer, and a firmware patching method that pulls a notoriously
closed component into the light. That’s the kind of project that turns passive consumers into active learners.

And there’s a nice sustainability subplot: reusing older devices for specialized roles is both practical and fun. A Nexus 5 that’s slow at modern apps
can still be fast at being a single-purpose lab instrument. A Raspberry Pi 3 that’s too small for your latest container stack can still excel as a
portable wireless measurement node.

Experience Notes: what it feels like to turn “normal hardware” into a Wi-Fi lab tool

People often imagine Wi-Fi experimentation as a cinematic montage: a dark room, scrolling green text, dramatic beeps, and a final shot where you whisper,
“I’m in.” Real life is less Hollywood and more “why does this build fail when nothing changed?”but that’s exactly why the experience is valuable.

The first emotional shift usually happens when you realize how much of Wi-Fi is not your operating system. On many Broadcom-based devices, the
Wi-Fi chip is running its own world: timing-sensitive MAC behavior, radio control, and a lot of decision-making happen inside firmware you don’t normally
get to inspect. Nexmon flips the script by treating that firmware as a place you can learn from andcarefullyextend. Even reading the project’s structure
can feel like opening a “behind the scenes” door.

The next experience is humility via compatibility. When you’re working at the firmware/driver boundary, you get a crash course in version reality:
chip revisions aren’t all the same, firmware builds differ, and the host driver expects certain behaviors. That can feel annoying until you realize it’s
the same discipline used in professional embedded development: track your versions, document what you changed, and assume that “close enough” is a myth.
If you like tidy engineering, this part is oddly satisfyinglike labeling cables, but for software.

Then comes the “aha” moment when captures become interpretable. With radiotap-style metadata available, frames stop being anonymous bytes and
start telling a story: signal strength trends, rate changes, channel context, and the subtle hints of interference or retries. In a responsible home lab,
this can be surprisingly practical. For example, you might discover that a device dropping off your network isn’t “buggy” so much as it’s living on the
edge of coverage and constantly retrying. Or you might learn that a particular location in your home is a Wi-Fi dead zone not because of distance, but
because the signal path goes through a refrigerator that seems to be auditioning for the role of “Faraday cage.”

The most meaningful experience, though, is developing respect for the airwaves. When you can see more of what’s happening on-air, Wi-Fi stops feeling like
magic and starts feeling like a shared space with rules, tradeoffs, and unintended consequences. You also become more careful: you isolate test networks,
you avoid experiments that could disrupt others, and you treat captured traffic like sensitive data. That mindset is the difference between “cool project”
and “problem waiting to happen.”

Finally, there’s the quiet joy of repurposing. A Nexus 5 that once handled daily life can become a dedicated lab node. A Raspberry Pi 3 can travel in a
backpack as a measurement device instead of sitting under a TV running a media center you forgot you installed. It’s the same maker satisfaction as fixing
an old radioexcept the “radio” is a slab of glass that suddenly has a second career in learning and research.

Final thoughts

Nexmon’s big idea is simple: if closed firmware is blocking legitimate Wi-Fi research and visibility, build a framework that makes firmware extension more
approachable and repeatable. The reason it still gets attention years later is that the problem hasn’t disappearedWi-Fi is still complicated, firmware is
still closed, and people still want to understand what their devices are doing.

If you treat it as a learning and measurement toolused ethically, in scoped environmentsit’s a genuinely fascinating way to turn everyday hardware into
something closer to professional Wi-Fi instrumentation. And if nothing else, it’s comforting to know your old Nexus 5 can do something more dignified than
sitting in a drawer, slowly evolving into a spicy pillow.