Re: iptables not working with monolithic 2.6.26.5 kernel on ARM

[Patrick McHardy <kaber@trash.net>]

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.