Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
Hi everyone,
I want to share my findings on this issue after conducting an extensive log analysis over several weeks on my Deco XE75 Pro (3-pack). My setup: Movistar (Spain) fiber via ONT, PPPoE, 3 nodes connected via Ethernet backhaul, approximately 35 devices including IoT (smart appliances, cameras, robot vacuum, smart plugs, solar inverter DTUs).
I used Claude AI to systematically analyze several weeks of raw system logs, and the results reveal not one but three interconnected firmware bugs that together make the XE75 Pro unstable for any modern home network.
Bug 1: PPPoE parser — pppd: len < 0 (same as this thread)
Confirmed on my system: the error appears every ~10 seconds, 24/7, without interruption. MTU is set to 1480 (well below the 1492 PPPoE maximum). Tested with new Cat6 cables. The error persists regardless of network load. It is a firmware bug in the PPPoE packet parser — it calculates a negative payload length, likely when processing LCP echo requests or keepalive packets. On its own it doesn't crash the connection, but it generates constant CPU load and log I/O that contributes to memory exhaustion over time.
Bug 2: 802.11k band steering infinite loop — THE CRITICAL ONE
This is the bug that actually kills the network. The band steering daemon (nrd) attempts 802.11k measurements on connected devices. When a device uses a private/randomized MAC address (the default on every modern iPhone, Android, and Windows device since 2020), the Deco fails to process the beacon report correctly and enters an infinite retry loop — one measurement attempt every 6-9 seconds, 24/7, for as long as the device remains connected.
Log signature:
estimatorPerformMeasurement: Do 11k measurement for [MAC] on channel X
estimatorCmnHandleBeaconReportEvent: Invalid beacon report for [MAC]
wlanifBSteerEventsHandleBeaconReport: Can't find local reported BSS on band of channel 0 for BSS 00:00:00:00:00:00
I reproduced this with four completely different devices: Amazon Fire TV Stick (6 GHz band), Apple iPhone (5 GHz band), Samsung Galaxy Tab S10 Ultra (5 GHz band), and Samsung Galaxy phone (5 GHz band). All triggered the same loop. The common factor is randomized MAC addresses. When I disabled MAC randomization on a device, the 802.11k measurement completed successfully.
This bug affects ALL bands — I initially thought disabling 6 GHz would fix it (and it did remove the Fire TV loop), but a different device triggered the same loop on 5 GHz within days. You cannot disable 5 GHz, so there is no workaround other than disabling MAC randomization on every single client device, which is impractical.
Bug 3: Memory leak leading to node failure
The combination of Bug 1 (constant PPPoE errors) and Bug 2 (802.11k infinite loop) progressively consumes RAM until the system reaches a critical threshold. My logs show:
memfree less than 10000 KB
Once memory drops below ~10 MB, a cascade failure occurs:
- The Lua-based client manager crashes (
Lua: call failed) for every connected device - TDP communication between nodes fails (
tdp_trans_relay error code 01) - The web interface crashes (
Error: CGI produced less bytes than expected,Broken pipe) - Satellite nodes lose connection and go RED
After a reboot, the system runs clean for 4-5 days, then degrades progressively until nodes go red again around day 6-7.
Timeline of my testing:
- Day 1: Analyzed logs, identified 802.11k loop on Fire TV via 6 GHz. Disabled 6 GHz band.
- Days 2-4: Logs completely clean. No 802.11k errors, no memory issues, no red nodes.
- Day 6:
Lua: call failederrors return, TDP errors appear. Memory degradation begins again. - Day 8: New device (Samsung Tab S10) triggers 802.11k loop on 5 GHz. Both satellite nodes go red.
- Subsequent weeks: Multiple devices trigger the loop. The problem is systemic and unfixable from the user side.
This bug is not new. I found identical reports on this community forum dating back to 2021 affecting Deco M4, M5, X20, X55, X75, and XE75 models. Five years, same bug, no fix.
My conclusion:
The Deco XE75 Pro is fundamentally incompatible with modern devices that use MAC randomization — which is every smartphone, tablet, and laptop sold in the last 5 years. The product is advertised for up to 200 connected devices but fails with just 35. I am returning my 3-pack to Amazon as the product does not meet its advertised specifications.
I hope this detailed analysis helps TP-Link finally address these issues, and helps other users in this thread understand what is happening to their networks.
Note: my model (XE75Pro) runs a completely different firmware branch (1.3.0) than the XE75 V1.0 units reported in other threads (1.4.3). The fact that the same bugs are present across different models and firmware versions confirms this is a systemic platform-level issue in the Deco firmware, not specific to any single hardware revision.
