Re: [LARTC] ipp2p segmentation fault

[Jim Barber <jim.barber@ddihealth.com>]

Thanks Mario.

I might try again using the source code from Debian's version of
iptables to see how it goes.
I thought they had disabled ipp2p support in it completely, but I guess
the patch must add it back.

Also maybe 0.8.2 fixes something that was wrong with 0.8.1_rc1.
Or maybe the snapshot tar-ball of iptables I got had a problem.

But I'm glad to hear that it works on a 2.6.22 series kernel.
I was wondering if perhaps it was a bit too new for the patches.

Thanks.

----------
Jim Barber
DDI Health



Mario Antonio Garcia wrote:
> Jim,
>
> I am using Debian Etch with:
> 2.6.22.6 customized kernel
> Iptables from the Stable (Etch) branch
> I got Iptables sources also from the stable branch:
> apt-get source iptables	
> ln -s /usr/src/iptables-1.3.6.0debian1/iptables /usr/src/iptables-1.3.6
>
> I downloaded ipp2p-0.8.2.tar.gz from its site, and Modified the Makefile to use CC instead of ld.
>
> Working fine so far.
>
> Mario Antonio
>
> ----- Original Message -----
> From: "Jim Barber" <jim.barber@ddihealth.com>
> To: lartc@mailman.ds9a.nl
> Sent: Saturday, October 6, 2007 1:52:45 AM (GMT-0500) America/New_York
> Subject: [LARTC] ipp2p segmentation fault
>
> Hi all.
>
> On Sep 26th I decided to try and get ipp2p working on my machine that acts as a gateway for my Internet connection.
> This machine is running Debian.
>
> I performed the install by doing the following steps:
>
> - I installed the Debian package called linux-source-2.6.22 for my Linux kernel source and unpacked the resulting tar.bz2 file.
>
> - From the netfilter.org site I downloaded the following snapshot packages and unpacked them into my build area:
>
> 	iptables-1.3.8-20070925.tar.bz2
> 	patch-o-matic-ng-20070925.tar.bz2
>
> - I ran the patch-o-matic-ng runme script correctly defining the KERNEL_DIR and IPTABLES_DIR parameters.
>    I also used the --download parameter so that it would fetch the ipp2p out-of-tree repository.
>
> - When running the patch-o-matic-ng script I said 'No' to all the extensions except for the ipp2p one since that is all I was interested in.
>    The patch seemed to successfully apply.
>
> - I configured and built the Linux sources enabling all the netfilter modules that I needed (including the ipp2p one that is now patched in).
>
> - I then built and installed the kernel.
>
> - I also built and installed the iptables package (again specifying the KERNEL_DIR parameter)
>    This new iptables is installed under my /usr/local/ tree which is earlier in my $PATH.
>
> - I rebooted off the new kernel and all looks good and a 'uname -a' confirms I am on the new kernel.
>
>
> I'm using shorewall to configure my firewall rules so it loads pretty much all the iptables/netfilter modules on start up.
>
> The module has loaded okay as far as I can tell:
>
> 	root@gecko:~# lsmod | grep p2p
> 	ipt_ipp2p               8256  0
> 	x_tables               15236  43 xt_comment,xt_policy,xt_multiport,ipt_ULOG,ipt_TTL,ipt_ttl,ipt_TOS,ipt_tos,ipt_SAME,ipt_REJECT,ipt_REDIRECT,ipt_recent,ipt_owner,ipt_NETMAP,ipt_MASQUERADE,ipt_LOG,ipt_iprange,ipt_ipp2p,ipt_ECN,ipt_ecn,ipt_ah,ipt_addrtype,xt_tcpmss,xt_pkttype,xt_physdev,xt_NFQUEUE,xt_NFLOG,xt_MARK,xt_mark,xt_mac,xt_limit,xt_length,xt_helper,xt_hashlimit,xt_dccp,xt_conntrack,xt_CONNMARK,xt_connmark,xt_CLASSIFY,xt_tcpudp,xt_state,iptable_nat,ip_tables
>
> And the help for it works okay:
>
> 	root@gecko:~# iptables -m ipp2p --help
> 	iptables v1.3.8-20070925
>
> <Snip removing regular iptables help items...>
>
> 	IPP2P v0.8.1_rc1 options:
> 	 --ipp2p        Grab all known p2p packets
> 	 --edk          [TCP&UDP]       All known eDonkey/eMule/Overnet packets
> 	 --dc           [TCP]           All known Direct Connect packets
> 	 --kazaa        [TCP&UDP]       All known KaZaA packets
> 	 --gnu          [TCP&UDP]       All known Gnutella packets
> 	 --bit          [TCP&UDP]       All known BitTorrent packets
> 	 --apple        [TCP]           All known AppleJuice packets
> 	 --winmx        [TCP]           All known WinMX
> 	 --soul         [TCP]           All known SoulSeek
> 	 --ares         [TCP]           All known Ares
>
> 	 EXPERIMENTAL protocols (please send feedback to: ipp2p@ipp2p.org) :
> 	 --mute         [TCP]           All known Mute packets
> 	 --waste        [TCP]           All known Waste packets
> 	 --xdcc         [TCP]           All known XDCC packets (only xdcc login)
>
> 	 DEBUG SUPPPORT, use only if you know why
> 	 --debug                Generate kernel debug output, THIS WILL SLOW DOWN THE FILTER
>
> 	Note that the follwing options will have the same meaning:
> 	 '--ipp2p' is equal to '--edk --dc --kazaa --gnu --bit --apple --winmx --soul --ares'
>
> 	IPP2P was intended for TCP only. Due to increasing usage of UDP we needed to change this.
> 	You can now use -p udp to search UDP packets only or without -p switch to search UDP and TCP packets.
>
> 	See README included with this package for more details or visit http://www.ipp2p.org
>
> 	Examples:
> 	 iptables -A FORWARD -m ipp2p --ipp2p -j MARK --set-mark 0x01
> 	 iptables -A FORWARD -p udp -m ipp2p --kazaa --bit -j DROP
> 	 iptables -A FORWARD -p tcp -m ipp2p --edk --soul -j DROP
>
>
> When I created some shorewall tcrules for ipp2p a 'shorewall check' command shows a segmentation fault occurring and aborts reporting that I don't have IPP2P support.
> Delving further I found shorewall's test for ipp2p support in /usr/share/shorewall/lib.base where is it running the following command:
>
> 	$IPTABLES -A fooX1234 -p tcp -m ipp2p --ipp2p -j ACCEPT
>
> Note that I've correctly defined the $IPTABLES variable in the main config file to point to /usr/local/sbin/iptables instead of /sbin/iptables
>
> If I run the command directly myself I also get the segmentation fault:
>
> 	root@gecko:~# iptables -A fooX1234 -m ipp2p --ipp2p -j ACCEPT
> 	Segmentation fault
>
> This is despite the help for the module working as you can see above.
> Using /usr/local/sbin/iptables makes no difference, but a which command shows I'm running the correct version:
>
> 	root@gecko:~# which iptables
> 	/usr/local/sbin/iptables
>
> Any idea how I can track down what is wrong?
>
> Finally, just in case it helps anyone, here is the output from an strace:
>
> 	root@gecko:~# strace iptables -A fooX1234 -m ipp2p --ipp2p -j ACCEPT
> 	execve("/usr/local/sbin/iptables", ["iptables", "-A", "fooX1234", "-m", "ipp2p", "--ipp2p", "-j", "ACCEPT"], [/* 21 vars */]) = 0
> 	brk(0)                                  = 0x8055000
> 	access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
> 	mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f58000
> 	access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
> 	open("/etc/ld.so.cache", O_RDONLY)      = 3
> 	fstat64(3, {st_mode=S_IFREG|0644, st_size\x19567, ...}) = 0
> 	mmap2(NULL, 19567, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7f53000
> 	close(3)                                = 0
> 	access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
> 	open("/lib/i686/cmov/libdl.so.2", O_RDONLY) = 3
> 	read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0p\n\0\000"..., 512) = 512
> 	fstat64(3, {st_mode=S_IFREG|0644, st_size–84, ...}) = 0
> 	mmap2(NULL, 12412, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f4f000
> 	mmap2(0xb7f51000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7f51000
> 	close(3)                                = 0
> 	access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
> 	open("/lib/i686/cmov/libc.so.6", O_RDONLY) = 3
> 	read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\260a\1"..., 512) = 512
> 	fstat64(3, {st_mode=S_IFREG|0755, st_size\x1335720, ...}) = 0
> 	mmap2(NULL, 1340944, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7e07000
> 	mmap2(0xb7f49000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x142) = 0xb7f49000
> 	mmap2(0xb7f4c000, 9744, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb7f4c000
> 	close(3)                                = 0
> 	mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7e06000
> 	set_thread_area({entry_number:-1 -> 6, base_addr:0xb7e06ac0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
> 	mprotect(0xb7f49000, 4096, PROT_READ)   = 0
> 	munmap(0xb7f53000, 19567)               = 0
> 	brk(0)                                  = 0x8055000
> 	brk(0x8076000)                          = 0x8076000
> 	open("/usr/local/lib/iptables/libxt_ipp2p.so", O_RDONLY) = -1 ENOENT (No such file or directory)
> 	open("/usr/local/lib/iptables/libipt_ipp2p.so", O_RDONLY) = 3
> 	read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300\4\0"..., 512) = 512
> 	fstat64(3, {st_mode=S_IFREG|0755, st_size\x11602, ...}) = 0
> 	mmap2(NULL, 11284, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7f55000
> 	mmap2(0xb7f57000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x1) = 0xb7f57000
> 	close(3)                                = 0
> 	--- SIGSEGV (Segmentation fault) @ 0 (0) ---
> 	+++ killed by SIGSEGV +++
> 	Process 23813 detached
>
>
> I notice it is trying to open libxt_ipp2p.so in /urs/local/lib/iptables/ which failed...
> Is that something that should be on my system?
>
> Regards,
>
>   

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc