RT-AC86U 384.5 and 384.6 alpha2 Router Powers Down/No Lights, No Access

[GHammer]

I have an odd issue.
I have had two different RT-AC86U simply shutdown at nearly the same time of day.
I sent the first router back thinking it was a bad router. The second one running 384.5 then 384.6 alpha2 did the same.
I was away for 10 days and on the 2nd day, no access to my home server. When I returned the router was dark with no connectivity for any device. Had to power cycle the router. I factory reset the router and loaded alpha2. Today (2 days later) I awoke to find a dark router again. Hit the power button and it powered up and was functioning fine.
My router is on a UPS with around 6 hours of runtime, so no power failure. Other devices connected to the UPS show no loss of power.

Each time the system logs show nothing of concern until the time of the failure.

Jul  8 05:52:02 kernel: Emergency Sync complete

Again, two routers, two different builds, same failure at the same time of day (05:50-05:52)

I have reset the router and returned to the current ASUS firmware for now.

The only thing different in the config of the router is DHCP assignments, enabling IPV6, and establishing port forwarding for a server.

I saved the full system log for the last failure if interested.

 

[NoSync]

I have an odd issue.
I have had two different RT-AC86U simply shutdown at nearly the same time of day.
I sent the first router back thinking it was a bad router. The second one running 384.5 then 384.6 alpha2 did the same.
I was away for 10 days and on the 2nd day, no access to my home server. When I returned the router was dark with no connectivity for any device. Had to power cycle the router. I factory reset the router and loaded alpha2. Today (2 days later) I awoke to find a dark router again. Hit the power button and it powered up and was functioning fine.
My router is on a UPS with around 6 hours of runtime, so no power failure. Other devices connected to the UPS show no loss of power.

Each time the system logs show nothing of concern until the time of the failure.

Jul  8 05:52:02 kernel: Emergency Sync complete

Again, two routers, two different builds, same failure at the same time of day (05:50-05:52)

I have reset the router and returned to the current ASUS firmware for now.

The only thing different in the config of the router is DHCP assignments, enabling IPV6, and establishing port forwarding for a server.

I saved the full system log for the last failure if interested.

On my RT-AC86U I sometimes get that if I reboot from the UI or change wireless settings (no matter the fw version). Never had it happening spontaneously though.

 

[ColinTaylor]

Jul  8 05:52:02 kernel: Emergency Sync complete

Again, two routers, two different builds, same failure at the same time of day (05:50-05:52)

Do you have an automatic reboot scheduled for 05:50 (Administration > System)?

 

[GHammer]

Do you have an automatic reboot scheduled for 05:50 (Administration > System)?

No, I do have one, but it is 06:02

 

[ColinTaylor]

No, I do have one, but it is 06:02

That's too close to be a coincidence. Try disabling the reboot and see if the problem goes away.

 

[GHammer]

That's too close to be a coincidence. Try disabling the reboot and see if the problem goes away.

That would suggest the router is looking ahead.
It's a daily reboot, so why only certain days? It didn't fail for the first one or two days.

I will see if the router does the same with the stock ASUS firmware.
I put it in place before folks are up and about, so don't want to wipe the router and reconfig from factory settings to get back to RMerlin during the day.

If it is dying because of looking ahead on the scheduled restart, that would be fixable.

 

[ColinTaylor]

I've just had a look at the source code. The reboot is triggered from watchdog.c. AFAICT because the watchdog only runs periodically it does try to predict whether it's within it's reboot window. It's also possible that there's a slight error in its calculation but that's beyond my ability to analyse.

EDIT: Just realised that we've had this conversation before: https://www.snbforums.com/threads/router-unresponsive-power-cycle-and-working.47353/#post-413183

 

[GHammer]

I've just had a look at the source code. The reboot is triggered from watchdog.c. AFAICT because the watchdog only runs periodically it does try to predict whether it's within it's reboot window. It's also possible that there's a slight error in its calculation but that's beyond my ability to analyse.

EDIT: Just realised that we've had this conversation before: https://www.snbforums.com/threads/router-unresponsive-power-cycle-and-working.47353/#post-413183

Indeed we have. Then, I returned that router for refund and bought another finding the same issue.

 

[john9527]

What is your 'default' time when the router first boots before the clock is sync'd?

 

[GHammer]

What is your 'default' time when the router first boots before the clock is sync'd?

May 5 01:05:05

 

[GHammer]

Makes sense that a scheduled restart could be the culprit here.

I have reset to factory, loaded alpha2, formatted jffs, reset to factory, reconfigured manually.
No scheduled restarts.
Plain vanilla save for DHCP assignments, enabling IPV6, and establishing 2 port forwarding rules.
Let's see where this takes us.

 

[GHammer]

It seems there is interaction between scheduled restarts and the router simply turning off.
I disabled the scheduled restarts and enough time has passed for the issue to appear.
Still running with no problems to report.

This time I did not enable full cone NAT. Last try it was enabled. When enabled, there were errors shown in the logs. No torrents, etc that would cause high connection rates. With the full cone off, no error.
nf_conntrack: expectation table full
net_ratelimit: 15 callbacks suppressed

We can live with the lack of full cone and without the scheduled restarts.

 

[RMerlin]

This time I did not enable full cone NAT. Last try it was enabled. When enabled, there were errors shown in the logs. No torrents, etc that would cause high connection rates. With the full cone off, no error.
nf_conntrack: expectation table full
net_ratelimit: 15 callbacks suppressed

You can increase it, using a nat-start or firewall-start script.

http://netfilter.vger.kernel.narkive.com/8eUaStlj/expectation-table-size

 

[GHammer]

You can increase it, using a nat-start or firewall-start script.

http://netfilter.vger.kernel.narkive.com/8eUaStlj/expectation-table-size

Thank you, I'll get that done.

BTW- many days since a powerdown since I disabled scheduled restarts.

 

[Treadler]

Thank you, I'll get that done.

BTW- many days since a powerdown since I disabled scheduled restarts.

Using either scheduled wireless, or scheduled reboot, results in intermittent power downs for me.
IMHO, scheduling is ‘broken’, & I no longer bother using it/them.

 

[GHammer]

Using either scheduled wireless, or scheduled reboot, results in intermittent power downs for me.
IMHO, scheduling is ‘broken’, & I no longer bother using it/them.

I guess the scheduler needs a little love then.