ipset maximal/minimal revision conflict

ipset maximal/minimal revision conflict

[Mr Dash Four]

I get a weird error when executing the following ipset command:

[root@test1 ~]# ipset -N test hash:net,port
ipset v6.4: Kernel supports hash:net,port type, family INET with maximal 
revision 0 while ipset program with minimal revision 1.
You need to upgrade your kernel.

The "revision", as far as I know, is exactly the same - ipset 6.4! The 
userspace has been compiled from the released v6.4, while the kernel 
part was built from a snapshot dated 24 April, which included the 3 
patches not present in .39-rc4 (so, in essence, if anything, the kernel 
part should be newer than the userspace part of the released v6.4, 
right?). It is strange that I do not get this error when attempting any 
other type of set (hash:ip or hash:net).

It is also worth noting that I have IPv6 administratively disabled on 
that machine, though do not know if that's the reason for the above 
error. How can I correct this?

Re: ipset maximal/minimal revision conflict

[Jozsef Kadlecsik]

On Tue, 26 Apr 2011, Mr Dash Four wrote:

> I get a weird error when executing the following ipset command:
> 
> [root@test1 ~]# ipset -N test hash:net,port
> ipset v6.4: Kernel supports hash:net,port type, family INET with maximal
> revision 0 while ipset program with minimal revision 1.
> You need to upgrade your kernel.
> 
> The "revision", as far as I know, is exactly the same - ipset 6.4! The
> userspace has been compiled from the released v6.4, while the kernel part was
> built from a snapshot dated 24 April, which included the 3 patches not present
> in .39-rc4 (so, in essence, if anything, the kernel part should be newer than
> the userspace part of the released v6.4, right?). It is strange that I do not
> get this error when attempting any other type of set (hash:ip or hash:net).

The hash:*port* types have got a new revision due to the introduced SCTP 
and UDPLITE support. The ipset package contains the matching kernel 
modules, the kernel tree is a little bit behind.

I do not want to burden the kernel with any multi-revision support until 
2.6.39. After the non-rc kernel version is out, I'll start to maintain 
the revisions support.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset maximal/minimal revision conflict

[Mr Dash Four]

> The hash:*port* types have got a new revision due to the introduced SCTP 
> and UDPLITE support. The ipset package contains the matching kernel 
> modules, the kernel tree is a little bit behind.
>   
I see, the ipset files in the kernel version and the kernel files in the 
ipset package are out of sync then, right?

Would I be able to successfully split this up by using the source files 
in the kernel/ directory of the ipset 6.4 package and move them over to 
the ipset kernel source directory, whilst keeping all the 
make/configuration files in the ipset kernel directory (Kbuild and 
alike) intact?

Would that solve the above problem (keeping/building the ipset package 
as a whole is *not* an option for me, before you ask)? I also assume 
that the kernel files in the ipset package are newer as the above error 
suggests, right?

Re: ipset maximal/minimal revision conflict

[Jozsef Kadlecsik]

On Tue, 26 Apr 2011, Mr Dash Four wrote:

> > The hash:*port* types have got a new revision due to the introduced SCTP and
> > UDPLITE support. The ipset package contains the matching kernel modules, the
> > kernel tree is a little bit behind.
> >   
> I see, the ipset files in the kernel version and the kernel files in the ipset
> package are out of sync then, right?
> 
> Would I be able to successfully split this up by using the source files in the
> kernel/ directory of the ipset 6.4 package and move them over to the ipset
> kernel source directory, whilst keeping all the make/configuration files in
> the ipset kernel directory (Kbuild and alike) intact?
> 
> Would that solve the above problem (keeping/building the ipset package as a
> whole is *not* an option for me, before you ask)? I also assume that the
> kernel files in the ipset package are newer as the above error suggests,
> right?

You can copy over the files (header files too) from the ipset package to 
the kernel tree.

If I dropped supporting kernels between 2.6.34-2.6.37, the sources would 
be identical in the ipset package and an updated kernel tree.

Best regards,
Jozsef
-
E-mail  : kadlec@blackhole.kfki.hu, kadlec@mail.kfki.hu
PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics
          H-1525 Budapest 114, POB. 49, Hungary

Re: ipset maximal/minimal revision conflict

[Mr Dash Four]

> You can copy over the files (header files too) from the ipset package to 
> the kernel tree.
>   
Actually, what I did was to create 1 mega patch with 1) the difference 
between .39-rc4 and .35-88 (the latest stable kernel released by Fedora) 
as far as the ipset kernel modules are concerned; 2) all 
menuconfig-related ipset settings (so that when I run make menuconfig I 
could select the ipset settings properly); and 3) the difference between 
.39-rc4 (git as of 24 April) and ipset 6.4 (the kernel part).

Applied it successfully to the kernel source tree and I am now building 
it (.35.12-88). If/When it finishes I'll install it on my test harness 
here and will see how it goes. I briefly looked at the differences 
between the 6.4 release and the latest kernel modules I've had from that 
git and they are quite extensive indeed.

One thing I also noticed - in the kernel part of v6.4 you have 
"-DCONFIG_IP_SETMAX" extra CFLAGS defined, but that seems to be missing 
from the git kernel tree - is that on purpose or is this new to be added 
later on?


By the time I typed this the kernel build has completed successfully. 
Installation and testing follows...