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.