First of all: l7filter-patchset is built to patch the kernel sources only. There is no need to hardwire the version of l7filter into the ebuild of iptables. Problem: if i.e. the kernel is patched with a masked l7filter package, lets say version 2.6 then iptables tries to patch itself with the patch v2.3 (see ebuild). This could cause serious impacts and icompatibilities, since the version of l7filter-kernel patch and the version of l7filter-iptables patch MUST match. Suggestion: remove the useflag l7filter and let the l7filter-ebuild decide or make the useflag to gather the version of the applied l7filter patch.
that doesnt really make sense ... there is no way to make iptables dynamically figure out what version of l7 it needs to use if having the patch in the ebuild is a problem, then we punt it ... make users patch iptables themselves
I suggest to switch back to the useflag -extensions as before, otherwise we could end up with dozens of useflags for every single kernel patch. Additionally it is not iptables devs job to make sure l7-filter is working. It is rather the job of l7-filter devs, to make sure l7-filter patches the kernel sources correctly and that the iptables headers are installed into the kernel sources and to make sure iptables builds fine and finally marking l7-filter as stable. Leave the choice about which l7-filter version the user wanna have installed up to them. (my opinion)
> Leave the choice about which l7-filter version the user wanna have installed up > to them. which means we punt l7 support from the ebuild personally i dont care; i dont use l7 nor do i know what it is
As soon as iptables builds with the iptables headers in the kernel source, there is no need to add l7 to iptables useflag. I think, it's best to let it handle by l7-filter patches - similar to the patch-o-matic and other kernel patchsets. All these patches may add some iptables headers in the kernel source <<< that's all iptables should pay attention to if USE="extensions" is set. Bundling the version of l7-filter into the ebuild is not good, since i.e. you may run this version of iptables against different kernels which require different versions of l7-filters, i.e. kernel 2.6.18 requires l7-filter version 2.6. I.e. a user is running kernel 2.6.18 and installed l7-filter version 2.6, then reemerges iptables and they think it is version 2.6. But it's not, it is an untested mixed situation of l7-filter version 2.6 and 2.3.
again, that doesnt make sense ... iptables userspace needs to build the userspace iptables l7 module in order to work ... so iptables itself needs the l7 patch if it is to work with the l7 in the kernel you cant just apply the patch to the kernel and have the user space iptables magically start working
Well then, the ebuild of iptables MUST gather the version of the installed l7-filter package. I.e. by parsing the output of emerge -p l7-filter with sed.
(In reply to comment #5) > again, that doesnt make sense ... iptables userspace needs to build the > userspace iptables l7 module in order to work ... so iptables itself needs the > l7 patch if it is to work with the l7 in the kernel > > you cant just apply the patch to the kernel and have the user space iptables > magically start working I still don't understand what you mean: The older version of iptables built fine with "extensions" useflag and both patches (iptables-layer7-2.6.patch, kernel-2.6.18-layer7-2.6.patch) applied to the kernel sources. What I mean: iptables should look into the kernel sources for patches & extensions and patch itself automatically if the "extensions" useflag is set. I thought this is already standard. Since extensions should use the iptables-headers of the kernel. I simply don't understand why it should be necessary to put the patch into the ebuild?
> What I mean: iptables should look into the kernel sources for patches & > extensions and patch itself automatically if the "extensions" useflag is set. I > thought this is already standard. Since extensions should use the > iptables-headers of the kernel. no, this is not what it did ... iptables have always pulled down the l7 patch and applied it to the iptables ebuild in order to build the user space l7 module previously, USE="extensions" would install both imq/l7 patches and look in the kernel tree to figure out what extensions to build. but it did so only to figure out what userspace modules were viable ... it did not take patches or anything out of the kernel tree
Hm, I see. Now, how can we solve that? Well, what about parsing the output of emerge -p l7-filter with sed to get the installed l7-filter version? Or if you know of any other solution?
Well, there are differences between the patch-versions 2.3 and 2.6: diff iptables-layer7-2.3.patch iptables-layer7-2.6.patch 1,3c1,2 < diff -Nurp iptables-1.3.3/extensions/.layer7-test iptables-1.3.3-layer7/extensions/.layer7-test < --- iptables-1.3.3/extensions/.layer7-test 1969-12-31 18:00:00.000000000 -0600 < +++ iptables-1.3.3-layer7/extensions/.layer7-test 2005-08-14 17:13:04.000000000 -0500 --- > --- iptables-1.3.5-stock/extensions/.layer7-test 1969-12-31 18:00:00.000000000 -0600 > +++ iptables-1.3.5-layer7/extensions/.layer7-test 2006-05-09 01:10:47.000000000 -0500 7,10c6,8 < diff -Nurp iptables-1.3.3/extensions/libipt_layer7.c iptables-1.3.3-layer7/extensions/libipt_layer7.c < --- iptables-1.3.3/extensions/libipt_layer7.c 1969-12-31 18:00:00.000000000 -0600 < +++ iptables-1.3.3-layer7/extensions/libipt_layer7.c 2006-01-18 00:05:35.000000000 -0600 < @@ -0,0 +1,378 @@ --- > --- iptables-1.3.5-stock/extensions/libipt_layer7.c 1969-12-31 18:00:00.000000000 -0600 > +++ iptables-1.3.5-layer7/extensions/libipt_layer7.c 2006-09-10 15:44:20.000000000 -0500 > @@ -0,0 +1,393 @@ 85a84,98 > + /* Ignore everything on the line beginning with the > + first space or tab . For instance, this allows the > + protocol line in http.pat to be "http " (or > + "http I am so cool") instead of just "http". */ > + if(strchr(line, ' ')){ > + char * space = strchr(line, ' '); > + space[0] = '\0'; > + } > + if(strchr(line, '\t')){ > + char * space = strchr(line, '\t'); > + space[0] = '\0'; > + } > + > + /* sanity check. First non-comment non-blank > + line must be the same as the file name. */ 89c102 < + protoname, filename); --- > + line, filename); 389,392c402,404 < diff -Nurp iptables-1.3.3/extensions/libipt_layer7.man iptables-1.3.3-layer7/extensions/libipt_layer7.man < --- iptables-1.3.3/extensions/libipt_layer7.man 1969-12-31 18:00:00.000000000 -0600 < +++ iptables-1.3.3-layer7/extensions/libipt_layer7.man 2005-08-14 17:13:04.000000000 -0500 < @@ -0,0 +1,13 @@ --- > --- iptables-1.3.5-stock/extensions/libipt_layer7.man 1969-12-31 18:00:00.000000000 -0600 > +++ iptables-1.3.5-layer7/extensions/libipt_layer7.man 2006-09-10 15:55:19.000000000 -0500 > @@ -0,0 +1,14 @@ 401c413 < +name in /etc/l7-protocols/ --- > +name in /etc/l7-protocols/ or one of its first-level child directories. 404c416,417 < +Use \fIdirectory\fP instead of /etc/l7-protocols/ --- > +Use \fIdirectory\fP instead of /etc/l7-protocols/. This option must be > +specified before --l7proto.
unfortunately, i cant think of a clean solution ... what you've proposed is the only real way of knowing which version to use, but that doesnt translate well (or at all) into proper dependencies with portage in other words, there is no clean way to translate the l7 2.3 or 2.6 logic into the DEPEND variable of iptables this is why there is supposed to be a clean userspace<->kernel ABI ... so that the l7 2.3 iptables modules works fine with a kernel using l7 2.6
Okay. Then I have the following suggestions: 1. Since the marginal changes of the iptables patch I suggest to switch to version 2.6 for that patch. 2. I am into l7-filter for almost a year now and I had tested version 2.5 of l7-filter with kernel 2.6.17.x on gentoo and vanilla sources without any problems. In version 2.6 of l7-filter only an additional patch for kernel 2.6.18 was added and the patch for kernel 2.6.17.x is the same as in version 2.5 of l7-filter. Since version 2.6 of l7-filter came out I am testing it on a production system on kernel 2.6.18 with the modified ebuild of iptables to make sure to get version 2.6. Runs without any errors. So, I suggest to mark l7-filter version 2.6 as stable.
Another solution: modify the l7-filter ebuild so it writes the version as a comment into the file: /usr/src/linux/net/ipv4/netfilter/ipt_layer7.c which can then be read out by iptables ebuild.
there is no iptables version that has l7 2.6 in it as no one has pointed it out and the answer is no; it is not valid for the iptables package to inspect the kernel sources to figure out what version of l7 to apply
(In reply to comment #14) > there is no iptables version that has l7 2.6 in it as no one has pointed it out That's the reason I built my own iptables ebuild aka version -r41 which uses l7 version 2.6. So there is at least my iptables version using version 2.6 l7. :) I copied the iptables ebuild version -r4 to portage overlay, renamed it to -r41, edited the version-string of the ebuild to 2.6 and created the digest. iptables built without any problems and works fine.
well iptables-1.3.6-r1 now has updated l7filter patch as for the rest of the issues you raised here, that is a bug in l7 itself
