[Bug 1689] Resetting the timeout counter for a named set element

[bugzilla-daemon at netfilter.org]

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>