Build ipset-6.23 on the Linux-2.6.32 kernel experience

New version of Ipset

Last week, in the children's Hospital to wait for a small doctor waiting for the interval, received a push message NetFilter mailing list, Ipset the latest 6.23 version of the new features, many are exactly what I need, especially the timeout and skbinfo parameter support, specific details please self-view manual, if you do not want to see so much, I here simply paste:

Timeout
All set types supports the optional timeout parameter when creating a set and adding entries. The value of the timeout
parameter for the Create command means the default timeout value (in seconds) for new entries. If a set is created with
Timeout support, and then the same timeout option can is used to specify Non-default timeout values when adding entries. Zero
Timeout value means the entry is added permanent to the set. The timeout value of already added elements can be changed
By readding the element using The-exist option. Example:

Ipset Create test Hash:ip timeout 300
Ipset Add test 192.168.0.1 Timeout 60
Ipset-exist Add test 192.168.0.1 timeout 600
...
Skbinfo, Skbmark, Skbprio, Skbqueue
All set types support the optional skbinfo extension. This extension allow to store the MetaInfo (firewall mark, TC class
and hardware queue) with every entry and maps it to packets by usage of the SET netfilter target with--MAP-SET option. Skb┅\
Mark option Format:mark or Mark/mask, where MARK and MASK is 32bit hex numbers with 0x prefix. If only Mark is speci‐
Fied mask 0xFFFFFFFF is used. Skbprio option has TC class Format:MAJOR:MINOR, where MAJOR and MINOR numbers is hex
Without 0x prefix. Skbqueue option is just decimal number.

Ipset Create foo Hash:ip skbinfo
Ipset add foo skbmark 0x1111/0xff00ffff skbprio 1:10 skbqueue 10
...
NoMatch
The hash set types which can store net type of data (i.e. hash:*net*) support the optional NoMatch option when adding
Entries. When matching elements in the set, entries marked as NoMatch is skipped as if those were not added to the set,
Which makes possible to build-sets with exceptions. See the example at hash type hash:net below.

When elements is tested by Ipset, the NoMatch flags is taken into account. If one wants to test the existence of a
Element marked with NoMatch in a set and then the flag must is specified too.
...
Compile

In short, compared to the older version of 4.5, did add a lot of new things, so can't wait to download, compile, trial, generally speaking, these steps are routine, will not encounter any particularly difficult, especially after reading its readme:

0. You need the source tree of your kernel (version >= 2.6.32)
And it has been configured with Ip6tables support enabled,
Modules compiled. For kernel versions < 2.6.39 please apply
The Netlink.patch against your kernel tree, which adds the
New subsystem identifier for Ipset.
And my kernel is 2.6.32 version, although relatively old, but there is no way. However, since the explicit support 2.6.32, it is reassuring that, in addition to the Readme, its website also clearly stated that the support 2.6.32 kernel:
For the new branch
Linux kernel source code (version >= 2.6.32)
Source of ipset:ipset-6.23.tar.bz2 (md5sum)
So the routine work begins:
tar xjvf ipset-6.23.tar.bz2
CD ipset-6.23
./configure
The report says there's no netlink.patch for the kernel, but it's not a problem, but at this point, I'm asking:
Question: Obviously just updated the header file, why do you want to give the kernel source tree patch ah?
I feel that this action is not quite regular, in order not to rely on the source tree, I will this patch to compile the required 2.6.32 kernel header file, so configure successfully passed, but encountered another problem, prompted me not to install LIBMNL, because I this is a clean environment, so the NetFilter site downloaded a new version of the LIBMNL source, routine installation libmn L This step for me is not necessary, such as my daily toss netfilter, how may not install LIBMNL ah ...
Next is make, smooth through, then make modules, error a lot, and then I feel that this ipset-6.23 is not support 2.6.32, all the documentation is TMD in the nonsense! The error is the following file:
ipset-6.23/kernel/net/netfilter/xt_set.c
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' set_match_v0_checkentry ':
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:99:error: ' const struct Xt_mtchk_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:108:error: ' const struct Xt_mtchk_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' Set_match_v0_destroy ':
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:123:error: ' const struct Xt_mtdtor_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' set_match_v1_checkentry ':
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:148:error: ' const struct Xt_mtchk_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:157:error: ' const struct Xt_mtchk_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' Set_match_v1_destroy ':
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:169:error: ' const struct Xt_mtdtor_param ' has no member named ' Net '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' set_target_v0 ':
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:231:error: ' const struct Xt_match_param ' has no member named ' Targinfo '
/usr/src/ipset-6.23/kernel/net/netfilter/xt_set.c:in function ' set_target_v0_checkentry ':
I found the following macro definition in this source file:

#ifdef have_checkentry_bool#define check_ok    1#define check_fail (err) 0#define CONST       const#define FTYPE       Bool#define xt_par_net (PAR) null#else/* Linux_version_code >= kernel_version (2,6,35) */#define CHECK_OK    0# Define Check_fail (Err) (ERR) #define Const#define FTYPE       int#define xt_par_net (PAR)->net#endif

Obviously, according to the comments, I should define have_checkentry_bool, but the definition of this macro should be automated to be reasonable, should not go to manual intervention, in the Configure file, found the following definition statement:

If Test-f $ksourcedir/net/netfilter/xt_state.c &&     $GREP-Q ' bool State_mt_check ' $ksourcedir/net/ netfilter/xt_state.c; Then    {$as _echo "$as _me:${as_lineno-$LINENO}: Result:yes" >&5$as_echo "Yes" >&6;}    Have_checkentry_bool=defineelse    {$as _echo "$as _me:${as_lineno-$LINENO}: Result:no" >&5$as_echo "no" > &6; }    Have_checkentry_bool=undeffi

Attention $ksourcedir/net/netfilter/xt_state.cThis vicious statement, I immediately furious, specify the source file is to find in this file the match check callback function return value type, the author can't pass the kernel version number also distinguish? is the return value specification for the match check not fixed for a fixed kernel version? For the 2.6.32 kernel, can the following call change? ：

if (par->target->checkentry! = NULL &&!par->target->checkentry (PAR))    return-einval;

I'm angry, but I can't force the open source software to be what it is, as Bill Gates once said, I'm a little bit too sure that a programmer with no pay can write first-class software. Well, I specify a certain source code file, let the configure process to define the evil Have_checkentry_bool macro, it is worth noting that, in addition to the macro, the same as the purpose of the different kernel version to adapt to the role of a macro: Have_xt_target _param, its role is to define it as Xt_target_param in a lower version of the kernel without defining the xt_action_param struct, and to turn it into xt_match_param when necessary. After defining the two macros, Xt_set compiled through, but the Ipset kernel module itself is an error, and this ipset kernel module itself is more important than xt_set, to know that Xt_set is only a link with the iptables of the module used, even if it does not fit, It should not be difficult to write your own, however, for the kernel module of Ipset itself, if you want to write yourself, it is equivalent to the realization of ipset-6.23 itself ... Fortunately, this time the new error is not many:
  CC [m] /usr/src/ipset-6.23/kernel/net/ NETFILTER/IPSET/IP_SET_CORE.O
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:in function ' Call_ Ad ':
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:1444:error: ' Size_max ' Undeclared (first use In this function)
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:1444:error: (Each undeclared Identifier is reported only once
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:1444:error:for Each function it appears in.)
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:1444:warning:type defaults to ' int ' in Declaration of ' _min1 '
/usr/src/ipset-6.23/kernel/net/netfilter/ipset/ip_set_core.c:1444:warning:comparison of distinct Pointer types lacks a cast
Make[4]: * * * [/USR/SRC/IPSET-6.23/KERNEL/NET/NETFILTER/IPSET/IP_SET_CORE.O] Error 1
strong> It says that Size_max is not defined, This constant is more than 3.5 of the high version of the kernel, 2.6.32 if not manually defined by the compiler can not be compiled through, although it is not difficult to manually define, but increasingly feel the ipset-6.23 of the compilation of documents and support version of the documentation is irresponsible nonsense, is simply in the RIP!! I found another document that made it clear how much of a plausible fact it would be:
2 Supported Configurations
* Iptables >= 1.4.3
* Kernel-source >= 2.6.29
For ipset-6 you need:
* LIBMNL
* Linux kernel >= 2.6.35
At least with the ipset-6.23 source of comments can be right, but in addition to the nonsense.
This is a disgusting fact! After I have defined the Size_max, the compilation will pass smoothly, although there are some types of warnings to convert, but ignoring them will not have any big consequences. So I think it's necessary to make a real patch in order to make ipset-6.23 's documentation better for the public, and indeed I do, and I want to do something that has the following goals:
1. Compiling ipset-6.23 relies only on kernel header files and no longer relies on source code;
2. Rely on the kernel version to fit the data structure and macro definition instead of looking for eigenvalues in the kernel source.
Since my goal was only to compile successfully on the 2.6.32 kernel, I did not test 2.6.33/34/35/36 and 3.0/1/2/3/4/5/6/7/8 ... but I believe that more than 3.5 of the kernel version will be able to compile successfully. Ipset-6.23 's packager may not have been tested at all in the lower version, such as the 2.6.32 kernel, and the work that followed the fix might have been left to someone like me, and, in addition, the 2.6.32 version might not have been used as much, and it's taken for granted that it doesn't provide full access support. I do not blame the author and the packager, perhaps in the revision process is indeed some impulse, so here to clarify.
This is reminiscent of the term fashion, this is at the end of the 19th century extensive industrialization reached the peak of the birth of a word, people generally believe that progress is inevitable, the latest is the best, the change of the forward, speed is accelerated, the way to maintain fashion is to stand in the forefront of the trend. This concept has been widely embraced and passed on to the Linux 3.X kernel era ... If you are still using the 2.6.9 kernel, and found a big bug in it, no one cares about you, the most front-end surfers will say: The world is improving, why not try the 3.17 version of the kernel?!
Go directly to the ipset-6.23 directory and execute PATCH-P1 <. /ipset-6.23.patch, while the contents of Ipset-6.23.patch are as follows:

Diff-nur ipset-6.23/kernel/include/linux/netfilter/ipset/ip_set.h ipset-6.23.new/kernel/include/linux/netfilter/ Ipset/ip_set.h---ipset-6.23/kernel/include/linux/netfilter/ipset/ip_set.h 2014-09-23 19:18:34.000000000 +0800+++ Ipset-6.23.new/kernel/include/linux/netfilter/ipset/ip_set.h 2014-11-13 16:27:15.000000000 +0800@@ -26,6 +26,9 @@ # Define IP_SET_MODULE_DESC (A, B, c) _ip_set_module_desc (A, __stringify (b), __stringify (c)) + #if Linux_ve Rsion_code <= kernel_version (2,6,35) + #define SIZE_MAX (~ (size_t) 0) + #endif/* Set features */enum Ip_set_feature {Ipset_type_ip_flag = 0,diff-nur ipset-6.23/kernel/net/netfilter/xt_set.c ipset-6.23.new/kernel/net/netfilter/xt_ SET.C---ipset-6.23/kernel/net/netfilter/xt_set.c 2014-09-23 19:18:34.000000000 +0800+++ ipset-6.23.new/kernel/net/ netfilter/xt_set.c 2014-11-13 16:26:50.000000000 +0800@@ -28,12 +28,18 @@ module_alias ("Ipt_set"); Module_alias ("Ip6t_set"); -#ifdef have_checkentry_bool+ #if Linux_version_code <= kernel_version (2,6,35) #define CHECK_OK 1 #define CHECK_FAIL (ERR) 0 #define Const Const #define FTYPE bool+/* only confirm version 2.6.32:) */+ #if linux_version_code = kernel_ve Rsion (2,6,32) +/* Netns is not supported completly */+ #define XT_PAR_NET (PAR) (&init_net) + #else #define X T_par_net (PAR) null+ #endif #else/* Linux_version_code >= kernel_version (2,6,35) */#define CHECK_OK 0 #define CH Eck_fail (Err) (err) @@ -217,7 +223,7 @@ -217,7 * Revision 0 interface:backward compatible with Netfilter/iptables */-#i Fdef have_xt_target_param+ #if linux_version_code <= kernel_version (2,6,35) #undef xt_action_param #define Xt_action _param Xt_target_param #define CAST_TO_MATCH (const struct Xt_match_param *)

With this patch, the IPSET-6.23 software package can be compiled directly on the 2.6.32 kernel.
Compilation PostScript: 1. The Have_checkentry_bool macro for namespace ipset-6.23 defines xt_par_net as NULL, and XT_PAR_NET this macro takes out the net struct body:

struct NET {    ...    struct net_generic    *gen;}

It is worth noting that the Gen field:

struct Net_generic {    unsigned int len;    struct Rcu_head rcu;    void *ptr[0];};

Let's take a look at its notes:

/* * Generic net pointers is to is used by modules to put some private * stuff on the struct net without explicit struct NET modification * The rules is simple: * 1. Register the OPS with Register_pernet_gen_device to get the ID * of    your private pointer; * 2. Call Net_assign_generic  () to put the private data on the struct * NET (most preferably this should is done in the    ->init callback *    of the OPS registered); * 3. Don't change this pointer while the net is alive; * 4. Do no try to has any private reference on the Net_generic object. * * After accomplishing all of the above, the private pointer can is * accessed with the net_generic () call. */

Ipset is to put his own data in the Gen field, if net because the Have_checkentry_bool macro is null, then with, Mao? Can you use it even if it is compiled? In fact, since the value is not determined when the net is empty:

Static inline struct ip_set_net *ip_set_pernet (struct net *net) {    return net_generic (NET, ip_set_net_id);}

This can cause panic to crash. Therefore, this primitive code cannot be used at all when the Have_checkentry_bool macro is defined. Because net is empty, if you judge, the kernel will not crash, but can not get any data, if not judged, the kernel will crash. So the code itself can be said to be wrong!
We know that the 2.6.32 kernel might not be enough to support the net namespace, but anyway, init_net is there, so I defined xt_par_net as &init_net.
2. Should I submit a patch I am afraid of being scolded, and I do not want to curse, so this matter to distant friends to do. In my opinion, a lot of people who make mistakes are stubborn, and gently say a word to start a curse. People who can only program are not provoked. Other do not say, anyway, I was looking at the readme operation, the above written >=2.6.32 can, however I just can't compile, confiure inside the method is really disgusting. Anyway is write wrong!!! Just do it!!!

Build ipset-6.23 on the Linux-2.6.32 kernel experience