Feature request: Time/date startup value in /system/clock

RouterOS General
1

Certificate verification will fail on system startup before NTP synchronization is available, because time/date is 1.01.1970 and certificates validity starts on a later date.
This is a problem if NTP server access is only available AFTER the secured connection is in place.

A parameter “startup-date” under /system/clock would be useful in this case, so date will to be set to a specified value on system startup and updated later via NTP.
Of course this could be done via a script, but that’s not really nice.

2

+1, but is better one RTC onboard…

3

I agree with that, but… :laughing:
A RTC usually implies a lithium cell battery. which will limit the temperature range for the router, since lithium cells are not stable and reliable above 60 deg. Celsius, tending to let out some magical smoke.
This is no problem in desktop installations, where the device stays cool. But in an rack with limited ventilation one can possibly expect temperatures above that limit.

4

Really not are need one 3 years clock without power, only one capacitor with maintain date and time for 10 minutes, or just for reboot…

And is better than start date/time with RouterOS build date and time.
For example, if the package are made 26/06/2014, is absurd to start the clock on 1970…

Or better, if the bios [firmware] are builded for example 25/05/2014 is absurd to start the RB with one previous date…

5

Pretty sure you can set a script to run on boot can’t you? Have it set the initial time to something close.

Rtc in the higher end models would be worth the extra 2 bucks IMHO. At least on higher end models.

6

A RTC usually implies a lithium cell battery. which will limit the temperature range for the router, since lithium cells are not stable and reliable above 60 deg. Celsius, tending to let out some magical smoke.

Usually cetificates are installed on gateway, not on access point, RB1100, RB1200, CCR, CRS and all rack models must have one RTC,
the rack never go to 60°!!!

“We” do not need one perennial battery, but just if I reboot the device (without leave the power) the clock must still syncronized…

7

Pretty sure you can set a script to run on boot can’t you? Have it set the initial time to something close.

Yes, at the startup you can read date/time of the routeros package and set the actual time to that…

:global npkdate value=[/system package get system value-name=build-time];
/system clock set date=[:pick $npkdate 0 [:find $npkdate " " -1] ];
/system clock set time=[:pick $npkdate ([:find $npkdate " " -1] + 1) [:len $npkdate] ];

or with more complex script you can set date & time to the last good syncronization with NTP…

Run each 60 minutes:

:if ([/system ntp client get value-name="status"] = "synchronized") do={
/file remove [find where name~"lastsync"];
/system clock print file="lastsync";
};

Run at boot:

:global lastsync value=[/file get [find where name="lastsync.txt"] value-name="creation-time"];
/system clock set date=[:pick $lastsync 0 [:find $lastsync " " -1] ];
/system clock set time=[:pick $lastsync ([:find $lastsync " " -1] + 1) [:len $lastsync] ];

BUT…

Really users community must find everytime one walktrought for each “miss” or “bug”?

8

Is like someone on next RouterOS 6.16rc11 like my ideas…

*) time - on routerboards, current time is saved in configuration on reboot
and on clock adjustment, and is used to set initial time after reboot;

9

Hooray. Hope it will be saved periodically in order to survive unexpected power outage.

10

is like is saved only on “reboot” command…

11

If so, it is not enough.

12

You can use my script… :wink:

13

Thanks for the offer.

14

It is also saved “on clock adjust”. Is a SNTP update considered a clock adjust?
Anyway, to solve certificate validity issues, it is enough.
Good job MT team!

15

yes, I edit my post because mt also add “and on clock adjustment” :smiley: