dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>
dnsmasq maintains dnsmasq.time across reboots and uses it as a means of
determining if current time is good enough to validate dnssec time
stamps. By including /etc/dnsmasq.time as a time source for sysfixtime,
the mechanism was effectively defeated because time was set to the
last time that dnsmasq considered current even though that time is in
the past. Since that time is out of date, dns(sec) resolution would
fail thus defeating any ntp based mechanisms for setting the clock
correctly.
In theory the process is defeated by any files in /etc that are newer
than /etc/dnsmasq.time however dnsmasq now updates the file's timestamp
on process TERM so hopefully /etc/dnsmasq.time is the latest file
timestamp in /etc as part of LEDE shutdown/reboot.
Either way, including /etc/dnsmasq.time as a time source for
sysfixtime is not helpful.
On systems that have an RTC prefer it to the file-based time fixup (i.e.
use hwclock when there is a permanent clock instead of the faked up time
logic that is needed when there is not RTC).
We can't rely on hctosys kernel feature either as we're usually using
RTC as kernel modules which are usually being loaded after hctosys was
run, leading in the following error:
hctosys: unable to open rtc device (rtc0)
Signed-off-by: Daniel Dickinson <openwrt@daniel.thecshore.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
SVN-Revision: 48661
Seems like the reverse order relies on GNU specific getopt hackery which
musl does not replicate
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 41045
Simply scan for the most recent file in /etc and set
system time to this file modification time if it's in the future
It allow some time dependent program to work immediatly
without waiting for ntpd to sync
v1: v2: bad approach
v3: simply scan /etc, thanks to Bastian Bittorf for the idea
v4: use sort -n, thanks to Catalin Patulea
v5: use [] instead of [[]], thanks to Andreas Mohr
v6: use openwrt style, thanks to Bastian Bittorf
Signed-off-by: Etienne CHAMPETIER <etienne.champetier@free.fr>
SVN-Revision: 39422
