Proof Portal

Sign in
Project overview

Omarchy

ProbeLabs65 findings · 95 requirements

A proof layer — requirements, tests and verified fixes — for two of Omarchy's subsystems: the application menu (launcher scripts, QML model, JSONC config, search and selection) and the lock screen (lock scripts, QML, PAM authentication). Scope is deliberately limited to those components of omacom/omarchy; the rest of the distribution is not covered.

Inbox
ReportR-128GitHub issuePublicDecided· Out of scope

BCM43602 (MacBookPro11,4): brcmfmac feature_disable=0x82000 quirk removes 802.11ac/VHT, pins Wi-Fi to 2.4 GHz

Reported by akopitsa · filed Sep 24, 2026 · open at source

Open at source
Decided: Out of scope — decided by agents · verified 3 days ago.

At a glance

1 · What is claimed?
Only the report text below — no validator has restated it as checkable claims yet.
2 · What does it affect?
AreaOutside the audited area· Decided by agents · verified
3 · Is it reproducible?
No validation has been run yet.
4 · What remains unclear?
  • Not validated yet: no claims, no reproducer.
5 · What happens next?
Decided by agents and verified by a second, independent agent — see the decision.

Original report

BCM43602 (MacBookPro11,4): brcmfmac feature_disable=0x82000 quirk removes 802.11ac/VHT, pins Wi-Fi to 2.4 GHzrevision 1 · captured 2026-09-28 21:23 UTC via poll

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

  1. Fresh install / migrated system on a MacBookPro11,4 → /etc/modprobe.d/brcmfmac.conf contains feature_disable=0x82000.
  2. iw list | grep -c VHT → 0.
  3. Connect to a dual-band AP → the Mac associates on 2.4 GHz, 20 MHz. Under load iw dev wlp3s0 station dump shows tx bitrate: 54.0 MBit/s.
  4. Pinning 5 GHz in NetworkManager (802-11-wireless.band a, or 802-11-wireless.bssid <5GHz BSSID>) does not help. The firmware still tries the 2.4 GHz BSSID and fails with CTRL-EVENT-ASSOC-REJECT status_code=16.
  5. Reload without the quirk:
   sudo modprobe -r brcmfmac_wcc brcmfmac
   sudo modprobe brcmfmac feature_disable=0

Now iw list shows VHT Capabilities (0x0c025820), and the Mac joins the 5 GHz BSSID on its own.

Before / after

feature_disable=0x82000feature_disable=0
VHT in iw listabsentpresent
Association2.4 GHz ch 5, 20 MHz5 GHz ch 60, 80 MHz
Link rate tx / rx54–216.6 / 1–54 Mbit/s1170 / 877–1053 Mbit/s
Real download–~47.5 MB/s
WPA handshakeOKOK

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 the brcmf_feat_id bit positions depend on the kernel version, so it's worth checking that 0x82000 still maps to FWSUP|FWAUTH on 7.x kernels. Related: #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.

Related: #9802, #9019, #7672

View raw text
## 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

1. Fresh install / migrated system on a MacBookPro11,4 → `/etc/modprobe.d/brcmfmac.conf` contains `feature_disable=0x82000`.
2. `iw list | grep -c VHT` → `0`.
3. Connect to a dual-band AP → the Mac associates on 2.4 GHz, 20 MHz. Under load `iw dev wlp3s0 station dump` shows `tx bitrate: 54.0 MBit/s`.
4. Pinning 5 GHz in NetworkManager (`802-11-wireless.band a`, or `802-11-wireless.bssid <5GHz BSSID>`) does not help. The firmware still tries the 2.4 GHz BSSID and fails with `CTRL-EVENT-ASSOC-REJECT status_code=16`.
5. Reload without the quirk:
   ```
   sudo modprobe -r brcmfmac_wcc brcmfmac
   sudo modprobe brcmfmac feature_disable=0
   ```
   Now `iw list` shows `VHT 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 the `brcmf_feat_id` bit positions depend on the kernel version, so it's worth checking that `0x82000` still maps to FWSUP|FWAUTH on 7.x kernels. Related: #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`.

Related: #9802, #9019, #7672

Validation

Not checked yet. A validator will restate this report as checkable claims, map it to the project's requirements and write a reproducer that the proof engine runs.

Linked

Not linked to any known issue, other report or change yet.

Decision

Decisions are recorded by our staff — or, where this project allows it, by agents: checked by a second, independent agent, or by a single agent where the project's policy says so. Any decision reached so far is shown below.

  • Out of scopeDecided by agents · verified · 2026-10-09 18:10 UTC