Installing Omarchy Linux on Your Old Mac? Here’s the Fix for Your Wi-Fi
A dual-boot Omarchy install, a decade-old Broadcom chip, a lot of wrong turns, and the firmware file nobody shipped.
Setting the scene
I run Omarchy - the Hyprland-based Arch Linux setup dual-booted alongside macOS on a MacBook Pro13,2: the 2016 13-inch, Touch Bar model. If you’ve never dual-booted Linux on an Intel Mac, the short version is: most of it works shockingly well.
Except Wi-Fi. Wi-Fi was cursed.
Not “doesn’t work” cursed — that would’ve been easy, I’d have bought a USB dongle on day one and moved on with my life. It was the much worse kind of cursed: it worked sometimes. Some boots, it connected on the first try and ran flawlessly for hours. Other boots, it would fail. No pattern I could find.
If you’ve dealt with Broadcom Wi-Fi on Linux before, you already know where this is going, because you’ve read the same forum threads I have: “BCM43602 is a known, unfixable firmware defect. Broadcom won’t re-release the firmware. Buy a USB adapter.” That’s the community consensus, and it’s repeated everywhere — Arch Wiki talk pages, Reddit, GitHub issues on MacBook-Linux projects. I believed it too, for a while. I was wrong, and so, it turns out, is a lot of that advice.
The hardware, for the record
$ lspci -k | grep -A3 -i network
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43602 802.11ac Wireless LAN SoC (rev 02)
Subsystem: Apple Inc. Device 0157
Kernel driver in use: brcmfmac
Kernel modules: brcmfmac$ cat /sys/class/dmi/id/product_name
MacBookPro13,2Broadcom BCM43602 (PCI vendid=0x14e4, devid=0x43ba), a dual-band 802.11ac chip, driven by the in-kernel brcmfmac driver. On paper, a chip Linux has supported for a decade. In practice, my personal nemesis for several weekends.
The symptom
Every failed connection attempt logged the exact same thing:
wlp2s0: CTRL-EVENT-ASSOC-REJECT bssid=00:00:00:00:00:00 status_code=16Two details matter here. status_code=16 in the 802.11 spec means "authentication rejected due to timeout waiting for the next frame in sequence" — not "wrong password," not "rejected by the router," a genuine timeout. And the bssid=00:00:00:00:00:00 is the real tell: that's not a real access point's address, it's all zeroes. wpa_supplicant makes that up locally when it never got a real response frame from the router at all. So whatever was going wrong, it was happening before the router had any chance to say yes or no. Not a wrong password, not a security mismatch, not the router rejecting me — my laptop was shouting into the void and nothing was shouting back.
On a bad boot, this would repeat every few seconds, forever:
$ journalctl -b 0 --no-pager | grep -c "CTRL-EVENT-ASSOC-REJECT"
284Chasing ghosts (a.k.a. everything that didn’t work)
Here’s the thing about “known unfixable” bugs: there’s usually a grain of truth buried in them, along with a pile of workarounds people swear by that half-fix a different bug with similar symptoms. I went through all of them.
Regulatory domain. The classic Linux-wifi-on-Mac gotcha — the country regulatory domain resets to a generic “00 world” domain on every boot unless you persist it, which restricts channels and can cause exactly this kind of flaky behavior:
sudo iw reg set AUExcept mine was already correctly set to AU on every boot, no persistence hack needed. Not it.
The famous modprobe fix. If you search for BCM43602 problems, this is the fix that comes up over and over — disabling the firmware’s own (apparently buggy) roaming logic and a specific broken feature bitmask:
echo "options brcmfmac roamoff=1 feature_disable=0x82000 pno_enable=0" | \
sudo tee /etc/modprobe.d/brcmfmac.confThis is a real fix for a real class of BCM43602 bugs — bad firmware-driven roaming causing random disconnects. I applied it. It helped, sometimes. It also did not stop a fresh boot from hitting 146, then 284 straight authentication timeouts. Real fix, wrong bug.
Reloading the driver mid-session.
sudo modprobe -r brcmfmac_wcc brcmfmac && sudo modprobe brcmfmac
sudo systemctl restart NetworkManagerNo change whatsoever on an already-bad boot. Whatever was wrong got decided very early, at firmware init, and a driver unload/reload from userspace couldn’t touch it.
WPA3 transition mode / Protected Management Frames. My router broadcasts a WPA2/WPA3-mixed SSID for the main network, and I know old Broadcom firmware can get confused by that. I locked the client to key-mgmt=wpa-psk only (no SAE), confirmed PMF was off. Then, as a clean test, I connected to a completely different, plain WPA2-only SSID on the same router instead. Identical failure, same millisecond timing. That ruled out AP-side security negotiation entirely — it wasn't about which network I was joining.
Stale connection state. Deleted the NetworkManager profile, recreated it from scratch, tried again. Identical failure.
By this point I’d eliminated regulatory domain, firmware roaming behavior, driver state, security mode, and connection profile staleness. Every lever I had access to from userspace, pulled, with no effect on a bad boot. I was about ready to write “yep, it’s just broken” and order a USB dongle.
The clue I’d been ignoring the whole time
It was sitting in dmesg/journalctl from the very first boot, and I'd skimmed past it every single time because it sounds like a benign warning:
brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43602-pcie for chip BCM43602/2
brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43602/2 wl0: Nov 10 2015 06:38:10 version 7.35.177.61 (r598657) FWID 01-ea662a8cTwo things jump out once you actually read them instead of skimming past. First: Nov 10 2015. My wifi firmware blob was over a decade old, and Broadcom has confirmed they're not releasing a new one — that part of the "unfixable" folklore is true. Second, and this is the part I'd glossed over every time: "device may have limited channels available."
Get ozdadirri’s stories in your inbox
Join Medium for free to get updates from this writer.
I decided to actually check what “limited channels” meant, concretely:
$ iw phy | grep -A20 "Frequencies:"
* 2412.0 MHz [1] (20.0 dBm)
* 2417.0 MHz [2] (20.0 dBm)
...
* 2472.0 MHz [13] (20.0 dBm)
* 2484.0 MHz [14] (disabled)That’s it. That’s the whole list. Zero 5GHz frequencies, on a chip that is supposed to be dual-band 802.11ac. Not “weak 5GHz.” No 5GHz band at all.
I went and looked at what firmware files actually exist on disk:
$ ls /usr/lib/firmware/brcm/ | grep 43602
brcmfmac43602-pcie.ap.bin.zst
brcmfmac43602-pcie.bin.zstThen I looked at what exists for other Broadcom chips in that same package:
$ ls /usr/lib/firmware/brcm/ | grep -E "4356-pcie|43455-sdio"
brcmfmac4356-pcie.clm_blob.zst
brcmfmac4356-pcie.Intel Corporation-CHERRYVIEW D1 PLATFORM.txt.zst
brcmfmac4356-pcie.Xiaomi Inc-Mipad2.txt.zst
brcmfmac43455-sdio.clm_blob.zst
brcmfmac43455-sdio.raspberrypi,4-model-b.txt.zst
...Every other chip ships either a .clm_blob calibration file, or board-specific .txt NVRAM files matched to real hardware (a Xiaomi tablet, a Raspberry Pi, an Intel reference platform). My chip's Apple variant ships with neither. It had been running, this entire time, with zero board calibration data — no antenna gain tables, no RF chain configuration, no Bluetooth-coexistence parameters, nothing. Just generic firmware defaults on hardware that was never designed to run on generic defaults.
That’s Apple’s fault, not Broadcom’s, really: Apple ships this calibration data through macOS, tied to the exact board ID, and it was never contributed back to the open-source linux-firmware project the way, say, Raspberry Pi's or Xiaomi's was. Which meant my "known unfixable firmware bug" was actually a known missing file — a very different, and much more fixable, problem.
Finding the fix
A search for the missing file — a community-sourced board config file attached to a Linux kernel Bugzilla ticket.
curl -sL "https://bugzilla.kernel.org/attachment.cgi?id=285753" -o brcmfmac43602-pcie.txtOpening it up, this is a real Broadcom board file — antenna gain tables, RX/TX chain config, Bluetooth-coexistence desense tables, the works:
boardrev=0x1101
sromrev=11
boardtype=0x073e
vendid=0x14e4
devid=0x43bamacaddr=xx:xx:xx:xx:xx:xxccode=X3
regrev=15
...
antswitch=0
rxchain=3
txchain=3
aa2g=3
aa5g=3
femctrl=10
agbg0=2
agbg1=2
aga0=2
aga1=2
...
Three placeholder values need real values before it’s usable:
grep -n "macaddr\|^ccode\|^regrev" brcmfmac43602-pcie.txt
# macaddr=xx:xx:xx:xx:xx:xx
# ccode=X3
# regrev=15Generate a real, unique MAC address first. This part actually matters more than it sounds like it should: every unpatched card with this exact issue reports the same generic fallback MAC address, because without real calibration data the firmware can’t read its actual unique hardware address. If you skip this step and just leave the placeholder — or copy someone else’s already-filled-in value from a tutorial — you’ll be sharing a MAC address with everyone else who has this exact problem and fixed it the same way. Generate your own:
printf '02'; for i in 1 2 3 4 5; do printf ':%02x' $((RANDOM % 256)); done; echo
# → e.g. xx:xx:xx:xx:xx:xxThen patch the file:
sed -i "s/^macaddr=xx:xx:xx:xx:xx:xx/macaddr=xx:xx:xx:xx:xx:xx/" brcmfmac43602-pcie.txt
sed -i "s/^ccode=X3/ccode=0/" brcmfmac43602-pcie.txt # worldwide default, X3 was a test placeholder
sed -i "s/^regrev=15/regrev=1/" brcmfmac43602-pcie.txtAnd install it where the driver actually looks for it:
sudo cp brcmfmac43602-pcie.txt /usr/lib/firmware/brcm/brcmfmac43602-pcie.txt
sudo rebootThe moment of truth
$ iw phy | grep -A20 "Frequencies:"
* 2412.0 MHz [1] (20.0 dBm)
...
* 2462.0 MHz [11] (20.0 dBm)
Band 2:
* 5180.0 MHz [36] (20.0 dBm)
* 5200.0 MHz [40] (20.0 dBm)
* 5220.0 MHz [44] (20.0 dBm)
* 5500.0 MHz [100] (20.0 dBm) (no IR, radar detection)
...Band 2 exists. A whole 5GHz band that had never once appeared on this machine before, just showed up because a text file with the right numbers in it now lives in /usr/lib/firmware/brcm/.
$ journalctl -b 0 --no-pager | grep -c "CTRL-EVENT-ASSOC-REJECT"
0Zero. Not “better.” Zero, for the entire boot. Stable ping, clean DHCP lease, no drops across a soak test. The laptop that had spent weeks convincing me its Wi-Fi chip was cursed connected on the first attempt, every attempt, from then on.
What actually happened, in one sentence
A ten-year-old firmware blob wasn’t the real problem — Broadcom not shipping a firmware update is a real limitation, but a survivable one. The real problem was that linux-firmware never got the board-specific calibration file Apple's variant of this chip needs to run correctly, so the radio had been operating completely uncalibrated the entire time, producing exactly the kind of erratic, boot-dependent, "no discoverable pattern" failures that make a hardware defect and a missing config file look identical from the outside.
If you’ve got this problem too
Check for the signature before you assume your chip is broken:
lspci -k | grep -A3 -i network # confirm the chip
journalctl -k --no-pager | grep -i clm_blob # look for the warning
iw phy | grep -A5 "Frequencies:" # is a whole band just... missing?Broadcom chip, no clm_blob available in the log, and a band that should exist but doesn't in the iw phy output? Look for a board-specific .txt NVRAM file next to your chip's .bin in /usr/lib/firmware/brcm/ — if there isn't one, that's your prime suspect too. The exact file above is specific to BCM43602 / devid=0x43ba, but the same approach — search for a community NVRAM dump matched to your chip and board before writing it off as unfixable — applies to plenty of other Broadcom-on-Mac Linux setups.
Here’s the full sequence in one go (this is what actually fixed it):
# 1. Download the NVRAM file
curl -sL "https://bugzilla.kernel.org/attachment.cgi?id=285753" -o ~/brcmfmac43602-pcie.txt
# 2. Generate a unique MAC address (don't skip this - reusing a shared/placeholder one causes conflicts)
MAC=$(printf '02'; for i in 1 2 3 4 5; do printf ':%02x' $((RANDOM % 256)); done)
echo "Generated MAC: $MAC"
# 3. Edit the placeholder value for your macaddress
sed -i "s/^macaddr=xx:xx:xx:xx:xx:xx/macaddr=$MAC/" ~/brcmfmac43602-pcie.txt
sed -i "s/^ccode=X3/ccode=0/" ~/brcmfmac43602-pcie.txt
sed -i "s/^regrev=15/regrev=1/" ~/brcmfmac43602-pcie.txt
# 4. Install it and reboot
sudo cp ~/brcmfmac43602-pcie.txt /usr/lib/firmware/brcm/brcmfmac43602-pcie.txt
sudo reboot
After reboot, verify it worked:
iw phy | grep -A20 "Frequencies:" # should show Band 2 / 5GHz now
journalctl -b 0 - no-pager | grep -c "CTRL-EVENT-ASSOC-REJECT" # should be 0 or near-0References
- NVRAM file (Linux kernel Bugzilla attachment) — the actual board config file used above.
- Omarchy — the Arch/Hyprland setup this whole dual-boot adventure is running.
