Hello @Joseph-TP 

Thank you for your follow-up. Below are the answers to your numbered questions, now extended with the detailed findings from my long-term testing.

1. DFS usage

I am currently running DFS enabled on the BE800 (channel 112).
In the past I briefly tested DFS disabled, but my long-term setup uses DFS enabled continuously. The issue still appears reliably after 12–96 hours of uptime with DFS on.

During the failure:

- Wi-Fi stays connected

- LAN stays connected

- internal routing and SMB work

- only WAN/Internet forwarding stops on the wireless BE550

This behavior was the same regardless of DFS mode, so at this point DFS does not appear to be the cause, though I cannot fully rule it out without deeper diagnostics.

2. Topology verification

Yes, your diagram almost matches my network:

              PC

                |

ISP → BE800 (main router) → Switch TL-SE1005M (2.5Gbps) → BE550 (wired backhaul – living room) - notebook & TV + (other smaller devices uses WLAN)
                | 
                | → BE550 (wireless backhaul – bedroom) - notebook & TV + (other smaller devices uses WLAN)

I also swapped both BE550 units, swapped their roles (wired ↔ wireless), changed placement, distance, and channels (DFS & non-DFS).
In every test:

- the problem always followed whichever BE550 was used as the wireless backhaul node.

This confirms it is not a hardware defect, not placement, not signal strength, and not environment.
It is specific to wireless EasyMesh backhaul on BE550.

3. Distance and signal environment

The wireless BE550 is approximately two apartment walls away from the BE800.
Signal strength is very good, and moving the device closer does not change the behavior.

Even when positioned one meter from the BE800, the wireless BE550:

- keeps Wi-Fi and LAN fully functional

- still loses only WAN routing after 12–96 hours

- still allows access to the BE800 web interface through the failing node

- still forwards LAN traffic perfectly

Therefore, distance or wall attenuation is not contributing to the issue.

4. When the issue started

The issue has been present since the very first day I started using the BE550 wireless backhaul (back when my setup was only BE500 as the main router + BE550 as the satellite), and it has remained unchanged across every firmware version for over a year — even after replacing the main router with the BE800.

In the beginning I also reported the issue directly with other bugs via email to TP-Link engineering/support, and we exchanged several diagnostic messages.
However, after the introduction and stabilization of Ethernet Backhaul in Satellite mode, as well as the later addition of full WebUI access for satellite nodes, it seems that the wireless backhaul investigation was either deprioritized or abandoned — I did not receive further follow-up or a fix, and the issue continues to behave exactly the same today.

During the failure:

TV on Ethernet → LAN OK, Internet fails

laptop on Ethernet → LAN OK, Internet fails

laptop on Wi-Fi → LAN OK, Internet fails

LED remains normal (no exclamation mark), Tether shows the node as connected, and LAN bridging stays fully functional — confirming that the failure occurs only inside the routing/backhaul forwarding process of the wireless BE550, while the wireless link itself remains stable.

I also found a temporary workaround:
by connecting the wireless BE550 to a Tapo smart plug and scheduling an automatic daily restart, the issue does not appear.
So a daily reboot of the wireless BE550 prevents the failure from happening.

There is also a smaller, separate LED-related bug where LEDs eventually turn themselves back on after being disabled.

This suggests a possible configuration-synchronization issue between BE800 ↔ BE550.

And happen in both Ethernet and wired BE550 satellites nodes.

This behavior is independent of the routing issue but has been consistently reproducible.