### System details

- Fresh Omarchy installation; `omarchy version`: **4.0.4-1**
- Kernel: **7.2.5-3-omarchy**, x86_64
- CPU: AMD Ryzen 7 3700X; motherboard: MSI B450 TOMAHAWK MAX II
- GPU: NVIDIA GeForce RTX 3060, driver 610.57.04
- Wi-Fi: Realtek RTL8821CU USB Wi-Fi/Bluetooth adapter, **0bda:c820**, driver **rtw88_8821cu**
- Firmware reported by driver: **24.11.0, H2C version 12**
- `networkmanager 1.58.1-1`, `wpa_supplicant 2:2.12-1`, `linux-firmware-realtek 20260810-2`
- NetworkManager uses wpa_supplicant; iwd is inactive. Regulatory domain: IN.

### What's wrong?

On this installation, the adapter can return partial Wi-Fi scan results but repeatedly fails to connect with **“The Wi-Fi network could not be found.”** NetworkManager logs association timeouts and `ssid-not-found`. A nearby 2.4 GHz network appears with strong signal, while the desired 5 GHz network initially does not appear. A targeted scan subsequently discovers that 5 GHz AP at approximately -56 dBm on channel 161 / 5805 MHz.

This is a reproduced connection failure on the shipped networking stack. The observations identify scan/association timing failures, but do **not** establish whether the underlying defect is in the kernel driver, firmware, hardware, or integration. No alternate-kernel comparison has been performed, so this is not a confirmed kernel regression.

### Steps that reproduced the failure

On the affected machine, before applying the workaround:

1. Boot Omarchy with the RTL8821CU adapter present and Wi-Fi unblocked.
2. Run `nmcli -f SSID,CHAN,SIGNAL,SECURITY device wifi list --rescan yes`.
3. Attempt connection with `sudo nmcli --ask device wifi connect "<SSID>"`, or activate the saved profile with `sudo nmcli --ask connection up "<profile>"`.
4. Observe the failure above. Creating another profile and disabling profile power saving did not resolve it.

Expected: discover nearby supported-band networks and connect using valid credentials.

Actual: broad scans time out/abort, and association fails even when the SSID appears in partial results. The same saved credentials later succeeded with the workaround, without replacing the driver or firmware.

### Diagnostic evidence

`omarchy debug --no-sudo --print` was collected. Relevant system details are listed above; selected networking logs are included below rather than the full log, which contains unrelated machine/network identifiers. Interface names are replaced with `<wifi>` where appropriate.

Driver initialization:

```text
rtw88_8821cu 1-9:1.2: Firmware version 24.11.0, H2C version 12
usbcore: registered new interface driver rtw88_8821cu
```

During a debug-logged attempt, a broad scan request covered 38 frequencies across 2.4 and 5 GHz. Roughly 13 seconds elapsed before acknowledgment, followed by the 10-second scan timeout. Selected log messages:

```text
23:25:51 nl80211: Drv Event 35 (NL80211_CMD_SCAN_ABORTED) received for <wifi>
23:25:51 <wifi>: nl80211: Scan aborted
23:25:51 <wifi>: Scan completed in 10.826052 seconds
23:25:51 nl80211: Received scan results (2 BSSes)
23:25:51 <wifi>: Scan was aborted - do not use the incomplete scan results to trigger new operations
23:25:51 <wifi>: Radio work 'scan' [pointer omitted] done in 24.086391 seconds
23:25:53 NetworkManager: Activation: (wifi) association took too long, failing activation
```

Other connection/control operations also exhibited approximately 13-second delays. Targeted discovery reached the correct AP, but the original approximately 25-second association window still expired. A device-scoped 90-second timeout allowed the sequence to complete.

`rfkill` showed no soft/hard block. The adapter supports both 2.4 and 5 GHz. Inspected kernel logs did not show firmware-load failure or a stream of USB errors. These observations do not rule out a driver/firmware or hardware fault.

### Workaround tested on this machine

The retained configuration combines:

1. A wpa_supplicant interface configuration with `ctrl_interface=/run/wpa_supplicant` and **`freq_list=5805`**, loaded through a systemd service override while retaining `-u` for NetworkManager's D-Bus management.
2. A bounded `ExecStartPost` helper that issues `wpa_cli -i <wifi> scan freq=5805`. The frequency setting alone did not reliably seed initial NetworkManager discovery; the targeted startup scan was needed for automatic activation.
3. A NetworkManager configuration default scoped to the adapter:

   ```ini
   [connection-realtek-wifi]
   match-device=interface-name:<wifi>
   802-1x.auth-timeout=90
   ```

4. The intended saved profile uses its actual band/channel/BSSID and autoconnect. Other saved profiles were prevented from competing during verification.

Separately, the target profile had `ipv4.method=link-local` and `ipv6.method=ignore`. After association, IPv4 therefore had only a link-local address. Changing both methods to `auto` restored DHCP/router configuration. The origin of those profile settings is unknown; this is **not** evidence that Omarchy defaults create them, and it does not explain the earlier scan failures.

Temporary USB autosuspend, deep-power-saving, and scan-MAC-randomization experiments were reverted. No third-party driver, replacement kernel, or firmware was installed.

### Verification and limitations

- Restarted the supplicant with the persisted workaround; NetworkManager automatically activated the saved network without a manual connection command, taking approximately **42 seconds** from activation start to success.
- Obtained a normal DHCP lease and router/DNS configuration.
- Wi-Fi-bound internet ping: **4/4 replies, 0% loss**. Wi-Fi-bound IPv4 and IPv6 HTTPS requests: **HTTP 200**.
- Removed Ethernet from default-route/DNS selection for the active maintenance connection, confirmed both default routes used Wi-Fi, and repeated ordinary IPv4/IPv6 HTTPS requests successfully.
- Full reboot, suspend/resume, and long-duration stability have **not** been tested.

This is a channel-specific workaround, not a proposed global default or a repair of the underlying delay. Router channel changes or a changed USB interface name require adjusting it. Broad scanning remains the unresolved behavior.

Related but different hardware/symptom: #10889 describes RTL8723DE becoming unusable while already connected; this report concerns USB RTL8821CU scan/initial-association timeouts.