WAN Reconnect Problems Across ASUS Routers / Firmware Versions

[mekki]

Problem description: ASUS router sometimes does not attempt to reconnect WAN connection (or silently fails--nothing in log files) after outage even after modem comes back up.

Steps to reproduce: Intermittent, so inconsistent. Disconnect modem and reconnect (unclear if manual modem disconnect can trigger same way as actual brief upstream last mile outage). Router will not attempt to reconnect WAN (or silently fails--nothing in log files) even after modem has recovered and is back up.

Observed behaviour: Router intermittently doesn't reconnect WAN after modem outage.

Expected behaviour: When modem comes back up, router will reconnect WAN consistently, automatically, regardless of how long modem was down.

Workarounds:

• Most often: Logging into router and just hitting "apply" in WAN settings leads to successful (manual) WAN reconnection.
• Less often: Occasionally, router reboot is required for WAN reconnection.
• Much less often: Power cycling of just modem leads to WAN reconnection. The vast majority of the time this has no effect and manual router config apply/reboot is required.
• Rarely: Power cycling of both modem and router required for WAN reconnection.
• Extremely rarely (only seen once, with RT-AC3100): Laptop direct ethernet connection to modem could get WAN IP, but router could not with any combination of above workarounds. Required factory reset of router to get WAN reconnection: Strong evidence for ASUS firmware issue.

Needless to explain that having to do any of these workarounds manually on a regular basis when living in a place where ISP last mile infrastructure is shirtty, is extremely problematic. During the good times, I only have to manually restore WAN connection 3-4 times per week. On bad days (like today, where I finally got off my butt to submit this post), it could be 10+ times per day, with each outage being only a few seconds. That's why it's crucial that it be automatic.

Affected ASUS routers: I can confirm the issue on 3 ASUS routers over the past many years and all of the official ASUS firmware releases throughout their life (yes, I tried them ALL), including the 3rd party WRTMerlin firmware (so problem must be part of upstream base firmware) but probably more routers affected than the 3 I've seen this on: RT-AC68U, RT-AC3100, RT-BE96U (currently seeing this on 3.0.0.6.102_32882).

Troubleshooting attempted:

• Tried different DHCP query frequencies (Normal, Aggressive, Continuous): Normal MAY work slightly better, but still inconsistently doesn't reconnect WAN with Normal, though POSSIBLY less frequently than Aggressive/Continuous (very hard to measure with inherent inconsistency).
• Tried using daily automatic router reboot schedule in case there was some sort of buffer/memory issue: No effect. (By which I mean, if there was an outage that happened to happen before the schedule reboot, the scheduled reboot WOULD address it just like a regular reboot mentioned above, but it had no effect on consistent WAN reconnections for outages at other times.
• Tried range of TTL, MTU settings: No effect.
• Tried pretty much every firmware version for above devices including WRTMerlin versions: Given inconsistent nature of problem, very hard to tell if it's more or less frequent across some firmware versions than others. My gut says "maybe", but it's a very maybe maybe. No firmware version permanently solved the issue; that's for sure. Some MAY have reduced frequency of problem, but not enough that I noted it.
• Periodic factory resets: Aside from very rare instance mentioned above, generally had no effect. I usually did a factory reset when upgrading firmware anyways.
• DSL via PPPoE: I've tested the WAN connections via PPPoE on a vDSL service (Bell) with a modem in passthrough mode (e.g. Sagemcom 2864) and the issue does NOT occur: PPPoE WAN connections reconnect automatically after vDSL modem outages without issue, consistently. The described problem is only related to DHCP WAN connections (e.g. cable).
• Disabling IPv6 everywhere: No effect.
• Replacing cables: While I can think of no reason why a cable could be responsible for a lack of WAN reconnect given that when the connection is up the router achieves advertised speeds (1000 Mbps down / 50 Mbps up) with zero packet loss, nevertheless, for sake of completeness, I have replaced every combination of cable, with CAT 5e, CAT 6, CAT 6 shielded, both store bought and cut, crimped, and tested myself, with no effect on WAN reconnect problems.

Speculation: May be related to the "Your ISP's DHCP Does Not Function Properly" issue that has been frequently reported in other threads. I have, even more inconsistently, and only with the RT-AC3100, seen this error. Most of the time there's just "WAN Connection: WAN was exceptionally disconnected." in the log file, and no attempt to restore the WAN after that. These could be totally unrelated things.

Further speculation: My ISP thinks that it could be related to an upstream DHCP server punishing DHCP requests that are done too quickly when it doesn't recognize that its own last mile connection went down so thinks the router is trying to request a 2nd IP before the first times out. The suggested solution was to change the DHCP Query Frequency to even less than "Normal", with infinite retries that double the delay between retries each time. I've submitted a request to ASUS to see if it's possible to add this "Backoff" mode DHCP Query Frequency, and have asked the same of our ASUSWRT-Merlin friends (https://www.snbforums.com/threads/f...hcp-query-frequency-backoff-mode.88788/page-2) but folks elsewhere have suggested this backoff mode DHCP query frequency won't address the underlying issue and that it's potentially a broader firmware problem related to how ASUS devices handle WAN connections (I've seen some mention of "wanduck" issues--Unsure if related)

Yet further speculation: It's been suggested that the problem is in the ISP-mandated-and-locked-down-modem's firmware, possibly related to its passthrough mode. If that's the case, it's not clear why the router doesn't try to reconnect the WAN automatically or is unsuccessful doing so, but a manual reconnect attempt works. If it were a modem firmware problem, one would expect the manual reconnect to fail as well. If someone has a theory as to why the router's automatic WAN reconnect would not happen but a manual one would and how the modem's firmware is responsible, please share it!

Current setup (Have had same issue with other setups in the past): 1 Gbps cable connection with Teksavvy (Toronto - via Rogers last mile infrastructure, upgraded in my area in 2018) -> Technicolor TC4400 DOCSYS 3.1 modem (Rev 2, Firmware Version 70.13.43-190628-D D3.1 2x2 D3.0 32x8: Latest officially supported version, locked down and controlled by Rogers for updates) in (officially supported/configured by ISP) passthrough mode -> Single ethernet connection (TC4400 has two ethernet ports but it's known that only one can be used) to RT-BE96U (3.0.0.6.102_32882) 1 Gbps WAN port (have tried on 10 Gbps WAN port: no difference).

Note: I'm NOT trying to troubleshoot the modem outages. That's a different problem not suitable to this forum. I'm trying to sort out why once a given outage resolves, the ASUS router doesn't reconnect to WAN automatically and requires a manual WAN reconnection; and, why this behaviour persists across generations of ASUS routers and firmware.

This issue has been ruining my work-from-home productivity and enjoyment of internet-related hobbies and those of my family for a very, very long time. I beg your kind help, and, should I prove to be a n00b, your patience if I missed something obvious. Thanks! ^_^

 

[OzarkEdge]

Needless to explain that having to do any of these workarounds manually on a regular basis when living in a place where ISP last mile infrastructure is shirtty, is extremely problematic.

Have you tried using the ISP router, double-natted if necessary... does it recover automatically from this frequent ISP trouble?

Is the ISP coax shield properly grounded to the building Earth ground? Are the coax connections at the demarc in good repair? Does the ISP coax connect directly and only to the modem, or is a bunch of building coax bits in play?

Is the modem etc. on a UPS to ensure sufficient and reliable power?

Have you had the ISP modem and gateway box replaced?

OE

 

[mekki]

Thanks for your reply. While I very much appreciate your attempts to diagnose the modem dropping, that's not my goal in this thread. I'll sort that out with my ISP.

With regards to the ISP modem, The Technicolor TC4400 is modem only with no router capabilities (only passthrough), so there's no option to do that. Swapping the device with a modem+router and then setting up double-NAT or DMZ is not something I've tried, no. But even if it did work, it doesn't explain the causes of the above scenario with ASUS routers failing to reconnect to WAN connections once they're back up.

For completeness sake:

- ISP coax shield properly grounded to the building earth ground: Yes.
- Coax connections at the demarc in good repair: Yes.
- Directly and only to the modem: Yes.
- UPS: No. Power fluctuations could theoretically explain the drops, but not the above WAN reconnection issues. I might add a UPS for kicks.
- ISP modem replaced: No. Again, not clear how replacing ISP modem would affect ASUS router's WAN reconnect issues.
- Gateway box: None.

 

[OzarkEdge]

Thanks for your reply. While I very much appreciate your attempts to diagnose the modem dropping, that's not my goal in this thread. I'll sort that out with my ISP.

I would get the ISP service fixed/confirmed ok before hanging my network on it. Seriously, how many routers and firmware must you suspect first? If the ISP equipment/router can't hold up a reliable WAN connection, you should insist they come and fix it. Rent their equipment for a month if you have to... beats living with crappy WAN service for years.

But even if it did work, it doesn't explain the causes of the above scenario with ASUS routers failing to reconnect to WAN connections once they're back up.

The intent is to establish the ISP as responsible for fixing their service/equipment.

I'd be careful making too many soft assumptions and conclusions and ruling things out prematurely... this approach to troubleshoooting, no matter how analytical, can lead you away from the problem... or have you trying to engineer a solution to a problem you may not have.

- UPS: No. Power fluctuations could theoretically explain the drops, but not the above WAN reconnection issues. I might add a UPS for kicks.

Like here... bad power can cause trouble you may not expect. Don't talk yourself out of trying things. Add a UPS for clean, reliable power to protect data and hardware... not for kicks.

- ISP modem replaced: No. Again, not clear how replacing ISP modem would affect ASUS router's WAN reconnect issues.

And here... how many routers have you tried over a "very very long time" while insisting nothing could possibly be wrong with the ISP's modem and "shirtty" infrastructure? I would have insisted on a modem swap/upgrade long ago. No network admin should allow their users to suffer WAN connection issues any longer than it takes to fix the problem asap.

I'm not familiar with cable modems having a passthrough mode. If it's a modem only, I wonder what is left to bypass... and have you used it not in passthrough mode? Every cable modem I've used has been plug and play with nothing to configure by the customer.

I've used cable modems with ASUS routers since the RT-N66U at multiple locations/ISPs and have not suffered any WAN connection trouble other than the usual service outages at large. Given this and your negative assessment of your cable service, I would get the ISP service fixed/reliable first and then troubleshoot from there... not consider it a separate/unrelated issue just because.

OE

 

[bennor]

During your troubleshooting steps did you try removing the router and connect a PC with a locked down firewall directly to the TC4400/Teksavvy equipment and see if the issue persists?

Seems like its a problem with the TC4400 and certain routers. One suggestion at the following link is that it may be a "modem issue" and to contact Teksavvy via their community discussion board.

https://www.reddit.com/r/teksavvy/comments/n8cjxw

level 1
TSI-Emmanuella
·3 yr. ago TSI-Agent
Hello, sorry for the issues you are currently experiencing on your end! It may be a modem issue, however, it would also be best to verify the signal levels to make sure there are no issues on the line. To better assist you, we will need to verify your account info; please send us a private message with your account info in the TekSavvy community forum by clicking on the "need support" option https://community.teksavvy.com/discussions.

On a side note. Using a different ISP provider I ran into intermittent issue with WAN disconnection problems with an Asus router using DSL. Thought it was the Asus router's fault, turned out it was a bad DSL card upstream. Took a number of calls to the ISP to get it fixed. Similarly the Asus router log didn't indicate any issues other than the WAN connection being lost and later restored. Start by having the ISP check the modem signal levels and things on their side first before spending hours trying to diagnose the router or it's settings.

And not sure how many ISP's these days still use the MAC address of the client side equipment as a method of identifying one's account and preventing other equipment from using the service. But cloning the MAC address of the intial router or PC used when the service was first activated to the Asus router should be tried to see if it has any effect.

 

[Techtype]

- UPS: No. Power fluctuations could theoretically explain the drops, but not the above WAN reconnection issues. I might add a UPS for kicks.

OzarkEdge​

Like here... bad power can cause trouble you may not expect. Don't talk yourself out of trying things. Add a UPS for clean, reliable power to protect data and hardware... not for kicks.

 

[dave14305]

Do you have the additional Network Monitoring options enabled (DNS, Ping) on the WAN -> Dual WAN page? Might help the router detect a short or subtle outage better, and react accordingly.

 

[brummygit]

I found this thread whilst researching problematic WAN reconnections after failures. I only started to see these recently after moving to fibre broadband with a new ISP on connecting via an ONT - I've previously been in a double NAT situation.

I'm not technical enough to work through this on my own but also found the following - I wonder if there's a link to the troubleshooting and fix developed by @Lynx :

Problem: udhcpc does not deconfig upon WAN cable disconnect

I have just identified that: 7252 admin 3492 S /sbin/udhcpc -i eth0 -p /var/run/udhcpc0.pid -s /tmp/udhcpc -t1 -T5 -A0 -O33 -O249 does not renew upon a physical WAN cable disconnect and reconnect. See here...

www.snbforums.com

Router not getting internet back after WAN drop

ChkWAN helped on my end as well! I'm using it for several days and I immediately noticed results. I had issue where 70-80% of WAN IP renewals got stuck, but somehow other 20-30% was successful. After multiple firmwares, 2 months of testing, I finally stopped checking network logs etc... I'm...

www.snbforums.com

maintain-wan-lease/maintain-wan-lease at master · lynxthecat/maintain-wan-lease

Resolve problem with Asus Merlin routers in terms of release/renew of udhcpc. - lynxthecat/maintain-wan-lease

github.com

 

[Tech9]

I only started to see these recently

Interesting. Someone identified and tried to solve the same issue years ago.

Asus guys may need to search GitHub from time to time. Does the script solve the issue?

 

[brummygit]

Interesting. Someone identified and tried to solve the same issue years ago.

Asus guys may need to search GitHub from time to time. Does the script solve the issue?

I'm temporarily running the latest Asus stock firmware (haven't updated my signature) as I was trying to compare the behaviour, so haven't been able to try this fix.

If it really is so clear cut I wonder if RMerlin could include a fix in his code.

 

[brummygit]

I bought myself some hardware and built an Opnsense firewall/router. Using this for routing and connectivity to my primary fibre ONT and secondary 5G backup router, with my Asus devices in AP mode i can confirm everything is now stabilised. It certainly seems to be an Asus issue, but my fix isn't for someone who doesn't understand firewalls.