My ASUS AX-56U date/time changed to default after WAN disconnected for over 30 minutes

[pseu_asus]

Hi, Guys,
I found my AX-56U router's syslog timestamp changed to May 5,2018 when I was reviewing the syslog file for trouble shooting. The router did not reboot for about 2 weeks and I had no power outage at home. After I narrowed down , I found this happened days ago when there was a storm around. The storm caused a network outage from the service provider's side and it lasted about 6 hours. So my router lost WAN connection for 6 hours for sure. The syslog timestamp then changed to May 5,2018 about 30 minutes later after the network outage. I confirmed I did not have power outage nor the router rebooted during the time. After the WAN outage restored, the syslog indicated that it had a NTP

Is this by design? If so, as a workaround,should I have a home NTP service to let the router do NTP sync with a LAN server during WAN outage?

 

[drinkingbird]

Hi, Guys,
I found my AX-56U router's syslog timestamp changed to May 5,2018 when I was reviewing the syslog file for trouble shooting. The router did not reboot for about 2 weeks and I had no power outage at home. After I narrowed down , I found this happened days ago when there was a storm around. The storm caused a network outage from the service provider's side and it lasted about 6 hours. So my router lost WAN connection for 6 hours for sure. The syslog timestamp then changed to May 5,2018 about 30 minutes later after the network outage. I confirmed I did not have power outage nor the router rebooted during the time. After the WAN outage restored, the syslog indicated that it had a NTP

Is this by design? If so, as a workaround,should I have a home NTP service to let the router do NTP sync with a LAN server during WAN outage?

I've never looked or noticed, but if having accurate logfile time is critical to you then yes I'd run an NTP server on your LAN and point the router to that. The question is why would that be so critical?

 

[pseu_asus]

Thanks!
Q: The question is why would that be so critical?
A: The timestamp change in syslog (probably system date/time changed) when losing WAN connection is related to some of my scripts. I have to update the scripts when querying some keywords from syslog with proper date/time.

 

[tgl]

I found my AX-56U router's syslog timestamp changed to May 5,2018 when I was reviewing the syslog file for trouble shooting. The router did not reboot for about 2 weeks and I had no power outage at home. After I narrowed down , I found this happened days ago when there was a storm around. The storm caused a network outage from the service provider's side and it lasted about 6 hours. So my router lost WAN connection for 6 hours for sure. The syslog timestamp then changed to May 5,2018 about 30 minutes later after the network outage. I confirmed I did not have power outage nor the router rebooted during the time. After the WAN outage restored, the syslog indicated that it had a NTP

Is this by design?

No, that's an iron-clad bug; no sane NTP client implementation would do that in preference to letting the system clock free-run. (Although ... are you 100% sure of your facts here? You've got a UPS that will hold up your router for six hours?)

You can try complaining to Asus but I would not recommend holding your breath for a fix. The idea of pointing the router at a local source of time seems reasonable as a workaround, if you can also support the local source of time and any intervening network hardware through a power outage.

 

[Tech9]

You can try complaining to Asus but I would not recommend holding your breath for a fix.

No chance for any fix. RT-AX56U is on End-of-Life list already.

End-of-life product list

 

[ColinTaylor]

The syslog timestamp then changed to May 5,2018 about 30 minutes later after the network outage. I confirmed I did not have power outage nor the router rebooted during the time.

The router must have rebooted. That is the only situation when the timestamp is May 5, 2018.

 

[pseu_asus]

No, that's an iron-clad bug; no sane NTP client implementation would do that in preference to letting the system clock free-run. (Although ... are you 100% sure of your facts here? You've got a UPS that will hold up your router for six hours?)

You can try complaining to Asus but I would not recommend holding your breath for a fix. The idea of pointing the router at a local source of time seems reasonable as a workaround, if you can also support the local source of time and any intervening network hardware through a power outage.

Thanks for your further information.
And the situation was: the storm just caused the provider's network outage about 2 miles away. And there was no power outage at my home. I had run the "uptime" command on my router to confirm that.
Yes, I will consider to have a NTP server in my home network and point the device to it for NTP sync.

 

[pseu_asus]

No chance for any fix. RT-AX56U is on End-of-Life list already.

End-of-life product list

Thanks, I don't expect any fix on the old gun. I will setup a home NTP server and point my device to it so as to work around.

 

[pseu_asus]

The router must have rebooted. That is the only situation when the timestamp is May 5, 2018.

Hi, Colin, I did run the command "uptime" to confirm the router did not reboot .

maven@RT-AX56U-CM:/tmp/home/root# uptime
 20:43:16 up 30 days, 17:46,  load average: 0.60, 0.66, 0.72

That's why it is weird.
If it was rebooted, I wouldn't start this thread.

 

[ColinTaylor]

Without seeing your complete log file it's difficult to speculate what happened. All I know is that there is only one line in the firmware that sets that date:

asuswrt-merlin.ng/release/src/router/rc/common.c at 312ed2c0d8642abef3fd8621d94095f2cba7702a · RMerl/asuswrt-merlin.ng

Third party firmware for Asus routers (newer codebase) - RMerl/asuswrt-merlin.ng

github.com

That routine is also called by the NTP process. So I suppose it's conceivable that due to the network outage your upstream NTP server returned an invalid date (e.g. 0000000000 = 1st Jan 1970). The sanity check in the firmware would realise that date is wrong and set it's clock back to the default build date. Then sometime later, once the NTP server was functioning properly the date would have been corrected.

 

[tgl]

Do you still have the router log from the period of the outage? It'd be interesting to see the exact NTP-related log messages during and after the outage.