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.
