Deco X1500 – Recurrent Wi-Fi stack failure, logs show Realtek driver issues
Hello everyone,
I’m sharing a long-term stability issue I’ve been troubleshooting for several weeks with TP-Link Deco X1500, hoping to confirm whether this is a known firmware/driver problem and whether a fix exists.
Environment
Model: Deco X1500 (2 units)
Firmware: 1.3.0 Build 20250725 Rel. 54254 (Latest available via Deco app)
Operation Mode: Access Point (no routing, no NAT)
Backhaul: Wired Ethernet
Switch was tested and later removed (APs directly connected)
Mesh per-client: disabled for every device
Fast roaming: disabled
Beamforming: disabled
OFDAM/MU-MIMO: disabled
Clients: ~45 devices (phones, PCs, IoT, cameras, media devices)
Symptoms
Network is stable for hours or days, then suddenly:
Wi-Fi becomes unstable
Some clients disconnect and reconnect
IoT devices (especially 2.4 GHz cameras) fail to reconnect at all
One AP occasionally showed solid red LED
Web UI remains accessible and logs can still be downloaded
Reboot temporarily fixes the issue, but it always returns (auto reboot scheduled 04:00 every day)
Key log patterns (repeated across many days)
The logs consistently show:
Realtek driver errors:
rtk_get_vap_status: cfg80211 return -19
Wi-Fi stack resets without system reboot:
wifi reload
Restarting network stack
AP sync timer expires
hostapd losing control:
wpa_ctrl_open fail
hostapd_update_tpie: send vendor_elements fail
Important detail:
There is no kernel panic
The device is not fully crashed
The Wi-Fi stack appears to enter a deadlock / corrupted state
Based on behavior and logs, this looks like:
A firmware / Realtek Wi-Fi driver stability issue
Triggered by client density, IoT traffic, or sustained load
Causing partial Wi-Fi stack failures where some clients never recover
Questions for TP-Link / community
Is this a known issue with Deco X1500?
Is there a newer or beta firmware that addresses:
cfg80211 return -19
Wi-Fi stack reload loops without reboot?
What are recommended settings?
Please, assist in this issue. I can provide DEBUG-level logs showing multiple occurrences of this behavior.
Thanks!
