bugzilla-daemon at netfilter.org
2023-Jun-09 12:06 UTC
[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>
bugzilla-daemon at netfilter.org
2023-Jun-22 17:00 UTC
[Bug 1689] Resetting the timeout counter for a named set element
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>
bugzilla-daemon at netfilter.org
2023-Jun-23 07:39 UTC
[Bug 1689] Resetting the timeout counter for a named set element
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>
bugzilla-daemon at netfilter.org
2023-Jun-23 14:15 UTC
[Bug 1689] Resetting the timeout counter for a named set element
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>
bugzilla-daemon at netfilter.org
2023-Jun-23 15:18 UTC
[Bug 1689] Resetting the timeout counter for a named set element
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>
bugzilla-daemon at netfilter.org
2023-Jul-13 15:15 UTC
[Bug 1689] Resetting the timeout counter for a named set element
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>
bugzilla-daemon at netfilter.org
2024-Jul-23 08:00 UTC
[Bug 1689] Resetting the timeout counter for a named set element
https://bugzilla.netfilter.org/show_bug.cgi?id=1689 --- Comment #6 from Pablo Neira Ayuso <pablo at netfilter.org> --- For the record, timeout is not altered with reset command: commit 4c90bba60c26db7dc7df450f748e86440149786e Author: Pablo Neira Ayuso <pablo at netfilter.org> Date: Mon Oct 2 11:57:42 2023 +0200 netfilter: nf_tables: do not refresh timeout when resetting element reset command only operates on counter and quota. See man nft(8) reset Reset state in all contained elements, e.g. counter and quota statement values. -- 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/20240723/7c1abcc7/attachment.html>
bugzilla-daemon at netfilter.org
2024-Jul-23 15:39 UTC
[Bug 1689] Resetting the timeout counter for a named set element
https://bugzilla.netfilter.org/show_bug.cgi?id=1689 --- Comment #7 from Eric Fahlgren <evil.function at proton.me> --- (In reply to Pablo Neira Ayuso from comment #6)> netfilter: nf_tables: do not refresh timeout when resetting element > > reset command only operates on counter and quota.Is that a regression, or intentional? It goes counter to what Phil says in #2, above, "If accepted, this will also reset element timeouts", which I thought was the whole point of this feature? -- 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/20240723/6cefa1cd/attachment.html>
Apparently Analagous Threads
- [Bug 1725] New: Updating and destroying set elements
- [Bug 1674] New: ebtables causing packet loss
- [Bug 1730] New: nft does not handle IPv6 addresses with embedded IPv4 addresses
- [Bug 1395] New: Add element fails with Error: Could not process rule: Invalid argument
- [Bug 1685] New: Calling the nftnl_set_free function may trigger the "double free" problem.