To Linux-2.6.32 compile the kernel ipset-6.23 bumpy experience

The new version number Ipset

Last week, a doctor waited at the children's Hospital for a gap called quantity. A mailing list that accepts Netfilterpush information, List Ipset new features of the latest 6.23 version number, very like what I need now is, especially the timeout and skbinfo support parameters, for more details, please refer to their own 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 number of 4.5. I did add a lot of new things, so I couldn't wait to download them. Compile. Trial, generally, these steps are routine. Will not encounter any particularly big difficulties, 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 number, although the comparison is older. But there is no way. It's just that the support 2.6.32. That's a relief. In addition to the Readme, the site also understands 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)
Then started the routine work:
tar xjvf ipset-6.23.tar.bz2
CD ipset-6.23
./configure
The report says no Netlink.patch is being played for the kernel. It's just not a thing. At this point, however, I raised the question:
Question: Obviously just updated the header file, why do you want to give the kernel source code tree patch ah?
I feel that this action is not quite regular, in order not to rely on the source tree, I hit the patch to compile the required 2.6.32 kernel header file, so configure successfully passed, but encountered another problem. Tip I did not install LIBMNL, because I this is a clean environment, so at the netfilter site download a new version of the LIBMNL source code. Routine installation of LIBMNL. 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 felt. This ipset-6.23 basically does 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 definitions 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, based on staring, I should define Have_checkentry_bool, but this macro definition should be self-motivated to be reasonable, should not go to manual intervention. In the Configure file, the following definition statements were found:

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 code 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 differentiate? is the return value specification for the match check not fixed for a fixed kernel version number? For the 2.6.32 kernel, can the following call change? ：

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

I was very angry. But I can't force open-source software to do anything, just like Bill Gates said before. The process of not getting paid the ape can't write first-class software, which I have a little bit of a letter.

All right. I specify a certain source code file, let configure process to define that evil Have_checkentry_bool macro. It is important to note that, in addition to that macro, there is another macro that is designed to fit between different kernel version numbers: Have_xt_target_param. Its role is to define it as xt_target_param in the kernel of the lower version without defining the Xt_action_param struct. Turn into xt_match_param when necessary. After defining the two macros, Xt_set compiled the pass, but the Ipset kernel module itself has an error. And this Ipset kernel module itself is more important than xt_set, to know that Xt_set is only a iptables linkage with the module used, even if it does not fit. Writing one yourself should not be difficult, however for the kernel module of Ipset itself. If you want to write your own, it is equivalent to the realization of ipset-6.23 itself ... OK. There are not many new errors this time:
  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 undefined. This constant is in the high version of more than 3.5 kernel, 2.6.32 assume that not manually defined by the basis can not be compiled through, although it is not difficult to manually define, but increasingly think that the ipset-6.23 compiled documents and support version number of the document is irresponsible nonsense. It's just a rip-off! I found another document. It is clear how much of a plausible fact:
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 the gaze can be ipset-6.23 in the source code. Besides, it's nonsense.
This is a disgusting fact! After I have defined the Size_max, the compilation will pass smoothly, although there are some types of conversion warnings, 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, actually I did, and I wanted to do something that had the following goals:
1. Compiling the ipset-6.23 relies solely on the kernel header files and no longer relies on the source code.
2. Rely on the kernel version number to fit the data structure and macro definition instead of looking for eigenvalues in the kernel source code.
Because my goal was only to compile successfully on the 2.6.32 kernel, because 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 the kernel version number above 3.5 will be able to compile successfully.

Ipset-6.23 's packers may not have tested at all on the lower version, like the 2.6.32 kernel. This job, and the corrections that followed, may have been left to me, in addition to that. 2.6.32 This version number may not be used in many people, it is natural to not provide full access to the support. I do not blame the author and the packager, perhaps in the revision process is indeed some impulse. So clarify here.

This is reminiscent of the term Vogue, which was born at the peak of the extensive industrialization at the end of the 19th century. It is generally believed that progress is inevitable, the latest is the best, the change of the forward, the 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 ... Suppose you're still using the 2.6.9 kernel, and you've found a big bug in it, and nobody cares about you. Surfers at the forefront of the trend will say: "The world is making progress, why not try the kernel of version 3.17?"
Go directly to the ipset-6.23 folder and run Patch-p1 <. /ipset-6.23.patch is available, while the contents of Ipset-6.23.patch such as the following:

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 look at its gaze:

/* * 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 its own data in the Gen field. Suppose net because the Have_checkentry_bool macro is null, then with, Mao? Can you use it even if it is compiled? In fact. Because there is no inference that net is empty when the value is taken:

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, assuming that the kernel does not crash, but does not take any data, assuming that there is no inference, the kernel will crash. So the code itself can be said to be wrong!
We know that the 2.6.32 kernel may not support the net namespace well enough. But anyway, init_net is there, so I define xt_par_net as &init_net.
2. Should I submit a patch I'm afraid of being scolded. And I don't want to curse. So this thing to the distant friends to do. In my opinion, a lot of people who make mistakes are stubborn. You can start a curse by saying a word lightly.

A man who can only be programmed cannot afford to be offended.

Don't say anything else. Anyway, I was looking at the readme operation. The above written >=2.6.32 can, but I just can't compile, confiure inside the method is really disgusting.

Anyway not written correctly!. You can't do it with a TMD.

！

Copyright notice: This article Bo Master original articles, blogs, without consent may not be reproduced.

To Linux-2.6.32 compile the kernel ipset-6.23 bumpy experience