Since the Quattro iwd → NetworkManager/wpa_supplicant migration, this machine repeatedly roams onto the router's 6 GHz radio, fails to hold the association, and falls back to 5 GHz — in a loop. Under iwd on the same hardware, same AP and same room, it never touched 6 GHz at all.

I want to be upfront that this may well be upstream behaviour in wpa_supplicant's BSS selection rather than an Omarchy bug. I'm reporting it here because the *migration* is what changes which supplicant users get, so this is the point where the regression becomes visible, and because #6783 and #6612 suggest migration fallout is in scope. Happy to be redirected upstream.

## Before / after

Same router, same radios, same physical location. The only variable is the supplicant.

| | iwd (Jul 19 – Aug 15, 27 days) | wpa_supplicant (Aug 15 → now) |
|---|---|---|
| 6 GHz associations | **0** | 28 in one boot, **36 in another (< 1 hour)** |
| Disconnects | 13 in 27 days | dozens per hour at worst |
| Longest unbroken run | **10 days** | ~72 s on 6 GHz |

The detail I found most telling: iwd *enumerated* the 6 GHz band at startup (`6GHz Band:` on Jul 19) and then deliberately never associated to it. It parked on the 5 GHz BSS at −31 dBm and stayed there for ten days.

The exact trigger, from `/var/log/pacman.log`:

```
[2026-08-15T01:12:42-0400] [ALPM] installed wpa_supplicant (2:2.12-1)
[2026-08-15T01:12:42-0400] [ALPM] installed networkmanager (1.58.0-1)
[2026-08-15T01:13:02-0400] [ALPM] removed iwd (3.12-1)
```

## The loop

The AP (a Bell Giga Hub) advertises one SSID from three radios — `…:79` on 6 GHz (6135 MHz, ch 37), `…:7D` on 5 GHz (5785 MHz, ch 157), `…:7C` on 2.4 GHz. wpa_supplicant keeps electing the 6 GHz BSS:

```
13:33:39  Trying to associate with 0e:ac:8a:05:77:79 (SSID='…' freq=6135 MHz)
13:33:39  Associated with 0e:ac:8a:05:77:79
13:33:40  deauthenticating from 0e:ac:8a:05:77:79 by local choice (Reason: 3=DEAUTH_LEAVING)
13:33:40  CTRL-EVENT-DISCONNECTED bssid=0e:ac:8a:05:77:79 reason=3 locally_generated=1
13:33:40  Trying to associate with 0e:ac:8a:05:77:79 (SSID='…' freq=6135 MHz)
13:34:52  deauthenticating from 0e:ac:8a:05:77:79 by local choice (Reason: 3=DEAUTH_LEAVING)
13:34:53  Trying to associate with 0e:ac:8a:05:77:79 (SSID='…' freq=6135 MHz)
13:34:59  deauthenticating from 0e:ac:8a:05:77:79 by local choice (Reason: 3=DEAUTH_LEAVING)
13:35:04  Trying to associate with 0e:ac:8a:05:77:7d (SSID='…' freq=5785 MHz)   ← 5 GHz, holds
```

Hold times on 6 GHz of 1 s, 6 s and 72 s, back to back. `locally_generated=1` — the client is leaving, the AP is not kicking it. 6 GHz reads strong at close range and then collapses in practice.

## Why it's easy to misdiagnose

The symptom is **jitter, not bandwidth**, so speed tests report everything is fine while the desktop feels broken:

| metric | thrashing | after workaround |
|---|---|---|
| gateway RTT avg | 43.3 ms | 2.7 ms |
| gateway RTT max | 135.4 ms | 6.3 ms |
| gateway jitter (mdev) | 51.2 ms | 1.6 ms |
| link rate TX/RX | 960 / 576 Mbit | 1200 / 907 Mbit |

Bulk transfers average straight through the stalls and still benchmark 355–421 Mbps single-stream. I chased this in entirely the wrong direction for a while because every speed test looked healthy.

## Workaround (verified)

```bash
nmcli connection modify <name> 802-11-wireless.band a
nmcli connection up <name>
```

`nm-settings(5)` documents that `band=a` prevents association on 2.4 GHz *and* 6 GHz for that network. After applying: zero 6 GHz attempts, link steady at 1200.9/907.4 Mbit, gateway RTT avg 1.634 ms / mdev 1.507 ms. Confirmed working on `mt7921e`, which matters because the man page warns `band` is driver-dependent.

Worth noting for anyone who finds this: `802-11-wireless.bssid` also works but is worse — per the same man page it "will prevent roaming and also disable background scanning".

## Scope / caveats

- **This is one machine against one AP.** I have not reproduced it on other hardware, and I don't know how widespread it is. Treat the numbers as a single well-documented data point, not a claim about the general case.
- The combination doesn't seem exotic though: MediaTek MT79xx is common in mini PCs and laptops, ISP-supplied 6E routers are now standard, and marginal 6 GHz coverage is the norm rather than the exception. Anyone hitting this would likely just conclude their Wi-Fi got worse after upgrading.
- I couldn't attach `omarchy-debug` output — it requires an interactive sudo/TTY and this was captured from a non-interactive shell. Happy to add it in a comment if useful.

## Possible actions

I don't think `band=a` is a sensible default — it would deny working 6 GHz to people it serves well. Smaller things that might help:

- A troubleshooting entry, or a note in the iwd → NetworkManager migration, covering "Wi-Fi got flaky/laggy after Quattro" with the `band` knob as the first thing to try.
- Possibly an `omarchy-wifi-band` helper, which would sit naturally beside the existing `omarchy-audio-*` commands.

Thanks for Omarchy — happy to run further diagnostics or test a patch on this hardware if that's useful.