On Mon, 13 Aug 2018 13:03:54 +0200
Florian Westphal <fw@xxxxxxxxx> wrote:
> Jan Engelhardt <jengelh@xxxxxxx> wrote:
> > On Sunday 2018-08-12 23:05, Florian Westphal wrote:
> >
> > >Neal P. Murphy <neal.p.murphy@xxxxxxxxxxxx> wrote:
> > >> Does nftables have an equivalent of iptables' "-m time"?
> > >
> > >-m time is problematic (kernel has no idea what a timezone is).
> >
> > The kernel certainly does have a timezone (if only a limited understanding how
> > to use it). In its simplest form, it's UTC.
>
> Kernel doesn't know when DST transitions occur though.
> Its an utter mess and usually needs shell/cron scripts to catch this.
>
> I found no way to reliably prevent false matching when e.g.
> CET moves to CEST and vice versa.
>
Unless the kernel handles/schedules the change itself, it will never be reliable. However, for most intents and purposes, adjusting the kernel TZ within 10ms or so of the change is good enough (for real world use; RT is a different story). The change normally happens in the wee hours of the morning when many people are (supposed to be) sleeping; there probably wouldn't be a lot of firewall rules firing at that time. Users of the feature can be warned to avoid placing timed rules within 10 minutes before and after the change. (Yes, even Linux has its quirks.)
I changed Smoothwall Express to use -m time 4 years ago, and corrected a couple bugs shortly after. In short,
- Set the BIOS clock to local time (the BIOS clock is for humans anyway).
- Run a modern ntpd to keep the system clock reasonably accurate.
- Run a cron script a month or three before the local DST change to find the exact date/time of the
next change. (Local authorities tend to change the date/time on a whim.)
- Run a script/program one minute before the change.
- Sleep for 50 seconds.
- Spin, sleeping 10ms, looking for the TZ to change. (Grouse and die if it never happens.)
- Run Madore's program to set the kernel TZ and the HW clock.
Since then, no one has complained about timed rules firing at the wrong time (unless they happen to have bad hardware), nor have they complained about having to convert times in their heads, or change all their timed rules because DST came or went.
No, it's not perfect; nothing mankind does is. But the method I implemented *is* consistent and pretty darn close. And it allows us to set timed rules without resorting to mental masturbations. We use localtime with netfilter. Netfilter reports localtime to us. What netfilter uses internally is immaterial to us. For what it's worth, setting the system and HW clocks accurately with NTP is usually far more troublesome than setting the kernel TZ.
So, what would it take to 'port' -m time to nft?
