Hello,
My RUTX50 repeatedly reaches a state where all Wi-Fi SSIDs remain visible, but no client can authenticate. macOS and iOS ask for the WPA2 password again; entering the correct password does not help. Ethernet access to RutOS usually remains available. Initially a reboot restored Wi-Fi, but during the latest incident even a hard power cycle did not restore reliable operation.
Device and configuration:
- RUTX50
- RutOS: RUTX_R_00.07.23.7
- Regulatory country: US, Outdoor mode
- 2.4 GHz: channel 6, 20 MHz, 20 dBm
- 5 GHz: channel 40, 40 MHz, 23 dBm
- WPA2-PSK/CCMP
- Main SSID “Tortuga” on 2.4 and 5 GHz
- Separate 2.4 GHz SSID “Tortuga2G” was disabled as a test
- Guest SSID was initially active on 2.4 and 5 GHz; it has now also been disabled, leaving only the main SSID active
- Wi-Fi WAN/campground repeater functionality is not normally used; Starlink is the WAN source
Clients are mainly recent Apple devices (MacBook Pro M1 and iPhone 16/17 Pro) plus a Victron Cerbo GX, which uses 2.4 GHz. Both 2.4 and 5 GHz authentication fail at the same time.
The kernel/hostapd logs repeat errors such as:
ath10k_ahb a000000.wifi: failed to wait for created wmi peer ... on vdev 0/1: -110
ath10k_ahb a000000.wifi: failed to add peer ... when adding a new sta: -110
hostapd: Could not add STA to kernel driver
hostapd: did not acknowledge authentication response
nl80211_recv_beacons->nl_recvmsgs failed: -5
The problem recurred after approximately 24 hours with Tortuga2G disabled. After the next hard power cycle, the same ath10k peer-creation errors started again within roughly two minutes and repeated every few seconds. This makes normal RF congestion, an incorrect password, or a single disabled SSID unlikely explanations.
One failing association attempt used MAC prefix 50:8A:06 (Tuya OUI), but this device never obtained a DHCP lease and may simply be a nearby device. Other client MACs also failed, so I am not treating it as the cause.
The DHCP hostname “einstein” has now been positively identified as the Victron Cerbo GX:
- Wi-Fi MAC: 48:E7:DA:86:F4:51
- IP: 192.168.1.108
The Cerbo successfully connected even after the first ath10k errors had appeared. There was a timing correlation between reconnecting it and one later failure, but no evidence that it is the cause; at most it could expose a router driver/firmware defect.
This appears similar to:
- RUTX50 2.4 GHz Wi‑Fi Dropping / Beacons Failing – Possible ath10k Firmware Issue
- Severe Wi-Fi driver crash / simultaneous client disconnections on latest firmware (Layer 2 drop)
Questions:
- Is this ath10k WMI peer timeout (-110) a known issue in RUTX_R_00.07.23.7?
- Is it fixed in RUTX_R_00.07.24.1, or is a downgrade recommended?
- Does the rapid recurrence after a hard power cycle indicate a Wi-Fi hardware fault/RMA case?
- Which additional logs should be captured during the failed state?
I have a RutOS troubleshoot file and Apple Wireless Diagnostics available, but would prefer to provide them privately because they may contain sensitive configuration details.
Thank you.
Update from the current live test:
Immediately after disabling TortugaGuest and applying the configuration, Apple clients could authenticate to Tortuga again without a full router reboot. Save & Apply likely reloads hostapd/the Wi-Fi subsystem, so this does not yet prove that the guest SSID itself is the cause. TortugaGuest and Tortuga2G will remain disabled while the main mixed-band Tortuga SSID is left unchanged, to see whether the failure returns.