Posted: Wed Mar 09, 2022 15:02 Post subject: [SOLVED] Asus RT-AC66U Crashing
Hello all,
I have been using DD-WRT with my Asus RT-AC66U for a number of years now and have been very content. My router has had rock solid performance without major issues, up until a few weeks/months ago. I noticed that my router would occasionally conk out without any warning and then come back online a few minutes later. I upgraded the firmware to a more recent version a week or so ago hoping that would fix the issue but the issue still persists. I am not sure if it is a resources problem or a temperature problem.
So here is the relevant information first -
Asus RT-AC66U
DD-WRT v3.0-r48432 giga (03/01/22)
Router/AP
I have Pi-Hole configured to act as my Ad-Block and DHCP provider. I also have DDNS configured to work my with Pi so it can act as a VPN server for remote connections. Lastly, I do have some routing tables added for an L3 Cisco switch I have, but I can't imagine that would be causing this issue.
Here is an output of my syslog:
Code:
Mar 9 09:25:15 DD-WRT daemon.info ntpclient[2040]: Time set from 2.pool.ntp.org [45.15.168.198].
Mar 9 09:25:15 DD-WRT daemon.info process_monitor[2038]: cyclic NTP Update success (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
Mar 9 09:25:15 DD-WRT user.info : [sfe] : shortcut forwarding engine successfully stopped
Mar 9 09:25:16 DD-WRT user.info : [sfe] : shortcut forwarding engine successfully started
Mar 9 09:25:16 DD-WRT user.info : [nas] : wait for network init
Mar 9 09:25:16 DD-WRT user.info : [sfe] : shortcut forwarding engine successfully stopped
Mar 9 09:25:17 DD-WRT user.info root: WireGuard number of non failed tunnels in fail set: 0
Mar 9 09:25:18 DD-WRT user.info : [vpn modules] : vpn modules successfully unloaded
Mar 9 09:25:18 DD-WRT user.info : [vpn modules] : nf_conntrack_proto_gre successfully loaded
Mar 9 09:25:18 DD-WRT user.info : [vpn modules] : nf_nat_proto_gre successfully loaded
Mar 9 09:25:18 DD-WRT user.info : [vpn modules] : nf_conntrack_pptp successfully loaded
Mar 9 09:25:18 DD-WRT user.info : [vpn modules] : nf_nat_pptp successfully loaded
Mar 9 09:25:20 DD-WRT user.info : [sfe] : shortcut forwarding engine successfully started
Mar 9 09:25:21 DD-WRT user.info : [sfe] : shortcut forwarding engine successfully started
Mar 9 09:25:21 DD-WRT daemon.debug process_monitor[2038]: Restarting cron (time sync change)
Mar 9 09:25:21 DD-WRT user.info : [cron] : daemon successfully stopped
Mar 9 09:25:21 DD-WRT user.info : [cron] : daemon successfully started
Mar 9 09:25:21 DD-WRT cron.info cron[2461]: (CRON) STARTUP (fork ok)
Mar 9 09:25:21 DD-WRT user.info : [process_monitor] : daemon successfully stopped
Mar 9 09:25:21 DD-WRT daemon.info process_monitor[2038]: [process_monitor] : cleanup timers
Mar 9 09:25:22 DD-WRT user.info : [process_monitor] : successfully started
Mar 9 09:25:22 DD-WRT daemon.debug process_monitor[2466]: We need to re-update after 3600 seconds
Mar 9 09:25:22 DD-WRT daemon.info process_monitor[2466]: [process_monitor] : set timer: 3600 seconds, callback: ntp_main()
Mar 9 09:25:23 DD-WRT user.debug : ttraff: data collection started
Mar 9 09:25:24 DD-WRT user.info : [dropbear] : ssh daemon successfully started
Mar 9 09:25:24 DD-WRT authpriv.info dropbear[2471]: Running in background
Mar 9 09:25:24 DD-WRT user.info : [httpd] : https daemon successfully started
Mar 9 09:25:26 DD-WRT user.info : [nas] : start nas lan
Mar 9 09:25:26 DD-WRT user.info : [nas] : start nas for wl0
Mar 9 09:25:26 DD-WRT user.info : [nas] : NAS lan (wl0 interface) successfully started
Mar 9 09:25:26 DD-WRT user.info : [nas] : start nas lan
Mar 9 09:25:26 DD-WRT user.info : [nas] : start nas for wl1
Mar 9 09:25:26 DD-WRT user.info : [nas] : NAS lan (wl1 interface) successfully started
Mar 9 09:25:28 DD-WRT user.info : [nas] : daemon successfully stopped
Mar 9 09:25:30 DD-WRT user.info : [nas] : daemon hanging, send SIGKILL
Mar 9 09:25:30 DD-WRT user.info : [nas] : start nas lan
Mar 9 09:25:30 DD-WRT user.info : [nas] : start nas for wl0
Mar 9 09:25:30 DD-WRT user.info : [nas] : NAS lan (wl0 interface) successfully started
Mar 9 09:25:30 DD-WRT user.info : [nas] : start nas lan
Mar 9 09:25:30 DD-WRT user.info : [nas] : start nas for wl1
Mar 9 09:25:30 DD-WRT user.info : [nas] : NAS lan (wl1 interface) successfully started
Mar 9 09:25:30 DD-WRT user.info : [httpd] : daemon successfully stopped
Mar 9 09:25:30 DD-WRT daemon.info httpd[2475]: [httpd] : httpd server shutdown
Mar 9 09:25:31 DD-WRT daemon.info httpd[2485]: [httpd] : httpd SSL server started at port 443
Mar 9 09:25:31 DD-WRT user.info : [httpd] : https daemon successfully started
Mar 9 09:25:31 DD-WRT user.info : [resetbutton] : daemon successfully stopped
Mar 9 09:25:31 DD-WRT user.info : [resetbutton] : resetbutton daemon successfully started
Mar 9 09:29:44 DD-WRT daemon.info httpd[2493]: [httpd] : Authentication fail
Mar 9 09:29:44 DD-WRT daemon.err httpd[2493]: [httpd] : Request Error Code 401: Authorization required. Wrong username and/or password!
Everything appears to have been working fine until 9:25AM EST this morning when the NTP sync occurred. Then SFE stopped and started, VPN modules were loaded and unloaded, CRON stopped and started etc.
Any ideas what is going on that is causing all of these services to be restarted? Looking at the syslog nothing immediately stands out as the issue. I did find a Reddit thread that suggested it might be caused because I have SFE enabled with NTP and how that can break it, but I am not 100% that is what they are implying.
Joined: 16 Nov 2015 Posts: 6414 Location: UK, London, just across the river..
Posted: Wed Mar 09, 2022 20:34 Post subject:
TheDood wrote:
Quote:
Failing power supply or other hardware related problem?
Try with a different power supply
Is there anything in the syslog that indicates a bad power supply?
nope there wont be anything in the syslog ...regarding bad PSU...
with bad power supply, router behaves odd...it either reboots, or its radio behaves badly...or some other strange bad performance...when CPU is heavy loaded...
if your PSU is bad, you can check it with multimeter...
then find a better one or the same...i use 5 Amps PSU on my R7000 (i lost the original), so there is some extra power _________________ Atheros
TP-Link WR740Nv1 ---DD-WRT 55179 WAP
TP-Link WR1043NDv2 -DD-WRT 55303 Gateway/DoT,Forced DNS,Ad-Block,Firewall,x4VLAN,VPN
TP-Link WR1043NDv2 -Gargoyle OS 1.15.x AP,DNS,QoS,Quotas
Qualcomm-Atheros
Netgear XR500 --DD-WRT 55460 Gateway/DoH,Forced DNS,AP Isolation,4VLAN,Ad-Block,Firewall,Vanilla
Netgear R7800 --DD-WRT 55460 Gateway/DoT,AD-Block,Forced DNS,AP&Net Isolation,x3VLAN,Firewall,Vanilla
Netgear R9000 --DD-WRT 55363 Gateway/DoT,AD-Block,AP Isolation,Firewall,Forced DNS,x2VLAN,Vanilla
Broadcom
Netgear R7000 --DD-WRT 55460 Gateway/SmartDNS/DoH,AD-Block,Firewall,Forced DNS,x3VLAN,VPN
NOT USING 5Ghz ANYWHERE
------------------------------------------------------
Stubby DNS over TLS I DNSCrypt v2 by mac913
Data-point: my RT-AC66u works fine with build DD-WRT v3.0-r47381 giga (09/08/21) and with various other builds.
Let me elaborate a bit. Those other builds - the ones my AC66U works with - include a build _later_ than that the one I mentioned. That later build is 48322 (though that particular build did have a minor problem . .). I have not tested any builds with numbers greater than 48322. _________________ My router: Asus RT-AC66U
Operating systems on devices that I use with that router: GNU-Linux; Windows 10; Android 13
Data-point: my RT-AC66u works fine with build DD-WRT v3.0-r47381 giga (09/08/21) and with various other builds.
Let me elaborate a bit. Those other builds - the ones my AC66U works with - include a build _later_ than that the one I mentioned. That later build is 48322 (though that particular build did have a minor problem . .). I have not tested any builds with numbers greater than 48322.
So it might be advantageous to roll back to that build? I don't mind continually upgrading to the most current releases either. I just want this issue to be either stopped, or reduced. And if nothing works, then I can live with it.
Joined: 08 May 2018 Posts: 14129 Location: Texas, USA
Posted: Thu Mar 10, 2022 18:04 Post subject:
You should probably consider switching to CTF or CTF+FA, rather than the Atheros SFE if that is what you are using. Also, the behavior is normal. NTP syncs, SFE reloads, if I am not mistaken (and this may also apply to CTF/CTF+FA). This is why I manipulated the NTP interval to once a day on my Atheros devices. _________________ "Life is but a fleeting moment, a vapor that vanishes quickly; All is vanity"
Contribute To DD-WRT Pogo - A minimal level of ability is expected and needed... DD-WRT Releases 2023 (PolitePol)
DD-WRT Releases 2023 (RSS Everything)
----------------------
Linux User #377467 counter.li.org / linuxcounter.net
@TheDood: my thinking was as follows. Try that build. If your problem persists, probably you have a hardware problem - and so should try to repair your router or else replace your router (with another instance of the same model or with a different model). _________________ My router: Asus RT-AC66U
Operating systems on devices that I use with that router: GNU-Linux; Windows 10; Android 13
You should probably consider switching to CTF or CTF+FA, rather than the Atheros SFE if that is what you are using. Also, the behavior is normal. NTP syncs, SFE reloads, if I am not mistaken (and this may also apply to CTF/CTF+FA). This is why I manipulated the NTP interval to once a day on my Atheros devices.
This was what I was going to try next. I wasn't really sure what the difference was between SFE and CTF/CTF+FA. Thanks! 😎
WouldRatherBeFOSS wrote:
@TheDood: my thinking was as follows. Try that build. If your problem persists, probably you have a hardware problem - and so should try to repair your router or else replace your router (with another instance of the same model or with a different model).
If @kernel-panic69's reccomendation does not work, I will certainly try the roll back. Thans fam 😎
You should probably consider switching to CTF or CTF+FA, rather than the Atheros SFE if that is what you are using. Also, the behavior is normal. NTP syncs, SFE reloads, if I am not mistaken (and this may also apply to CTF/CTF+FA). This is why I manipulated the NTP interval to once a day on my Atheros devices.
At the risk of bumping the thread, it looks like the issue persists. Is there a way for the NTP sync to occur and then not have the CTF or SFE restart networking services? Or perhaps not have the Wireless service restart? I understand the importance of NTP but I'd rather have more consistent network services then accurate time.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Sat Apr 02, 2022 18:08 Post subject:
For all its worth Ive manipulated the NTP interval to once a week, its doubtful that the time will go out of sync that much in a week and also will minimize the symptoms described. For my money I would dare to even make NTP update every two weeks and I doubt that will make router time go out of sync for more than 1 second within that period.
Default is excessive to say the least. Windows updates once a week by default afaik.
Anything else is unlikely to happen here, someone would have to scour the code and understand whats going on and why and make some optional settings that will change the current behavior and tbh I dont see that as some priority over the other jobs in todo lists.
Least of all convincing BS to spend time on this is highly unlikely.
So I apologize for the radio silence but I have been working on a number of things suggested in this thread.
I first downgraded to @WouldRatherBeFOSS suggestion and used that build. The issue still persisted.
Then I tried upgrading to the most recent release and then I tried @egc and @Alozaros suggestion of upgrading/replacing the power supply. It arrived last Saturday and I have been running it since. The issue seemed to be occurring less frequently but I am not sure if I would contribute that to the new PS.
I also followed @kernel-panic69 suggestion of using CTF over SFE. Don't think it fixed anything but its nice to know that a better option existed.
Quote:
For all its worth Ive manipulated the NTP interval to once a week, its doubtful that the time will go out of sync that much in a week and also will minimize the symptoms described. For my money I would dare to even make NTP update every two weeks and I doubt that will make router time go out of sync for more than 1 second within that period.
@the-joker is there any documentation pointing to adjusting the NTP sync via CLI? No stress on the implementation since I bet the CLI solution is trivial.
Quote:
Are you running the GUI as https?
That explains why is dependant of the time.
@Per Yngve Berg I am, and I cannot be sure when, but I believe I had this issue prior to implementing HTTPS.
Funny enough, as I type out this post, my router dropped AGAIN. Here are my syslogs:
Code:
Apr 04 10:15:19 Home_Router_(DD-WRT) ntpclient Time set from 2.pool.ntp.org [84.2.46.19].
Apr 04 10:15:19 Home_Router_(DD-WRT) process_monitor cyclic NTP Update success (servers 2.pool.ntp.org 212.18.3.19 88.99.174.22)
Apr 04 10:15:20 Home_Router_(DD-WRT) logger : [ctf] : fast path forwarding successfully started
Apr 04 10:15:21 Home_Router_(DD-WRT) root WireGuard number of non failed tunnels in fail set: 0
Apr 04 10:15:22 Home_Router_(DD-WRT) logger : [vpn modules] : vpn modules successfully unloaded
Apr 04 10:15:22 Home_Router_(DD-WRT) logger : [vpn modules] : nf_conntrack_proto_gre successfully loaded
Apr 04 10:15:22 Home_Router_(DD-WRT) logger : [vpn modules] : nf_nat_proto_gre successfully loaded
Apr 04 10:15:22 Home_Router_(DD-WRT) logger : [vpn modules] : nf_conntrack_pptp successfully loaded
Apr 04 10:15:22 Home_Router_(DD-WRT) logger : [vpn modules] : nf_nat_pptp successfully loaded
Apr 04 10:15:23 Home_Router_(DD-WRT) httpd [httpd] : Request Error Code 408: Unexpected connection close in initial request.
Apr 04 10:15:23 Home_Router_(DD-WRT) logger : [ctf] : fast path forwarding successfully started
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : start nas lan
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [ctf] : fast path forwarding successfully started
Apr 04 10:15:25 Home_Router_(DD-WRT) process_monitor Restarting cron (time sync change)
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : start nas for wl0
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : NAS lan (wl0 interface) successfully started
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : start nas lan
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : start nas for wl1
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [nas] : NAS lan (wl1 interface) successfully started
Apr 04 10:15:25 Home_Router_(DD-WRT) logger : [cron] : daemon successfully stopped
Apr 04 10:15:26 Home_Router_(DD-WRT) logger : [cron] : daemon successfully started
Apr 04 10:15:26 Home_Router_(DD-WRT) cron (CRON) STARTUP (fork ok)
Apr 04 10:15:26 Home_Router_(DD-WRT) logger : [process_monitor] : daemon successfully stopped
Apr 04 10:15:26 Home_Router_(DD-WRT) process_monitor [process_monitor] : cleanup timers
Apr 04 10:15:26 Home_Router_(DD-WRT) logger : [process_monitor] : successfully started
Apr 04 10:15:26 Home_Router_(DD-WRT) process_monitor We need to re-update after 3600 seconds
Apr 04 10:15:26 Home_Router_(DD-WRT) process_monitor [process_monitor] : set timer: 3600 seconds, callback: ntp_main()
Apr 04 10:15:26 Home_Router_(DD-WRT) logger : [nas] : daemon successfully stopped
Apr 04 10:15:27 Home_Router_(DD-WRT) logger : ttraff: data collection started
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : daemon hanging, send SIGKILL
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : start nas lan
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : start nas for wl0
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : NAS lan (wl0 interface) successfully started
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : start nas lan
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : start nas for wl1
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [nas] : NAS lan (wl1 interface) successfully started
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [httpd] : daemon successfully stopped
Apr 04 10:15:29 Home_Router_(DD-WRT) httpd [httpd] : httpd server shutdown
Apr 04 10:15:29 Home_Router_(DD-WRT) httpd [httpd] : httpd server started at port 80
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [httpd] : http daemon successfully started
Apr 04 10:15:29 Home_Router_(DD-WRT) logger : [resetbutton] : daemon successfully stopped
Apr 04 10:15:30 Home_Router_(DD-WRT) logger : [resetbutton] : resetbutton daemon successfully started
Apr 04 10:15:30 Home_Router_(DD-WRT) logger : [dropbear] : ssh daemon successfully started
Apr 04 10:15:30 Home_Router_(DD-WRT) dropbear Running in background
Also, who can ask about edit access to the Wiki? I followed the steps that I found and sent an email but have not heard back. I'm not much of a programmer and would like to contribute where I can.
Joined: 31 Jul 2021 Posts: 2146 Location: All over YOUR webs
Posted: Mon Apr 04, 2022 16:10 Post subject:
As above, my current NTP is set to
Code:
ntp_timer=432000
Which is 120 Hours or 5 days.
Code:
nvram set ntp_timer=<your-desired-time-in-seconds>
nvram commit
As to the OP, I dont see any supporting evidence of a crash, services that depend on NTP will need to be restarted.
Now if, the services wouldn't restart or connectivity would be affected for more than the time required to restart services and connectivity to be restored all around, then it would be a bug/issue, otherwise its how its suppose to work afaik.
In any case, delay NTP updates to a value that suits both accurate time and usage needs. I have no complaints.