NextBSD · Driver delivery · restricted firmware
bwn, bwi, malo, upgt — the wifi drivers whose firmware isn't redistributable (not merely "non-free"). Nobody bakes these into an install image, not even Debian's firmware ISO or OpenBSD's fw_update. Here's the per-chip legal reality and exactly how every distro handles them in 2026 — and what that leaves NextBSD.
All three chip families need firmware that was never granted redistribution rights — so the universal industry answer is "the distro ships the driver but not the blob; the user fetches/extracts it." Every OS uses some flavor of that dodge (fwcutter extraction, third-party download, or a segregated firmware server). None can put these on an offline image. And it barely matters: all three are dead 2000s-era hardware, and the b43 fetch route is itself now bit-rotting because Broadcom pulled the source URLs.
p54 (PrismGT) firmware is redistributable and in linux-firmware, so upgt's cousin "just works." That's wrong. Live check (July 2026): isl3886usb/isl3887usb/isl3886pci/3826.arm all 404 from linux-firmware and appear nowhere in WHENCE. The p54 firmware is a third-party blob on the maintainer's site (daemonizer.de) with no clear redistribution grant. So upgt and Linux p54 are both on non-redistributable firmware — Linux's is merely easier to fetch (ready-made blobs vs extract-from-driver).| FreeBSD driver | Linux driver | Hardware | Firmware status (2026) |
|---|---|---|---|
bwn / bwi | b43 / b43legacy | Broadcom BCM43xx (AirForce; 4306/4311/4312/4318/4321/4322) | not redistributable Absent from linux-firmware (only the newer brcmfmac/brcmsmac blobs are there, marked redistributable). Must be extracted from a proprietary Broadcom driver via b43-fwcutter; distros are explicitly not allowed to redistribute the extracted blob. |
upgt | p54usb / p54pci | Conexant/Intersil PrismGT (ISL38xx) | not redistributable Not in linux-firmware (verified 404). Third-party blob on daemonizer.de; GlobespanVirata "has not given explicit permission to redistribute." Easier to fetch than b43 (ready blobs), but no clean license. |
malo | — (none mainline) | Marvell Libertas 88W8335 (PCI/CardBus) | not redistributable + Linux-orphaned Marvell refused distribution rights. No 88W8335 entry in linux-firmware; the Linux libertas/mwl8k firmware covers different Marvell chips. The proposed mrv8k Linux driver (2008 RFC) never merged — this chip works only on the BSDs. |
The through-line: ship the driver, not the firmware. Nobody carries these blobs in a repo package or on an install ISO — it's always fetch-and-extract or user-supplied.
| OS | b43 (BCM43xx) | p54 (PrismGT / upgt) | malo (88W8335) |
|---|---|---|---|
| Debian | firmware-b43-installer in contrib — downloads Broadcom driver + runs fwcutter at install. Not on any firmware ISO. | Not packaged (bug #481234); manual wget from daemonizer.de | No package; unsupported |
| Ubuntu | firmware-b43-installer + b43-fwcutter in multiverse (same fetch-extract) | Manual, as Debian | Unsupported |
| Fedora | b43-fwcutter tool in repo; blobs via RPM Fusion nonfree-tainted or manual. (Most use the RPM Fusion broadcom-wl akmod instead.) | Not packaged; manual | Unsupported |
| Arch | b43-fwcutter in repo; b43-firmware in AUR — currently fails to build; Broadcom pulled the URLs | AUR p54-firmware (fetch from daemonizer.de) | Unsupported |
| openSUSE | b43-fwcutter ships install_bcm43xx_firmware (download + extract + install) | Manual | Unsupported |
| Gentoo | sys-firmware/b43-firmware ebuild fetches driver + runs fwcutter at emerge; b43-openfwwf open fw for a few chips | Overlay/manual | Unsupported |
| NixOS | networking.enableB43Firmware → fetch + fwcutter at build; marked unfree | Manual | Unsupported |
| FreeBSD | net/bwn-firmware-kmod, bwi-firmware-kmod — build from source only, no binary pkg | upgt; firmware ports-only | net/malo-firmware-kmod (blobs sourced from OpenBSD), ports-only |
| OpenBSD | bwi + firmware via fw_update (own server) | upgt/pgt via fw_update | malo via fw_update |
| NetBSD | bwi: firmware not shipped, obtain separately | upgt: not in base | malo: needs /libdata/firmware/malo/…, not in base |
OpenBSD is the interesting case for NextBSD because it's a BSD that keeps all four drivers yet keeps the firmware out of the base sets. The blobs live on firmware.openbsd.org and are pulled on demand by fw_update(8), which also runs automatically at install/upgrade. All four tarballs are present on the mirror today:
bwi-firmware-1.4p5.tgz malo-firmware-1.4p5.tgz
pgt-firmware-1.2p5.tgz upgt-firmware-1.1p5.tgzfw_update." The reconciliation: OpenBSD segregates non-free firmware onto its own server so it's not in the shipped OS, then fetches it for the user — the same "we don't ship it, the user pulls it" dodge as fwcutter, just automated and centrally hosted. It works in practice, but it's a pragmatic gray-area stance, not a clean redistribution license — OpenBSD is absorbing the risk of mirroring blobs a vendor "refuses to grant distribution rights" to.b43-fwcutter sidesteps redistributionbroadcom-wl-5.100.138, or -6.30.163.46 for LP-PHY). The firmware is embedded in its binary object (wl_apsta.o).b43-fwcutter <driver>, which parses the blob and writes the individual images (ucode5.fw, initvals, PCM…) into a b43/ directory./lib/firmware/b43/, where the kernel b43 driver loads them at interface-up.Why it's legal-ish: the distro never ships the firmware — only the GPL fwcutter tool and a script that makes the end user download Broadcom's driver and extract locally. That's the whole reason no offline/firmware install ISO carries b43: a Broadcom-only laptop still needs a wired connection or a second machine to get online first. And it's decaying — the AUR build now fails because Broadcom removed the driver download URLs, so even the fetch route is bit-rotting.
brcmfmac (redistributable, in linux-firmware) years ago, so b43 is purely keep-old-laptops-alive — and, per above, the fetch route is starting to break.mwl8k/mwifiex. Relevant today only on the BSDs.Nobody ships these in-image, the hardware is dead, and the one BSD that keeps them (OpenBSD) does so via a fetch-from-our-server step that NextBSD's base-is-self-contained, no-runtime-fetch rule specifically rejects. So the realistic options:
| Option | What it means | Fit |
|---|---|---|
| Drop the drivers | Don't carry bwn/bwi/malo/upgt at all. | Cleanest. Dead hardware; zero users lost in practice. Least surface. |
| Carry driver, no firmware | Ship the .ko (NetBSD-style); a user with rights to the blob drops it in /boot/firmware themselves. | Fine. Honest, keeps base clean, doesn't pretend to support the card OOTB. |
OpenBSD-style optional fw_update | Host blobs on a NextBSD mirror, fetch via an explicitly-optional post-install tool (never base). | Not worth it. Inherits OpenBSD's legal gray area for dead hardware, and still a fetch. Only if you ever build a general optional-firmware tool for other reasons. |
Recommendation: drop them, or carry-driver-only. The wall here is redistribution rights no image can climb — so making a firmware-included ISO (which you should, Debian-style, for the ~19 redistributable wifi drivers) simply doesn't reach these four. They're not a gap in your build; they're a gap in the licensing of 20-year-old silicon.
Sources (live-verified July 2026 where noted): kernel.org b43 / p54 firmware docs · Debian bcm43xx / prism54 wikis · linux-firmware WHENCE (b43/p54/malo absent; brcm redistributable) · daemonizer.de p54 fw · prism54.org (no redist grant) · OpenBSD malo(4) / fw_update(8) + firmware.openbsd.org tarballs · FreshPorts bwi/malo-firmware-kmod · LWN mrv8k RFC · AUR/Gentoo/NixOS/openSUSE package pages.