Severe Wi-Fi driver crash / simultaneous client disconnections on latest firmware (Layer 2 drop)

Hello Teltonika Support Team,

I am experiencing a critical and persistent Wi-Fi stability issue on my RUTX50 since updating to the latest firmware. During periods of higher network activity (e.g., video streaming/training sessions), the entire Wi-Fi module appears to crash or restart, causing all connected clients to drop simultaneously. My Setup is small. no extra AP, only 1 Windows Notebook, 2 Android devices, 1 Smart TV and 1 Smarthome device

Environment & Setup:

  • Device: RUTX50

  • Firmware: Latest release (recently re-installed cleanly & recovery)

  • WAN Connection: Mobile (5G/LTE via Lidl Mobile, stable connection)

  • Wi-Fi Configuration: Combined SSID (2.4 GHz and 5 GHz networks sharing the same name/WPA2-PSK key). Band Steering is disabled.

The Symptom (Log Evidence): The issue is definitively isolated to a Layer 2 Wi-Fi drop on the router side. The RutOS system log clearly shows that completely different client devices (an Intel-based Windows laptop and a tablet) are disconnected at the exact same second, followed by a re-connection a few seconds later.

Example from my log:

2026-05-27 20:27:31 WiFi Connections Notice: WiFi client connected: AC:5A:FC:C4:49:0B (Intel Laptop)
2026-05-27 20:27:36 WiFi Connections Notice: WiFi client connected: D2:42:65:95:A1:10 (Tablet)
2026-05-27 20:27:30 WiFi Connections Notice: WiFi client disconnected: AC:5A:FC:C4:49:0B
2026-05-27 20:27:30 WiFi Connections Notice: WiFi client disconnected: D2:42:65:95:A1:10

Troubleshooting already performed (without success): To rule out client-side issues and aggressive power-saving or roaming mechanisms, we have already adjusted the following settings based on advanced troubleshooting:

  1. Client-Side (Intel Wi-Fi Card): Fixed preferred band to 5 GHz, disabled all power-saving modes (MIMO Power Save set to ‘No SMPS’), set Roaming Aggressiveness to ‘Lowest’, and disabled ‘Fat Channel Intolerant’. Windows Random Hardware Addresses are turned OFF.

  2. Router-Side (Wireless Advanced Settings):

    • Reduced 5 GHz bandwidth from 80 MHz to a fixed 40 MHz with “Force 40MHz mode” enabled.

    • Set “ACS exclude DFS” to ON to prevent radar-scan drops.

    • Set Distance Optimization to a fixed value (10m) to avoid ACK timeout miscalculations.

    • Increased “Time interval for rekeying GTK” to the maximum of 65535 to rule out key-handshake bugs.

    • Turned “Disable Inactivity Polling” to ON to stop the hostapd process from dropping active clients.

    • Set “802.11w Management frame protection” to Disabled (strictly using WPA2-PSK).

Despite all these isolation steps, the simultaneous disconnections still occur. Since multiple independent devices drop at the exact same moment, this points directly to a bug in the wireless driver (ath11k / mac80211 or hostapd process) handled by the new firmware, specifically when operating a combined SSID setup.

Could you please investigate if this is a known regression in the hostapd/Wi-Fi driver stack of this firmware version, or provide a hotfix?

Best regards
Tomas

Hello again,

I have now extracted and attached the raw log files (system.log, wifi.log, and kernel.log) from the troubleshoot file to provide your development team with the exact root cause.

Upon analyzing the logs, I found a massive loop error that heavily points to a software regression in a Teltonika background daemon rather than a classic client-side or wireless configuration issue.

Key Findings in system.log: The log is completely flooded every few seconds with the following continuous error loop generated by the proprietary wifi_scanner service:

daemon.info wifi_scanner: Failed to parse iwinfo scan data
daemon.err wifi_scanner: Failed to lookup iwinfo ubus object
daemon.err wifi_scanner: Failed to get wireless connected clients

Conclusion: The wifi_scanner daemon appears to be failing to communicate via ubus due to changed data structures or missing objects in this specific firmware version (Linux version 6.6.119 build Thu May 14 2026). This endless loop creates heavy internal overhead, locks up the ubusd communication bus, and eventually triggers a complete crash/restart of the hostapd process, forcing a simultaneous Layer 2 disconnection of all active clients (like my laptop on 5GHz and tablet on 2.4GHz).

Please write me for these logfiles.

Best regards, Tomas

Hello,

noone have this issue? its only on my device?

Greetings,

Apologies for the delayed response.

Could you please let me know which firmware version you upgraded from and which version you upgraded to when this issue first started occurring?

Could you also confirm whether the issue is still present on the latest stable firmware, 07.23.7? If possible, please upgrade to this version without keeping the existing settings and let us know if the issue persists.

Additionally, do you have Wi-Fi WAN (Wi-Fi client mode) configured or enabled, even if it is not currently being used?

Best Regards,
Justinas