I have a Deco X60 (with 3 deco's) for a few weeks, trying with KPN and TP-Link to get this working:

- Using TV from KPN directly from router (Experiabox V12) LAN ports 3 and 4. On this router, LAN-port 2 is a switch with other devices. On router LAN port 1 is the main DECO

- Have the Deco set in AP-mode

- Backhaul via Wifi

- Many times trying to watch TV it's freezing the screen

- Disconnecting the Deco from the router repairs watching TV

- Connecting the Deco freezes screen again

- Disabling (random?) devices from the Wifi Deco repairs TV temporarily

- Thought about multicast, can't find stuff of that on the devices

- Deco support asks weird, unrelated questions or questions of which I already told them the answer (like in what mode the set is working)

- It's not going anywhere, still having issues

Finding this thread got me thinking: Is it possible that the link to the router sometimes is lost for a moment and the Deco starts sending it's own IP addresses in a range that's already occupied by the router (DHCP server)? How can I test that?

btw, this is a regular home situation (in The Netherlands) so don't tell me these consumer products are not for me. True, it's almost Plug-and-play, but then, after a few days impossible to watch TV. Then it took me days of work just to find out what's happening!

Can anyone tell me what IP's are being given out by this 'smart'DHCP? Is it equal to the range of the router? Can it be changed, is Deco using a fixed range (so I can change the router's range) Does Deco start at eg. xxx.xxx.xxx.1? In that case I can change the router's IP range at eg. xxx.xxx.xxx.50 or xxx.xxx.xxx.75 or a complete other IP like 168.192.8.xxx

@pdfowler Can you inform us about the behaviour of the Eero that you ordered? Is it doing what it's suppost for?

@TP-Link 

I have two TV's. But this also goes wrong with one TV connected. 

As told by you the 'out' port of the deco can only be used to connect other decos, not for other hardware, because the deco is already connected with one port to the ethernet. 

@TP-Link , I see in Post #24 the DHCP disable switch will be added to the next .x release (1.6).  Excellent!!!!!! Thanks so much @TP-Link for bearing with us on this one. This is a very important update and I am looking forward to it. I am guessing this .x release will be in the coming 2-3 months?

@Blueman2 lol TP Link bearing with us....

This issue was raised in Feb 2019.

They promised it'd be fixed in 1.6.0 announced in October 2020.

I think we've been more than patient bearing with TP Link.

They don't care about this.

As others say move on to a better product. I'd recommend one, but anything other than TP Link should be better on this front.

I did not realize that actual release (1.6) had been disclosed yet, so was hoping this was new news and indicated impending release.  Yes, it has been way too long of a wait and has cost me many hours of diagnosing and repairing my network.  

@Blueman2 

See post 18 23/10/2020.

https://community.tp-link.com/en/home/forum/topic/222270?page=2

@TP-Link I changed the setting, but it is still giving the same problem. Here a tiny part of the log :

Thu Apr 15 18:00:47 2021 daemon.err nrd[7171]: send ioctl failed

Thu Apr 15 18:01:04 2021 daemon.err uhttpd[3198]: BusyBox v1.22.1 (2021-02-04 11:24:59 CST) multi-call binary.

Thu Apr 15 18:01:04 2021 daemon.err uhttpd[3198]:

Thu Apr 15 18:01:04 2021 daemon.err uhttpd[3198]: Usage: rm [-irf] FILE...

Thu Apr 15 18:01:04 2021 daemon.err uhttpd[3198]:

Thu Apr 15 18:01:04 2021 daemon.err