2011-04-06
Strange iptables error with kernels >= 2.6.32 – solved
Alright. If you ever come into the same situation I was in and need a newer kernel (2.6.32 or up, perhaps also 2.6.31) on some system with old iptables package (versions below 1.4.0 I think, 1.3.5 in my case: CentOS5/RHEL5), you might get this helpful error message when using the iprange module in your iptables rules:
iptables: Unknown error 18446744073709551615
Or even more helpful, if you use iptables-restore to load your rules, you will get an error in the line containing the COMMIT statement (iptables-restore: line X failed).
The reason for this is that the netfilter guys have removed an interface to the iprange module in kernel version 2.6.31 or 2.6.32 (see my bug report at #711 of the netfilter bugzilla).
Just posting this so it might hopefully help others if they get into the same situation.
See also Strange MySQL (5.0) issue with authentication
See also Migrating aptitudes knowledge about auto-installed packages
See also Unifying config file syntaxes with nesting
Permalink
Patrick said,
January 7, 2012 at 19:52 UTC (+0000)
Was just what I was looking for. It helped thanks!
Shy said,
February 20, 2012 at 18:27 UTC (+0000)
Hi,
I’m experiencing the same problem so I tried to look at the bugzilla link you gave but I can’t reach the site. Anyway I can get into that link or elsewhere to find solution?
Thanks so much!
sven said,
February 21, 2012 at 11:09 UTC (+0000)
The netfilter bugzilla was somehow changed, so the bug isn’t accessible under the old link (I updated my post accordingly, thanks for the hint to the problem).
However, what it boils down to:
If you use a kernel newer than (or equal to) 2.6.32, you get this error if your iptables commandline tools are not updated accordingly. I’m not sure which revision of the iptables tools are needed, but probably any version above 1.4.0 is enough.
Shy said,
February 21, 2012 at 14:49 UTC (+0000)
Thanks for the update Sven. The thing is I compared the kernel, iptables ver and distro between the working and the non-working servers and its working on one server.
Working Server:
root:~# dpkg –list |grep iptables
ii iptables 1.4.8-3 administration tools for packet filtering and NAT
root:~# uname -mrs
Linux 2.6.32-5-686 i686
root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.3 (n/a)
Release: 6.0.3
Codename: n/a
Non-working server:
root:~# dpkg –list |grep iptables
ii iptables 1.4.8-3 administration tools for packet filtering and NAT
root:~# uname -mrs
Linux 2.6.32-5-amd64 x86_64
root:~# lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 6.0.3 (squeeze)
Release: 6.0.3
Codename: squeeze
So between the working and the non-working servers, both have the same kernel that bug reports to be affected. And higher than 1.4 ver of iptables.
I did rsync of the iptables script from the working server to the non-working server, checked the entire script for any loose space or misplaced commands and did another restore, but still failed.
I also did a reinstall of the iptables.
Any other ideas?
sven said,
April 4, 2012 at 11:50 UTC (+0000)
Hi Shy.
I’m not sure if you solved the problem by now. If so: What was the solution?
If not: The only thing I notice is that one of the machines is running a 32bit kernel, while the other machine uses a 64bit kernel. What kind of userland are you using on the machine with the 64bit kernel? If it is 32bit, this might be the problem, because some structures used by iptables when communicating with the kernel might just not be compatible between a 64bit kernel and 32bit userland.