WiFi instability on 5.01.B.1.0-0 (5.1 Beta 1): mass disconnections, PTK handshake timeouts, clients unable to auto-reconnect. Fully resolved by switching to 5.0 stable

[vpit]

Device: Keenetic Ultra (NC-1812), hw_version 1218C000
Firmware: KeeneticOS 5.01.B.1.0-0 (5.1 Beta 1, preview channel, built Apr 18 2026)
Chipset: MT7992-BE7200 (WiFi 7), SKU: #5.MT7992-BE7200-7975-7977
Resolved by: Downgrade to KeeneticOS 5.0 stable (main channel)

Problem

WiFi became completely unstable — both 2.4 GHz and 5 GHz bands affected simultaneously. Wired Ethernet worked perfectly throughout. The problem persisted across router reboots and WiFi radio restarts (interface WifiMaster0/1 down/up).

Symptoms

1. Wireless clients unable to auto-connect — must toggle WiFi off/on on the client device
2. When connected, connection drops after seconds to minutes
3. Drops are distance-dependent (worse at range) but also occur within 1 meter of the router
4. After drop, clients get stuck in "zombie state" — they think they're connected but the router has already deauthenticated them
5. Affects all client types: iPhones (iOS 18), iPads, Android (Galaxy S20 FE, Redmi A7 Pro), Huawei tablet, Denon AVR, Yandex Station, IoT sensors
6. ~15 WiFi clients on the network

Log evidence (from self-test and syslog)

PTK 4-way handshake timeouts (router sends msg 1, client never responds):

 

 

May 8 11:26:31 WifiMaster1/AccessPoint0: STA(ba:c3:32:22:e6:9e) pairwise key handshaking timeout (msg 1 of 4-way)

May 10 19:36:31 WifiMaster0/AccessPoint0: STA(c4:82:e1:21:34:af) pairwise key handshaking timeout (msg 1 of 4-way)

 

MIC corruption during key exchange:

 

 

 

May 8 11:29:14 WifiMaster0/AccessPoint0: STA(1e:9f:6c:f6:d2:31) MIC differs in key handshaking

May 8 12:45:19 — same device, repeated

May 8 13:27:35 — same device, repeated

 

Group key handshake timeout:

 

May 9 12:00:14 WifiMaster1/AccessPoint0: STA(1e:9f:6c:f6:d2:31) group key handshaking timeout

 

RSN IE failure:

 

May 10 19:36:21 WifiMaster1/AccessPoint0: STA(1e:9f:6c:f6:d2:31) RSN IE sanity check failure (status code: 43)

 

Mass simultaneous disconnection — all clients on both bands at once:

 

 

 

 

 

 

 

 

May 10 19:42:57 WifiMaster0/AccessPoint0: STA(c4:82:e1:21:34:af) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster0/AccessPoint0: STA(00:06:78:4d:b7:9e) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster0/AccessPoint0: STA(82:a3:78:3d:23:24) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster0/AccessPoint0: STA(d4:12:43:ae:ef:62) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster1/AccessPoint0: STA(b2:92:d9:13:a9:53) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster1/AccessPoint0: STA(8c:c8:4b:a5:5f:db) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster1/AccessPoint0: STA(92:7a:20:d3:34:b1) disassociated by AP (reason: due to inactivity)

May 10 19:42:57 WifiMaster1/AccessPoint0: STA(82:fe:44:93:b9:91) disassociated by AP (reason: due to inactivity)

 

Constant "retransmits limit reached" for multiple devices across all 3 days.

What was ruled out

• RF interference: Channel scan shows <10% load on both bands, minimal neighbor networks
• Neighbor issues: Adjacent apartments report no WiFi problems
• Channel selection: Tested manual channels (ch 11 on 2.4 GHz, ch 36/80 MHz on 5 GHz) — no improvement
• Band steering: Disabled via CLI — no improvement
• WPA3/FT: Disabled both — no improvement
• Radio restart: interface WifiMaster0/1 down/up — no improvement
• Router reboot: Full power cycle — no improvement
• Hardware failure: No kernel panics, watchdog resets, thermal warnings, or PHY errors in logs

Configuration at time of issue

• SSID: same on both bands (band-steering enabled)
• Security: WPA2 + WPA3 (SAE), PMF, Fast Transition (802.11r)
• 2.4 GHz: auto channel, 20/40 MHz, BGN+AX+BE
• 5 GHz: auto channel, up to 160 MHz, AN+AC+AX+BE
• WireGuard VPN active
• USB storage (Seagate 2TB NTFS) attached

Resolution

Switching from preview channel (5.1 Beta 1) to main channel (5.0 stable) immediately resolved all WiFi issues. No configuration changes were needed — same settings work perfectly on 5.0.

Self-test diagnostic files from during the issue are available on request.

[Ivan Chaynikov]

Hello,

Adding another data point to the known PTK handshake issues on NC-1812.

Environment:
- Device: NC-1812 (Netcraze Ultra), chipset MT7992-BE7200
- Firmware: KeeneticOS 5.0.11 (stable, main channel)
- Service tag: [fill in 15-digit code from device label]
- Client: MacBook Pro M4 Max, macOS Tahoe 26.5

Symptom:
The Mac cannot reliably connect to the 5GHz SSID (WifiMaster1).
SAE key exchange completes, association succeeds, but the 4-way handshake fails at message 1 of 4. AP deauthenticates the client after a 5-second timeout.

Router log (characteristic sequence):
[I] WifiMaster1/AccessPoint0: STA(xx:xx:xx:xx:xx:xx) SAE key exchange done, PWE method: H2E.
[I] WifiMaster1/AccessPoint0: STA(xx:xx:xx:xx:xx:xx) had associated (has FT caps).
[I] WifiMaster1/AccessPoint0: STA(xx:xx:xx:xx:xx:xx) pairwise key handshaking timeout (msg 1 of 4-way).
[I] WifiMaster1/AccessPoint0: STA(xx:xx:xx:xx:xx:xx) had deauthenticated by AP (reason: PTK 4-way handshake timeout).

Key observations:
1. The issue occurs ONLY on the 5GHz radio (WifiMaster1). On 2.4GHz (WifiMaster0) the same client completes the handshake correctly ("set key done in WPA3/WPA3PSK").
2. Other clients on the 5GHz radio connect normally — the bug is specific to the combination of MT7992 + macOS Tahoe.
3. The same Mac worked stably on this 5GHz network for several months before the macOS Tahoe upgrade.

Tested on the router side (no effect):
- Disabled Fast Transition (802.11r)
- Disabled RRM/BTM (802.11k/v)
- Disabled MLO, DL/UL MU-MIMO, DL/UL OFDMA, TWT, Airtime Fairness
- Changed standard from 802.11a/n/ac/ax/be to 802.11a/n/ac/ax (without BE)
- Changed channel width (160 → 80 → 40 MHz)
- Tried different channels (UNII-1 / UNII-3)
- Network protection: WPA2-PSK + WPA3-PSK transition, WPA2-only, WPA3-only
- Full SSID removal and recreation

Tested on the Mac side:
- Removed network cache and re-added the network
- Disabled Private Wi-Fi Address for this network
- Disabled Bluetooth
- Disabled iCloud Keychain sync for Wi-Fi

The same Mac also has issues on another AP (Huawei AX3, HiSilicon Gigahome chipset) — confirming this is primarily a macOS Tahoe regression, not chipset-specific. However, MT7992 behaves more strictly: the connection cannot be established at all, while Huawei AX3 reconnects with packet loss. If a firmware-side mitigation is possible (e.g., increasing the PTK handshake timeout or making msg 1 retries more lenient), it could help users until Apple ships a fix.

Thanks.