Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

layer7 doesn't seem to work well with gentoo-sources-2.6.17-r4. This is with
iptables-1.3.5-r1:

# iptables -A FORWARD -m layer7 --l7proto bittorrent -o br0 -j DROP
iptables: Unknown error 4294967295


and with iptables-1.3.5-r3:

# iptables -A FORWARD -m layer7 --l7proto bittorrent -o br0 -j DROP
iptables: Invalid argument


During kernel compilation I get this:

...
  CC      net/ipv4/netfilter/ipt_layer7.o
net/ipv4/netfilter/ipt_layer7.c:460: warning: initialization from incompatible
pointer type
net/ipv4/netfilter/ipt_layer7.c:461: warning: initialization from incompatible
pointer type
...


When I remerge iptables, I get messages of this kind:

"* For layer 7 support emerge net-misc/l7-filter-2.1 before this"


I would like to emerge 2.1, but that doesn't exist in portage! I'd like to use
a stable version, but 1.4 doesn't even work with gentoo-sources-2.6.16-r*.
That's why I switched to l7-filter-2.2, which now also doesn't work with the
latest gentoo-sources.
Unfortunately, there now is no version at all in portage that works with the
latest gentoo-sources. Hopefully, there will be a stable one soon.

Please let me know if you need anymore infos or how I can help!

oh, btw:

# grep _IP_NF_ /usr/src/linux/.config
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_CT_ACCT=y
CONFIG_IP_NF_CONNTRACK_MARK=y
CONFIG_IP_NF_CONNTRACK_EVENTS=y
CONFIG_IP_NF_CONNTRACK_NETLINK=y
CONFIG_IP_NF_CT_PROTO_SCTP=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IRC=y
CONFIG_IP_NF_NETBIOS_NS=y
CONFIG_IP_NF_TFTP=y
CONFIG_IP_NF_AMANDA=y
CONFIG_IP_NF_PPTP=y
CONFIG_IP_NF_H323=y
# CONFIG_IP_NF_QUEUE is not set
CONFIG_IP_NF_MATCH_LAYER7=y
# CONFIG_IP_NF_MATCH_LAYER7_DEBUG is not set
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
CONFIG_IP_NF_MATCH_RECENT=y
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_DSCP=y
CONFIG_IP_NF_MATCH_AH=y
CONFIG_IP_NF_MATCH_TTL=y
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_MATCH_HASHLIMIT=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_TARGET_NETMAP=y
CONFIG_IP_NF_TARGET_SAME=y
CONFIG_IP_NF_NAT_SNMP_BASIC=y
CONFIG_IP_NF_NAT_IRC=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_NAT_TFTP=y
CONFIG_IP_NF_NAT_AMANDA=y
CONFIG_IP_NF_NAT_PPTP=y
CONFIG_IP_NF_NAT_H323=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
CONFIG_IP_NF_TARGET_DSCP=y
CONFIG_IP_NF_TARGET_TTL=y
CONFIG_IP_NF_TARGET_CLUSTERIP=y
CONFIG_IP_NF_RAW=y
CONFIG_IP_NF_ARPTABLES=y
CONFIG_IP_NF_ARPFILTER=y
CONFIG_IP_NF_ARP_MANGLE=y

Manually patching the kernel with the sources netfilter-layer7-v2.3.tar.gz from
http://l7-filter.sourceforge.net/ works fine.

Unpack the source and apply both patches with:

cd /usr/src/linux
patch -p1 < iptables-layer7-2.3.patch
patch -p1 < kernel-2.6.17-layer7-2.3.patch

make sure, you have compiled iptables with useflag "extensions", to do so:

echo "net-firewall/iptables extensions" >> /etc/portage/package.use

and remerge iptables.

Finally, make sure to enable Layer7 in the config.

i'd even go the latest version of iptables which uses the l7filter use flag.

I'll look at getting some later versions stabilised soon and old versions
purged.

The 'iptables: Unknown error 4294967295' and 'iptables: Invalid argument' are
due to the iptables not being compiled after l7-filter support is added to the
kernel.

If the error messages only come from iptables not being reinstalled after
having l7 support in the kernel, the following should work:

1. emerge -C l7-filter l7-protocols
2. emerge -C gentoo-sources-2.6.17-r4 
3. rm -rf /usr/src/linux /usr/src/linux-2.6.17-gentoo-r4
4. emerge gentoo-sources-2.6.17-r4
5. ln -s /usr/src/linux-2.6.17-gentoo-r4 /usr/src/linux
6. emerge l7-filter-2.2 l7-protocols-2006.06.03
7. CONFIG_IP_NF_MATCH_LAYER7=y
8. make && make modules_install
9. USE="l7filter" emerge iptables-1.3.5-r3
10. reboot (the kernel above of course ;-))

Well, it did not work!

I did try patching with l7 v2.3 patches manually, but without success. Ok, I
admit I didn't try very hard. But as the l7-filter ebuild seems to be
necessary, manually patching with another patch seems to mess everything up
(eg. ebuild fails).

@Daniel: I guess this bug can be interpreted as a version bump request to
l7-v2.3, although I don't know if 2.3 does the job. I will do some testing...

I can also confirm 'iptables: Unknown error 429496729"
Firestarter stop working after install 2.6.17-r4 kernel.

update:
I also trayed advises from comment 2 and 3 but CONFIG_IP_NF_MATCH_LAYER7 is not
present after pathes in .config i dont know what to do so im falling back to
2.6.16-r13 kernel
Sry for english

Ok i'am found it you nust check "Connection tracking (required for masq/NAT)
(IP_NF_CONNTRACK)" and CONFIG_IP_NF_MATCH_LAYER7=y will by visible :P

(In reply to comment #2)
> i'd even go the latest version of iptables which uses the l7filter use flag.

This is not neccessary, the latest stable iptables work fine, the only thing:
iptables needs to be installed with extensions support.

A reemerge of iptables after patching the kernel with the two patches included
in the source is not neccessary.

(In reply to comment #3)
> If the error messages only come from iptables not being reinstalled after
> having l7 support in the kernel, the following should work:
> ...
> Well, it did not work!

It can't work, since the kernel 2.6.17 needs a different patch. The l7-filter
patch of version 2.2 will only work for kernel 2.6.16.x and not for kernel
2.6.17.x

> 
> I did try patching with l7 v2.3 patches manually, but without success. Ok, I
> admit I didn't try very hard. But as the l7-filter ebuild seems to be
> necessary, manually patching with another patch seems to mess everything up
> (eg. ebuild fails).

Nothing would be messed up, since you only patch the kernel sources and nothing
else is touched.


> @Daniel: I guess this bug can be interpreted as a version bump request to
> l7-v2.3, although I don't know if 2.3 does the job. I will do some testing...

Yes, it is a version bumb.

(In reply to comment #8)
> > I did try patching with l7 v2.3 patches manually, but without success. Ok, I
> > admit I didn't try very hard. But as the l7-filter ebuild seems to be
> > necessary, manually patching with another patch seems to mess everything up
> > (eg. ebuild fails).
> 
> Nothing would be messed up, since you only patch the kernel sources and nothing
> else is touched.

You're right, it works applying the patches manually, thanks! 

With 'messed up' I meant that the l7-filter ebuild doesn't work anymore as soon
as the new patches have been applied. This is understandable of course, as the
2.3 patch can't be reversed with 2.2. I had troubles with the ebuild and the
kernel source. After some combination of emerging, unmerging of l7-filter-2.2
and applying patches 2.3, I messed up the kernel source and couldn't even do
'make menuconfig' anymore.

kernel 2.6.17-r4 successfully patched by hand with l7-filter 2.3

Both patches applied without errors.

System is running stable since 2006-07-25 for almost 3 days.

layer7-match works and iptables filters as expected.

Dependency needs to be set for l7-filter-2.2 since it does not work with
2.6.16.x kernel sources.

(In reply to comment #10)
> kernel 2.6.17-r4 successfully patched by hand with l7-filter 2.3
> 
> Both patches applied without errors.
> 
> System is running stable since 2006-07-25 for almost 3 days.
> 
> layer7-match works and iptables filters as expected.
> 

corrected:

Dependency needs to be set for l7-filter-2.2 since it DOES NOT WORK WITH
2.6.17.x kernel sources.

Thanks cilly, Piotrek and R!tman

Sorry i was wrong in comment #2.

I've added l7-filter-2.3
iptables-1.3.4-r4 also contains the latest patch there too.

I couldn't do dependencies because the kernel sources could be anything. I did
however put a explicit die into 2.2 and 1.4 if you used a too modern kernel.

Because of the kernel priviledge escalation bugs (that are fixed in 2.6.17) can
you please reminded me to push for 2.3 to go stable in 30days.

Hope I haven't needed to reply to any other comments here. just ask if I have.

(In reply to comment #12)

> I've added l7-filter-2.3
> iptables-1.3.4-r4 also contains the latest patch there too.

Do you really mean iptables-1.3.4-r4?

To point out again:

iptables itself does not need any patch, iptables needs only to be compiled
with extensions. The two patches, which are included in the l7-filter source
patch only kernel sources. The patch iptables-layer7-2.3.patch patches the
netfilter extensions in the kernel source so iptables can use the layer7 match
extensions. The patch kernel-2.6.17-layer7-2.3.patch patches the kernel source
to be able to compile the kernel with Layer7 support.

> Because of the kernel priviledge escalation bugs (that are fixed in 2.6.17) 
> can you please reminded me to push for 2.3 to go stable in 30days.

of course :-)

(In reply to comment #12)
> Thanks cilly, Piotrek and R!tman

Thank YOU!

> I've added l7-filter-2.3
> iptables-1.3.4-r4 also contains the latest patch there too.

Using both, works without any troubles :-)! 

> Because of the kernel priviledge escalation bugs (that are fixed in 2.6.17) can
> you please reminded me to push for 2.3 to go stable in 30days.

I'll do that! I guess you'll also want the corresponding iptables version
stablized.

(In reply to comment #13)
> Do you really mean iptables-1.3.4-r4?
> 
> To point out again:
> 
> iptables itself does not need any patch, iptables needs only to be compiled
> with extensions. The two patches, which are included in the l7-filter source
> patch only kernel sources. The patch iptables-layer7-2.3.patch patches the
> netfilter extensions in the kernel source so iptables can use the layer7 match
> extensions. The patch kernel-2.6.17-layer7-2.3.patch patches the kernel source
> to be able to compile the kernel with Layer7 support.

You're probably right about that, iptables-1.3.5-r4 is not really needed. But I
guess it's a reasonable approach to include the iptables-layer7-2.3.patch in
iptables, not l7-filters. Therefore, if you follow that approach, you do need
this version. Otherwise the patch is not applied.

(In reply to comment #14)

> You're probably right about that, iptables-1.3.5-r4 is not really needed. But I
> guess it's a reasonable approach to include the iptables-layer7-2.3.patch in
> iptables, not l7-filters. Therefore, if you follow that approach, you do need
> this version. Otherwise the patch is not applied.

iptables-layer7-2.3.patch does not patch iptables at all!

In my opinion, the iptables-layer7-2.3.patch has a name which gives wrong
conclusions. It should be named: netfilter-layer7-2.3.patch or
iptables-extension-layer7-2.3.patch.

I do not see an advantage to include this patch into iptables itself, since
iptables can use the netfilter extensions in the kernel sources.

Keep in mind: iptables does not need to be recompiled, if the layer7-patch
changes, compiling the new kernel and iptables needs only to be restarted and
it loads the newly built extension.

In my opinion it is a disadvantage to include the layer7-patch into iptables,
since upon a layer7-change, you need to compile the kernel AND iptables.

Therefor, I advise to stay with the "extensions"-useflag in iptables.

(In reply to comment #12)
> Because of the kernel priviledge escalation bugs (that are fixed in 2.6.17) can
> you please reminded me to push for 2.3 to go stable in 30days.

This is the reminder.

he current stable version of l7-filter (1.4) will not compile with a2.6.12(?)
kernels and above. l7-filter-2.3 compiles will 2.6.17 and hopefully later
versions.

Please bump this to stable and purge earlier versions.

Test Plan: (thanks R!tman)
1. emerge ~l7-filter-2.3 ~l7-protocols-2006.06.03
2. CONFIG_IP_NF_MATCH_LAYER7=m/y IP_NF_IPTABLES=m/y IP_NF_CT_ACCT=m/y
IP_NF_CONNTRACK=m/y EXPERIMENTAL=y
3. make && make modules_install
4. USE="l7filter" emerge ~iptables-1.3.5-r4
5. modprobe lreboot (the kernel above of course ;-))
6. iptables -A FORWARD -m layer7 --l7proto bittorrent -o {interface} -j DROP
7. watch bittorrent fail.

if this all works well can 
l7-filter-2.3
l7-protocols-2006.06.03
iptables-1.3.5-r4

please be marked stable.

err hit enter too soon.
step 5: modprobe ipt_layer7

diff -u iptables-1.3.5-r1.ebuild iptables-1.3.5-r4.ebuild
shows the only difference is the l7-version used and small changes to the
mechanics of USE flags.

This works for me, but in step 7 I watched limewire fail ;-). And I didn't do
modprobe, as I didn't compile as module.

Nevertheless, I only tested with gentoo-sources-2.6.17-r4, yet. As soon as
other sources become stable I will test with those too.

I use the latest stable iptables with useflag "extensions" and the
l7-filter-2.3 with the latest stable kernel 2.6.17-gentoo-r4.

Everything works fine. layer7 filtering does it's job perfectly.

Just tried gentoo-sources-2.6.17-r7 which has gone stable. Same thing, works
like a charm, using the exact steps mentioned by dragonheart.
I again only tried limewire, which was successfully blocked.

Seems stable to me :-). 

Dragonheart, thanks for administrating this!

(In reply to comment #21)
> Just tried gentoo-sources-2.6.17-r7 which has gone stable. Same thing, works
> like a charm, using the exact steps mentioned by dragonheart.
> I again only tried limewire, which was successfully blocked.
> 
> Seems stable to me :-). 
> 
> Dragonheart, thanks for administrating this!

Oops!
Sorry, Daniel Black, thanks to YOU! Sorry, mixed that up, I somehow thought
your nickname was dragonheart... 

please, mark stable!

In x86:

Compiles and works fine, i tested it with bittorrent.

distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632)
[disabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: [Not Present]
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-tbird -mtune=athlon-tbird  -O2 -pipe
-fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/X11/xkb"
CONFIG_PROTECT_MASK="/etc/env.d /etc/gconf /etc/revdep-rebuild /etc/terminfo"
CXXFLAGS="-march=athlon-tbird -mtune=athlon-tbird  -O2 -pipe
-fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo/ "
LINGUAS=""
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise"
SYNC="rsync://rsync.belnet.be/packages/gentoo-portage"
USE="x86 X bitmap-fonts bzip2 cairo cdr cli crypt dbus dlloader dri dvd dvdr
eds elibc_glibc emboss encode fam firefox fortran gif gpm gstreamer gtk hal
input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jpeg
kernel_linux ldap libg++ mad mikmod mp3 mpeg ncurses nptl nptlonly ogg opengl
pam pcre perl png ppds pppd python qt3 qt4 quicktime readline reflection sdl
session spell spl ssl tcpd truetype truetype-fonts type1-fonts udev unicode
userland_GNU video_cards_vesa vorbis win32codecs xml xorg xv zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
MAKEOPTS, PORTAGE_RSYNC_EXTRA_OPTS

Stabled on ppc:
 - l7-filter-2.3
 - l7-protocols-2006.06.03
 - iptables-1.3.5-r4

(In reply to comment #25)
> Stabled on ppc:
>  - l7-filter-2.3
>  - l7-protocols-2006.06.03
>  - iptables-1.3.5-r4

What about amd64 and x86? Are there still issues? 

(In reply to comment #26)
> 
> What about amd64 and x86? Are there still issues? 
> 
the amd64 stabilization it's up to the maintainer, since they(amd64) don't have
any version stabilized.

For x86...hm...you'll have to wait :)

Hi Daniel,

Since the Bug was reported 2006-07-25 I was using l7-filter 2.3 in a production
x86 system under all 2.6.17.x kernels.

It is time to mark it stable.

cilly

Stabled on ppc:
 - l7-filter-2.3
 - l7-protocols-2006.06.03
 - iptables-1.3.5-r4"

sed -i 's/ppc/x86/'

I'm marking this as FIXED since amd64 never had a stable version.  If they want
to stabilize this, they can REOPEN.