How exactly is time/date reset (or retained) during power off?

[bengalih]

So I had an issue today I've never seen before and it appears to be due to something funky happening with the date/time not being retained (or even updated) on the router:
I use EAP Proxy configuration to connect to my ISP's fiber network and this requires the proper date for the certificate to be validated.
This service starts after boot, and presumably re-validates every so often (might be only once every week or two).

When I got hope today I found that my internet connection wasn't working and when I investigated I found the certificate validation wasn't happening due to a date error.
When I paid closer attention to the logs I saw that it said my certificate was only valid starting 1/12/22. Today is 1/25/22, but my syslog entries were showing that it was only 1/7/22.

I didn't notice this until after I got my device online through non EAP means, at which point it appears the date updated properly. When I went back to try my Proxy it successfully validated the certificate.

So I have these questions:

1. Any idea what could have caused my system to thing it was still 1/7/22 even though it has been online connected through at least 11pm on 1/24/22 ?
2. This issue didn't appear to happen after a router reboot, and it has never happened to me before after a reboot. What I don't understand is this:
   • If the device loses its date/time on reboot, how is it able to get the current date/time if it can't connect to the internet? I'm sure my device must have at the very least the proper date before connecting or else it wouldn't even be able to validate the certificate. Does the device have a CMOS battery that stores the date and is pulled by the OS at some point during boot? If the CMOS battery fails will I never have the correct date unless it connects (or I set manually)?

I'm thinking of writing a script to write the current time to a file every hour and then set the time through a boot script early on. I would like to do this probably after the CMOS gets read, but before it connects to the network. Where would be the best place to insert the script into the boot process?

 

[ColinTaylor]

The router has no way of retaining the date/time (unless you install a third party solution). It has no battery. This is why there a multiple posts reminding people to configure valid public WAN DNS servers when using DoT. DoT cannot create a TLS connection without the date/time being set correctly, and for that to happen it first needs a working non-encrypted DNS to resolve the NTP server address (or alternatively hard-code the IP address).

I'm thinking of writing a script to write the current time to a file every hour and then set the time through a boot script early on. I would like to do this probably after the CMOS gets read, but before it connects to the network. Where would be the best place to insert the script into the boot process?

There have been scripts posted in the past that do this. Search the forum for those.

P.S. The router doesn't have "CMOS". That's a PC term that is technically incorrect anyway.

 

[bengalih]

The router has no way of retaining the date/time (unless you install a third party solution). It has no battery. This is why there a multiple posts reminding people to configure valid public WAN DNS servers when using DoT. DoT cannot create a TLS connection without the date/time being set correctly, and for that to happen it first needs a working non-encrypted DNS to resolve the NTP server address (or alternatively hard-code the IP address).


There have been scripts posted in the past that do this. Search the forum for those/

Ok. But....

There has to be someway that my router is pulling at least the current date before connecting online.
I say this based on the experience I just had and the tests I did.
If my date is off, I don't appear to be able to validate my ISP certificate, and if that fails I fail to get online.
If the router couldn't pull the date from something every time it rebooted then I would never be able to connect, and yet it appears to.

I can't explain it, which is why I am asking for some advice. I'm going to do a third round of testing here as soon as I can take it offline again.

 

[ColinTaylor]

I understand what you're saying. I don't have any experience of the type of WAN connection you're using. All I can say for sure is that the router does not retain its date and time when it's rebooted. It boots up with a default date and time that's hard-coded into the firmware. That is currently May 5th @ ~ 06:05 GMT. (There is a very early boot stage where the date/time is Jan 1st 1970).

 

[bengalih]

I understand what you're saying. I don't have any experience of the type of WAN connection you're using. All I can say for sure is that the router does not retain its date and time when it's rebooted. It boots up with a default date and time that's hard-coded into the firmware. That is currently May 5th @ ~ 06:05 GMT.

I figured it out by talking with someone on the ISP forum who is familiar with this. I didn't realize (or forgot) that the script which installs the configuration files also installed fake-hwclock which effectively does write the time to a file on shutdown/restart.

That explains why this has always worked for me in the past, but doesn't exactly explain why without a reboot my time got "lost" and my device thought it was 1/7 when it was 1/25.

 

[ColinTaylor]

That explains why this has always worked for me in the past, but doesn't exactly explain why without a reboot my time got "lost" and my device thought it was 1/7 when it was 1/25.

Maybe your custom script was invoked by some change you made in the GUI. Hence it picked up the date/time of the last reboot. Depends how your custom script works I suppose.

 

[bengalih]

Yeah, not sure. Now that I understand the working parts better I can better troubleshoot if it happens again.

It would seem though, that among other things that ntp must not have been syncing my time with pool.ntp.org.
If my log dates when I was troubleshooting today show my date as 1/7/22, then they must not have updated since at least that date or else my system would reflect that later date.

I don't really see any syslog date from ntp so not sure how I would diagnose that part in the future.

 

[bengalih]

FYI for anyone interested I did two things to hopefully mitigate this in the future:

added an init-start script with the following line:

ntp -n -q -p 10.10.10.100

This basically syncs from my local time server (Domain Controller) at boot time. Obviously this only works if you have a local time server to set from before you get online. If your problem isn't the same as mine and you can get online, you can change to:

ntp -n -q -p pool.ntp.org

or another reliable ntp server of your choice. You may even want this server to be different than the ones you have set in nvram for more redundancy.

I also created a cron job to write the date to a file daily:

cru a save_time "0 8 * * * /tmp/mnt/flash_drive/entware/bin/fake-hwclock save"

I already had fake-hwclock installed via Entware so it will automatically load this file at boot time via an service script.
If you don't want to install it you can do something similar just calling date to write the datetime to a file and then adding something to read it from the file during the init-script.