Expected: # USE='static ipv6 -extensions' emerge =iptables-1.3.5-r1 to provide functional binary. Actual: # USE='static ipv6 -extensions' emerge =iptables-1.3.5-r1 produces misbehaving binary. Reproducible: always, on PPC. Cannot reproduce on x86. Work-around: # USE='-static' emerge =iptables-1.3.5-r1 Details: # iptables getsockopt failed strangely: No such file or directory Issue is unresolved on NetFilter list at: http://lists.netfilter.org/pipermail/netfilter/2006-May/065675.html
Created attachment 89199 [details] emerge info
works fine for me on my ppc run `strace -f -o out iptables` and post the 'out' file as an attachment
Created attachment 89426 [details] Output of 'strace -f -o out iptables'
that should of course be reading: getsockopt(3, SOL_IP, 0x42 /* IP_??? */, 0xffdb7b8c, 0xffdb7b88) = -1 ENOPROTOOPT (Protocol not available) instead of ENOENT
also post a log of strace when run on iptables with USE=-static getsockopt() is just a system call ... there isnt any logic in glibc ...
Created attachment 89443 [details] Output of 'strace -f -o out iptables' (USE=-static)
This looks like an interesting kernel bug Quick overview after spending some quality time with gdb (some attachments will follow) * the weird return value occurs only if "ip_tables" module is loaded; it goes away whenever you unload the module * I reproduced the problem with a small test program, and it occurs regardless of whether it is statically linked or not * the arguments going into the getsockopt system call are IDENTICAL when the sympton occurs and when it doesn't, and the socket descriptor passed is valid in both cases * the weird return value is present in the registers immediately after the syscall returns, before userspace code has any chance to corrupt errno The reason why this problem is only occuring in the static iptables is that the problematic code happens inside some init functions only used by static iptables. Kernel team: any suggestions on what to look at next?
Created attachment 92262 [details] small test program that produces same symptom
Created attachment 92263 [details] register dump from iptables failure
Created attachment 92264 [details] register dump from iptables success
perhaps related ... http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367656
I don't think so; the amd64 one is a glibc bug. I think a glibc bug has been ruled out in this case because gdb showed the syscall coming back with different results despite identical arguments coming in -- the presence or absence of ip_tables module in the kernel determined the result code, not whether the program was statically or dynamically compiled.
Wormo: Well, when ip_tables loads, it overrides getsockopt with nf_getsockopt, so I guess the bug is in nf_sockopt.c in the kernel. I'll look into it a little more.
Okay, I figured this one out. :p It's a pretty annoying bug, but I'm not sure why this only comes up with USE="static". Okay, so we know that ip_tables loads sockopts to support its features, so lets take a look at that code: /usr/src/linux/net/ipv4/netfilter/iptables.c The get method that's causing this problem is assigned in ipt_sockopts, specifically the function do_ipt_get_ctl. In do_ipt_get_ctl, the specific command we have a problem with is IPT_SO_GET_REVISION_[MATCH|TARGET]. Now, here's where the problem is. try_then_request_module tries to call the symbol: xt_find_revision to satisfy this request. Unfortunately, the symbol isn't available, so it tries to request it. If you haven't compiled the module it's requesting, you'll get -2 (-ENOENT) back, and hence this is the value that's returned that confuses iptables. A patch to add a check for -ENOENT and printing out the missing module name then return -EPROTONOSUPPORT instead of -ENOENT will be attached and fixes the bug for me.
Created attachment 117470 [details, diff] Not checking the return values is not good... okay? :p Please test this and tell me if it fixes the problem for you.
perhaps it should even go so far as: if (ret == -ENOENT) { .... } else if (ret < 0) { <complain about unhandled error value here> }
Yeah, that's probably a good idea. I still haven't gotten a response from upstream about it.
Fixed upstream: http://svn.netfilter.org/cgi-bin/viewcvs.cgi?rev=6890&view=rev
