All of lore.kernel.org
 help / color / mirror / Atom feed
* meta time broken
@ 2022-04-05  1:17 Lukas Straub
  2022-04-05  1:31 ` Lukas Straub
  0 siblings, 1 reply; 6+ messages in thread
From: Lukas Straub @ 2022-04-05  1:17 UTC (permalink / raw)
  To: netfilter-devel

[-- Attachment #1: Type: text/plain, Size: 1025 bytes --]

Hello Everyone,
I want to set up a rule that matches as long as the current time (/time
of packet reception) is smaller than a given unix timestamp. However
the whole "meta time" expression seems to be broken. I can't get it to
work with either a unix timestamp or iso time. What's weird is that
after setting the rule and listing it again, it will always display a
date around 1970 instead of whatever was entered.

Reproducer:
nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time < $(date --date='now + 2 hours' '+%s') accept"
nft list chain inet filter prg_policy

Reproducer 2:
nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time \"2022-04-01 01:00\" - \"2022-04-10 01:00\" accept"
nft list chain inet filter prg_policy

nftables v1.0.2 (Lester Gooch)
Linux usbrouter 5.10.0-13-armmp #1 SMP Debian 5.10.106-1 (2022-03-17) armv7l GNU/Linux

Regards,
Lukas Straub

-- 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: meta time broken
  2022-04-05  1:17 meta time broken Lukas Straub
@ 2022-04-05  1:31 ` Lukas Straub
  2022-04-05 11:15   ` Phil Sutter
  2022-04-05 11:16   ` Florian Westphal
  0 siblings, 2 replies; 6+ messages in thread
From: Lukas Straub @ 2022-04-05  1:31 UTC (permalink / raw)
  To: netfilter-devel

[-- Attachment #1: Type: text/plain, Size: 1368 bytes --]

On Tue, 5 Apr 2022 01:17:05 +0000
Lukas Straub <lukasstraub2@web.de> wrote:

> Hello Everyone,
> I want to set up a rule that matches as long as the current time (/time
> of packet reception) is smaller than a given unix timestamp. However
> the whole "meta time" expression seems to be broken. I can't get it to
> work with either a unix timestamp or iso time. What's weird is that
> after setting the rule and listing it again, it will always display a
> date around 1970 instead of whatever was entered.
> 
> Reproducer:
> nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time < $(date --date='now + 2 hours' '+%s') accept"
> nft list chain inet filter prg_policy
> 
> Reproducer 2:
> nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time \"2022-04-01 01:00\" - \"2022-04-10 01:00\" accept"
> nft list chain inet filter prg_policy
> 
> nftables v1.0.2 (Lester Gooch)
> Linux usbrouter 5.10.0-13-armmp #1 SMP Debian 5.10.106-1 (2022-03-17) armv7l GNU/Linux
> 
> Regards,
> Lukas Straub
> 

Hmm, after staring at the code for a bit. I could imagine it's due to
time_t being 32 bit on my platform and nftables trying to stuff a unix
timstamp with nanosecond resolution in it...

Regards,
Lukas Straub

-- 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: meta time broken
  2022-04-05  1:31 ` Lukas Straub
@ 2022-04-05 11:15   ` Phil Sutter
  2022-04-05 11:16   ` Florian Westphal
  1 sibling, 0 replies; 6+ messages in thread
From: Phil Sutter @ 2022-04-05 11:15 UTC (permalink / raw)
  To: Lukas Straub; +Cc: netfilter-devel

Hi Lukas,

On Tue, Apr 05, 2022 at 01:31:28AM +0000, Lukas Straub wrote:
> On Tue, 5 Apr 2022 01:17:05 +0000
> Lukas Straub <lukasstraub2@web.de> wrote:
> 
> > Hello Everyone,
> > I want to set up a rule that matches as long as the current time (/time
> > of packet reception) is smaller than a given unix timestamp. However
> > the whole "meta time" expression seems to be broken. I can't get it to
> > work with either a unix timestamp or iso time. What's weird is that
> > after setting the rule and listing it again, it will always display a
> > date around 1970 instead of whatever was entered.
> > 
> > Reproducer:
> > nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time < $(date --date='now + 2 hours' '+%s') accept"
> > nft list chain inet filter prg_policy
> > 
> > Reproducer 2:
> > nft "add chain inet filter prg_policy; flush chain inet filter prg_policy; add rule inet filter prg_policy meta time \"2022-04-01 01:00\" - \"2022-04-10 01:00\" accept"
> > nft list chain inet filter prg_policy
> > 
> > nftables v1.0.2 (Lester Gooch)
> > Linux usbrouter 5.10.0-13-armmp #1 SMP Debian 5.10.106-1 (2022-03-17) armv7l GNU/Linux
> > 
> > Regards,
> > Lukas Straub
> > 
> 
> Hmm, after staring at the code for a bit. I could imagine it's due to
> time_t being 32 bit on my platform and nftables trying to stuff a unix
> timstamp with nanosecond resolution in it...

Thanks for the report. Can you try this patch?

------------------------8<-----------------------------
--- a/src/meta.c
+++ b/src/meta.c
@@ -405,7 +405,7 @@ static void date_type_print(const struct expr *expr, struct output_ctx *octx)
                nft_print(octx, "Error converting timestamp to printed time");
 }
 
-static time_t parse_iso_date(const char *sym)
+static uint64_t parse_iso_date(const char *sym)
 {
        struct tm tm, *cur_tm;
        time_t ts;
@@ -444,9 +444,9 @@ static struct error_record *date_type_parse(struct parse_ctx *ctx,
                                            struct expr **res)
 {
        const char *endptr = sym->identifier;
-       time_t tstamp;
+       uint64_t tstamp;
 
-       if ((tstamp = parse_iso_date(sym->identifier)) != -1)
+       if ((tstamp = parse_iso_date(sym->identifier)) != (uint64_t)-1)
                goto success;
 
        tstamp = strtoul(sym->identifier, (char **) &endptr, 10);
------------------------8<-----------------------------

Thanks, Phil

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: meta time broken
  2022-04-05  1:31 ` Lukas Straub
  2022-04-05 11:15   ` Phil Sutter
@ 2022-04-05 11:16   ` Florian Westphal
  2022-04-05 11:41     ` Lukas Straub
  1 sibling, 1 reply; 6+ messages in thread
From: Florian Westphal @ 2022-04-05 11:16 UTC (permalink / raw)
  To: Lukas Straub; +Cc: netfilter-devel

Lukas Straub <lukasstraub2@web.de> wrote:
> Hmm, after staring at the code for a bit. I could imagine it's due to
> time_t being 32 bit on my platform and nftables trying to stuff a unix
> timstamp with nanosecond resolution in it...

Will you send a patch?

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: meta time broken
  2022-04-05 11:16   ` Florian Westphal
@ 2022-04-05 11:41     ` Lukas Straub
  2022-04-05 12:02       ` Florian Westphal
  0 siblings, 1 reply; 6+ messages in thread
From: Lukas Straub @ 2022-04-05 11:41 UTC (permalink / raw)
  To: Florian Westphal; +Cc: netfilter-devel

[-- Attachment #1: Type: text/plain, Size: 478 bytes --]

On Tue, 5 Apr 2022 13:16:45 +0200
Florian Westphal <fw@strlen.de> wrote:

> Lukas Straub <lukasstraub2@web.de> wrote:
> > Hmm, after staring at the code for a bit. I could imagine it's due to
> > time_t being 32 bit on my platform and nftables trying to stuff a unix
> > timstamp with nanosecond resolution in it...  
> 
> Will you send a patch?

Yes, I already sent one. The mailing list seems to be a bit flacky, did
you get it?

Regards,
Lukas Straub

-- 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: meta time broken
  2022-04-05 11:41     ` Lukas Straub
@ 2022-04-05 12:02       ` Florian Westphal
  0 siblings, 0 replies; 6+ messages in thread
From: Florian Westphal @ 2022-04-05 12:02 UTC (permalink / raw)
  To: Lukas Straub; +Cc: Florian Westphal, netfilter-devel

Lukas Straub <lukasstraub2@web.de> wrote:
> On Tue, 5 Apr 2022 13:16:45 +0200
> Florian Westphal <fw@strlen.de> wrote:
> 
> > Lukas Straub <lukasstraub2@web.de> wrote:
> > > Hmm, after staring at the code for a bit. I could imagine it's due to
> > > time_t being 32 bit on my platform and nftables trying to stuff a unix
> > > timstamp with nanosecond resolution in it...  
> > 
> > Will you send a patch?
> 
> Yes, I already sent one. The mailing list seems to be a bit flacky, did
> you get it?

No, but its in patchwork.  Patch gives following warning:

meta.c:449:56: warning: comparison of integer expressions of different
signedness: 'uint64_t' {aka 'long unsigned int'} and 'int' [-Wsign-compare]
  449 |         if ((tstamp = parse_iso_date(sym->identifier)) != -1)


Would you mind sending a v2?

I'd suggest to change parse_iso_date() to split return value and
converted value, for example:

static time_t parse_iso_date(const char *sym)
->
static bool parse_iso_data(uint64_t *res, const char *sym)

or similar.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-04-05 14:08 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-05  1:17 meta time broken Lukas Straub
2022-04-05  1:31 ` Lukas Straub
2022-04-05 11:15   ` Phil Sutter
2022-04-05 11:16   ` Florian Westphal
2022-04-05 11:41     ` Lukas Straub
2022-04-05 12:02       ` Florian Westphal

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.