From: Slavko <linux@slavino.sk>
To: netfilter ML <netfilter@vger.kernel.org>
Subject: Re: Sets update
Date: Sun, 21 Jul 2024 13:23:37 +0200 [thread overview]
Message-ID: <20240721132337.29d2fbc9@bonifac.skk> (raw)
In-Reply-To: <ba07a45c-7564-4b40-92de-ea698d16f49f@app.fastmail.com>
[-- Attachment #1: Type: text/plain, Size: 2796 bytes --]
Hi,
Dňa Sun, 21 Jul 2024 10:58:30 +0100 "Kerin Millar" <kfm@plushkava.net>
napísal:
> Firstly, you should not use "delete element". It will never be
I am aware of this, but AFAIK the "destroy" is available from kernel 6.3
and i am on 5.15, thus i am out of luck. With any luck, the timeout will
not happen during update (due timeout value and set update interval),
thus in my case it can work reliable.
> Secondly, though you could handle each element one by one, I would
> not recommend it.
OK, i was in doubt.
> Yes, grouping elements in this way is sensible. Note that there is no
> need to worry about the ARG_MAX constraint because nft is being made
> to read from the standard input rather than use the -c option.
I hope in that, don't worry about -c option, i can understand the point
of answer ;-)
> However, I would suggest generating one element per line because the
> way in which nft reports errors is atrocious in the case of long
> lines.
Of course, it was simplified example in mail... Beside of nft errors,
it is more readable in any case...
> {
> echo "add element ... {"
> sed 's/$/,/'
> echo "}"
> } | nft -f -
Eh, that looks really nice (simple), but IMO it is good for (nonexistent
yet) update command. As one needs any IP twice/thrice, thus list must be
read into memory in script, or i miss something?
> add element ... { <existing-ip> timeout <new-timeout> }
> add element ... { <existing-ip> expires <new-timeout> }
In case of existing IP i understand the "add element" as noop (does
nothing) command, thus this is IMO expected.
> I doubt it. Perhaps we need a new "update element" command to act
> similarly to the set statement bearing the same name.
Yes, and while it is possible to update timeout from packet path, it is
surprising, that it is impossible from command line, the code itself
must exists, just user interface is missing?
> Mind you, it gets worse. While the nft utility supports a JSON output
> mode to ease parsing, its output is less accurate than the
> conventional output mode in so far as all "timeout" and "expires"
> values are truncated to integer seconds and conveyed as JSON integers.
I am fain with that timeout precision, mostly because i am not
interested on per element timeouts :-D
I start to play with jq in shell for that, it seems as possible, but
that is in only on my "playing" machine, where i use nftables already.
I am curios why is not possible to directly use ipsets from nftables.
Yes, the nftables's sets are powerful and becomes better, but still are
not direct replacement of ipsets in some cases. Perhaps someone
competent can provide answer (other than "nobody coded it").
regards
--
Slavko
https://www.slavino.sk
[-- Attachment #2: Digitálny podpis OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2024-07-21 11:23 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-21 7:44 Sets update Slavko
2024-07-21 9:58 ` Kerin Millar
2024-07-21 10:04 ` Kerin Millar
2024-07-21 11:23 ` Slavko [this message]
2024-07-21 12:29 ` Kerin Millar
2024-07-21 14:38 ` Slavko
2024-07-21 15:46 ` Kerin Millar
2024-07-23 7:24 ` Slavko
2024-07-23 7:37 ` Slavko
2024-07-23 9:39 ` Pablo Neira Ayuso
2024-07-23 10:23 ` Slavko
2024-07-23 11:32 ` Kerin Millar
2024-07-23 12:19 ` Pablo Neira Ayuso
2024-07-21 16:09 ` Eric
2024-07-21 16:46 ` Kerin Millar
2024-07-21 17:58 ` Slavko
2024-07-22 20:36 ` Pablo Neira Ayuso
2024-07-23 7:26 ` Slavko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240721132337.29d2fbc9@bonifac.skk \
--to=linux@slavino.sk \
--cc=netfilter@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox