Florian Westphal <[email protected]> wrote:
> Ander Juaristi <[email protected]> wrote:
> This looks good to me, but there are three usability issues.
>
> The worst one first:
>
> nft add rule filter input hour 23:15-00:22 counter
>
> This works. But this fails:
> nft add rule filter input hour 23:15-03:22 counter
> Error: Range has zero or negative size
>
> Because values are converted to UTC, the first one will be a range from
> 21:15 to 22:22 UTC, so left < right. Second one is not.
>
> The obvious workaround:
>
> meta hour < "04:22" will NOT match at 00:28 (GMT+2), as its still 22:28 in
> the UTC time zone.
>
> It will match once local time is past 0 hours UTC.
>
> I suggest to try to fix this from the evaluation step, by
> swapping left and right and inverting the match.
>
> So 76500-8520 (left larger right) turns into "!= 8520-76500",
> which appears to do the right thing.
>
> shape and I have no idea how to fix this without using/relying on kernel time
> zone.
Argh, I reworded this and forgot to delete this half-sentence above.
> Even when relying on kernel time zone for everything, I don't see
> how we can support cross-day ("22:23-00:42") matching, as the range is
> invalid.
And that as well of course, swap and invert should work just fine.
> Second problem:
> Only solution I see is to change kernel patch to rely on
> sys_tz, just like xt_time, with all the pain this brings.
This stands, as the weekday is computed in the kernel, we will
need to bring sys_tz into this on the kernel side, the current
code uses UTC so we could be several hours off.
This can be restricted to the 'DAY' case of course.
