Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 472388 - net-firewall/iptables: x32/n32 ABIs: iptables -L: can't initialize iptables table `filter': Invalid argument
Summary: net-firewall/iptables: x32/n32 ABIs: iptables -L: can't initialize iptables t...
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo's Team for Core System packages
URL: http://bugzilla.netfilter.org/show_bu...
Whiteboard:
Keywords:
Depends on:
Blocks: x32
  Show dependency tree
 
Reported: 2013-06-05 10:26 UTC by daemontux
Modified: 2021-11-06 17:09 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
strace -s 4096 -o log iptables -L (log,8.10 KB, text/plain)
2013-06-30 09:59 UTC, daemontux
Details
kernel config (config-3.8.13,66.17 KB, text/x-mpsub)
2013-06-30 10:00 UTC, daemontux
Details
working kernel.config (kernel.config,87.13 KB, text/plain)
2013-07-02 16:25 UTC, SpanKY
Details
Test case A (a.c,358 bytes, text/x-csrc)
2013-11-07 13:17 UTC, cjanderson
Details
Test case B (b.c,344 bytes, text/x-csrc)
2013-11-07 13:18 UTC, cjanderson
Details
emerge --info (file_472388.txt,5.67 KB, text/plain)
2014-05-02 12:05 UTC, Thibaud CANALE
Details

Note You need to log in before you can comment on or make changes to this bug.
Description daemontux 2013-06-05 10:26:48 UTC
iptables does not work on x32 abi.

#iptables -L
iptables v1.4.19.1: can't initialize iptables table `filter': Invalid argument
Perhaps iptables or your kernel needs to be upgraded.

With the same configs (kernel, useflags) and version of packages it works properly on  x64 abi.


Portage 2.1.11.62 (default/linux/amd64/13.0/x32, gcc-4.7.3, glibc-2.16.0, 3.8.13 x86_64)
=================================================================
System uname: Linux-3.8.13-x86_64-Intel-R-_Atom-TM-_CPU_D510_@_1.66GHz-with-gentoo-2.2
KiB Mem:     1002644 total,    816152 free
KiB Swap:          0 total,         0 free
Timestamp of tree: Tue, 04 Jun 2013 09:30:01 +0000
ld GNU ld (GNU Binutils) 2.22
app-shells/bash:          4.2_p45
dev-lang/python:          2.7.3-r3
dev-util/pkgconfig:       0.28
sys-apps/baselayout:      2.2
sys-apps/openrc:          0.11.8
sys-apps/sandbox:         2.6-r1
sys-devel/autoconf:       2.69
sys-devel/automake:       1.10.3, 1.12.6
sys-devel/binutils:       2.22-r1
sys-devel/gcc:            4.7.3
sys-devel/gcc-config:     1.7.3
sys-devel/libtool:        2.4-r1
sys-devel/make:           3.82-r4
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc:           2.16.0
Repositories: gentoo
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="* -@EULA"
CBUILD="x86_64-pc-linux-gnux32"
CFLAGS="-march=native -mtune=generic  -O2 -pipe -mfpmath=sse -mssse3 -mcx16 -msahf"
CHOST="x86_64-pc-linux-gnux32"
CONFIG_PROTECT="/etc"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=native -mtune=generic  -O2 -pipe -mfpmath=sse -mssse3 -mcx16 -msahf"
DISTDIR="/usr/portage/distfiles"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs collision-protect config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync multilib-strict news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="en_US.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/usr/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY=""
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="amd64 berkdb bzip2 cli cracklib crypt cxx dri gdbm iconv lzma mmx modules mudflap multilib ncurses netlink nls nptl openmp pam pcre python2 readline session sse sse2 sse3 ssl ssse3 unicode zlib" ABI_X86="x32" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc efi-64" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7" RUBY_TARGETS="ruby19 ruby18" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
Comment 1 SpanKY gentoo-dev 2013-06-17 02:45:10 UTC
it's working fine for me with linux-3.8.3 and iptables-1.4.19.1

attach your kernel .config as well as the log from doing:
  strace -s 4096 -o log iptables -L
Comment 2 daemontux 2013-06-30 09:59:01 UTC
Created attachment 352296 [details]
strace -s 4096 -o log iptables -L
Comment 3 daemontux 2013-06-30 10:00:10 UTC
Created attachment 352298 [details]
kernel config
Comment 4 Kyle Sanderson 2013-07-01 09:10:00 UTC
Present with net-firewall/iptables-1.4.19.1.

Same failure in the strace that daemontux provided in Comment 2.
Comment 5 Kyle Sanderson 2013-07-02 03:13:46 UTC
No idea how Vapier got this to work on his x32 system. Forcing the application to compile as m32 or m64 instead of mx32 (same sort of thing as bug 466840 comment 2) definitely works. Hope this helps!
Comment 6 SpanKY gentoo-dev 2013-07-02 16:25:27 UTC
Created attachment 352462 [details]
working kernel.config

here's my kernel config w/linux-3.8.3

running in a native x32 chroot:

# qlist -Iv iptables
net-firewall/iptables-1.4.19.1

# file -L `which iptables`
/sbin/iptables: ELF 32-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 3.4.0, stripped

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       icmp --  0.0.0.0/0            0.0.0.0/0           
DROP       udp  --  0.0.0.0/0            0.0.0.0/0           
DROP       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:138
DROP       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:137
DROP       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:620
DROP       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:53
DROP       udp  --  0.0.0.0/0            0.0.0.0/0            udp dpt:111
ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           
ACCEPT     icmp --  0.0.0.0/0            0.0.0.0/0           
DROP       all  --  0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Comment 7 cjanderson 2013-11-04 07:40:03 UTC
I am able to reproduce this the stock x32 stage3 and net-firewall/iptables-1.4.20. 

The syscall that is traced above
Nov 04 00:17:17 x32 kernel: ip_tables: : 3900 != 3896

The problem appears to be 8 byte alignment for the structure ( kernel side is: http://lxr.linux.no/linux+v3.12/+code=compat_ipt_get_entries) as the sizeof struct ipt_get_entries is 40, not 36.

Adding -fpack-struct to the CFLAGS got this to work for me.
Comment 8 cjanderson 2013-11-07 01:03:35 UTC
> Adding -fpack-struct to the CFLAGS got this to work for me.
-fpack-struct=4 aligns the structures when setting stuff like the policy and the like. It seems for work well for a test box that does DNAT,SNAT, MASQ, REDIRECT, MANGLING amongst other things.

The same thing happens with gcc 4.7.2 as well as 4.8.1. Is this perhaps a GCC bug?
Comment 9 Kyle Sanderson 2013-11-07 01:10:05 UTC
(In reply to cjanderson from comment #8)
> > Adding -fpack-struct to the CFLAGS got this to work for me.
> -fpack-struct=4 aligns the structures when setting stuff like the policy and
> the like. It seems for work well for a test box that does DNAT,SNAT, MASQ,
> REDIRECT, MANGLING amongst other things.

I believe it's a kernel bug. The underlying system is amd64, but the pointer sizes don't line up. I've been just compiling iptables separately for amd64 and it works. I'm glad someone's found a fix though. Maybe it should be part of the ebuild?
Comment 10 cjanderson 2013-11-07 13:17:25 UTC
(In reply to Kyle Sanderson from comment #9)
> I believe it's a kernel bug. The underlying system is amd64, but the pointer
> sizes don't line up. I've been just compiling iptables separately for amd64
> and it works. I'm glad someone's found a fix though. Maybe it should be part
> of the ebuild?

I thought that it was kernel side, but could not really find anything in the kernel. But I did find something odd when compiling with 32 and 64 bits when you have a 64 bit structure that is in the array. Thats hard to explain, so I attach two example files, one called a.c and the other b.c. The only difference between the two i the line  "unsigned long long a,b;" in a.c becomes a "char a,b" in b.c.

When you run these using -m32 -m64 and -mx32 you get the following:
              a.c  b.c
gcc -m32 ->  36   36
gcc -m64 ->  40   36
gcc -mx32 -> 40   36

I have not looked into why the 64 bit kernel expects the structure ipt_entries to be 36 bytes and not 40.
Comment 11 cjanderson 2013-11-07 13:17:47 UTC
Created attachment 362724 [details]
Test case A
Comment 12 cjanderson 2013-11-07 13:18:06 UTC
Created attachment 362726 [details]
Test case B
Comment 13 cjanderson 2013-11-14 22:44:16 UTC
Due to the lack of interest in this bug, I thought I might add some commentary.
AFIK, the kernel doesn't understand x32, as this is one of the models/modes supported by a 64bit kernel. And, for all intents and purposes, x32 is a 32 bit address space, ie. pointers as far as the applications developer is concerned. Given this gross over simplification, then, should not the x32 case for the test case a.c read 36 and 36? Or have I missed something?
Comment 14 cjanderson 2013-11-14 23:12:33 UTC
And as the kernel is expecting 36 bytes for a similar structure, which is the one for which this error is generated, it would appear that the problem is with the compiler.
Comment 15 Thomas Deutschmann (RETIRED) gentoo-dev 2013-11-15 10:51:01 UTC
I am not familiar with x32 ABI, but have you seen comment 10 in Debian's bug report 690548 [1]?

Isn't that the same problem and if Jan is right, you cannot run iptables x32 with a x64 kernel?



[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690548#10
Comment 16 cjanderson 2013-11-15 20:35:19 UTC
(In reply to Thomas D. from comment #15)
> Isn't that the same problem and if Jan is right, you cannot run iptables x32
> with a x64 kernel?

> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690548#10

I believe that the assertion made in the debian bug is that even when COMPAT_... is enabled, and even when the x32 magical thunking (compat_...) is done in an AMD64 bit kernel that supports x32 is that you will not be able to run a 32 bit iptables on the aforementioned kernel. If this is correct, then why can I take a stock stage3 for i486, emerge iptables, the thing works?

I believe that the sizeof the structure is correct in the kernel, viz 36, and the problem lies with the generation of the x32 code, based on the fact that the user side structure is somehow incorrect.
Comment 17 Thibaud CANALE 2014-05-02 12:05:03 UTC
Created attachment 376200 [details]
emerge --info

Hello everyone,

Getting this same error with x32 ABIs, I followed cjanderson's advice (comment 7),

`CFLAGS="-march=corei7-avx -O2 -pipe -ggdb -fpack-struct" CXXFLAGS="${CFLAGS}" emerge -vat iptables'

and as expected, iptables works fine now … unlike ip6tables:

# ip6tables -L -nv         
ERROR: 0 not a valid target)

But this is strange, because both /sbin/iptables and /sbin/ip6tables are symlink to /sbin/xtables-multi, so, I don't understand why one works unlike the other.

I can provide more informations if you need it.

Best regards.
Comment 18 s_verma797 2014-05-03 13:28:20 UTC
(In reply to Thibaud "thican" CANALE from comment #17)
> Created attachment 376200 [details]
> emerge --info
> 
> Hello everyone,
> 
> Getting this same error with x32 ABIs, I followed cjanderson's advice
> (comment 7),
> 
> `CFLAGS="-march=corei7-avx -O2 -pipe -ggdb -fpack-struct"
> CXXFLAGS="${CFLAGS}" emerge -vat iptables'
> 
> and as expected, iptables works fine now … unlike ip6tables:
> 
> # ip6tables -L -nv         
> ERROR: 0 not a valid target)
> 
> But this is strange, because both /sbin/iptables and /sbin/ip6tables are
> symlink to /sbin/xtables-multi, so, I don't understand why one works unlike
> the other.
> 
> I can provide more informations if you need it.
> 
> Best regards.

Same problem I have on my newly installed system.
-fpack-struct solves just like yours.
ip6tables give the same error.
# ip6tables -L -nv         
> ERROR: 0 not a valid target)

Used stage3-x32-20140325.tar.bz2 for the install.
iptables version is 1.4.20
Kernel gentoo-sources version 3.12.13
Comment 19 Thibaud CANALE 2014-07-27 13:17:04 UTC
Hello,

I think we should add this bug to the tracker “x32 porting issues” bug 393673, and mark this bug as “confirmed”.
Comment 20 SpanKY gentoo-dev 2015-08-20 17:24:36 UTC
the getsockopt(SOL_IP, IPT_SO_GET_INFO) call in iptables (libiptc/libiptc.c:TC_INIT) is failing because sizeof(struct ipt_get_entries) is 40 but the kernel wants 36 (net/ipv4/netfilter/ip_tables.c:compat_get_entries).  this is because the alignment of entrytable is set to 8 while the kernel uses 4.  putting __attribute__((packed)) on that struct in linux/netfilter_ipv4/ip_tables.h gets past that error.

but then it all falls down when it tries to parse that structured return.  most likely due to the other structs not being packed in the same way.

moved the report upstream.
Comment 21 SpanKY gentoo-dev 2015-08-20 17:32:55 UTC
i've added the struct pack hack for x32 for now:
http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35a3bea74f790d3fd69cab4b40f245078dd6bf18
Comment 22 Joshua Kinard gentoo-dev 2015-08-31 11:12:41 UTC
Running MIPS/N32 here, but don't have netfilter stuff loaded into this kernel.  Ran the two test cases, though, and here's the output:

# ./a
ipt_get_entries is 40 bytes

# ./b
ipt_get_entries is 36 bytes

# file ./a
./a: ELF 32-bit MSB executable, MIPS, N32 MIPS-IV version 1, dynamically linked, interpreter /lib32/ld.so.1, for GNU/Linux 2.6.32, not stripped


Running 'iptables -L' by itself yields this, which I think is because I'm missing the kernel options:

# iptables -L
iptables v1.4.21: can't initialize iptables table `filter': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Comment 23 SpanKY gentoo-dev 2015-08-31 17:52:14 UTC
(In reply to Joshua Kinard from comment #22)

try extending the existing pack struct hack for n32 to see if it works for you
Comment 24 Joshua Kinard gentoo-dev 2015-09-07 04:16:24 UTC
(In reply to SpanKY from comment #23)
> (In reply to Joshua Kinard from comment #22)
> 
> try extending the existing pack struct hack for n32 to see if it works for
> you

Looks like MIPS doesn't need the patch, even for N32:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Comment 25 Stuart Shelton 2020-08-23 20:49:55 UTC
It's an old bug, but I've just realised that net-firewall/iptables-1.8.5 provides an 'iptables' implementation which works on AMD64/x32.

However, this version still fails with:

```
$ sudo ip6tables-save
# Generated by ip6tables-save v1.8.5 on Sun Aug 23 20:48:43 2020
*nat
ERROR: 0 not a valid target)
Aborted
```

... when built on x32.

I've solved this by having an AMD64 chroot to build pure 64bit binary packages, and then merge these onto the (multilib) x32 system by emerging the package with CHOST set.

It would be excellent to not have to do this any longer!

The remaining packages I'm aware of as well as iptables are iproute2 and miniupnpd as dependencies.