From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: iptables not working with monolithic 2.6.26.5 kernel on ARM Date: Fri, 03 Oct 2008 14:56:15 +0200 Message-ID: <48E6166F.40607@trash.net> References: <18661.41641.113458.932029@martins.ozlabs.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netfilter-devel@vger.kernel.org To: Martin Schwenke Return-path: Received: from stinky.trash.net ([213.144.137.162]:55795 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751022AbYJCM5S (ORCPT ); Fri, 3 Oct 2008 08:57:18 -0400 In-Reply-To: <18661.41641.113458.932029@martins.ozlabs.org> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Martin Schwenke wrote: > I'm seeing the following error on my Buffalo Linkstation Pro: > > # iptables -L > iptables v1.3.6: can't initialize iptables table `filter': No chain/target/match by that name > Perhaps iptables or your kernel needs to be upgraded. > > This is with a monolithic 2.6.26.5 kernel: > > root@slinky:~# uname -a > Linux slinky 2.6.26.5-dirty #9 PREEMPT Fri Oct 3 13:26:38 EST 2008 armv5tel GNU/Linux > > * I think the "-dirty" comes from me having edited > net/ipv4/netfilter/ip_tables.c to uncomment the #define for > DEBUG_IP_FIREWALL_USER (see below). That's certainly the only thing > different to the standard 2.6..26.5 kernel... > > * As you can see, this is an ARM box. > > * I've been seeing this problem since I first compiled a 2.6.22 kernel > for this box. > > * I've tried iptables-1.3.8 and it didn't help. I did a quick diff > with the latest version iptables/libiptc/libiptc.c in git and can't > see any changes that would help. > > When I strace the above command, I see this: > > ... > socket(PF_INET, SOCK_RAW, IPPROTO_RAW) = 3 > getsockopt(3, SOL_IP, 0x40 /* IP_??? */, "filter\0\300\244\306\6\300D\0\0\0\200\\M\304\234\\M\304"..., [84]) = 0 > getsockopt(3, SOL_IP, 0x41 /* IP_??? */, 0x1c0c0, 0xbea17c30) = -1 EINVAL (Invalid argument) > close(3) = 0 > open("/proc/sys/kernel/modprobe", O_RDONLY) = -1 ENOENT (No such file or directory) > ... > > This suggests to me the 2nd call to getsockopt in > iptables/libiptc/libiptc.c:TC_INIT() is failing. > > So, I start to poke around. Does this mean that the table exists? > > # cat /proc/net/ip_tables_names > filter > > So, I define DEBUG_IP_FIREWALL_USER in the kernel in > net/ipv4/netfilter/ip_tables.c and try again. Now I get this debug: > > get_entries: 668 != 672 > > This is generated by this code in get_entries(): > > if (*len != sizeof(struct ipt_get_entries) + get.size) { > duprintf("get_entries: %u != %zu\n", > *len, sizeof(get) + get.size); > return -EINVAL; > } > > I can see code in libiptc.c calculating and passing *len but I don't > understand what's going on enough to know how to debug it. > > Any suggestions? > > (I'm not on the list, please CC: me... :-) If I remember correctly we had a similar reports that were related to ABI mismatches. Please verify that both userspace and kernel are using the same ABI, in case they are please post your .config.