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.
