Back in 2020 I wrote up how to enable Wi-Fi on a 2011 MacBook Pro under Fedora — and that article ended on a frustrated note: the driver worked after installation, then died on every restart, and reinstalling it was the only fix I could find. I asked readers for help and never got a satisfying answer. Five years later, running Fedora 44 on the very same machine, I finally understand what was happening — and a few new obstacles have appeared since that deserve documenting too.
The hardware
The 2011 MacBook Pro carries a Broadcom BCM4331 Wi-Fi chip. Confirm yours with:
lspci | grep -i -E 'network|wireless'Broadcom’s licensing means the driver can’t ship in Fedora’s official repos — that part hasn’t changed since 2020. It lives in RPM Fusion’s nonfree repo.
Installing the driver (2026 edition)
Enable RPM Fusion (free and nonfree — the command self-adapts to your Fedora version):
sudo dnf install \
https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm \
https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpmThen install the driver — and here’s the crucial difference from my 2020 article — make sure you get the akmod variant:
sudo dnf install akmod-wlLoad it immediately (or just reboot):
sudo akmods --force && sudo modprobe wlSolving the 2020 mystery: kmod vs akmod
My old article’s “deal-breaker” — Wi-Fi dead after every restart, resurrected only by reinstalling — turns out to have a mundane explanation.
A kmod is a kernel module pre-built for one specific kernel version. Install it today, it matches today’s kernel, everything works. Then updates bring a new kernel, you reboot into it — and the module no longer matches. Result: no Wi-Fi. Reinstalling “fixed” it because the reinstall built a fresh module for whatever kernel happened to be running. I was treating the symptom on a loop.
An akmod is the cure: instead of a pre-built module, it installs a small factory (plus compiler and kernel headers) that rebuilds the module automatically for whatever kernel you boot — a systemd service checks at every startup and compiles on the spot if needed. Install once, forget forever. The first build after a kernel update takes a few minutes of fan noise on a 2011 machine; that’s the factory working, not a hang.
Five years, one word of difference: akmod-wl instead of a static kmod. That’s the whole resolution.
A tale of two boots
One subtlety worth knowing: whether you see the factory at work depends on the machine’s setup. On my 2011 MacBook Air (same era, same akmod approach), the first boot after a kernel update shows the module being compiled right on the console — the akmods service runs early and holds up the boot until the build finishes, so by the time the desktop loads, Wi-Fi is simply there. It makes me smile every time: a fifteen-year-old laptop pausing to build its own driver before letting you in.
I assumed for a while that my MacBook Pro handled this differently — no visible compile, and Wi-Fi missing after a kernel update — but the journal (journalctl -u akmods) set me straight: the Pro builds during boot too, and remarkably fast (about thirty seconds for wl-kmod on a 2011 Sandy Bridge). The difference is purely theatrical: quiet boot (rhgb quiet) hides the console behind the splash screen, so the Air performs its ritual in public while the Pro does it behind the curtain. Same factory, same shift — different stage door.
The actual gotcha is subtler: a module built during boot isn’t automatically loaded into the running kernel. It can sit in /lib/modules, freshly compiled and ready, while Wi-Fi stays stubbornly absent — which is exactly how you conclude something has broken when nothing has. The instant, cable-free rescue:
sudo modprobe wlNo reboot needed — though a reboot also fixes it, since the next boot finds the module already built and loads it normally.
And a related trap from a recent morning: if you install updates and shut the lid without rebooting, the next cold boot is when the new kernel — and the build — happens. Wi-Fi absent at first light doesn’t mean the fix regressed; check the factory’s log before panicking:
journalctl -u akmods --since -12h --no-pagerIf the journal shows Building and installing wl-kmod [ OK ], the build succeeded and the module merely needs loading (sudo modprobe wl, as above). A failed build is the other story: the new kernel has outpaced RPM Fusion’s broadcom-wl patches — update the package over ethernet or tethering, re-run sudo akmods --force && sudo modprobe wl, or boot the previous kernel from the GRUB menu until a fix ships.
Part 2: it loads, but won’t connect (new since 2020)
On Fedora 44 the driver loaded fine — networks visible, password accepted — but the connection spun forever in “configuring” and eventually asked for the password again. Same symptom on two different routers. The password was never wrong; something else had changed since 2020: the world around the driver.
Watching the connection attempt live told the whole story:
journalctl -u NetworkManager -fThe key line appeared immediately: Config: added 'key_mgmt' value 'SAE'. SAE is WPA3 authentication. Modern routers default to “WPA2/WPA3 mixed mode,” and NetworkManager optimistically picks WPA3 — but the proprietary wl driver predates WPA3 and can’t speak it. The handshake dies, NetworkManager concludes the password must be wrong, and you get the endless loop. (macOS connects fine on the same chip because Apple’s driver does support WPA3 — same silicon, different software.)
The fix pins this one connection to the WPA2 half of mixed mode — no router changes needed, and every modern device keeps using WPA3:
nmcli connection modify "Your Network Name" wifi-sec.key-mgmt wpa-psk wifi-sec.pmf disable
nmcli connection up "Your Network Name"(pmf is protected management frames — another WPA3-era feature wl can’t do. And note the quotes: they’re for bash, not nmcli — only needed if your network name contains spaces.)
A second modern obstacle worth knowing about even though it wasn’t my culprit: MAC address randomization. NetworkManager randomizes the MAC during scanning for privacy; wl handles this badly on some setups. If connections still fail after the WPA2 pin, drop this in place:
sudo tee /etc/NetworkManager/conf.d/wifi-rand-mac.conf << 'EOF'
[device]
wifi.scan-rand-mac-address=no
[connection]
wifi.cloned-mac-address=permanent
EOF
sudo systemctl restart NetworkManagerThe fix doesn’t survive GUI edits
A follow-up discovery, one week later: the Wi-Fi loop came back. Nothing had broken — I had merely opened the connection in Plasma’s GUI editor to change the band mode (chasing better speeds), and saving that edit silently rewrote the security section back to defaults. The wpa-psk pin was gone, NetworkManager was back to trying SAE, and the endless loop returned as if we’d never fixed it.
The GUI editor doesn’t know about surgical nmcli tweaks; it flattens them on every save. So the rule for this profile is: edit it via nmcli only. Band changes included — to keep it on 2.4GHz (where the BCM4331’s 802.11n still works fine):
nmcli connection modify "Your Network Name" wifi.band bgAnd since I’ll inevitably forget this rule, a small rescue script re-applies the pin and verifies it:
#!/bin/bash
# Re-pin Wi-Fi to WPA2 after GUI edits flatten it (BCM4331 can't do WPA3)
SSID="${1:-Your Network Name}"
nmcli connection modify "$SSID" wifi-sec.key-mgmt wpa-psk wifi-sec.pmf disable
nmcli connection up "$SSID"
nmcli -f 802-11-wireless-security.key-mgmt,802-11-wireless-security.pmf connection show "$SSID"To check the negotiated link rate without touching the GUI at all: nmcli -f IN-USE,SSID,CHAN,RATE,SIGNAL device wifi list — the starred row is the active connection. On b/g you’re capped at 54 Mbit/s; with n on 2.4GHz expect 72–144 Mbit/s.
Two small lessons from the terminal
Secrets and agents. If nmcli connection up fails with “Secrets were required, but not provided,” the profile’s password is likely stored agent-owned (in your desktop wallet), which terminal sessions can’t reach. Cleanest fix: delete the profile and reconnect fresh with nmcli device wifi connect "Name" password '...', or set wifi-sec.psk-flags 0 to store it system-owned.
Passwords in your history. Any password typed as a command argument lands in ~/.bash_history — and in your screenshots, if you publish terminal sessions like I do. Prefer interactive prompts (nmcli --ask, or the GUI dialog) when secrets are involved.
Summary
| Symptom | Cause | Fix |
|---|---|---|
| Wi-Fi dead after restart/update | Static kmod built for old kernel | Install akmod-wl instead |
| Wi-Fi absent right after a kernel update | Module built at boot but not loaded | sudo modprobe wl (or reboot) |
| Endless “configuring,” re-asks password | Router offers WPA3, wl can’t speak it | Pin connection to wpa-psk, disable pmf |
| Still failing to associate | MAC randomization | Disable scan randomization, use permanent MAC |
| “Secrets were required, but not provided” | Agent-owned password, no GUI agent | Fresh profile or psk-flags 0 |
| Loop returns after editing the connection | GUI editor resets security section, removing the WPA2 pin | Re-apply the pin; edit this profile via nmcli only |
Postscript: the third gear (5GHz)
The speed story turned out to have three chapters, not two. The b/g default capped the link at 54 Mbit/s; enabling 802.11n on 2.4GHz lifted it to 270. But the wifi list revealed the same SSID broadcasting on channel 44 — the router’s 5GHz radio — at 540 Mbit/s, and the BCM4331 does 5GHz n happily. One more nmcli edit:
nmcli connection modify "Your Network Name" wifi.band a
nmcli connection up "Your Network Name"Two things to know. First, the modify alone changes nothing — the profile is edited but the live connection keeps humming along on its old settings until the connection up forces a reconnect. (I sat there wondering why nothing had changed until the penny dropped.) Second, wifi.band a is a pin, not a preference: the connection will now refuse 2.4GHz entirely. Near the router that’s free speed; carry the laptop two rooms away and 5GHz’s weaker wall penetration may bite, with nothing in the symptoms pointing at a band pin made months earlier. The unpin, for future me:
nmcli connection modify "Your Network Name" wifi.band ""Final tally: 54 → 270 → 540 Mbit/s, a ten-fold improvement on a fifteen-year-old chip — all of it in software.
Epilogue: the machine keeps better notes than you do
Here’s what the logs say happened the morning I thought the fix had regressed: the machine booted a new kernel, built its own driver in 31 seconds, and waited patiently for someone to load it. Here’s what I remember happening: the Wi-Fi was broken. I was in a rush between machines — another laptop had just died of a low battery mid-piece — and silence where a network should be reads as breakage when you’re in a hurry.
Every component did its job flawlessly that day. akmods compiled. dnf dutifully guarded its signing keys (and halted the update until I answered, which I didn’t notice for ninety minutes — also not dnf’s fault). The module loaded when asked. The only fault anywhere in the system was a human under time pressure — and when I later reconstructed the day from memory, journalctl corrected me on the sequence of events in three separate places. I’d merged two sessions into one and misplaced a shutdown entirely.
The more often the journal corrects me, the less I trust my own recollection — and the more I’ve learned to embrace that rather than fight it. So, troubleshooting lesson zero, before any nmcli incantation: consult the logs first. Your memory stores the gist; the journal stores what actually happened. You need both, but only one of them is admissible evidence.
The 2011 MacBook Pro remains a lovely Linux laptop — the driver situation just requires knowing which decade each of its problems comes from.