Re: Xtables-addons 1.32/ipset-GENL 5.2

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux