netfilter buglog - Sep 2020 - [Bug 1472] New: [sets] global named sets that can be utilised across families

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

            Bug ID: 1472
           Summary: [sets] global named sets that can be utilised across
                    families
           Product: nftables
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: vtolkm at gmail.com

kernel 5.9.0-rc6 armv7l | nft 0.9.6

Currently named sets can be utilised in rules only within the family a set is
defined.

However, there are use cases where the same sets are applicable for different
families, and thus it would be handy if there were a sort of (global) sets that
could be utilised across families - mitigating redundancy and providing more
flexibility with rules.

-- 
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/20200923/64e47c10/attachment.html>

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

--- Comment #1 from vtolkm at gmail.com ---
something curious going on there, now with a netdev conf changed to:

ether type 0x8005 log flags all prefix "nd et 805 DROP: " drop;
ether type 0x0806 log flags all prefix "nd et arp DROP: " drop;
ether type 0x8068 log flags all prefix "nd et 068 DROP: " drop;
ether type 0x8100 log flags all prefix "nd et vlan DROP: " drop;
ether type 0x880C log flags all prefix "nd et 80C DROP: " drop;
ether type 0x8847 log flags all prefix "nd et 847 DROP: " drop;
ether type 0x8848 log flags all prefix "nd et 848 DROP: " drop;
ether type 0x9000 log flags all prefix "nd et 000 DROP: " drop;

the log even prints:

[Sat Sep 26 09:54:48 2020] nd et vlan DROP: IN=eth2 OUT= ARP HTYPE=1
PTYPE=0x0800 OPCODE=1 MACSRC=78:ba:f9:73:f5:74 IPSRC=10.238.192.1
MACDST=00:00:00:00:00:00 IPDST=10.238.249.167

____

This a bit unsettling, not knowing whether the logs prints erroneously or the
netdev filter firing wrong.

-- 
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/20200926/9a6ad5b7/attachment.html>

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

--- Comment #2 from vtolkm at gmail.com ---
please discard the last comment, posted in the wrong bug :(

-- 
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/20200926/13ac7d6d/attachment.html>

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

kfm at plushkava.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kfm at plushkava.net
             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/20201203/fae62dc4/attachment-0001.html>

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

--- Comment #3 from Pablo Neira Ayuso <pablo at netfilter.org> ---
(In reply to vtolkm from comment #0)
> kernel 5.9.0-rc6 armv7l | nft 0.9.6
> 
> Currently named sets can be utilised in rules only within the family a set
> is defined.
> 
> However, there are use cases where the same sets are applicable for
> different families, and thus it would be handy if there were a sort of
> (global) sets that could be utilised across families - mitigating
redundancy
> and providing more flexibility with rules.
What is your use-case?

-- 
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/20201203/c9058b58/attachment.html>