Ander Juaristi <a@xxxxxxxxxxxx> wrote:
> These keywords introduce new checks for a timestamp, an absolute date (which is converted to a timestamp),
> an hour in the day (which is converted to the number of seconds since midnight) and a day of week.
>
> When converting an ISO date (eg. 2019-06-06 17:00) to a timestamp,
> we need to substract it the GMT difference in seconds, that is, the value
> of the 'tm_gmtoff' field in the tm structure. This is because the kernel
> doesn't know about time zones. And hence the kernel manages different timestamps
> than those that are advertised in userspace when running, for instance, date +%s.
>
> The same conversion needs to be done when converting hours (e.g 17:00) to seconds since midnight
> as well.
>
> The result needs to be computed modulo 86400 in case GMT offset (difference in seconds from UTC)
> is negative.
>
> We also introduce a new command line option (-t, --seconds) to show the actual
> timestamps when printing the values, rather than the ISO dates, or the hour.
>
> Some usage examples:
>
> time < "2019-06-06 17:00" drop;
> time < "2019-06-06 17:20:20" drop;
> time < 12341234 drop;
> day "Sat" drop;
> day 6 drop;
> hour >= 17:00 drop;
> hour >= "17:00:01" drop;
> hour >= 63000 drop;
>
> We need to convert an ISO date to a timestamp
> without taking into account the time zone offset, since comparison will
> be done in kernel space and there is no time zone information there.
>
> Overwriting TZ is portable, but will cause problems when parsing a
> ruleset that has 'time' and 'hour' rules. Parsing an 'hour' type must
> not do time zone conversion, but that will be automatically done if TZ has
> been overwritten to UTC.
>
> Hence, we use timegm() to parse the 'time' type, even though it's not portable.
> Overwriting TZ seems to be a much worse solution.
>
> Finally, be aware that timestamps are converted to nanoseconds when
> transferring to the kernel (as comparison is done with nanosecond
> precision), and back to seconds when retrieving them for printing.
>
> We swap left and right values in a range to properly handle
> cross-day hour ranges (e.g. 23:15-03:22).
Might make sense to also do this for days.
> The first time, we need to call expr_evaluate_range, error printing
> disabled, because otherwise an error (example below) will be printed
> even though the ruleset was eventually successfully evaluated. This
> might be misleading for the end user.
>
> meta-test:25:11-21: Error: Range has zero or negative size
> hour eq 23:15-03:22 drop;
> ^^^^^^^^^^^
nft add inet filter input meta hour '"12:22-12:23"' counter
-> gets parsed as 'meta hour 12:22'.
Could this at least throw an error? Its not obvious why this doesn't
work as expected.
('"12:22"-"12:23"' will work of course).
nft --debug=netlink add inet filter input meta day '"Sat"-"Fri"' counter
... doesn't do anything. nft returns 1, but no error is shown.
Looks like range errors are not displayed anymore:
nft --debug=netlink add inet filter input tcp dport 23-22
should throw an error message.
