netfilter buglog - Jul 2020 - [Bug 1438] New: nft generates wrong intervals for sets with auto-merge

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

            Bug ID: 1438
           Summary: nft generates wrong intervals for sets with auto-merge
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: Debian GNU/Linux
            Status: NEW
          Severity: major
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: public_timo.s at silentcreek.de

Hi,

I'm relatively new to nftables, currently moving my iptables/ipset setups to
nftables. I did a few experiments with scripting sets and encountered the
following bug in nftables 0.9.0-2 (Debian 10) as well as 0.9.3-2 (Ubuntu
20.04).

If I have the following simple script to set up a set:
  #!/usr/sbin/nft -f
  add set inet filter myset { type ipv4_addr; flags interval; auto-merge }
  add element inet filter myset { 192.168.0.0/24 }
  add element inet filter myset { 192.168.0.2 }
  add element inet filter myset { 192.168.1.0/24 }
  add element inet filter myset { 192.168.1.100 }

After loading this script with `nft -f', I run `nft list set inet filter
myset'
and the result looks like this:
  table inet filter {
          set myset {
                  type ipv4_addr
                  flags interval
                  auto-merge
                  elements = { 192.168.0.0/31, 192.168.0.2,
                               192.168.1.0-192.168.1.99, 192.168.1.100 }
          }
  }

Ouch! This is utterly wrong, obviously.

Please note that my experiments have shown that this bug occurs only if the
elements are added in individual `add element' statements in the script
file.
If I put all elements in a single statement, the resulting set is correct, like
so:
  add element inet filter myset { 192.168.0.0/24, 192.168.0.2, 192.168.1.0/24,
192.168.1.100 }

The resulting set is fine then and has only one element, as expected:
192.168.0.0/23

I understand that having multiple `add element' lines might not be ideal,
but
the wiki doesn't suggest that this would be wrong (nor does `nft -cf').
Hence,
I consider this a major bug, since the auto-merged intervals do not at all
match what would be expected.

Cheers,

Timo

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200701/9ec84db2/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kfm at plushkava.net

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200703/0f6cfd13/attachment-0001.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

--- Comment #1 from kfm at plushkava.net ---
I tested the given ruleset against nftables (commit c156232) and Linux 5.7.19,
including the net_set_rbtree patch mentioned in bug 1451. I changed
"inet" to
"ip", just because it suits my existing ruleset. The following errors
occur,
every time:

  ./test.nft:4:1-44: Error: Could not process rule: File exists
  add element ip filter myset { 192.168.0.2 }
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  ./test.nft:6:1-46: Error: Could not process rule: File exists
  add element ip filter myset { 192.168.1.100 }
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I suppose that's an improvement on the behaviour that Timo is seeing, but
hardly ideal. It's clear that that there are are still issues concerning the
auto-merge functionality, as has also been stated in the 13th comment of bug
1392.

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/14219d08/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1392

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/664e5c6d/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://bugzilla.netfilter.
                   |                            |org/show_bug.cgi?id=1449

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200828/0ae4bb79/attachment.html>

https://bugzilla.netfilter.org/show_bug.cgi?id=1438

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |1461

-- 
You are receiving this mail because:
You are watching all bug changes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.netfilter.org/pipermail/netfilter-buglog/attachments/20200829/9722c62c/attachment.html>