What's new

Solved UPDATE: No longer required. See thread. - [Feature request] Option for DHCP Query Frequency Backoff Mode

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Anecdotally, in case you guys do decide to try to chase down the WAN bug issues, at one point today, I factory reset the modem (TC4400) while the RT-BE96U was off, then turned on the RT-BE96U after the cable uplink had fully synched on the modem (plus several minutes grace time). The router then reported "Your ISP's DHCP does not function properly" for WAN connection. All I did was disconnect the ethernet cable to the WAN port of the RT-BE96U, waited 3 seconds, reconnected, and magically it restored the WAN connection fine. This is bonkers to troubleshoot.
 
Still waiting on TP-Link router to arrive and will post that testing, but, in the meantime, for those keeping track, today the RT-BE96U showed connected WAN, with an IP address in the 24.x range as expected, but none of the LAN clients (wired or wireless) had Internet access. This is a new failure mode I haven't seen before... Reboot "fixed" it... Until the next random WAN problem...
 
New models Asus routers come with 2-year free beta tester membership. Didn't you know?

Report the issues you encounter to Asus in the Feedback form for a chance to get them fixed by 2026. 🫠

You can report issues to TP-Link as well, but by 2026 your model will be EoL and the one they sell will be h/w revision v10.4 or higher. 🤭
 
Last edited:
For those keeping track, I just swapped in the TP-Link Archer AXE75 AXE5400 model, 1-for-1 for the RT-BE96U, same cables, power source, connection to modem, and I didn't even reboot the modem... and it Just Works™. More testing to do, but for the moment, my theory that the ASUS DHCP WAN stack is fundamentally broken is gaining a lot of steam...
 
Test it for longer period of time, but I'm not surprised. Folks with WAN connection issues often find much cheaper routers work properly.

This specific TP-Link Archer AXE75 has positive feedback and is often recommended by folks with VR sets. Price/performance ratio is excellent.
 
Additional day's worth of usage has revealed the following gem in the log files:
------------------------
2024-02-15 00:51:07 Led Controller INFO [1690] Start to run WAN0_ON

2024-02-15 00:51:06 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 00:51:04 Led Controller INFO [1690] Start to run WAN1_OFF

2024-02-15 00:51:04 Led Controller INFO [1690] Start to run WAN0_OFF

2024-02-15 00:51:04 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 00:43:15 Led Controller INFO [1690] Start to run WAN1_ON

2024-02-15 00:43:15 Led Controller INFO [1690] Start to run WAN0_OFF

2024-02-15 00:43:15 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 00:43:12 Led Controller INFO [1690] Start to run WAN1_OFF

2024-02-15 00:43:12 Led Controller INFO [1690] Start to run WAN0_ON

2024-02-15 00:43:12 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 00:43:10 Led Controller INFO [1690] Start to run WAN1_OFF
-----------------------

So, first, it should be pointed out that TP-Link's log file level is unreasonably low (as in, does not remotely log enough). Folks have complained about this elsewhere. The above series shows brief WAN outages and restores at 00:43:10 to 00:43:16 and later at 00:51:04 to 00:51:07. What actually happened here is WAN link went down, briefly, and router seamlessly reconnected, AS IT SHOULD BE! These same brief outages, as you can see in my other thread, would completely p0rk the ASUS DHCP WAN stack and it would never reconnect. I would have woken up today to internet being "down" and would have had to do a bunch of troubleshooting before my first work meeting. Instead, it Just Worked™.

Of course TP-Link should be slapped on the wrist for only logging LED controller responses for a WAN outage; obviously they should be showing the actual WAN stack actions in the log, but for my use case, this solves my longstanding issue with two generations of ASUS routers' defective DHCP WAN stacks that have made my life and that of my family miserable for years.
 
You lovely Merlin folk are far better connected with the ASUS firmware community. I don't have the sp00ns to fight the necessary battles to try to get ASUS to actually fix this. As was pointed out earlier, it's probably a very old bug from the Tomato era. I'm just going to try to return the RT-BE96U and get as much as my >$1000 back and be happy with the TP-Link. I already have to fight the "an RMA can't fix systemic firmware issues dating back a decade" battle; I can't fight the even harder battle of /actually/ getting ASUS to fix firmware this defective, affecting entire lines of devices.

As was correctly pointed out to me, the ASUS fandom is so strong that my detailed post was completely ignored and the suggested solution was "Put a UPS on your ISP modem", because there's no interest in actually troubleshooting; only brand allegiance. I've been an ASUS networking customer for >10 years, but I can't justify this. I hope the situation isn't the same with motherboards, or I'll be really upset at my next build...

Thank you again for being an awesome community of folks who actually Get It™.
 
These same brief outages, as you can see in my other thread, would completely p0rk the ASUS DHCP WAN stack and it would never reconnect.
Interesting. This is the same "known issue" identified in post #33. It has previously been reported to Asus.
 
Agreed! Modem wan drops are being troubleshooted next. Once I'm absolutely certain the TP-Link AXE75 is stable, I'll swap out the TC4400 modem with the CGA4234DGW TekSavvy has already sent me, to see if it addresses the occasional short WAN drop issues. But, honestly, even if they remain, a few seconds of downtime once or twice a day is manageable if the router automatically reconnects quickly and consistently, which the AXE75 seems to have no trouble with.

Incidentally, logged another ~8 s WAN drop this morning and the AXE75 handled it seamlessly. I didn't even notice (even though I was on a work Webex call during that time) until I went and checked the logs later today:

--------------------------------
2024-02-15 10:15:17 Led Controller INFO [1690] Start to run WAN1_ON

2024-02-15 10:15:17 Led Controller INFO [1690] Start to run WAN0_OFF

2024-02-15 10:15:17 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 10:15:10 Led Controller INFO [1690] Start to run WAN1_OFF

2024-02-15 10:15:10 Led Controller INFO [1690] Start to run WAN0_ON

2024-02-15 10:15:10 Led Controller INFO [1690] Start to run LAN_ON

2024-02-15 10:15:08 Led Controller INFO [1690] Start to run WAN1_OFF

2024-02-15 10:15:08 Led Controller INFO [1690] Start to run WAN0_OFF

2024-02-15 10:15:08 Led Controller INFO [1690] Start to run LAN_ON
-----------------------------------
 
Update: Vendor (B&H Photo) refused to let me return, even though they agreed it was a defect not fixable by RMA, because it was 2 weeks past their 30-day return window, even though it was bought on Dec 23, and shipped from USA to Canada over the holiday period, and extensive testing was required to identify the defect. I'm disappointed. I liked B&H...

I've submitted an RMA with ASUS and asked them to refund me since there's no way they're going to fix this deep a firmware issue anytime soon, so the device is effectively a > $1000 paperweight for me.
 
Test it for longer period of time, but I'm not surprised. Folks with WAN connection issues often find much cheaper routers work properly.

Asus routers should behave "properly" one would think...
 
Asuswrt works fine with Teksavvy, I was with them for nearly 10 years before moving to Ebox and FTTH.
 
Not necessarily an Asus fanboy, and am glad the problem got "solved" (after a fashion) but constant disconnects aren't something I'd have spent 30 days chasing a rabbit over when a squirrel is so obviously the culprit...
 
Interesting. This is the same "known issue" identified in post #33. It has previously been reported to Asus.
I'm sorry; I've been too embarrassed to ask, but I can't find any way to search posts by post number. "post #33" and dozens of variations return nothing useful in the search. Could you please provide the link that you reference, or help this n00b with how to search by post number?
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top