netfilter buglog - Jun 2023 - [Bug 1689] New: Resetting the timeout counter for a named set element

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

            Bug ID: 1689
           Summary: Resetting the timeout counter for a named set element
           Product: nftables
           Version: unspecified
          Hardware: x86_64
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: nft
          Assignee: pablo at netfilter.org
          Reporter: neur0armitage at proton.me

Is there a way to reset time timeout counter so that the set can be
told to extend the lifetime of a particular element?   If so would
attempting to re-add the same element to the named set do that?

-- 
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/20230609/3e0c693b/attachment.html>

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

Eric Fahlgren <evil.function at proton.me> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evil.function at proton.me

--- Comment #1 from Eric Fahlgren <evil.function at proton.me> ---
Yes, but...  Only in the packet path:
https://wiki.nftables.org/wiki-nftables/index.php/Updating_sets_from_the_packet_path

It would be nice to be able to also do this from the command line.  A
modification of current behavior could easily implement this, but a change in
semantics might cause issues with backward compatibility, so I'm not sure
how
feasible this would be.

$ nft add set inet table my_set4 '{ type ipv4_addr; flags timeout,dynamic;
timeout 7d; }'
$ nft add element inet table my_set4 '{ 1.2.3.4 }'

Now list the set, see the element is there and the timeout is counting down. 
Next, wait a minute or two and

$ nft add element inet table my_set4 '{ 1.2.3.4 expires 7d }'

List the set again, and it appears to simply confirm existence, then ignores
the 'expires' clause.  If the semantics were changed to reset the
expiration,
that would allow the desired result.

Alternatively, to avoid backward compatibility issues, leave 'add
element'
as-is and add an 'update element' command, which would mimic the in-path
rule
behavior.  Looks like more work, but avoids breaking existing usage.


(Side note: my specific use case is updating DoH IP block lists from
out-of-band sources.)

-- 
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/20230622/c8df9da2/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |phil at nwl.cc

--- Comment #2 from Phil Sutter <phil at nwl.cc> ---
Hi!

An implementation of 'reset set' command is currently under review:

https://lore.kernel.org/netfilter-devel/20230615143140.29489-1-phil at nwl.cc/
https://lore.kernel.org/netfilter-devel/20230615144414.1393-1-phil at nwl.cc/

If accepted, this will also reset element timeouts.

An alternative is to drop the element in the same transaction, e.g.:

| nft 'delete element t s { 23 }; add element t s { 23 }'

-- 
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/20230623/52f682ff/attachment.html>

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

--- Comment #3 from Eric Fahlgren <evil.function at proton.me> ---
Phil, you can't tell me you hadn't already been thinking about this,
that was
so fast!

I have no standing, but did read through the doc updates and the described
functionality looks good to me, with full coverage of the set-like entities.

-- 
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/20230623/7361edb5/attachment.html>

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

--- Comment #4 from Phil Sutter <phil at nwl.cc> ---
(In reply to Eric Fahlgren from comment #3)
> Phil, you can't tell me you hadn't already been thinking about
this, that
> was so fast!
Yes, this ticket and my implementation happened at the same time by
coincidence.
> I have no standing, but did read through the doc updates and the described
> functionality looks good to me, with full coverage of the set-like
entities.
Cool, thanks for the review!

-- 
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/20230623/6c107b4a/attachment.html>

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

Phil Sutter <phil at nwl.cc> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #5 from Phil Sutter <phil at nwl.cc> ---
Kernel support for resetting elements will come with v6.5, it is contained in
-rc1 already.

User space support just went upstream, so will be part of v1.0.8.

-- 
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/20230713/ca76e168/attachment.html>