OpenWrt Forum Archive

Topic: time disparity detected

The content of this topic has been archived on 6 May 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hi guys'

Can anyone explain me what does following line means:
"Jan 31 16:36:01 OpenWrt cron.warn crond[677]: time disparity of 4251875 minutes detected"

I am seeing this in my logread
i am using kamikaze 7.09 kernel ver 2.6
Can you also tell me what does that mean and what are the consequences and what makes it cause?
appreciated...

your modem doesn't have a battery to keep clock so each boot or reboot the modem sync with a ntp server and daemon says some info logs.

To expand on what Sonic said, when the router boots it will think it is 1 Jan 2000.  (4251875 minutes is just over 8 years).  So when crond starts, it thinks it is the year 2000.  Then an ntp client (e.g. ntpclient or ntpdate or ntpd etc.) syncs the time with a time server and suddenly crond notices it is 2008!  It thinks that 8 years just went missing, so it complains about it.

Thanks a lot guys i really appreciate it smile

Is this time check auto set now? I've been providing my own script for that for some time.....

napierzaza wrote:

Is this time check auto set now? I've been providing my own script for that for some time.....

Not sure what you mean.

When the router boots it will think it is 2000.
crond starts
When the WAN interface comes up, ntpclient starts and tries to sync the time.
ntpclient updates the time to the current time.
crond automatically notices that the time has changed and prints a warning in the logs.

What does your script do exactly?

You could create an entry in crontabs (if it is not there) rdate......

I use openwrt / midge and this already has an entry for time synchonisation. I think it's done every 2 ours.

(Last edited by mrx on 6 Feb 2008, 09:38)

Wodin wrote:
napierzaza wrote:

Is this time check auto set now? I've been providing my own script for that for some time.....

Not sure what you mean.

When the router boots it will think it is 2000.
crond starts
When the WAN interface comes up, ntpclient starts and tries to sync the time.
ntpclient updates the time to the current time.
crond automatically notices that the time has changed and prints a warning in the logs.

What does your script do exactly?

That's what I don't have - I never installed ntpclient.  I use "rdate" - it's less accurate, but I don't need high accuracy, and it's already there (enabled in busybox).  I installed my own startup script which runs "rdate -s foo" ("foo" is a Linux server on my home network, which has the "time" service enabled, and this server is running "ntpclient").  Got all that?  It's a long-winded way of saying "No, time check is not auto set now."

whbjr wrote:

I installed my own startup script which runs "rdate -s foo" ("foo" is a Linux server on my home network, which has the "time" service enabled, and this server is running "ntpclient").  Got all that?  It's a long-winded way of saying "No, time check is not auto set now."

Yes, I did not mean to imply that ntpclient was installed by default.  I would not call that a time "check".  More like "setting" the time smile

However, crond does do a check automatically and warns about the big time gap.

Anyway, thanks for the clarification.

Best approach is belt AND suspenders.

I have an init script check a certain file for timestamp. Once a day cron touches this file to update the timestamp.

That way any given reboot will start with SOMEWHAT good time even if network is not immediately available.  DSL modem locked up, power problems. whatever.

Also run ntpdate from cron to keep it in closer sync.

Having the right date is important if you are doing OpenVPN with certificates, which I am.

Is once a day enough to satisfy OpenVPN?  I thought you had to be closer than that.

My main concern is during certificate negotiation with OpenVPN.  I build my cert on Aug 2007 say with a lifetime until 2036.

Now the WRT boots up, thinks it January 1st 2000 and tries to talk to it's peer.  There is immediately a problem about you are trying to use a certificate for a date in the future.  Get me?  Just being in a timeframe after the certificate starts seems sufficient.

I wish these things had a battery-backed clock, or at least there was a cheap option to plug in one.

The discussion might have continued from here.