For some reason the forum filters will not allow me to post the startup errors, claiming that standard Linux directories are not permitted. I'll keep trying..

CRITICAL FIRMWARE BUGS IDENTIFIED IN BOOT LOG:

1. Script Syntax Error in Boot Sequence:
**removed for filters**: /etc/rc.d/S48luarsa_keys_gen: line 10: syntax error: unexpected "}"
/bin/sh: can't open **removed for filters

2. Missing Hardware Calibration Directory:
ln: /lib/firmware/qcn9100/caldata_1.bin: No such file or directory
ln: /lib/firmware/qcn9100/caldata_2.bin: No such file or directory

3. Infinitely Loop-Crashing Daemon (Causes RAM Exhaustion / Memory Leak):
IMPROXY: FATAL[init_interface@251]: exiting..... (Repeating constantly every 5 seconds)

So following a reboot, the logs are again filling with the element type is not option:3 error

This log segment is incredible because it shows the exact moment the router's brain fractured right before the Sonos loop took over.

Here is the anatomy of the crash at 12:05:36, broken down by what went wrong:

Phase 1: The Band Steering Crash (nrd daemon)

The log starts with absolute chaos from a background system called nrd (Network Resource Daemon). This is the piece of TP-Link’s software responsible for Mesh roaming and Band Steering (forcing devices to smoothly switch between 2.4GHz and 5GHz, or transition between your two Deco units).

Plaintext

nrd[15895]: stadbUpdateLinkPriorityBlackList: Failed to update black list.
nrd[15895]: send cmd: 35820 ioctl failed

• What happened: The router tried to update its "blacklist" (a temporary internal list of which devices should be blocked from a specific node or frequency to force them to roam to a better one).

• The failure: The command failed completely (ioctl failed). It tried to run it dozens of times in the exact same second, spamming the log.

Phase 2: The Core Network Driver Unravels (12:06:12)

A few seconds later, the driver completely lost contact with the physical Wi-Fi chips:

Plaintext

nrd[30979]: send_mesh_band_steering_ioctl: ioctl failed, cmd: 45
nrd[30979]: qca_get_phy_cap_info: get phy cap info failed

The router asked its internal Qualcomm network driver (qca) for the physical capabilities of the Wi-Fi hardware, and the driver responded with an error. The router’s mesh steering software essentially lost its map of the hardware.

Phase 3: The Mass Disconnect and the Sonos Loop Start (12:06:45)

Because the mesh steering software completely crashed, the router panicked and forcefully dropped multiple devices to try and clear the airwaves. Look at this rapid-fire cascade at 12:06:46:

• Device 38-42-0B-86-63-D4 -> Disassociated

• Device 48-A6-B8-DF-45-D0 -> Disassociated

• Device 70-70-AA-20-A2-C2 -> Disassociated

• Your Sonos Speaker (34-7E-5C-40-08-DC) -> Disassociated

• Device 34-7E-5C-40-05-30 (Another Sonos component nearby!) -> Disassociated

The moment the network collapsed, every single device tried to instantly reconnect at once.

At 12:07:04, your Sonos Right Speaker (08:DC) successfully reconnected (client_action:associate). And the literal exact same second it rejoined the broken network stack, the loop locked into place:

Plaintext

Fri Jul 17 12:07:04 2026 daemon.err client_mgmt: element type is not option:3
Fri Jul 17 12:07:20 2026 daemon.err client_mgmt: element type is not option:3
Fri Jul 17 12:07:36 2026 daemon.err client_mgmt: element type is not option:3

The Takeaway

This tells us that the option:3 loop isn't what causes the initial network drop.

Instead, TP-Link's mesh roaming software (nrd) crashes first because it fails to update its hardware routing tables. Once that crashes and the wireless radios reset, the Sonos speaker reconnects, floods the already-broken router code with its heavy sync traffic, and traps the router in that infinite option:3 memory leak.

This is gold-standard troubleshooting data. If you send this entire block to TP-Link support, they can't blame your house, your walls, or your setup. Their internal roaming daemon is failing a basic system call (ioctl), which is a 100% pure firmware bug.

  @rhbmcse Sadly, this is the game. Announce and release a bleeding edge hardware at a cheap price. The catch, released with half the features missing and lots and lots of bugs, that may or may not ever get fixed. Tiny team working with very old code.  Option 2, pay 5 x as much for ubi** or similar, and get a product that just stays working for years at a time without a reboot. The former appears to be TPlinks business model (and many similar others). Most are found at the low end of pricing. It's commonplace now, not just with PC componments, but many tech related products. Yes - It's as annoying as hell. There are so many deco hardwares now - It's kind of ridiculous.

  @HelpFixDecoApp 

I know not whether you are a TP-LINK employee.  Irrespectively, and this is not directed at you, rather at TP-LINK as a company.  I didn't buy an upgrade from my X50 to the XE75 pro to become a beta tester, and looking at the amount of problems that people are having with that particular firmware, I wouldn't want to upgrade anyway.

I have a home filled with IOT devices, as many people do these days.  There is an expectation that when you buy a pair of DECOs, purely to act as APs and nothing more, that they will just work.  The fact that one cannot get what is surely one of the most commonplace wireless devices to work (PS5) with a XE75pro wirelessly, I feel is quite embarrassing for TP LINK.

I don't want to spend hours on forums trying to get my network devices working, applying beta fixes etc.  I just want them, and expect them to work.  It is not my responsibility to continuously upload logs and tell TP LINK what they should already know.

Obscure devices, could be forgiven for not workig or playing well with a WIFI system.  SONOS systems and PS5s are really inexusible.

I made an error in buying another TP-LINK system.  I should have gone with another company but was pulled in by the cheap pricing and high hardware specs.  That was my mistake for which I take full responsibility.  It is not a mistake I will make again.  I can only hope that TP-LINK get their act together and finally give  us a firmware that works, without sloppy typos (unforgiveable) and missing files.  

Very poor, TP-LINK.

  @Solla-topee 

Yes my Deco firmware is exactly the one that you mentioned below. It is fully up to date there are no more updates available. 

I have two Deco nodes one master which is connected to my router. 

The router is handling DHCP not the decos. 

Connectivity between the two decores relies on a combination of 2.4 gigahertz 5 gigahertz and 6 gigahertz wireless back hole as there is no option in my apartment to run a cable between the two units. 

Connection between the two units reports as three bars - full - with the occasional fall back to two having said that I have a 900 megabits per second internet connection and either Deco node will do that comfortably. 

The deco's will stay up for a random amount of time there is no specific time lapse before the satellite deco which is in the living room will go red. At this point the satellite deco loses connectivity to the primary Deco connected to the router. It appears that the log is getting filled by the repeated same error which over time causes the secondary Deco to fall over at random. 

I can happily provide logs but what I will say is that they don't make happy Reading. There are continuous errors from multiple devices that are not happy even though every single function is disabled every device has mesh networking disabled and the network itself has beamforning and seamless roaming disabled. 

I will send logs over next time it falls over.  Sometimes it recovers but it's only a matter of time before then it goes solid red and loses its connection altogether. 

It would have been really nice to be able to collect logs without having to go into the web interface given that the entire ecosystem is basically managed by your mobile phone. 

@Solla-topee

Logs just sent.

Apologies - Had not realised that this could be done from the app.