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
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
Created attachment 352296 [details] strace -s 4096 -o log iptables -L
Created attachment 352298 [details] kernel config
Present with net-firewall/iptables-1.4.19.1. Same failure in the strace that daemontux provided in Comment 2.
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!
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
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.
> 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?
(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?
(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.
Created attachment 362724 [details] Test case A
Created attachment 362726 [details] Test case B
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?
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.
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
(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.
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.
(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
Hello, I think we should add this bug to the tracker “x32 porting issues” bug 393673, and mark this bug as “confirmed”.
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.
i've added the struct pack hack for x32 for now: http://gitweb.gentoo.org/repo/gentoo.git/commit/?id=35a3bea74f790d3fd69cab4b40f245078dd6bf18
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.
(In reply to Joshua Kinard from comment #22) try extending the existing pack struct hack for n32 to see if it works for you
(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
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.
