Same problem here. No auto sensing. Two satelite mesh devices can only connect via wifi to the main mesh. I have paved dedicated p2p cat6 cables from the main mesh to the two remote one. It will not connect over ethernet. 8mbps wire speed if not close to the main mesh. I'm shocked that people recommended this product. It's useless 

  @TP-Link 
What about a fix release for Deco M5 with HW version v3.0?
My home automation is down for 8 long months, because I was tired of resetting and re-configure my M5 to overcome your bug on daily basis

  @David-TP 

David-TP wrote

  @gilg57 

Hi, the 1.7.1 firmware of Deco M5 has optimized this feature: The WAN Port would not be changed unless the physical connection between the modem and main Deco was broken.

Please check whether you have updated M5 to 1.7.1 already.

 

@Avi1966 

The failure of the Ethernet Backhaul is not related to WAN/LAN auto-sensing.

It would be great if you could start a new thread here to tell us more details, like the model number and network topology so that we could cooperate together to find what was thh problem.

the optimisation you describe is still not correct! it doesn't need 'optimising' it NEEDS FIXING!

When a WAN outage occurs - or when the Modem provider issues a firmware update it is common practice for the Modem/Router to reboot.

When a modem/router reboots it will reinitialise the physical ethernet ports meaning they will appear to physically disconnect and reconnect. During a WAN failure this reboot will not have connection to the Internet (which I assume in this instance means the TP-Link cloud). The reconnect will therefore not be able to provide internet connection (as the WAN failure will remain) and the Deco's will mess up as they always have.

How hard is it to implement this the same way EVERY other manufacturer does it? Provide a configuration option to select and fix the outbound connection port. Use the code from OpenWRT if you don't have coders capable of writing this yourselves - it's really basic, actually - use the mesh code from there as well instead of your own.

Please stop -reinventing the wheel and STOP trying to force cloud services where there is no benefit to the customer (in this instance only a real detriment).

  @TP-Link 

I've just done a search (as I needed to change the email address on my tplink account) for this topic and cannot believe how many people have raised this issue.

hardwiring things like home automation and NAS servers to act as sources for streaming is commonplace - and the Deco firmware screwing around with the ethernet ports is totaly unacceptable.

I see that firmware 1.7.1 has 'optimized' the behavior. I don't believe it needs optimizing, it needs fixing as per every other router firmware around - and I can't see a setting in the 1.7.1 to control this function. 

So - please can you describe the 'optimized' behaviour for us. What previous versions did was not correct or acceptable and what we all want is to be able to nominate the WAN port(s) (the plural is for anyone with a 4g/5g backup connection). That and for the physical ports to WORK without a connection to a TP-Link cloud service or other WAN connection. 

So - please tell us what this firmware now does? (P.S. the annoucement link does not describe the new behaviour!)

  @TP-Link  This is unacceptable for such an expensive product. I have two x50 units, and whenever I lose the internet they mess up everything, they also reenabled their own DHCP and giving the same IPs as the rest of my home.
Also every time i have no internet all my IoT devices (wifi lights, wifi switches etc) cannot connect to my LOCAL server and i can't even switch on or off my own lights!!!!! This is ridiculous!!!

edit:
Is it that hard to put a third Operation Mode that just bridges all ethernet ports and wifi?
Deco shouldn't have to know if it has internet connectivity or not. Just bridge all ports, find the other units to make the mesh wifi, and let the rest of the network work on its own without any meddling!!!