Bugzilla Bug 150124

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