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

mt7925e Wi-Fi: first association after cold boot completes 4-way handshake then gets deauthed (reason 15), needs 2-3 retries

Reported by igorpeclat · filed Sep 10, 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

mt7925e Wi-Fi: first association after cold boot completes 4-way handshake then gets deauthed (reason 15), needs 2-3 retriesrevision 1 · captured 2026-09-28 21:23 UTC via poll

Summary

The MT7925e Wi-Fi card fails its first association after (cold) boot and needs 2–3 retries (~15–25 s) before the network is up. The first attempt gets all the way through auth, association, and even a completed 4-way handshake (CTRL-EVENT-CONNECTED), then the kernel deauths ~2.5–3 s later with Reason: 15 (4WAY_HANDSHAKE_TIMEOUT). After a warm reboot the first attempt succeeds.

This is on Omarchy (Arch base), stock config: no mt76 module options, no related kernel cmdline params, NetworkManager + wpa_supplicant (not iwd).

System

  • Laptop: Acer Predator PH315-55 (i7-12700H)
  • Card: mt7925e [14c3:7925], firmware WM Firmware Build 20260605184805 (linux-firmware 20260810-2)
  • Kernels: reproduced on 7.1.9-arch1-2 and 7.2.3-arch1-3
  • NetworkManager 1.58.1, wpa_supplicant 2.12
  • AP: TP-Link EAP670-class Wi-Fi 6, WPA2-PSK (wpa-psk, mixed WPA2/WPA3-SAE keymgmt offered by NM), two BSSIDs: 5 GHz …:3b and 2.4 GHz …:3a, PMF default (off)

Reproduction

  1. Boot the machine (after it has been powered off for minutes/hours).
  2. Observe journalctl -b 0 -o short-monotonic | grep wlp43s0.
  3. First attach attempt completes the 4-way handshake, then gets deauthed with reason 15; subsequent attempts on the sibling BSSID fail with authentication timed out; a later attempt succeeds.

Evidence from this boot (timestamps are monotonic seconds; network attach completed at ~59 s):

[   38.891104] wlp43s0: send auth to 50:4f:3b:7a:05:3b (try 1/3)
[   38.949021] wlp43s0: associated
[   40.009207] wpa_supplicant: WPA: Key negotiation completed with 50:4f:3b:7a:05:3b [PTK=CCMP GTK=CCMP]
[   40.009226] wpa_supplicant: CTRL-EVENT-CONNECTED - Connection to 50:4f:3b:7a:05:3b completed
[   42.993018] kernel: wlp43s0: deauthenticated from 50:4f:3b:7a:05:3b (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[   46.509009] wlp43s0: send auth to 50:4f:3b:7a:05:3a (try 1/3)   <- 2.4 GHz BSSID
[   46.577117] kernel: wlp43s0: association with 50:4f:3b:7a:05:3a timed out
[   50.369239] wlp43s0: send auth to 50:4f:3b:7a:05:3b (try 1/3)
[   50.472436] wpa_supplicant: WPA: Key negotiation completed ... (CONNECTED)
[   54.476204] kernel: wlp43s0: deauthenticated from 50:4f:3b:7a:05:3b (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[   57.965013] wlp43s0: send auth to 50:4f:3b:7a:05:3a (try 1/3)
[   58.079932] wpa_supplicant: WPA: Key negotiation completed ... -> this one sticks

Notably the 4-way handshake itself completes (PTK/GTK installed) ~1 s after association — but the AP-side evidently never sees/validates it, and the kernel-side timer then kills the link 3 s later. This smells like the card dropping EAPOL frames right after firmware reinit at boot.

Observations

  • Warm reboot (boot chain Sep 5, only 3 min gap): first-try success at ~20 s uptime, no retries.
  • Cold-ish boots: always ≥1 failed attempt, sometimes 3 (24 s lost this boot; ~13 s on the previous cold boot).
  • No mt7925e firmware error messages (Message … timeout, driver own failed) in the log — the failure is silent at the driver level.
  • No ASPM/swiotlb/iommu quirks in use; pcie_aspm default.

Related

  • Bug 219429 (mt7925e low-signal performance) covers general mt7925 flakiness; this is a distinct, deterministic post-boot handshake failure.
  • Framework/Manjaro threads mention similar "first association fails after boot" behavior.

Happy to test patches, capture tracing (dmesg with mt76 debug, wpa_supplicant -ddd), or try firmware variants.

View raw text
### Summary

The MT7925e Wi-Fi card fails its first association after (cold) boot and needs 2–3 retries (~15–25 s) before the network is up. The first attempt gets all the way through auth, association, and even a completed 4-way handshake (`CTRL-EVENT-CONNECTED`), then the kernel deauths ~2.5–3 s later with `Reason: 15 (4WAY_HANDSHAKE_TIMEOUT)`. After a warm reboot the first attempt succeeds.

This is on Omarchy (Arch base), stock config: no mt76 module options, no related kernel cmdline params, NetworkManager + wpa_supplicant (not iwd).

### System

- Laptop: Acer Predator PH315-55 (i7-12700H)
- Card: `mt7925e` [14c3:7925], firmware `WM Firmware Build 20260605184805` (linux-firmware 20260810-2)
- Kernels: reproduced on 7.1.9-arch1-2 and 7.2.3-arch1-3
- NetworkManager 1.58.1, wpa_supplicant 2.12
- AP: TP-Link EAP670-class Wi-Fi 6, WPA2-PSK (wpa-psk, mixed WPA2/WPA3-SAE keymgmt offered by NM), two BSSIDs: 5 GHz `…:3b` and 2.4 GHz `…:3a`, PMF default (off)

### Reproduction

1. Boot the machine (after it has been powered off for minutes/hours).
2. Observe `journalctl -b 0 -o short-monotonic | grep wlp43s0`.
3. First attach attempt completes the 4-way handshake, then gets deauthed with reason 15; subsequent attempts on the sibling BSSID fail with `authentication timed out`; a later attempt succeeds.

Evidence from this boot (timestamps are monotonic seconds; network attach completed at ~59 s):

```
[   38.891104] wlp43s0: send auth to 50:4f:3b:7a:05:3b (try 1/3)
[   38.949021] wlp43s0: associated
[   40.009207] wpa_supplicant: WPA: Key negotiation completed with 50:4f:3b:7a:05:3b [PTK=CCMP GTK=CCMP]
[   40.009226] wpa_supplicant: CTRL-EVENT-CONNECTED - Connection to 50:4f:3b:7a:05:3b completed
[   42.993018] kernel: wlp43s0: deauthenticated from 50:4f:3b:7a:05:3b (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[   46.509009] wlp43s0: send auth to 50:4f:3b:7a:05:3a (try 1/3)   <- 2.4 GHz BSSID
[   46.577117] kernel: wlp43s0: association with 50:4f:3b:7a:05:3a timed out
[   50.369239] wlp43s0: send auth to 50:4f:3b:7a:05:3b (try 1/3)
[   50.472436] wpa_supplicant: WPA: Key negotiation completed ... (CONNECTED)
[   54.476204] kernel: wlp43s0: deauthenticated from 50:4f:3b:7a:05:3b (Reason: 15=4WAY_HANDSHAKE_TIMEOUT)
[   57.965013] wlp43s0: send auth to 50:4f:3b:7a:05:3a (try 1/3)
[   58.079932] wpa_supplicant: WPA: Key negotiation completed ... -> this one sticks
```

Notably the 4-way handshake itself *completes* (PTK/GTK installed) ~1 s after association — but the AP-side evidently never sees/validates it, and the kernel-side timer then kills the link 3 s later. This smells like the card dropping EAPOL frames right after firmware reinit at boot.

### Observations

- Warm reboot (boot chain Sep 5, only 3 min gap): **first-try success** at ~20 s uptime, no retries.
- Cold-ish boots: always ≥1 failed attempt, sometimes 3 (24 s lost this boot; ~13 s on the previous cold boot).
- No `mt7925e` firmware error messages (`Message … timeout`, `driver own failed`) in the log — the failure is silent at the driver level.
- No ASPM/swiotlb/iommu quirks in use; `pcie_aspm` default.

### Related

- Bug 219429 (mt7925e low-signal performance) covers general mt7925 flakiness; this is a distinct, deterministic post-boot handshake failure.
- Framework/Manjaro threads mention similar "first association fails after boot" behavior.

Happy to test patches, capture tracing (`dmesg` with `mt76` debug, `wpa_supplicant -ddd`), or try firmware variants.

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 11:33 UTC