* [nftables] bug: rejects single-element intervals as supposedly empty
@ 2019-12-25 15:41 Florian Zumbiehl
2019-12-25 17:50 ` Florian Westphal
0 siblings, 1 reply; 3+ messages in thread
From: Florian Zumbiehl @ 2019-12-25 15:41 UTC (permalink / raw)
To: netfilter-devel
Hi,
I stumbled upon this bug in the Debian buster backports version of nftables
(0.9.2-1~bpo10+1), the git commit log doesn't look like this has been fixed
since, so here it is:
| # nft add rule foo bar udp dport 1-1
| Error: Range has zero or negative size
| add rule foo bar udp dport 1-1
| ^^^
Regards, Florian
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [nftables] bug: rejects single-element intervals as supposedly empty
2019-12-25 15:41 [nftables] bug: rejects single-element intervals as supposedly empty Florian Zumbiehl
@ 2019-12-25 17:50 ` Florian Westphal
2019-12-25 18:26 ` Florian Zumbiehl
0 siblings, 1 reply; 3+ messages in thread
From: Florian Westphal @ 2019-12-25 17:50 UTC (permalink / raw)
To: netfilter-devel, florz
Florian Zumbiehl <florz@florz.de> wrote:
> I stumbled upon this bug in the Debian buster backports version of nftables
> (0.9.2-1~bpo10+1), the git commit log doesn't look like this has been fixed
> since, so here it is:
>
> | # nft add rule foo bar udp dport 1-1
> | Error: Range has zero or negative size
> | add rule foo bar udp dport 1-1
I'd guess this is intentional and nft assumes user
meant something else such as 1-2 or 1-11.
We could autotranslate this to "dport 1" but I'm not sure its right.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [nftables] bug: rejects single-element intervals as supposedly empty
2019-12-25 17:50 ` Florian Westphal
@ 2019-12-25 18:26 ` Florian Zumbiehl
0 siblings, 0 replies; 3+ messages in thread
From: Florian Zumbiehl @ 2019-12-25 18:26 UTC (permalink / raw)
To: Florian Westphal; +Cc: netfilter-devel
Hi,
> > | # nft add rule foo bar udp dport 1-1
> > | Error: Range has zero or negative size
> > | add rule foo bar udp dport 1-1
>
> I'd guess this is intentional and nft assumes user
> meant something else such as 1-2 or 1-11.
Well, I would hope it is not intentional to claim that a one-element set
has zero or fewer elements!?
> We could autotranslate this to "dport 1" but I'm not sure its right.
Well, I don't know enough about the internals to know whether "translation"
is the right thing to do, but I would think the intended meaning (i.e.,
match port 1) is obvious, so that is what should happen?
Second-guessing the user on input that would seem obviously valid and
well-defined based on the documentation certainly doesn't seem like a good
idea to me. Just because there is a possibly more efficient way to encode
the same rule doesn't seem like a good reason to reject this encoding, as
that just complicates everything, and especially any code interfacing with
this, as you then have to special-case all those cases instead of just
generating a universal format that can represent all possible cases.
Also, nft accepts 1.2.3.4/32 just fine, or 1.2.3.0-1.2.3.255, which both
could be encoded more efficiently as well.
Regards, Florian
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2019-12-25 18:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-12-25 15:41 [nftables] bug: rejects single-element intervals as supposedly empty Florian Zumbiehl
2019-12-25 17:50 ` Florian Westphal
2019-12-25 18:26 ` Florian Zumbiehl
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).