Repository navigation
BCM43602 (MacBookPro11,4): brcmfmac feature_disable=0x82000 quirk removes 802.11ac/VHT, pins Wi-Fi to 2.4 GHz #13164
Description
Summary
On a MacBookPro11,4 (Mid-2015 15") with BCM43602 (14e4:43ba), the Apple Broadcom quirk options brcmfmac feature_disable=0x82000 (from install/hardware/apple/fix-brcmfmac-supplicant.sh / migration 1786391100.sh) removes 802.11ac (VHT) from the adapter. Wi-Fi stays on 2.4 GHz HT20 and often falls back to 54 Mbit/s legacy rates. Loading brcmfmac with feature_disable=0 restores VHT, and the Mac joins the 5 GHz AP at 80 MHz. On the WPA2/WPA3 transition-mode network that the quirk targets, the handshake still succeeds.
This is not the missing-NVRAM case in #7672. Band 2 (5 GHz) is advertised in both states. Only the VHT capabilities disappear.
System
- Model: MacBookPro11,4, BCM43602
[14e4:43ba]subsystem[106b:0152] - Omarchy 4.0.4-1, kernel 7.2.5-3-omarchy
- linux-firmware-broadcom 20260810-2, firmware
7.35.177.61 (r598657), no NVRAM/CLM/txcap blob - NetworkManager + wpa_supplicant
- AP: dual-band mesh, one SSID on both bands, WPA2/WPA3 transition (PSK + SAE + FT), CCMP only
Steps to reproduce
- Fresh install / migrated system on a MacBookPro11,4 →
/etc/modprobe.d/brcmfmac.confcontainsfeature_disable=0x82000. iw list | grep -c VHT→0.- Connect to a dual-band AP → the Mac associates on 2.4 GHz, 20 MHz. Under load
iw dev wlp3s0 station dumpshowstx bitrate: 54.0 MBit/s. - Pinning 5 GHz in NetworkManager (
802-11-wireless.band a, or802-11-wireless.bssid <5GHz BSSID>) does not help. The firmware still tries the 2.4 GHz BSSID and fails withCTRL-EVENT-ASSOC-REJECT status_code=16. - Reload without the quirk:
Now
sudo modprobe -r brcmfmac_wcc brcmfmac sudo modprobe brcmfmac feature_disable=0iw listshowsVHT Capabilities (0x0c025820), and the Mac joins the 5 GHz BSSID on its own.
Before / after
feature_disable=0x82000 |
feature_disable=0 |
|
|---|---|---|
VHT in iw list |
absent | present |
| Association | 2.4 GHz ch 5, 20 MHz | 5 GHz ch 60, 80 MHz |
| Link rate tx / rx | 54–216.6 / 1–54 Mbit/s | 1170 / 877–1053 Mbit/s |
| Real download | – | ~47.5 MB/s |
| WPA handshake | OK | OK |
The regulatory state (phy country 99, no clm_blob available) is the same in both runs, so it doesn't explain the difference. iw reg set changed nothing.
Expected
The WPA handshake workaround should not cost BCM43602 Macs 802.11ac/5 GHz. Possible directions:
- Drop the quirk for BCM43602 (
14e4:43ba/43bb/43bc) when the handshake works without it, or - Keep only the bit that fixes the handshake, if one of
0x2000(FWSUP) /0x80000(FWAUTH) alone keeps VHT. Note that thebrcmf_feat_idbit positions depend on the kernel version, so it's worth checking that0x82000still maps to FWSUP|FWAUTH on 7.x kernels. Related: MacBookPro16,1 Broadcom quirk disables WPA3-SAE #9802, where the same quirk disables WPA3-SAE.
Local workaround
# /etc/modprobe.d/zz-brcmfmac-local.conf
options brcmfmac feature_disable=0
modprobe merges both options lines, and the last value wins: modprobe --show-depends brcmfmac shows feature_disable=0x82000 feature_disable=0.
Activity
rand0mdud3 commentedon Sep 29, 2026
Counter-datapoint from identical hardware: MacBookPro11,5, BCM43602
14e4:43basubsystem106b:0152, kernel 7.2.5-3-omarchy, firmware 7.35.177.61 (r598657), no clm/txcap blob — withoptions brcmfmac feature_disable=0x82000active from/etc/modprobe.d/brcmfmac.conf,iw list | grep -c VHT= 6 and the link holds 5 GHz ch 36 at 400/400 Mbit/s, −42 dBm.So the quirk alone doesn't remove VHT here. Prime suspect for the divergence is the AP: yours is WPA2/WPA3 transition (PSK+SAE+FT); mine is plain WPA-PSK (
key-mgmt: wpa-psk, no SAE). If your mesh can offer a non-transition SSID, testing the quirk against that would isolate whether transition mode is the trigger.akopitsa commentedon Oct 10, 2026
Correction: the missing VHT I reported here was most likely not caused by
feature_disable=0x82000. The cause was the user regulatory domain,WIRELESS_REGDOM="UA", which the installer derived from myEurope/Kyivtimezone. Whenbrcmfmacloads withUAset, this BCM43602 firmware reports no VHT, whateverfeature_disableis. WithDEorUSit reports VHT, and that includes reloads with0x82000. My earlier reloads withfeature_disable=0brought VHT back only because aniw reg settest had left the regdomain at something other thanUA.That matches @rand0mdud3's MacBookPro11,5 datapoint above, where the quirk is active and VHT is present.
Details, a reload sweep (UA/US/DE/00) and a workaround are in #14828. What's still open here is whether the quirk itself stops 5 GHz association on a WPA2/WPA3 transition network. In one reload with
0x82000under a non-UAregdomain, the card associated on 2.4 GHz, but I haven't repeated that with a 5 GHz band pin, so it isn't confirmed. I'll report back after testing that, or close this if the quirk turns out to be harmless here.rand0mdud3 commentedon Oct 10, 2026
Confirming the corrected model from this 11,5 (same BCM43602, quirk active):
US, derived fromAmerica/Los_Angeles— consistent with your installer-derives-regdomain theory (my timezone hands me a VHT-friendly domain where yours handed youUA).feature_disable=0x82000active via/etc/modprobe.d/brcmfmac.conf.So: quirk + non-
UA+ VHT present, exactly as your correction predicts. On the remaining open question (5 GHz association on transition networks with the quirk): 5 GHz association works fine here with the quirk, but my home AP is not a transition network, so that only narrows it — your band-pinned retest is still the deciding datapoint.omarchybot commentedon Oct 12, 2026
Checked this against
quattro, alongside #14828 and both of your follow-ups.VHT: your correction holds up. The quirk in
install/hardware/apple/fix-brcmfmac-supplicant.shonly writesfeature_disable=0x82000, and nothing in it touches the regulatory domain. TheUAvalue comes frominstall/hardware/set-wireless-regdom.sh, which derives the country from the timezone. Your sweep in BCM43602 (MacBookPro11,4): timezone-derived WIRELESS_REGDOM="UA" removes 802.11ac (VHT) at brcmfmac load #14828 and @rand0mdud3's 11,5 datapoint (quirk active,US, VHT present on 5 GHz) both point there, so the missing 802.11ac is tracked in BCM43602 (MacBookPro11,4): timezone-derived WIRELESS_REGDOM="UA" removes 802.11ac (VHT) at brcmfmac load #14828, not here.The bit question: in upstream
brcmfmac/feature.h, bit 13 (0x2000) isFWSUP, but bit 19 (0x80000) isSAE, notFWAUTH.FWAUTHis bit 20 (0x100000). So the quirk turns off firmware SAE, not the firmware authenticator, and the comment in the installer is wrong about that. This is the cause of MacBookPro16,1 Broadcom quirk disables WPA3-SAE #9802 and is handled in open PR fix: preserve WPA3 on Broadcom BCM4364 and Apple Silicon Macs #13024. It does not affect VHT.Still open: whether the quirk on its own stops a BCM43602 joining 5 GHz on a WPA2/WPA3 transition network. That needs your hardware and AP; a VM can't reproduce it. The test that settles it, with a non-
UAregdomain set beforebrcmfmacloads in both runs:feature_disable=0x82000:nmcli connection up id <ssid> ap <5 GHz BSSID>, theniw dev wlp3s0 link.feature_disable=0, as the control.If both join 5 GHz, the quirk isn't involved and this can be closed in favour of BCM43602 (MacBookPro11,4): timezone-derived WIRELESS_REGDOM="UA" removes 802.11ac (VHT) at brcmfmac load #14828. If only the second one does, please post the
wpa_supplicantjournal lines from the first run.This was reviewed by Opus 5.5 alone. The second opinion (Codex) didn't run, because today's review budget on this machine was used up, so nobody has checked these findings independently. No fix is proposed until your result is in, so this is waiting on you.