Bug#690548: iptables: invalid size 40 (kernel) != (user) 48 on yeelong because kernel is 64 bits, iptables 32 bits

[Xavi Drudis Ferran]

Package: iptables
Version: 1.4.14-3
Severity: important
Tags: patch

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

* What led up to the situation?

I changed the hard disk of my Lemote Yeeloong laptop, and tried reinstalling
debian wheezy on it.

I followed http://wiki.debian.org/DebianYeeloong/HowTo/Install with 2012-10-11 installer
(loongson-2f netboot).

It installed ok at least to console, I still have to try X.

I then installed arno-iptables-firewall and it complained that
iptables was failing, telling me to look at dmesg.

dmesg said :

[ 0.068000] TCP: Hash tables configured (established 65536 bind 65536)
[ 23.220000] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 23.256000] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 25.896000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 25.928000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 25.960000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 25.988000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 26.016000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 26.068000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48
[ 26.096000] x_tables: ip_tables: limit.0 match: invalid size 40 (kernel) != (user) 48

It was the same that happened to me last year around june.

So after 3 or 4 tries I remembered the solution, but I don't remember that I reported
it then and so I'll do it now. I may be reporting on the wrong package or it may need
2 reports, I don't know

The problem seems to be that the linux kernel is 64 bits (it could be 32 bits, and iptables
would work as packaged, but then the kernel does only see 256 MB of RAM and I have 1 GB).

Iptables as packaged is a 32 bits mipsel executable, and seems to have some data structures
that include 32 bits pointers or something that don't work when shared with the 64 bit
kernel. Or something like that.

* What exactly did you do (or not do) that was effective (or
ineffective)?

The following procedure fixed it for me but I'm not sure what would be best for debian
as a whole. Maybe there could be 2 iptables and libnfnetlink packages for mipsel, one 32
bits and one 64 bits, and dependencies could be arranged somehow to have the right one
installed when the kernel is 64 bits ? Or maybe iptables code can be changed to cater
for the kernel data structures size being different of their own?

I don't know how usable is this fix but at least should explain the problem and help
someone find a better fix.

Here are my steps with missteps removed:

# cat - > /etc/dpkg/buildflags.conf
APPEND CFLAGS -march=loongson2f -Wa,--trap -mabi=64 -Wa,-mfix-loongson2f-nop -mno-branch-likely -L/usr/lib/gcc/mipsel-linux-gnu/4.6/64/
APPEND LDFLAGS -mabi=64 -Wl,-melf64ltsmip -Wl,-EL -Wl,-L/usr/lib/gcc/mipsel-linux-gnu/4.4.5/64/

(I just realised the second line -L argument is wrong, was right last year but I should have upgraded it for gcc 4.6
I'm using now, but the fact is that this is how I've done it, I guess it should work without -L)

# aptitude build-depends iptables
# aptitude install debian-keyring build-essential
$ apt-get source iptables
$ apt-get source libnfnetlink
$ cd libnfnetlink-1.0.0
(i tried dpkg-buildpackage but later discovered it was ignoring /etc/dpkg/buildflags.conf, and building a
32 bits library, until I saw I had to change debian/rules last year to make it use buildflags.conf, not
sure if that is the correct thing to do for the general debian case, I edited debian rules, haven't really
tried next command, but if it fails it's adding 5 lines there)
$ patch -p 1
--- libnfnetlink-1.0.0/debian/rules2012-10-13 22:11:25.000000000 +0200
+++ libnfnetlink-1.0.0/debian/rules2011-06-02 21:01:21.191999657 +0200
@@ -8,6 +8,11 @@
DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

CFLAGS = -Wall -g
+success:=$(shell dpkg-buildflags --export=make >build.flags && echo y)
+ifneq ($(success),y)
+$(error dpkg-buildflags failed)
+endif
+include build.flags

ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS)))
CFLAGS += -O0
$ dpkg-buildpackage

# dpkg -i libnfnetlink-dev_1.0.0-1_mipsel.deb libnfnetlink0_1.0.0-1_mipsel.deb

$ cd ../iptables-1.4.14
$ dpkg-buildpackage

# dpkg -i iptables_1.4.14-3_mipsel.deb

# /etc/init.d/arno-iptables-firewall start

* What was the outcome of this action?

no errors about iptables reported by arno-iptables-firewall and none in dmesg.
Firewall seems to work fine

* What outcome did you expect instead?

I'd like that the next time I install on a yeeloong iptables works out of the box,
or that I can keep upgrading iptables and libnfnetlink from the debian archive
without need to rebuild them each time.

Not sure what's the proper fix that makes it just work for yeeloong and doesn't
break or make things difficult for others...

Hope it helps me next time, hopefully someone else at least if it can't be
fixed in debian.

*** End of the template - remove these lines ***

I just realised this report is being filled by reportbug once I have
my recompiled package installed. Maybe the bug should use the 32 bit
versions, which are what really failed ?

-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: mipsel (mips64)

Kernel: Linux 3.2.0-3-loongson-2f
Locale: LANG=ca_ES.UTF-8, LC_CTYPE=ca_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages iptables depends on:
ii libc6-mips64 2.13-35
ii libnfnetlink0 1.0.0-1

iptables recommends no packages.

iptables suggests no packages.

-- no debconf information


--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org

[Fabio Pedretti]

There is a related patch in iptables git:

http://git.netfilter.org/iptables/commit/?id=64e88114437072b29bed8aae9eb04ed5e773708f

Informativa sulla Privacy: http://www.unibs.it/node/8155