Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure

Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure

Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
3 weeks ago
Model: Deco XE75 Pro  
Hardware Version: V3
Firmware Version: 1.3.0 Build 20250721 Rel 8514

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:

  1. The Lua-based client manager crashes (Lua: call failed) for every connected device
  2. TDP communication between nodes fails (tdp_trans_relay error code 01)
  3. The web interface crashes (Error: CGI produced less bytes than expected, Broken pipe)
  4. 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 failed errors 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.

0
0
#1
3 Reply
Re:Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
3 weeks ago - last edited 2 weeks ago

  @Javichu 

Hi,
Thank you very much for your tests and analysis regarding the Deco XE75 Pro. However, based on the information you provided, it's difficult to confirm whether there is a memory leak on the Deco. Generally, client devices with randomized MAC addresses work properly with the Deco XE75 Pro. If you encounter any issues with Deco products, we recommend contacting our technical support team or seeking assistance in the community. We are committed to helping you troubleshoot and resolve any problems as quickly as possible.
 

Regarding the Deco XE75 Pro V3, we have released a new firmware that introduces new features and improves performance. If other users are interested, we encourage you to visit this thread to give it a try.

Best Regards

0
0
#2
Re:Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
2 weeks ago

  @Solla-topee 

Respuesta típica de soporte deflectando. Aquí va una respuesta firme, con datos concretos de tus logs que no puedan ignorar:

Hi David,

Thank you for your reply. With all due respect, I must disagree with the statement that "it's difficult to confirm whether there is a memory leak." My logs provide clear, timestamped evidence of exactly that. Let me share the specific data:

 

Direct evidence of memory exhaustion:

From my system logs on March 7th, the Deco main node logged:

 

memfree less than 10000 KB

 

This is the Deco's own internal alert confirming available RAM dropped below 10 MB. This is not my interpretation — it is the firmware itself reporting critical memory exhaustion.

 

The cascade that follows is fully documented in my logs:

  1. Immediately after the memory warning, every connected client triggers Lua: call failed errors — the client management daemon crashes for all ~35 devices simultaneously
  2. Inter-node communication fails: tdp_trans_relay reports error code 01 for both satellite nodes
  3. The web interface crashes: Error: CGI produced less bytes than expected followed by Broken pipe in uhttpd
  4. Both satellite nodes go red and become unreachable

 

The 802.11k loop IS the cause, and it IS related to randomized MACs:

You state that "client devices with randomized MAC addresses work properly." My logs show otherwise. Here is the exact repeating pattern, logged every 6-9 seconds for hours:

 

nrd: estimatorPerformMeasurement: Do 11k measurement for [MAC] on channel X
nrd: estimatorCmnHandleBeaconReportEvent: Invalid beacon report for [MAC]
nrd: 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 different devices across three different brands:

  • Amazon Fire TV Stick (MAC 20:10:B1:xx:xx:xx) — triggered on 6 GHz, channel 293
  • Apple iPhone (MAC A6:FE:17:xx:xx:xx, randomized) — triggered on 5 GHz, channel 48
  • Samsung Galaxy Tab S10 Ultra (MAC 96:0A:A3:xx:xx:xx, randomized) — triggered on 5 GHz, channel 48
  • Samsung Galaxy phone (MAC D8:A3:5C:xx:xx:xx) — triggered on 5 GHz, channel 40

All four MACs have the locally-administered bit set, confirming they are randomized addresses. The loop runs 24/7 until the device disconnects or the node is rebooted.

 

Controlled test proving the link:

When I disabled the 6 GHz band, the Fire TV loop stopped. The logs went completely clean for 4 consecutive days — zero 802.11k errors, zero memory warnings, zero node failures. On day 6, a different device (the Samsung tablet) triggered the same loop on 5 GHz, memory degraded again, and both satellites went red on day 8. This is reproducible cause and effect, not coincidence.

 

Additionally, I have analyzed logs from another independent user in Spain running a 3-node Deco setup with ~50 IoT devices. Their logs from December 27, 2025 show the identical 802.11k loop on their living room node targeting an Apple device (MAC 74:B0:59:xx:xx:xx) on channel 48, running for 8+ hours continuously with over 8,000 error lines. Their bedroom satellite shows a Samsung device stuck in a connect/disconnect cycle every 10 seconds on 6 GHz. Same bugs, different household, different devices.

 

Regarding the new firmware for V3: my units are XE75Pro (not V3) running firmware 1.3.0 Build 20250721. Is the fix included in that firmware applicable to my hardware revision? If not, when can we expect a firmware update addressing the 802.11k steering loop for the XE75Pro?

I have the complete raw logs available and I am happy to share them with your engineering team if that would help. But the data clearly shows a memory leak caused by the 802.11k band steering daemon failing to handle randomized MAC addresses — which, as you know, are the default on every modern smartphone, tablet, and laptop sold since 2020.

 

Best regards

0
0
#3
Re:Deco XE75 Pro: 802.11k steering loop with random MACs causes memory leak & node failure
2 weeks ago

  @Javichu 

Hi,
The "Bug 1" error you mentioned is triggered by receiving LCP packets during PPPoE dialing and is unrelated to memory. "Bug 2" is caused by Deco periodically sending 802.11k measurements to the connected device, but the device does not respond. This might be due to the client device being far away or not supporting roaming (rather than using a random MAC address), and generally won't cause a drop in Deco's memory. Regarding the "memory leak" phenomenon you report, please send us a complete log file, and I will forward the case to our senior engineers for analysis to confirm the cause of the problem with your client list and Satellite Deco.

 

I'm not sure which hardware version of your Deco XE75 Pro you have, but the firmware in this link can be used on Deco XE75 Pro V2/V3.

Best Regards

0
0
#4