When MacBook WiFi drops on Fedora, the fix is below the driver

Why the driver is rarely the actual cause

I have spent more time on Broadcom WiFi (chipsets made by Broadcom, found in most MacBook Pros and many other laptops) on Fedora than on any other piece of hardware. Every friend who installs akmods-wl (the RPM Fusion package that builds and ships Broadcom’s proprietary wl driver out-of-tree) and a MacBook Pro eventually ends up posting the same question on a forum: the connection works, then drops, then comes back thirty seconds later. Adding more devices makes it worse. A different laptop on the same network is fine.

It is tempting to blame the driver. The driver is genuinely a poor citizen of the Linux kernel. It does not participate in mac80211 (the Linux subsystem that manages wireless scanning, roaming, and power-saving), it does not handle regulatory changes well, and every time the kernel updates you end up rebuilding it. That is real, and it is part of the story. It is not the whole story.

What is actually happening in nine out of ten of these setups is that the wireless access point (the router) and the client cannot agree on a roaming decision fast enough. Broadcom’s wl driver has a long-standing bug where it picks an access point based on the first probe response and then refuses to roam, even when the signal quality has degraded below the noise floor (the threshold at which the radio’s signal becomes indistinguishable from background interference). When you add devices, you add interference. When interference rises, the signal-to-noise ratio drops. When the ratio drops, the laptop’s retransmission count climbs. When retransmissions climb, throughput collapses. None of those steps happen instantly. They happen over thirty seconds, which is exactly the window the user notices.

A different laptop on the same network is fine because its driver and firmware do roam. iw (the diagnostic tool for nl80211, the Linux wireless configuration interface) shows roam events every few minutes on a working Intel or Qualcomm chipset. iw shows nothing on the Broadcom laptop, because the driver never tried.

What the symptoms actually mean

A drop of thirty seconds to a minute, repeated, with no obvious trigger, almost always points to the router kicking the client. The router’s logs show the same thing, if you can read them: a deauth frame (a packet the access point sends to formally end a session) with reason code 4 or 15. Reason code 4 is “disassociated due to inactivity,” which sounds contradictory on the surface but means the access point stopped receiving the client’s data frames for a while. Reason code 15 is “4-way handshake timeout,” meaning the WPA2/WPA3 rekey did not complete in time.

Both reasons are downstream effects. The router is reporting the symptom, not the cause.

The real question is why the client went quiet. Two patterns show up most often:

• Power management collisions. The Broadcom wl driver has its own power-saving mode that fights with iwd or NetworkManager’s defaults. When they take turns putting the radio to sleep, frames get dropped on the wake-up ramp. Disabling 802.11 power save on the client usually fixes this.
• AP isolation or band steering. The router, on a busy evening with multiple devices, decides to move everyone to the 5 GHz band. The Broadcom client sees the new SSID, fails to roam onto it, and falls back to 2.4 GHz, which is now congested. The 30-second window is the fallback timer.

Both are fixable without touching the driver.

What I changed on my own MacBook

Three things, in order of safety:

1. Turn off 802.11 power save for the wireless connection. Open NetworkManager’s connection editor for the WiFi profile, find the “Power saving” checkbox, uncheck it. The connection now stays awake across the polling interval, which is what the Broadcom firmware wants. This is the highest-yield change. It fixes the symptom in roughly half of these setups, including mine.

2. Pin the BSSID (the access point’s MAC address) for the home network. Same editor, set “BSSID” to the MAC of the strongest 5 GHz radio on your router. That tells the Broadcom driver to stop scanning for other access points. Combined with change one, this is enough for the steady-state home case.

3. If your router supports it, disable band steering and split the SSIDs. Most consumer routers expose a “Smart Connect” or “Band Steering” feature that does the moving for you. Turn it off. Create a separate SSID for 2.4 GHz and 5 GHz. Connect the MacBook to the 5 GHz SSID. Now the driver never gets the “go roam” hint, the router never has to deauth, and the 30-second windows stop showing up.

None of these changes require rebuilding the Broadcom driver. They do not require any kernel module parameters. They survive a Fedora upgrade.

Trade-offs

There are real costs to each fix:

• Disabling 802.11 power save on a battery-only laptop cuts battery life noticeably. On a desktop replacement MacBook Pro that is mostly plugged in, this is fine. On a thin-and-light that you carry around, the trade-off is real.
• Pinning the BSSID means you do not roam at a coffee shop or office anymore. The laptop will keep trying to use the home access point’s MAC even when you are a mile away. Take the network offline before you leave, or use the GNOME quick-toggle to disconnect manually. The Quick Settings panel in Fedora 40+ has a “Disconnect” toggle that does this in one click.
• Disabling band steering makes the network worse for everyone else. The other devices in the house, including phones and tablets, will hold onto whichever band they connected to first. For mixed-device households, that is usually an acceptable trade because phones roam better than Broadcom chipsets do, and they will pick the 5 GHz radio first anyway. For a household with multiple WiFi-only IoT devices (smart bulbs, cheap security cameras), splitting the SSIDs may force some of them to 2.4 GHz permanently, which is not always what you want.
• None of these changes touch the underlying driver bug. A future Fedora kernel update that improves Broadcom support could close the gap. Until then, the workarounds above are the path.

What I would tell past me

If you are reading this on the third evening of debugging the same flaky connection:

• Confirm the driver version with modinfo wl. If it is older than the latest RPM Fusion build, update it before changing anything else. Out-of-date wl is its own class of pain.
• Watch dmesg -w while you reproduce the drop. If you see “deauthenticated” frames or “wl_bss_connect_done failed,” the driver is at fault. If you see nothing, the router is at fault.
• Run iw dev wlan0 station dump once an hour for an afternoon. If the “rx retries” counter climbs faster than the “tx retries” counter, the client is the noisy sender. If both climb together, the air around you is congested and no driver swap will fix it.

The Broadcom WiFi situation on Linux is a perfect example of “the obvious fix is not the right fix.” Replacing the driver is the obvious fix. Configuring the connection around the driver is the right fix. The two look identical from the symptom side, and only from inside the diagnostic logs do they separate.