netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jozsef Kadlecsik <kadlec@netfilter.org>
To: Ian Pilcher <arequipeno@gmail.com>
Cc: netfilter-devel@vger.kernel.org
Subject: Re: Looking for info on ipset set type revisions
Date: Wed, 9 Mar 2022 10:02:52 +0100 (CET)	[thread overview]
Message-ID: <ffa9a4f-d09b-302b-3df6-89d33d88c8f@netfilter.org> (raw)
In-Reply-To: <32c1b5d3-59f9-8bf2-ee22-f4b6708d57be@gmail.com>

Hi Ian,

On Tue, 8 Mar 2022, Ian Pilcher wrote:

> I am working on a C program that uses libmnl to do some basic ipset 
> manipulation - namely create a set of type hash:ip,port and then add 
> entries.
> 
> The best technique I've found to figure out the exact messages required 
> is to use strace with the ipset command.  strace does a pretty good job 
> of decoding the netlink messages, and I can generally figure out the 
> significance and meaning of other constants by looking at the various 
> header files.
> 
> The one thing that I haven't yet been able to figure out is set type
> revisions.  When I use ipset to create a hash:ip,port set, I see that
> it is passing 6 as the IPSET_ATTR_REVISION.  I can also that 6 is the
> latest revision in lib/ipset_hash_ipportip.c, which is fine when using
> the ipset command or calling libipset.
> 
> What about programs that don't use libipset?  How can an application
> determine the latest/correct revision of a particular set type?  

You can query the kernel about the highest revision number it supports for 
a given set type by sending an IPSET_CMD_TYPE message. There's a tiny 
documentation about the messages and their format in lib/PROTOCOL. 
However, not relying on libipset then you have to know which features are 
available in the given revision.

> I haven't been able to find anything in any of the header files that 
> seems relevant, nor do I see any way for an application to discover this 
> information at runtime.
> 
> Should I just hardcode 6?

You can hardcode the highest revision number for a given set type from 
libipset. I don't plan new revisions to introduce and even if that would 
happen, the only downside of hardcoding the number is that you won't be 
able to use new features introduced in higher revisions.

The kernel part always provides backward compatibility.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.hu
PGP key : https://wigner.hu/~kadlec/pgp_public_key.txt
Address : Wigner Research Centre for Physics
          H-1525 Budapest 114, POB. 49, Hungary

      reply	other threads:[~2022-03-09  9:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 23:40 Looking for info on ipset set type revisions Ian Pilcher
2022-03-09  9:02 ` Jozsef Kadlecsik [this message]

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=ffa9a4f-d09b-302b-3df6-89d33d88c8f@netfilter.org \
    --to=kadlec@netfilter.org \
    --cc=arequipeno@gmail.com \
    --cc=netfilter-devel@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;
as well as URLs for NNTP newsgroup(s).