Recently I've encountered a problem with router's system time. The firware is tomato-K26USB-1.28.7497.1MIPSR2-Toastman-VLAN-RT-VPN. After a reboot, the time resets to Thu Jan 1 02:07:30 STD 1970. So I have to manually set the time. What is happening?
Do you have it set to auto-update the time in Basic -> Time and did you select an NTP time server on that page? On reboot my router goes back to Dec 31 but looking at the logs after a few seconds the time corrects itself after the router checks with the NTP server.
Yes, I set the time update on that page. There are option to setup the frequency. The lowest is every hour. Also there is on start-up. On start-up didn't update the time. Update after an hour is tooo long, as for a hour the VPN will not be able to connect due to time inconcistency. Also, the web page reports the time as Unavailable.
With the setting Every Hour, the time will be updated on startup as well as every hour thereafter.
Perhaps you should try a different selection of time server. Getting an Unavailable message suggests the one you are using is not responding.
Planiwa, I can't run that interactively, as a few days provider didn't provide to me internet access. So, on start-up TomatoUSB sets the date and time to Jan 1 1970 02:00, taken from unknown source, then updates it from time sources in internet. But if internet is unavailable, time is not corrected. This is incorrect approach, as time must be preserved on reboots, like in PCs. Otherways, looking in TomatoUSB log configuration, the log file may be set yo JFFS or external device. In that case, the log will be time inconsistent.
The other problem. If at start-up internet is unavailable, the time will not be corrected. But if the internet appears after suppose 10 mins, then time will still be incorect, as the correction will occur after minimum a hour depending on config. So even if internet is available, the time will be incorect for a long time, which will interfer with normal service working.
This is a bug may be, but must be corrected.
The initial 1970 time is not from some random source. Time is maintained in a millisecond counter beginning at 1970. So the counter is starting out at 0.
There is no hardware in the router to maintain time through reboot. It can only get the time from somewhere else. It could get it from a local host on the LAN but that will never be as accurate.
This is not a bug that can be "fixed" in the firmware.
So, this is hardware related… Doesn't RT-N16 have an internal backup clock to mantain the time? Like almost a lot of devices have, like TVs, tuners, even simple ADSL modems.
How about this scenario: worldwide internet is not accesible, but local (city) internet is acesible, so the router can VPN to some other local (city) service. But this will be impossible, as time difference will prevent VPN connection.
You're barking up the wrong tree and forum. You should fret about the lack of clock and battery with the hardware manufacturer, not in this firmware forum that isn't responsible for the lack of "offline hardware clock"
A (Unix) host can easily set its time from another (Unix) host's time. NTP is simply a protocol that automates this. The other host need not be far away.
[A few decades ago, computers were quite limited in their performance, and the people who worked with software were among the most intelligent humans. Today, most computers are consumer-grade appliances or toys, designed by profiteers for consumer-grade markets, and operated by consumer-grade minds. Most of these devices are crippled by design, as demonstrated by occasionally well-designed hardware and software. Nevertheless, most computers exceed the intellectual performance of their operators.]
I can think of three ways to achieve persistent time on an RT-N16 router:
1. Don't turn off the power. Don't reboot senslessly.
2. If the power is unstable, use a UPS.
3. If the router is turned on "manually" set the time "manually".
3.1 If there are timing-conflicts with services that that connect with other hosts, delay those services until the time is no longer in "The Epoch" (i.e. 1970).
3.2 If delay is too "hard", restart the service after the time has been set.
These three methods require no thinking.
A fourth method would be to get a reliable Internet service.
[As for maintaining Epoch time in milliseconds — It would take just 7 weeks to fill up a 32-bit counter.]