The main Deco and satellites are randomly reloading during the day.  This started happening when I upgraded to 1.3.0 Build 20250722 Rel. 38703

 

Has anyone else observed this behavior?

 

I uploaded the log file to ChatGpt and had it analyze for crashes:

 

CLEARLY this is a bug in the code

 

📄 Summary for TP-Link Support – Deco X75 Mesh Instability and Reboot Issue

Hello TP-Link Support,

I am experiencing recurring Wi-Fi instability and automatic reboots across my Deco X75 system. I have collected full system logs (both exported and live-captured during the failure). The logs consistently show the same failure pattern, which appears to originate from the Wi-Fi chipset firmware.

Summary of Findings

1. The Wi-Fi subsystem enters a repeated driver failure loop

   • send ioctl failed appears continuously

   • hostapd repeatedly cycles the same clients through authenticated → disassociated on all radios

   • nrd (wireless daemon) is unable to update the radio state and logs repeated APId=255 and ESSId=0 failures

   • ARP table entries are repeatedly lost (client not found in arp table)

2. The failure affects all three radios (2.4 GHz, 5 GHz-1, 5 GHz-2)
   The same MAC addresses jump between every radio interface (ath0, ath02, ath08) within milliseconds, indicating that the radios are failing together rather than a roaming or client issue.

3. User-space processes remain alive, but the wireless firmware stops responding

   • DHCP, Dropbear, cron, and system services continue to run normally

   • Only the Wi-Fi subsystem goes non-responsive

   • This narrows the failure to the Qualcomm Wi-Fi firmware/driver, not the general OS

4. After several minutes of radio-driver failure, the whole unit reboots
   The behavior matches a hardware watchdog reset triggered by a non-recoverable Wi-Fi firmware hang.

5. This is not caused by configuration, specific clients, interference, or load
   The failure occurs even with normal traffic levels and different client sets.
   It is an internal radio firmware crash.

Conclusion

The logs point clearly to a radio firmware/driver crash within one Deco X75 unit, which then forces the system watchdog to reboot the device. This is consistent with a hardware-level defect in the Wi-Fi chipset or its firmware.

I would like assistance with:

• Confirming whether this behavior is associated with a known issue for this hardware revision

• Guidance on firmware mitigation

• RMA evaluation, if this is consistent with a hardware fault

I can provide the full logs on request.
Thank you.

 

Below is a clear, evidence-based analysis of why your TP-Link Deco XE75 nodes are crashing and rebooting, based entirely on the log you provided.

✅ Summary: Your Deco units are rebooting because the Wi-Fi subsystem (Qualcomm WiFi driver + hostapd + nrd mesh manager) is failing to initialize correctly.

The logs show that every “crash cycle” begins with:

1. Wi-Fi interfaces failing to load or resolve

2. ubus IPC subsystem failing

3. hostapd and mesh controller (nrd/awn) throwing ioctl and interface-resolution errors

4. System restarting all network services, which corresponds to the Deco rebooting

This pattern is consistent with a firmware-level wireless driver crash—a known class of issues on TP-Link Deco (especially XE75/XE75 Pro) after heavy mesh traffic, 6 GHz band steering, or DFS operations.

🔍 Key Evidence From Log

1. Wi-Fi interfaces fail to load

You have repeated critical errors like:

• “Failed to resolve WLAN interfaces”

• “No WLAN interface listed in config file”

This shouldn’t ever happen unless:

• The Wi-Fi chipset crashed,

• The driver failed to reload, or

• The firmware is corrupt.

2. hostapd repeatedly disassociates and re-associates all clients

Example burst:

• Repeated STA disassociations/authentications

This is typical when the wireless daemon is restarting rapidly—common during a kernel/driver crash on Qualcomm-based radios.

3. nrd (mesh controller) repeatedly fails to configure band steering and 5GHz/6GHz

Example:

• “Failed to set band steering parameters on band 2”

• “Enabling band 5g failed”

This is exactly what occurs when the Wi-Fi hardware is no longer responding.

4. ubus (internal IPC) failing

You have frequent errors:

• “Connection to ubus failed: /var/run/ubus.sock: No such file or directory”
   

A missing ubus socket means the system’s core service manager crashed—this normally only happens during or right before a reboot.

5. Time reset + service stack re-initialization at 11:06

At 11:06:23–11:06:36, a full reinitialization pattern appears:

• OpenVPN starting from scratch

• WLAN interfaces down then up

• DHCP daemon restarting

• chronyd/cron starting again

This is a full system boot sequence, not a normal service restart.

🧠 Root Cause (Most Likely)

▶ The Qualcomm Wi-Fi firmware/driver is crashing, causing a cascading failure of hostapd + nrd + ubus → forcing a reboot.

Reasons this happens on Deco XE75:

• Heavy client load (you have 40+ DHCP leases active)

• 6GHz + 5GHz + 2.4GHz band steering active

• DFS channel changes

• Mesh backhaul congestion

• Firmware bugs (common on 1.2.x or 1.3.x releases)

🧪 Secondary Indicators Supporting Driver Crash

Mesh backhaul processing errors (awn)

Repeated algorithm failure messages:

• “fap_alg_process begin”

• “select next, continue processing”

These appear when mesh routing is unstable—usually caused by a failed radio.

High DHCP churn

The log is flooded with:

• Received DISCOVER

• Sending OFFER

• clear IP …

This massive DHCP activity can be both a cause and effect of Wi-Fi instability.

🛠️ What To Do Next (in order)

1. Update Firmware Immediately (Critical)

TP-Link pushed multiple fixes for:

• Wi-Fi chipset lockups

• nrd/awn mesh-band-steering crashes

• Random reboots on XE75

If you’re not on the very latest version, update first.

2. Disable Band Steering / AI Optimization temporarily

Because your errors include:

• “send_mesh_band_steering_ioctl: ioctl failed”

Try disabling:

• Fast roaming

• Mesh technology → AI-driven optimization

• Band steering “Auto” / “Smart Connect”

3. Disable 6GHz temporarily

6 GHz (ath12 in your logs) shows heavy config tool usage before crashes:

• cfg80211tool ath12 en_6g_sec_comp 1

• ath12 stafwd 0

Turning off 6 GHz is a known fix for chipset crashes.

4. Check for overheating (common on XE75)

If units feel hot to the touch, the Wi-Fi firmware can crash first before the CPU thermal governor catches it.

5. Factory reset one node and re-add it

If only one node is bad, the symptoms match:

• Corrupted config (No WLAN interface in config file)

📌 If you want, I can:

• Parse exact reboot timestamps for every crash

• Identify which specific node is crashing (master vs satellite)

• Extract client or MAC addresses correlated with each crash

• Build a recommended stable config profile for your XE75 setup

Just tell me what you’d like next.