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-1055GitHub issuePublicDecided· Out of scope

MacBookPro16,1 Broadcom quirk disables WPA3-SAE

Reported by kazeshini178 · filed Sep 2, 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

MacBookPro16,1 Broadcom quirk disables WPA3-SAErevision 1 · captured 2026-09-28 21:24 UTC via poll

MacBookPro16,1 Broadcom quirk disables WPA3-SAE

System details

2019 16-inch Intel MacBook Pro (MacBookPro16,1), Broadcom BCM4364B3 [14e4:4464], Omarchy 4.0.1-1 Quattro, linux-t2 7.1.8, brcmfmac firmware 9.30.514.0.32.5.94 (FWID 01-68d7ff80).

What's wrong?

Omarchy writes this module option on Apple systems using the BCM4364:

options brcmfmac feature_disable=0x82000

On this MacBookPro16,1, that option prevents connections to WPA3-only networks. Scanning still finds the AP, but authentication/association times out and NetworkManager eventually reports ssid-not-found.

The option's current comment says 0x80000 disables firmware authentication (FWAUTH). In the current brcmfmac feature enum, however, bit 19 (0x80000) is BRCMF_FEAT_SAE; FWAUTH is bit 20 (0x100000). Disabling 0x82000 therefore disables both firmware supplication and SAE. cfg80211 only advertises SAE offload when FWSUP and SAE remain enabled, and this firmware does not expose a separate host SAE path.

feature_disable=0x82000 never disabled FWAUTH: it disabled FWSUP and SAE. FWAUTH was enabled under the old configuration and remains enabled with the driver defaults. The behavioral change on MacBookPro16,1 is restoring FWSUP and SAE, which were verified against WPA2, transition-mode, and WPA3 networks. There is no evidence that disabling the separate FWAUTH capability is necessary or beneficial for this client-mode issue.

Reproduction:

  1. Confirm /etc/modprobe.d/brcmfmac.conf contains options brcmfmac feature_disable=0x82000 and load brcmfmac with that value.
  2. Attempt to join a WPA3-SAE network with PMF required. The connection times out.
  3. Reload brcmfmac with feature_disable=0, or remove the Omarchy-owned option and reboot.
  4. iw phy now reports SAE_OFFLOAD; the same profile joins successfully, obtains DHCP, and passes gateway and internet ping tests.

This was reproduced with the same adapter and firmware in one session. WPA3-SAE with PMF required connected after the live reload and again after persisting the driver default. A WPA2/WPA3 transition AP was then tested through both authentication paths: its normal WPA-PSK profile and a temporary SAE profile with PMF required both associated, obtained DHCP, and passed gateway and internet ping tests with 0% packet loss. The WPA-PSK profile also passed a disconnect/reconnect cycle. A separate WPA2-only AP was not available, but the WPA2 authentication path on the transition AP is verified.

This is related to #7439 and #7577, but those concern Apple Silicon BCM4378/BCM4387 systems. The proposed architecture guard in #7577 deliberately retains the quirk on x86_64 and therefore does not restore WPA3 on this Intel Mac.

Suggested narrow fix: exempt the verified MacBookPro16,1 from the quirk, correct the bit documentation, and migrate existing installs by removing only the exact Omarchy-owned configuration blocks. Other Apple models should retain the transition-mode workaround until they are tested.

View raw text
# MacBookPro16,1 Broadcom quirk disables WPA3-SAE

### System details

2019 16-inch Intel MacBook Pro (`MacBookPro16,1`), Broadcom BCM4364B3 `[14e4:4464]`, Omarchy 4.0.1-1 Quattro, `linux-t2` 7.1.8, brcmfmac firmware `9.30.514.0.32.5.94` (`FWID 01-68d7ff80`).

### What's wrong?

Omarchy writes this module option on Apple systems using the BCM4364:

```text
options brcmfmac feature_disable=0x82000
```

On this MacBookPro16,1, that option prevents connections to WPA3-only networks. Scanning still finds the AP, but authentication/association times out and NetworkManager eventually reports `ssid-not-found`.

The option's current comment says `0x80000` disables firmware authentication (`FWAUTH`). In the current brcmfmac feature enum, however, bit 19 (`0x80000`) is `BRCMF_FEAT_SAE`; `FWAUTH` is bit 20 (`0x100000`). Disabling `0x82000` therefore disables both firmware supplication and SAE. cfg80211 only advertises SAE offload when FWSUP and SAE remain enabled, and this firmware does not expose a separate host SAE path.

`feature_disable=0x82000` never disabled FWAUTH: it disabled FWSUP and SAE. FWAUTH was enabled under the old configuration and remains enabled with the driver defaults. The behavioral change on `MacBookPro16,1` is restoring FWSUP and SAE, which were verified against WPA2, transition-mode, and WPA3 networks. There is no evidence that disabling the separate FWAUTH capability is necessary or beneficial for this client-mode issue.

Reproduction:

1. Confirm `/etc/modprobe.d/brcmfmac.conf` contains `options brcmfmac feature_disable=0x82000` and load brcmfmac with that value.
2. Attempt to join a WPA3-SAE network with PMF required. The connection times out.
3. Reload brcmfmac with `feature_disable=0`, or remove the Omarchy-owned option and reboot.
4. `iw phy` now reports `SAE_OFFLOAD`; the same profile joins successfully, obtains DHCP, and passes gateway and internet ping tests.

This was reproduced with the same adapter and firmware in one session. WPA3-SAE with PMF required connected after the live reload and again after persisting the driver default. A WPA2/WPA3 transition AP was then tested through both authentication paths: its normal WPA-PSK profile and a temporary SAE profile with PMF required both associated, obtained DHCP, and passed gateway and internet ping tests with 0% packet loss. The WPA-PSK profile also passed a disconnect/reconnect cycle. A separate WPA2-only AP was not available, but the WPA2 authentication path on the transition AP is verified.

This is related to #7439 and #7577, but those concern Apple Silicon BCM4378/BCM4387 systems. The proposed architecture guard in #7577 deliberately retains the quirk on x86_64 and therefore does not restore WPA3 on this Intel Mac.

Suggested narrow fix: exempt the verified `MacBookPro16,1` from the quirk, correct the bit documentation, and migrate existing installs by removing only the exact Omarchy-owned configuration blocks. Other Apple models should retain the transition-mode workaround until they are tested.

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 10:35 UTC