141688 2006-07-25 03:38 0000 l7-filter-2.3 (and friends) stable request - was: l7-filter-2.2 doesn't work with gentoo-sources-2.6.17-r4 2006-10-03 14:14:39 0000 1 1 1 Unclassified Gentoo Linux Ebuilds unspecified All Linux RESOLVED FIXED P2 normal --- 1 hm@student.ethz.ch dragonheart@gentoo.org amd64@gentoo.org cilly@cilly.mine.nu hm@student.ethz.ch 2006-07-25 03:38:36 0000 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 cilly@cilly.mine.nu 2006-07-25 19:18:32 0000 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. dragonheart@gentoo.org 2006-07-25 22:26:49 0000 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. hm@student.ethz.ch 2006-07-25 23:44:42 0000 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... prezesp@wp.pl 2006-07-26 03:15:54 0000 I can also confirm 'iptables: Unknown error 429496729" Firestarter stop working after install 2.6.17-r4 kernel. prezesp@wp.pl 2006-07-26 04:33:10 0000 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 prezesp@wp.pl 2006-07-26 05:26:04 0000 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 cilly@cilly.mine.nu 2006-07-26 14:04:30 0000 (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. cilly@cilly.mine.nu 2006-07-26 14:07:50 0000 (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. hm@student.ethz.ch 2006-07-26 22:55:08 0000 (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. cilly@cilly.mine.nu 2006-07-27 06:43:46 0000 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. cilly@cilly.mine.nu 2006-07-27 06:46:32 0000 (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. dragonheart@gentoo.org 2006-07-28 07:33:58 0000 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. cilly@cilly.mine.nu 2006-07-28 08:50:15 0000 (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 :-) hm@student.ethz.ch 2006-07-28 21:47:37 0000 (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. cilly@cilly.mine.nu 2006-07-29 00:12:18 0000 (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. hm@student.ethz.ch 2006-08-27 23:13:52 0000 (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. dragonheart@gentoo.org 2006-08-28 02:33:45 0000 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. dragonheart@gentoo.org 2006-08-28 02:48:03 0000 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. hm@student.ethz.ch 2006-08-28 23:25:23 0000 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. cilly@cilly.mine.nu 2006-08-29 07:34:47 0000 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. hm@student.ethz.ch 2006-08-29 08:28:04 0000 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! hm@student.ethz.ch 2006-08-29 08:34:47 0000 (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... cilly@cilly.mine.nu 2006-09-18 02:30:13 0000 please, mark stable! armin76@gentoo.org 2006-09-26 09:49:14 0000 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 nixnut@gentoo.org 2006-10-01 04:48:14 0000 Stabled on ppc: - l7-filter-2.3 - l7-protocols-2006.06.03 - iptables-1.3.5-r4 hm@student.ethz.ch 2006-10-01 04:50:45 0000 (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? armin76@gentoo.org 2006-10-02 11:00:07 0000 (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 :) cilly@cilly.mine.nu 2006-10-02 11:27:10 0000 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 wolf31o2@gentoo.org 2006-10-03 14:14:39 0000 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.