Repository navigation
fix: preserve WPA3 on Broadcom BCM4364 and Apple Silicon Macs - #13024
thedavidweng wants to merge 4 commits into
Conversation
Automated AI review
Verified: the core fix is sound. Two issues and one test gap remain. Cleanup silently skips an Omarchy block that has lines after it
(Effective options are derived from kmod and kernel parameter-parsing source, not from running No Omarchy writer puts content after its block. The installers overwrite the file, and the old migration appends its block at the end. This shape therefore comes from a later user edit, such as Impact: for those users, WPA3-only networks keep failing, while the update prints "Restore WPA3 support on Broadcom BCM4364 and Apple Silicon Macs". Suggested change: remove either exact Omarchy block wherever it appears on whole-line boundaries, keeping all other bytes. Any Not every T2 Mac carries BCM4364The description and comments say every T2 Intel Mac has BCM4364, and they list
Impact: the PR also removes the quirk from these five T2 models, but its hardware evidence covers only BCM4364 (MacBookPro15,2 and 16,1). With the new T2 exclusion, the Context: the removal is plausibly correct on these models too. The t2linux Wi-Fi guide recommends this exact Suggested change: correct the chip names in the description, the installer comment and the test comment. Drop Optional test improvement: every T2 case in both suites uses Documentation note: Review informationTest scope: source review of the PR, AI process: Opus 5.5 Medium coordination and synthesis, independent Opus 5.5 Xhigh and GPT 6 Sol Xhigh technical assessments with targeted follow-up questions, Opus 5.5 Medium editorial check. Opt out: To stop receiving these reviews, reply to this comment saying so. |
|
Both findings were real. Fixed in 1. Cleanup skipped an Omarchy block with lines after itConfirmed, and the cause was exactly as described: the migration accepted the legacy block only as the whole file and the current block only as the file's tail, so on a T2 Mac where the installer appended the block and the user later added
Behavior now, all verified by running the migration against stubbed
Four new test cases pin this in 2. Not every T2 Mac carries BCM4364Confirmed against the sources you cited, and it changes which list the parts belong in:
I took the "drop them" branch rather than keeping them with an explanation, because keeping them would only re-arm the WPA3 break on any board whose T2 chip the check failed to see, while dropping them changes nothing for real hardware. The legacy list is now The T2 check is now load-bearing rather than redundant, so it is pinned by tests, which is the improvement you flagged as optional: On the supplicant history: confirmed. Current Also fixed the stale note in Tests
|
Automated AI review
Follow-up to the earlier automated review and the author's reply, checked at Verified: both earlier findings are resolved.
One new issue, two small leftovers and a note on related PRs follow. The fix depends on Arch's downstream wpa_supplicant patch, not on upstreamThe description says hostap commit
Mainline brcmfmac reports port authorization only for 802.1X fast-transition roams ( Impact: on current Omarchy the premise holds, because the mirrors serve the patched package. But dropping the quirk on T2 and BCM4364 Macs relies on Arch keeping that downstream revert. A future Suggested change: say in the description that upstream hostap 2.12 and main still contain Smaller itemsOptional test improvement: the reply says deleting the Documentation note: the new sentence at Related open PRs: two open PRs touch the same installer gate.
Review informationTest scope: follow-up source review of AI process: Opus 5.5 Medium coordination and synthesis, Opus 5.5 Xhigh technical review and final fact check, GPT 6 Sol Xhigh search for related issues, Opus 5.5 Medium editorial check. Opt out: To stop receiving these reviews, reply to this comment saying so. |
omarchybot
added
bug
The installer's claim that hostap 41638606054a is gone from wpa_supplicant was wrong: it is still in hostap 2.12 and main, and what actually clears the brcmfmac association timeouts is Arch's downstream revert of it (patches/0008-Revert-Mark-authorization-completed-on-driver-indica.patch, shipped in 2:2.12-1). Name the patch so a future wpa_supplicant release that drops it is recognisable as the trigger to revisit the quirk. Also fix the legacy migration's stale note about no install getting the quirk from the installer, and add cases that pin the T2 check on its own: with 43dc and 4488 out of the legacy lists, deleting 106b:180[12] from the installer or from 1786391100.sh left both suites passing.
|
All three items were real. Fixed in 1. The fix depends on Arch's downstream patch, not on upstreamConfirmed, and my earlier answer was wrong on the mechanism. I checked the sources rather than The commit is in That tag list is the evidence for "first shipped in 2:2.12-1" — the patch commit sits directly between So the premise holds on Omarchy because the mirrors serve the patched package, and the change is conditional on Arch keeping that patch. Both the installer comment and the description now say so explicitly and name the patch, so a 2. T2 exclusion was not pinned by testsConfirmed, and I reproduced the mutants rather than taking the report on faith. With Rather than only rewording the comments, I pinned the check. A T2 Mac reporting a legacy part is not a real configuration, which is exactly why no documented hardware exercises the check on its own, so
Each gate is now caught by the suite that owns it, so the claim in the previous reply holds. The two comments that called the T2 check "the only thing" excluding 3. Documentation note in
|
| Script | Result on this machine |
|---|---|
| installer leaf | writes no config — correct, BCM4364 + T2 is excluded |
1790165000.sh (WPA3 cleanup) |
removed the real quirk block, set reboot-required |
1786391100.sh (legacy) |
skipped, zero privileged calls |
The cleanup's calls on the real file content:
sudo cat .../brcmfmac.conf
omarchy-state set reboot-required
sudo rm -f .../brcmfmac.conf
That is the file currently in /etc, byte for byte, including its 4-line Omarchy
comment — so the exact-matching path removes it as a whole file rather than
stranding the block.
The legacy migration's gate was checked in both directions on this box: with the
real lspci (BCM4364 + T2) it made no privileged calls; with lspci stubbed to
BCM43602 and no T2 it appended the block and set reboot-required; and with a
T2 present plus BCM43602 it again made no calls, confirming the T2 check alone
holds the gate — the shape the newly added test case covers.
After state: not captured
Requires a module reload, which needs root and would drop the session's default
route. sudo requires a password here, so it was not attempted. The claim
"SAE_OFFLOAD returns once the block is gone" is therefore still inferred from the
source above, not measured. The block is still in place and the machine still
runs the workaround; a reboot after removing it would close this.
Automated AI review
Outcome: one documentation issue remains in the Live tests section; at Live tests: after-state provenance is unclearThe description says Suggested change: state which results were measured on which machine, mark the rest as expected, and paste literal output or name the command used. Evidence (source reading and text comparison, not a hardware run)Live tests: after-state provenance and iw transcripts (documentation note)Kind: source reading plus a text comparison of the PR description and the author's reply. Not a runtime reproduction; no Apple or Broadcom hardware was used. The two statementsPR description (current text):
Author reply, hardware section (edited 2026-09-30):
What iw actually printsiw prints only the extended features that are present, one line each, in the form So Related public evidenceIssue #9802 reports a measured after-state on a Details: Verified, small corrections, related PRsVerified:
Small corrections (optional):
Related open PRs: #11259 and #13362 also edit the installer leaf and conflict textually with this PR's T2 gate deletions against both suites (verification of the earlier optional test item, not a finding)Kind: isolated command-only run with the suites' own stubbed #!/bin/bash
# Deletes the 106b:180[12] (T2) check from each of the three gates in a
# throwaway copy of the repository and runs both brcmfmac suites against it.
# Usage: bash verify-t2-gates.sh [repo-root] (writes only under mktemp -d)
set -uo pipefail
root=$(cd -- "${1:-.}" && pwd)
work=$(mktemp -d)
trap 'rm -rf "$work"' EXIT
suites=(brcmfmac-supplicant-test.sh brcmfmac-wpa3-cleanup-test.sh)
run_suites() {
local label=$1 dir=$2 suite out status
for suite in "${suites[@]}"; do
out=$(bash "$dir/test/shell.d/$suite" 2>&1)
status=$?
if (( status == 0 )); then
printf '%-22s %-32s passes (%s ok)\n' "$label" "$suite" "$(grep -c '^ok - ' <<<"$out")"
else
printf '%-22s %-32s FAILS: %s\n' "$label" "$suite" \
"$(grep '^not ok - ' <<<"$out" | tail -n 1 | sed 's/^not ok - //')"
fi
done
}
copy() {
local dest="$work/$1"
mkdir -p "$dest/test"
cp -r "$root/install" "$root/migrations" "$dest/"
cp -r "$root/test/shell.d" "$dest/test/"
printf '%s\n' "$dest"
}
run_suites unmodified "$root"
d=$(copy installer)
sed -i '/^ ! lspci -nn | grep "106b:180\[12\]" >\/dev\/null &&$/d' \
"$d/install/hardware/apple/fix-brcmfmac-supplicant.sh"
! grep -q '106b:180' "$d/install/hardware/apple/fix-brcmfmac-supplicant.sh" || { echo "installer mutation not applied"; exit 2; }
run_suites "no T2 in installer" "$d"
d=$(copy legacy)
sed -i -e '/^if lspci -nn | grep "106b:180\[12\]" >\/dev\/null ||$/d' \
-e 's/^ ! { \[\[ \$sys_vendor == Apple\* \]\] &&$/if ! { [[ $sys_vendor == Apple* ]] \&\&/' \
"$d/migrations/1786391100.sh"
! grep -q '106b:180' "$d/migrations/1786391100.sh" || { echo "legacy mutation not applied"; exit 2; }
bash -n "$d/migrations/1786391100.sh" || { echo "legacy mutation broke syntax"; exit 2; }
run_suites "no T2 in 1786391100" "$d"
d=$(copy cleanup)
sed -i 's/grep -E "106b:180\[12\]|14e4:(4464|4425|4433)"/grep -E "14e4:(4464|4425|4433)"/' \
"$d/migrations/1790165000.sh"
! grep -q 'grep -E "106b:180' "$d/migrations/1790165000.sh" || { echo "cleanup mutation not applied"; exit 2; }
run_suites "no T2 in 1790165000" "$d"Actual output at Same output on a local merge of Actual output at the previously reviewed head Review informationTest scope: source review and sandbox tests with stubbed hardware at AI process: Opus 5.5 Medium coordination and synthesis, Opus 5.5 Xhigh technical review and final fact check, GPT 6 Sol Xhigh search for related issues, Opus 5.5 Medium editorial check. Opt out: To stop receiving these reviews, reply to this comment saying so. |
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| sudo rm -f "$conf" | ||
| fi | ||
| else | ||
| printf '%s\n' "$rest" | sudo tee "$conf" >/dev/null |
There was a problem hiding this comment.
When this migration removes an Omarchy block from a file that also contains administrator settings, tee truncates the file before writing the remaining content. If the update is interrupted or the write fails, those settings can be lost or left incomplete. A later retry may no longer find a complete block to remove and can mark the migration finished. Write the replacement completely before changing the original, while retaining the tested symlink behavior.
| sudo rm -f "$conf" | ||
| fi | ||
| else | ||
| printf '%s\n' "$rest" | sudo tee "$conf" >/dev/null |
There was a problem hiding this comment.
When an owned block is removed, command substitution strips trailing newlines from the retained content, and this printf writes it back with one final newline. A file with trailing blank lines or a surviving last line without a newline therefore changes outside the owned block. This breaks the migration’s byte-preservation promise and makes harmless administrator edits harder to distinguish from cleanup; preserve the original line endings and test the retained content byte-for-byte.
|
Reviewed at Tests, on a disposable Omarchy worker. Competing fix. #9803 fixes the same bug (#9802) by exempting only DMI product
Smaller findings, none blocking:
Nothing was pushed. This is waiting on the maintainer to choose between this PR and #9803. |
|
Update at the same head, What changed. #9803 was reworked on 2026-10-08. It now exempts BCM4364 ( Which fix goes forward. Both reviewers now pick #9803. It is the older fix and it fixes the cause of #9802 on every machine that has been tested. This PR changes behaviour on more hardware than that, but none of the extra machines has been tested:
That makes this PR wider in scope, not a better fix for the bug, so the older one wins. Codex agreed. Its agreement isn't guaranteed to be independent: it read both threads, including the earlier review of #9803 that reached the same conclusion. One thing this PR does better. Its cleanup matches blocks against the original lines in a single pass. #9803 matches repeatedly against text it has already edited, so in a contrived layout (legacy comment, current block, then a bare Because #9803 is the one going forward, this PR was not run on a worker again. The earlier test results at this head still stand. Nothing was pushed. It waits on the maintainer, who can still choose this PR's wider scope over #9803. |
Fixes #9802.
Supersedes #9803.
Follow-up to #6652, #7439, #7577, #7487, #9019, #12688.
Summary
Stop applying the
brcmfmactransition-mode quirk (feature_disable=0x82000) to Broadcom BCM4364 (14e4:4464) and Apple Silicon (14e4:4425|4433), and to every T2 Mac, restoring native WPA3-SAE offload without breaking legacy hardware.Context & Root Cause History
Origin (Apply the Broadcom Wi-Fi quirk to Macs without a T2 #6652): Introduced
feature_disable=0x82000to work around firmware 4-way handshake timeouts on legacy Macs (primarily BCM43602 onMacBookPro11,4and14,x) connecting to WPA2/WPA3 transition APs.Apple Silicon breakage (No Wi-Fi on Apple Silicon Macs: the Broadcom quirk's chip-ID gate includes BCM4378/4387 #7439, Stop the Broadcom Wi-Fi quirk breaking Apple Silicon Macs #7577): The derived PCI ID list included BCM4378 (
4425) and BCM4387 (4433), which completely wedged Wi-Fi on M1/M2 systems.WPA3 breakage on Intel Macs (MacBookPro16,1 Broadcom quirk disables WPA3-SAE #9802, Fix WPA3 on MacBookPro16,1 #9803):
0x82000sets bit 13 (BRCMF_FEAT_FWSUP) and bit 19 (BRCMF_FEAT_SAE). It never disabledFWAUTH(bit 20,0x100000).BRCMF_FEAT_SAE_EXT, the driver's userspace-SAE feature, is enabled only when the firmware'scapstring containssae_ext(brcmf_fwcap_mapinbrcmfmac/feature.c), and its only effect in the driver is theNL80211_FEATURE_SAEadvert incfg80211.c. The Apple parts do not have it, so disablingBRCMF_FEAT_SAEremovesNL80211_EXT_FEATURE_SAE_OFFLOADand leaves the driver with no route to WPA3-SAE at all.As a result, WPA3-SAE networks fail to associate on all BCM4364 systems.
PR Fix WPA3 on MacBookPro16,1 #9803 correctly identified this mechanism but scoped the exemption narrowly to DMI product
MacBookPro16,1.Why the whole T2 group can go back to driver defaults: two things changed, not just the BCM4364 exemption.
The quirk is a wpa_supplicant workaround, not a firmware one. hostap commit
41638606054a("Mark authorization completed on driver indication during 4-way HS offload") made wpa_supplicant 2.11 complete WPA state from the driver's authorization event, which broke WPA2-PSK and WPA3-SAE association on brcmfmac generally: it has wpa_supplicant wait for a port-authorized indication that brcmfmac only sends for 802.1X fast-transition roams. That commit is still present in hostaphostap_2_12andmain; nothing upstream reverted it. What clears the regression on Arch is a downstream revert,0008-Revert-Mark-authorization-completed-on-driver-indica.patchat the root of thewpa_supplicantpackaging directory (taken from Fedora, added in packaging commitcef15ba), which first shipped inwpa_supplicant 2:2.12-1(2026-08-10) — the version Omarchy's mirrors serve. So the regression the workaround outlived no longer exists on Arch, and this depends on Arch keeping that patch: a futurewpa_supplicantrelease that drops it would bring the association timeouts back on brcmfmac, at which point the T2 and BCM4364 exemptions would need revisiting. The installer comment names the patch for that reason.Not every T2 Mac carries BCM4364. Linux documents the other T2 Broadcom parts as
14e4:43dc= BCM4355 (MacBook Air 13" Late 2018 / True Tone 2019; brcmfmac commit69005e67ce54) and14e4:4488= BCM4377 (MacBook Pro 13" Touch 2019, MacBook Pro 13" 2020, MacBook Air 13" Scissor 2020; commitbf8bbd903f07). Both are T2-only in those lists, so the106b:180[12]exclusion — not the BCM4364 exemption — is what keeps the quirk off them. That is why43dcand4488are dropped from the legacy list instead of kept: with the T2 exclusion in place they matched no documented Mac, and leaving them in would only re-arm the WPA3 break on any board the T2 check failed to see. Both gates are now pinned separately by tests, since no real Mac carries a T2 together with a legacy part and would otherwise leave the T2 check untested.Fix:
Exclude every T2 Mac (
106b:180[12]) plus BCM4364 (14e4:4464) and Apple Silicon (14e4:4425|4433) from receiving the quirk.Only apply the quirk to legacy pre-T2 Broadcom parts (
14e4:(43ba|43bb|43bc|43a3)).Add a migration that removes Omarchy's own
0x82000block wherever it appears in/etc/modprobe.d/brcmfmac.conf, on whole-line boundaries, keeping every other byte the user wrote, and requests a reboot.Live tests
Provenance is spelled out per machine below: the before and after states on one and the same
MacBookPro15,2, plus the after state onMacBookPro16,1reported by the #9802 reporter.Before, measured on
MacBookPro15,2(BCM436414e4:4464+ T2106b:1801, firmware9.30.503.0.32.5.92)The install-time quirk block (mtime 2026-09-10, unchanged since Omarchy wrote it) was in
/etc/modprobe.d/brcmfmac.confand loaded.iwprints only the extended features that are present, so the missing4WAY_HANDSHAKE_STA_PSK,4WAY_HANDSHAKE_STA_1XandSAE_OFFLOADlines are the observation:With no SAE offload left, association to a WPA3-SAE AP fails:
After, measured on that same
MacBookPro15,2(BCM436414e4:4464+ T2106b:1801, firmware9.30.503.0.32.5.92, kernel7.2.6-arch2-Watanare-T2-4-t2)The block was removed from
/etc/modprobe.d/brcmfmac.confexactly as1790165000.shremoves it, then the machine rebooted — same firmware9.30.503.0.32.5.92FWID01-88a8883and same kernel as the before state above, so the two transcripts differ only in the quirk. Every STA-side feature comes back, and with itSAE_OFFLOAD:SAE_OFFLOAD_APcomes back as well, which the analysis below did not claim: it sits underFWAUTHandSAE, so0x82000removed it too.The WPA2 network
Etherre-associated on its own after the reboot and passes ping. The WPA3-only AP in range (Radiation, reported bynmcli dev wifi listasWPA3, saved profile withkey-mgmt=sae) now associates, takes a DHCP lease and passes ping:NetworkManager's own log for that association:
The first attempt dropped during association and the retry connected 4 seconds later; that is what I observed, and
Etherre-associated the same way after the reboot.Not tested: WPA2/WPA3 transition mode, which is what the quirk originally existed for. No transition-mode AP was in range on this machine. It is expected to work now — with
FWSUPandSAEboth back, the firmware handles the handshake and SAE for every AP, which is exactly what the legacy pre-T2 parts still cannot do and why they keep the quirk — but that is a prediction from the source, not an observation.After, measured on
MacBookPro16,1(BCM436414e4:4464, no T2, firmware9.30.514.0.32.5.94)Not measured by me — this is the result reported in #9802: reloading brcmfmac with the block gone brought
SAE_OFFLOADback iniwand a WPA3-only network connected. That machine covers the BCM4364 exemption, not the T2 one, which is why the T2 part of the gate needed the run above.Mechanism, verified on the affected hardware
On that same
MacBookPro15,2(BCM436414e4:4464and T2106b:1801, firmware9.30.503.0.32.5.92FWID01-88a8883, kernel7.2.6-arch2-Watanare-T2-4-t2) while it still carried the old block, the quirk's whole effect was the before-stateiwtranscript above: every STA-side feature gone, only4WAY_HANDSHAKE_AP_PSKleft. The after-state transcript shows the same driver coming back up without the block and with all of them restored.feature_disable=0x82000sets bits 13 and 19 of the driver'sBRCMF_FEAT_LIST, which areFWSUPandSAE;FWAUTH(bit 20) andSAE_EXT(bit 25) are untouched. Inbrcmfmac/cfg80211.c,NL80211_EXT_FEATURE_SAE_OFFLOADis nested inside theBRCMF_FEAT_FWSUPguard and gated onBRCMF_FEAT_SAE, so it disappears, while4WAY_HANDSHAKE_AP_PSKunderFWAUTHsurvives — which is precisely the asymmetry in that transcript. The same gating is in the v7.2 line, which is the one this machine runs.SAE_EXTis the driver's userspace-SAE feature, and on this hardware it is not available either:brcmf_fwcap_mapinbrcmfmac/feature.cenables it only for firmware whosecapstring containssae_ext, and its one use in the driver is theNL80211_FEATURE_SAEadvert incfg80211.c. Theexternal_authop that would give that advert meaning,brcmf_cyw_external_authinbrcmfmac/cyw/core.c, is registered only by the Cypress/PCIe bus. The Apple parts do not attach there:brcmf_pcie_devid_tablemaps 4364, 4377, 4378 and 4387 to the WCC bus (WCC/WCC_SEED), andbrcmfmac/wcc/core.cregisters noexternal_auth. That is why disabling the offload leaves these Macs with no route to WPA3-SAE.Running the PR's own scripts against that machine, with only the file paths redirected into a sandbox: the installer leaf writes nothing, the cleanup migration removes the block and requests the reboot, and the legacy migration skips with zero privileged calls.
Test suites
test/shell.d/brcmfmac-supplicant-test.sh— installer gate and the legacy migration: T2 Macs (on BCM4364, BCM4355 and BCM4377) get no quirk and are skipped by the legacy migration; BCM4364 and Apple Silicon get no quirk; BCM43602 and BCM4350 still get it; non-Apple vendors, brcmfmac-less parts and missing hardware are left alone; append/idempotency behavior is unchanged. A T2 Mac reporting a legacy part is covered explicitly, because no documented hardware exercises the106b:180[12]check on its own once43dcand4488are out of the legacy lists; without that case, deleting the T2 check from the installer or from1786391100.shleft this suite passing.test/shell.d/brcmfmac-wpa3-cleanup-test.sh— cleanup: removes the legacy and current Omarchy blocks on T2, BCM4364 and Apple Silicon; removes a block that has user lines both before and after it; preserves unrelatedoptionslines; leaves administrator-merged (feature_disablealongside other options) and reworded blocks untouched with no reboot request; writes through a symlink; leaves legacy pre-T2 models alone; stays idempotent; setsreboot-requiredbefore the edit.The two T2-on-a-legacy-part cases were added after review found that, with
43dcand4488out of the legacy lists, deleting the106b:180[12]check from the installer or from1786391100.shleft this suite passing. All three gates are now pinned: each mutant fails the suite that owns it.Related open PRs
Two open PRs touch the same installer gate and are worth sequencing before merge:
omarchy-pkg-add apple-bcm-firmwareinside the branch this PR narrows to pre-T2 IDs. If it is rebased with the package step left inside that branch, a fresh BCM4364 iMac19,x would stop getting the firmware #10306 exists to install. Gating the firmware install on the full Broadcom population, separately from the quirk gate, avoids that. This PR does not touch that step.optionsline. The cleanup matches blocks literally, so it would not remove a block written by that wording. Landing this PR first avoids the issue; if #9803 lands first, the cleanup needs a third owned-block variant.Merge Danger
Door: Two-way
The change removes a modprobe file from
/etc/modprobe.d/on affected systems. If any unforeseen regression occurs, re-addingoptions brcmfmac feature_disable=0x82000restores the previous behavior immediately.Blast Radius: Low
Restricted entirely to Apple hardware with Broadcom Wi-Fi. Fixes WPA3 across all T2 and BCM4364 Mac models while preserving the fallback for older legacy pre-T2 Macs.