Wi-Fi on Omarchy

Wi-Fi is one of the subsystems Quattro rewrote from the ground up. Everything below was checked against the v4.0.4 source tree and against issues filed in September 2026.

Status on 4.0.4

The component carries 235 tracked issues, 117 of them still open, and the open ones cluster hard in two places: Broadcom Wi-Fi in Intel Macs, and WPA2-Enterprise or 802.1X networks. Outside those clusters the open reports are mostly single-driver regressions rather than cards that never associate: Realtek rtw89 and Intel BE200 radios that stay dead after an s2idle resume in #7003, and an mt7925e that needs two or three tries on a cold boot in #11219. There is no tracked evidence for any card family being trouble-free, so treat “it worked on the ISO” as your own test, not a guarantee.

The stack itself changed in 4.0.0. Omarchy 3.x used iwd with the impala TUI. Issue #1414, filed by kromsam in September 2025 and carrying more than 120 thumbs-up and a hundred comments by the time it closed, argued that iwd could not carry desktop reality: VPN clients, eduroam, Enhanced Open. Quattro switched to NetworkManager and replaced impala, bluetui and wiremix with Quickshell panels. The network panel is Super + Ctrl + W. See the manual chapter on networking.

What Omarchy does automatically

Several things run at install time and again whenever hardware setup is re-run.

install/hardware/network.sh disables iwd.service, disables every systemd-networkd unit, and masks systemd-networkd-wait-online.service. It also hunts down the stock DHCP files archinstall used to drop (20-ethernet.network, 20-wlan.network, 20-wwan.network), checks that they are unmodified, and moves them into a timestamped backup directory under /etc/systemd/network/. That is why a 3.x machine that upgrades still lands on NetworkManager. install/config/enable-services.sh enables NetworkManager.service and masks NetworkManager-wait-online.service so nothing in the session blocks on DHCP.

install/hardware/set-wireless-regdom.sh derives a two-letter country from your timezone (falling back to zone.tab) and writes WIRELESS_REGDOM into /etc/conf.d/wireless-regdom. It deliberately does not run iw reg set live, because install is followed by a reboot. wireless-regdb is in the base package list; it went in after #1083, where a 6GHz card was locked out of that band without it.

Three quirk scripts target specific radios:

• install/hardware/fix-bcm43xx.sh looks for PCI IDs 14e4:43a0 and 14e4:4331 (BCM4360 in 2013 to 2015 Macs, BCM4331 in 2012 era Macs) and installs broadcom-wl-dkms. 4.0.3 switched this to the DKMS package after Arch dropped the prebuilt module. That switch has a known hole: DKMS needs linux-headers to build, and #10975 reports a BCM4331 MacBook losing Wi-Fi after the 4.0.3 reboot until the headers were installed over Ethernet.
• install/hardware/apple/fix-brcmfmac-supplicant.sh writes options brcmfmac feature_disable=0x82000, which turns off Broadcom’s firmware supplicant and authenticator so wpa_supplicant runs the four-way handshake in software. Without it, a Mac on a WPA2/WPA3 transition-mode access point gets as far as association, the handshake stalls, and the panel tells you the password is wrong. cupatea’s PR #6652 widened the trigger from the T2 bridge ID to the brcmfmac PCI IDs, so BCM43602, BCM4350, BCM4355, BCM4364, BCM4377, BCM4378 and BCM4387 all get it. BCM4360 is left out on purpose: it uses the out-of-tree wl driver, which never reads a brcmfmac option.
• install/hardware/intel/fix-wifi7-eht.sh writes options iwlwifi disable_11be=Y for Intel BE200 and BE211 (8086:e440, 8086:272b), because the EHT receive path drops those links to a crawl. The comment in the script says to remove it once Intel fixes the driver.

On the command side you get omarchy restart-wifi (rfkill unblock, radio on, rescan), omarchy network status, omarchy network band, omarchy network qr, omarchy network password, omarchy network speedtest, and omarchy dns. First login runs nm-online before deciding you have no Wi-Fi, so an Ethernet machine no longer gets a spurious setup prompt.

Known problems

Issue	Models	Status	Fixed in
#11745 Associates but no traffic until iw reg set	BCM43602 Intel Macs 2015-2017	Open	not fixed
#9019 Association fails, regdom never set	MacBookPro14,3 and similar	Open, workaround verified	not fixed
#11859 Wi-Fi dies after long uptime, toggle will not recover	BCM4360 MacBook Air 2017	Open	not fixed
#11613 Signal pinned near -90 dBm	MacBookPro13,3 and 2015-2017 siblings	Open	not fixed
#11791 Enterprise reconnect rebuilds profile, reports wrong password	any 802.1X, eduroam	Open	not fixed
#11985 Panel header says NOT CONNECTED while connected	any 802.1X, eduroam	Open	not fixed
#12028 Bar icon shows disconnected while connected	eduroam, many BSSIDs	Open	not fixed
#11961 Captive portal button opens a URL portals ignore	any	Open	not fixed
#11812 Joins 2.4GHz when 5GHz shares the SSID	ASUS Vivobook, MT7902	Open, workaround	not fixed
#11813 No automatic reconnect after a drop	ASUS Vivobook, MT7902	Open	not fixed
#1806 Cannot connect at all, BCM4377 brcmfmac	MacBook Pro 2020 (T2)	Open since the 3.x iwd era, thread workaround: blacklist hci_bcm4377	not fixed

The Broadcom Mac cluster is the one to take seriously. Clowdyffs on a MacBookPro14,1 found in #11745 that Wi-Fi showed connected with 100 percent packet loss until sudo iw reg set US. benjarlett went further in #9019: on a MacBookPro14,3 the firmware-supplicant quirk alone was not enough, because cfg80211 had no regulatory hint source at all and sat in the world domain until beacon hints accumulated, which took roughly 47 minutes. andyholst’s #11613 is separate again, a signal-strength problem he attributes to generic NVRAM data rather than the antenna tuning those machines need. Be careful reading that issue: the pull request it links is titled as a Cirrus Logic audio fix, bundled an NVRAM script for this card alongside it, and was closed without merging, so nothing has shipped for the signal problem.

The enterprise cluster is newer and is all panel logic, not driver logic. #11791 reports that the panel’s enterprise connect path always adds a fresh profile hardcoded to PEAP with MSCHAPv2, no CA certificate and an eight second auth timeout, then maps that timeout to “Wrong password” and reprompts. If your institution’s CAT installer already created a working profile, the panel ignores it, builds its own, and blames your password when that one fails.

Fixes that work

Work down this list. Stop when you are online.

1. omarchy restart-wifi, or Update > Hardware > Wi-Fi in the menu. It unblocks rfkill, turns the radio back on and rescans. This clears most “it worked ten minutes ago” cases.
2. Check the regulatory domain: iw reg get. A country 00 line means you are in the world domain, which on Broadcom hardware often means association or traffic failure. Put your country in /etc/conf.d/wireless-regdom and reboot.
3. On a Mac with brcmfmac, if step 2 alone does not hold, add options cfg80211 ieee80211_regdom=XX in /etc/modprobe.d/cfg80211.conf, rebuild the Limine boot image with sudo limine-mkinitcpio, and reboot. This is the workaround benjarlett verified across a cold reboot.
4. Confirm the Mac quirk is present: cat /etc/modprobe.d/brcmfmac.conf should show feature_disable=0x82000. The installer writes it and migration 1786391100 appends it on existing installs, then flags a reboot, because modprobe only reads the file when the module loads. If the line is missing, add it and reboot.
5. Slow or flaky on a dual-band SSID: omarchy network band 5. It refuses bands the access point is not answering on, and reverts if the radio cannot come back up.
6. Enterprise networks: build the profile once with nmcli, matching your institution’s documented EAP method, then bring it up with nmcli connection up <name>. Avoid re-entering credentials in the panel until #11791 is resolved.
7. Captive portals: if the sign-in button does nothing, open http://captive.apple.com or http://connectivitycheck.gstatic.com/generate_204 in your browser to force the redirect.
8. If a kernel or firmware update broke a previously working card, that is its own path. See wifi drops after a kernel update and the release channels page. 4.0.4 makes the bespoke linux-omarchy kernel the default boot entry on every machine, so a regression that appeared on 2026-09-15 is worth testing against the stock kernel.

Report it

Run omarchy debug. It writes /tmp/omarchy-debug.log with inxi -Farz, full dmesg, and the current boot’s warnings and errors from the journal. That log carries your PCI IDs, driver, firmware version and kernel, which is what triage needs first.

Add three things by hand, because they are what every Wi-Fi thread ends up asking for: lspci -nn | grep -i net for the exact PCI ID, iw reg get for the regulatory domain, and iw dev <iface> link for signal and negotiated rate. omarchy network status --verbose prints interface, address, gateway, SSID, signal in dBm, bitrate and ping in one go. If the failure is intermittent, say how long the machine had been up, as in0vik did in #11859. File at github.com/omacom/omarchy/issues and say whether Ethernet works, since that separates a radio problem from a DNS or firewall problem.

Related

• Bluetooth, which shares a chip with Wi-Fi on most combo cards
• T2 Macs and Intel MacBook Pro for the Broadcom story in full
• Wi-Fi drops after a kernel update
• Bluetooth stops after resume
• Tailscale not connecting
• What replaces what in Quattro