Xtables-addons 1.32/ipset-GENL 5.2

Xtables-addons 1.32/ipset-GENL 5.2

[Jan Engelhardt]

'ちわ

So a few people had been asking on whether ipset 5.x will be bundled 
along with Xtables-addons. Naturally this is a difficult question 
because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
1.32 (just out).

It has been augmented to not require the patch anymore, by moving it 
over from nfnetlink (booo) to genetlink which does not depend on static 
numbers, though you will need at least Linux 2.6.35 for this GENL 
variant in both compilation and at runtime.
(As such, ipset-5 is deactivated by default in Xt-a 1.32 and needs to be 
turned on in mconfig.)


Xt-a files at the usual place.

The plain genl patch to ipset-5 can be found as a commit at 
git://dev.medozas.de/ipset in the "genl" branch. It has received a run 
through the testsuite (as far as it went until ospf), and I take that as 
an indication that proxying the protocol onto genl was successful.

Re: Xtables-addons 1.32/ipset-GENL 5.2

[Jozsef Kadlecsik]

Hi,

On Tue, 4 Jan 2011, Jan Engelhardt wrote:

> So a few people had been asking on whether ipset 5.x will be bundled 
> along with Xtables-addons. Naturally this is a difficult question 
> because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
> 1.32 (just out).
> 
> It has been augmented to not require the patch anymore, by moving it 
> over from nfnetlink (booo) to genetlink which does not depend on static 
> numbers, though you will need at least Linux 2.6.35 for this GENL 
> variant in both compilation and at runtime.

I fully appreciate your effort, however with it you forked ipset 5.x and 
now the two branches cannot talk to each other.

I'm not convinced that ipset should be moved from nfnetlink to genetlink. 
It'd make life easier for the users at the beginning, however on the 
longer run it'd buy nothing and I believe ipset belongs to nfnetlink.

I considered the idea of adding support of both protocols, however it 
might make the acceptance for kernel inclusion harder. I'm not happy.

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: Xtables-addons 1.32/ipset-GENL 5.2

[Jan Engelhardt]

On Wednesday 2011-01-05 10:22, Jozsef Kadlecsik wrote:
>On Tue, 4 Jan 2011, Jan Engelhardt wrote:
>
>> So a few people had been asking on whether ipset 5.x will be bundled 
>> along with Xtables-addons. Naturally this is a difficult question 
>> because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
>> 1.32 (just out).
>> 
>> It has been augmented to not require the patch anymore, by moving it 
>> over from nfnetlink (booo) to genetlink which does not depend on static 
>> numbers, though you will need at least Linux 2.6.35 for this GENL 
>> variant in both compilation and at runtime.
>
>I fully appreciate your effort, however with it you forked ipset 5.x and 
>now the two branches cannot talk to each other.

Was not planned; I hardly see a case where there is a reason to mix
two versions of out-of-tree modules. (There is always a lockstep
update of both kernel and user side when using Xt-a.)

>I'm not convinced that ipset should be moved from nfnetlink to
>genetlink. It'd make life easier for the users at the beginning,
>however on the longer run it'd buy nothing and I believe ipset
>belongs to nfnetlink. I considered the idea of adding support of
>both protocols, however it might make the acceptance for kernel
>inclusion harder. I'm not happy.

The genl patch was solely made for the users wanting to try ipset5.

I cannot say I am happy about it either, knowing about the nfnetlink
doctrine. You say genl does not buy us anything, but I feel people
have not thought about what nfnl could possibly buy over genl. Right
now, nfnl has two drawbacks: preallocated IDs and extra memory use.

There were no intentions of inclusion of this genl patch, though that
does not mean I prohibit its integration.

Re: Xtables-addons 1.32/ipset-GENL 5.2

[Mr Dash Four]

> I fully appreciate your effort, however with it you forked ipset 5.x and 
> now the two branches cannot talk to each other.
>
> I'm not convinced that ipset should be moved from nfnetlink to genetlink. 
> It'd make life easier for the users at the beginning, however on the 
> longer run it'd buy nothing and I believe ipset belongs to nfnetlink.
>
> I considered the idea of adding support of both protocols, however it 
> might make the acceptance for kernel inclusion harder. I'm not happy.
>   
Jozsef,

I have been thinking along similar lines with regards to ipset/xtables 
for quite a while - I do not really need or use xtables apart from the 
ipset part.

Up until now I have been compiling rpm which builds the main xtables 
package and I also use a sepearate .spec file to create the kernel 
modules (kmod-*.rpm). The process is by no means flawless (my post 
history on here vouches that to be the case) so, waiting for ipset to be 
integrated with xtables every time a new ipset version is released is 
not always the best for me as a regular user of that package as your 
comments above highlight.

What I am getting at is this - I will try to create a .spec file for 
building a completely separate package which only deals with ipset and 
leaves xtables aside as it is highly likely that I will dump xtables 
once and for all as soon as I am able to create this package since I do 
not need/use its features, apart from what ipset currently offers me.

As it stands, Fedora does not distribute ipset on its own, but as part 
of the xtables package. I do not know whether this is going to change, 
but as far as I am concerned the moment I am able to build a separate 
ipset rpm which functions as it should, xtables is gone on all of my 
machines. I presume ipset, too, generates/uses kernel modules - is that 
the case?
 

Re: Xtables-addons 1.32/ipset-GENL 5.2

[Jozsef Kadlecsik]

On Wed, 5 Jan 2011, Mr Dash Four wrote:
[...]
> As it stands, Fedora does not distribute ipset on its own, but as part of the
> xtables package. I do not know whether this is going to change, but as far as
> I am concerned the moment I am able to build a separate ipset rpm which
> functions as it should, xtables is gone on all of my machines. I presume
> ipset, too, generates/uses kernel modules - is that the case?

Yes, of course.

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: Xtables-addons 1.32/ipset-GENL 5.2

[Pablo Neira Ayuso]

On 04/01/11 05:14, Jan Engelhardt wrote:
> 'ちわ
> 
> So a few people had been asking on whether ipset 5.x will be bundled 
> along with Xtables-addons. Naturally this is a difficult question 
> because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
> 1.32 (just out).
> 
> It has been augmented to not require the patch anymore, by moving it 
> over from nfnetlink (booo) to genetlink which does not depend on static 
> numbers, though you will need at least Linux 2.6.35 for this GENL 
> variant in both compilation and at runtime.

Not depending of static numbers is a good thing to me because it makes
the whole user-space simpler since: a) you don't have to send a message
to perform the initial family ID lookup and b) you don't have to
subscribe to genl control events (which is required since the the
floating family number may change if the module is unloaded).

> (As such, ipset-5 is deactivated by default in Xt-a 1.32 and needs to be 
> turned on in mconfig.)
> 
> Xt-a files at the usual place.
> 
> The plain genl patch to ipset-5 can be found as a commit at 
> git://dev.medozas.de/ipset in the "genl" branch. It has received a run 
> through the testsuite (as far as it went until ospf), and I take that as 
> an indication that proxying the protocol onto genl was successful.

This is going to confuse everyone. Since ipset-5 will be submitted into
mainline soon, some distributors may start packaging the user-space genl
binaries. Then, once we have it into the kernel, the distributed version
will not work with the one running upon nfnetlink.

I think it's way easier to submit a patch to reserve the subsystem ID
for ipset than adding this genl compatibility layer.

BTW, Jozsef, do you plan to submit ipset for the next linux kernel
release cycle?
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Xtables-addons 1.32/ipset-GENL 5.2

[Jan Engelhardt]

On Thursday 2011-01-06 03:11, Pablo Neira Ayuso wrote:
>On 04/01/11 05:14, Jan Engelhardt wrote:
>> 'ちわ
>> 
>> So a few people had been asking on whether ipset 5.x will be bundled 
>> along with Xtables-addons. Naturally this is a difficult question 
>> because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
>> 1.32 (just out).
>> 
>> It has been augmented to not require the patch anymore, by moving it 
>> over from nfnetlink (booo) to genetlink which does not depend on static 
>> numbers, though you will need at least Linux 2.6.35 for this GENL 
>> variant in both compilation and at runtime.
>
>Not depending of static numbers is a good thing to me because it makes
>the whole user-space simpler since: a) you don't have to send a message
>to perform the initial family ID lookup and b) you don't have to
>subscribe to genl control events (which is required since the the
>floating family number may change if the module is unloaded).

Sounds like genl could benefit from a pinning mechanism; rather than
just using CTRL_CMD_GETFAMILY, a CTRL_CMD_GETIT would use
module_get(genl_ops->owner) to grab the module, with the reverse
being a CTRL_CMD_PUTBACK, which is then also implicit on closing the
nl socket.

>> (As such, ipset-5 is deactivated by default in Xt-a 1.32 and needs to be 
>> turned on in mconfig.)
>> 
>> Xt-a files at the usual place.
>> 
>> The plain genl patch to ipset-5 can be found as a commit at 
>> git://dev.medozas.de/ipset in the "genl" branch. It has received a run 
>> through the testsuite (as far as it went until ospf), and I take that as 
>> an indication that proxying the protocol onto genl was successful.
>
>This is going to confuse everyone. Since ipset-5 will be submitted into
>mainline soon, some distributors may start packaging the user-space genl
>binaries.

Some distributors also package kernels patched with random things.

Falls under the well-known answer field of "those who have no clue
should not touch it".

Not providing a tarball, not providing a diff, stowing away the code
in git, and stowing it away in a non-default branch as is done with
ipset-genl keeps out the worst offenders.

Getting involved in NF packages in major distros works proactively
against incompatible or rotten package submissions.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Xtables-addons 1.32/ipset-GENL 5.2

[Jozsef Kadlecsik]

On Thu, 6 Jan 2011, Pablo Neira Ayuso wrote:

> On 04/01/11 05:14, Jan Engelhardt wrote:
> > So a few people had been asking on whether ipset 5.x will be bundled 
> > along with Xtables-addons. Naturally this is a difficult question 
> > because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
> > 1.32 (just out).
> > 
> > It has been augmented to not require the patch anymore, by moving it 
> > over from nfnetlink (booo) to genetlink which does not depend on static 
> > numbers, though you will need at least Linux 2.6.35 for this GENL 
> > variant in both compilation and at runtime.
> 
> Not depending of static numbers is a good thing to me because it makes
> the whole user-space simpler since: a) you don't have to send a message
> to perform the initial family ID lookup and b) you don't have to
> subscribe to genl control events (which is required since the the
> floating family number may change if the module is unloaded).

You mean "Depending on static numbers...", don't you?
 
> > (As such, ipset-5 is deactivated by default in Xt-a 1.32 and needs to be 
> > turned on in mconfig.)
> > 
> > Xt-a files at the usual place.
> > 
> > The plain genl patch to ipset-5 can be found as a commit at 
> > git://dev.medozas.de/ipset in the "genl" branch. It has received a run 
> > through the testsuite (as far as it went until ospf), and I take that as 
> > an indication that proxying the protocol onto genl was successful.
> 
> This is going to confuse everyone. Since ipset-5 will be submitted into
> mainline soon, some distributors may start packaging the user-space genl
> binaries. Then, once we have it into the kernel, the distributed version
> will not work with the one running upon nfnetlink.

Yes, that worries me too.

> I think it's way easier to submit a patch to reserve the subsystem ID
> for ipset than adding this genl compatibility layer.

That was rejected some time ago. :-)
 
> BTW, Jozsef, do you plan to submit ipset for the next linux kernel
> release cycle?

Yes: ipset-5 depends on the jhash.h patch so as soon as it's in Patrick's 
tree, I can submit the patches.

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: Xtables-addons 1.32/ipset-GENL 5.2

[Pablo Neira Ayuso]

On 06/01/11 10:46, Jozsef Kadlecsik wrote:
> On Thu, 6 Jan 2011, Pablo Neira Ayuso wrote:
> 
>> On 04/01/11 05:14, Jan Engelhardt wrote:
>>> So a few people had been asking on whether ipset 5.x will be bundled 
>>> along with Xtables-addons. Naturally this is a difficult question 
>>> because ipset-5 wants a kernel patch. But yes, it is included as of Xt-a 
>>> 1.32 (just out).
>>>
>>> It has been augmented to not require the patch anymore, by moving it 
>>> over from nfnetlink (booo) to genetlink which does not depend on static 
>>> numbers, though you will need at least Linux 2.6.35 for this GENL 
>>> variant in both compilation and at runtime.
>>
>> Not depending of static numbers is a good thing to me because it makes
>> the whole user-space simpler since: a) you don't have to send a message
>> to perform the initial family ID lookup and b) you don't have to
>> subscribe to genl control events (which is required since the the
>> floating family number may change if the module is unloaded).
> 
> You mean "Depending on static numbers...", don't you?

yes, sorry for the confusion.

>>> (As such, ipset-5 is deactivated by default in Xt-a 1.32 and needs to be 
>>> turned on in mconfig.)
>>>
>>> Xt-a files at the usual place.
>>>
>>> The plain genl patch to ipset-5 can be found as a commit at 
>>> git://dev.medozas.de/ipset in the "genl" branch. It has received a run 
>>> through the testsuite (as far as it went until ospf), and I take that as 
>>> an indication that proxying the protocol onto genl was successful.
>>
>> This is going to confuse everyone. Since ipset-5 will be submitted into
>> mainline soon, some distributors may start packaging the user-space genl
>> binaries. Then, once we have it into the kernel, the distributed version
>> will not work with the one running upon nfnetlink.
> 
> Yes, that worries me too.
> 
>> I think it's way easier to submit a patch to reserve the subsystem ID
>> for ipset than adding this genl compatibility layer.
> 
> That was rejected some time ago. :-)

Indeed, I forgot that.

>> BTW, Jozsef, do you plan to submit ipset for the next linux kernel
>> release cycle?
> 
> Yes: ipset-5 depends on the jhash.h patch so as soon as it's in Patrick's 
> tree, I can submit the patches.

great.