Every Friday around 9:51AM ET, the router drops the WAN connection without any explanation. Here are the relevant entries in the syslog:

2026-05-08 09:50:41 dhcpc[11008]: <4> 210153 send dhcp release ip x.x.x.x
2026-05-08 09:50:41 dhcpc[11008]: <6> 210056 teardown and release
 

Subsequently, the router sends many DHCP discover messages, with flags of 0 or 80, interspersed with the above sequence:

2026-05-08 09:51:22 dhcpc[26066]: <6> 210051 send discover with ip 0.0.0.0 and flags 0
2026-05-08 09:50:58 dhcpc[26066]: <6> 210051 send discover with ip 0.0.0.0 and flags 80

The ISP gets confused with this avalanche of conflicting messages, but several minutes later responds with a DHCP offer, to which the router responds with DHCP select, and the ISP replies with a DHCP ack. At that point, the router initializes its various services, but a couple minutes later the story repeats. Around 10:00AM, the connection instability finally ends. So, there are about 9 minutes every Friday morning when the Internet access is disrupted.

The DHCP lease of WAN IP address is 64872 seconds = 18 hours. Prior to the Friday morning disruption, the router for days successfully renews the lease at 1/2 time = 9 hours and the Internet access is stable for days. The router is configured to reboot automatically early morning every Sunday.

The ISP checked everything on their end and found no problems. This issue occurs in both the older AX11000 and the newer BE800 models (incl. a replacement BE800), all running the latest firmware. So, it is not a hardware problem.

AI has analyzed the syslog and concluded that there must be a service in the router's firmware that disrupts the WAN connection weekly. AI speculates this could be an attempted database / policy sync (even though parental controls are not configured), failed consolidation of traffic statistics, NTP sync conflict, etc. None of those can be solved by user configuration.

TP-Link tech support acknowledges the unexplained WAN IP address release, but blames the ISP for not immediately responding to DHCP discover messsages. Instead of looking into those other processes that could cause the connection teardown and release of WAN IP address, tech support wants to install a special firmware to sniff packets on the WAN interface (a no-go, given security risks).

Has anyone encountered this bug and possibly has a workaround?