On Fri, Feb 08, 2002 at 01:08:39AM -0800, David Miller wrote:
> Stelian has analyzed the bug already.
This is strange.
> From: Stelian Pop <[email protected]>
> To: "H. Peter Anvin" <[email protected]>
> Cc: Linux Kernel Mailing List <[email protected]>
> Subject: Re: 2.4.18-pre9: iptables screwed?
> Reply-To: Stelian Pop <[email protected]>
> In-Reply-To: <[email protected]>
>
> On Thu, Feb 07, 2002 at 08:24:28PM -0800, H. Peter Anvin wrote:
>
> > I get the following error with iptables on 2.4.18-pre9:
> >
> > sudo iptables-restore < /etc/sysconfig/iptables
> > iptables-restore: libiptc/libip4tc.c:384: do_check: Assertion
> > `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
> > Abort (core dumped)
The code you are quoting is only defined if debugging is compiled into
the iptables package. The default distribution of the iptables package
does _not_ ship with debugging enabled.
The Makefile of all iptables versions between 1.1.1 (released way before
the linux 2.4.0 kernel came out!) and 1.2.5 (current) have the following
line in the Makefile:
COPT_FLAGS:=-O2 -DNDEBUG
reads: define no debug
> > However, if I apply the rules manually (using iptables), I have no
> > problem; only if I'm using iptables-save or iptables-restore do I get
> > a dump...
>
> I have this since the netfilter update from pre6 or pre7...
>
> It seems to be caused by a change in the logic for the mangle table:
> the userspace tools check only for PREROUTING and OUTPUT chains
> (the 1 << 0 | 1 << 3 check), but the kernel code was recently updated
> to support more chains in this table (POSTROUTING etc).
This is true. We introduced this change after some testing since it
is needed for complex policy routing scenarios. It's the so-called
mangle5hooks.patch
> So it would seem that we need to have a more recent version of
> the userspace tools (CVS maybe, since the latest released version
> has the same bug), or the netfilter people should check the
> userspace tools version before introducing this kind of
> incompatible change.
I'm running the same iptables-1.2.2 binary (compiled at a 2.4.x kernel in July
2001) with a mangle5hooks-patch'ed linux kernel.
just re-checked it again:
======================================================================
sunbeam# rpm -qi iptables
Name : iptables Relocations: (not relocateable)
Version : 1.2.2 Vendor: Conectiva
Release : 2cl Build Date: Sun 17 Jun 2001 08:17:20 PM CEST
Install date: Thu 08 Nov 2001 01:42:57 PM CET Build Host: mapi2.distro.conectiva
Group : Networking Source RPM: iptables-1.2.2-2cl.src.rpm
Size : 439232 License: GPL
URL : http://netfilter.samba.org
Summary : Packet filtering tool for kernel-2.4.x
Description :
This is the packet filtering tool for kernel-2.4.x. It is much more
advanced than ipchains and can take full advantage of the new
features within the 2.4.x packet filtering code. It allows you to
set up masquerading, full NAT, stateful inspection rules, etc.
sunbeam# rpm -V iptables
sunbeam# cat foo
# Generated by iptables-save v1.2.2 on Fri Feb 8 10:35:05 2002
*mangle
:PREROUTING ACCEPT [36557505:30073123582]
:INPUT ACCEPT [31280258:26426457730]
:FORWARD ACCEPT [5276687:3646630572]
:OUTPUT ACCEPT [28690202:18841029987]
:POSTROUTING ACCEPT [34105840:22505172519]
:knf - [0:0]
-A PREROUTING -p tcp -m tcp --dport 25 -j knf
-A PREROUTING -p tcp -m tcp --dport 6667 -j knf
-A POSTROUTING -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j TCPMSS --clamp-mss-to-pmtu
-A knf -j MARK --set-mark 0xa
COMMIT
sunbeam# iptables-restore < foo
sunbeam# iptables -t nat -L -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 192.168.100.0/24 0.0.0.0/0
MASQUERADE all -- 192.168.101.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
======================================================================
Because it was working on several systems, we have decided to forward
this patch to the mainstream kerel.
We always want to make sure that nobody needs to update the iptables
package during the 2.4.x stable kernel series. Because of this (sane)
policy, we are keeping back a whole bunch of changes. We can't just
silently abandon backwards compatibility.
> (BTW, the quick and dirty fix for me was to hand edit
> /etc/sysconfig/iptables and remove all references to the mangle table,
> since I don't use it).
this is of coruse no possible 'solution'.
> Stelian Pop <[email protected]>
--
Live long and prosper
- Harald Welte / [email protected] http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
On Fri, Feb 08, 2002 at 10:55:48AM +0100, Harald Welte wrote:
> > > I get the following error with iptables on 2.4.18-pre9:
> > >
> > > sudo iptables-restore < /etc/sysconfig/iptables
> > > iptables-restore: libiptc/libip4tc.c:384: do_check: Assertion
> > > `h->info.valid_hooks == (1 << 0 | 1 << 3)' failed.
> > > Abort (core dumped)
>
> The code you are quoting is only defined if debugging is compiled into
> the iptables package. The default distribution of the iptables package
> does _not_ ship with debugging enabled.
Right, upon further analysis the redhat RPM is overriding COPT_FLAGS
and removes the -DNDEBUG from the compile line.
> We always want to make sure that nobody needs to update the iptables
> package during the 2.4.x stable kernel series. Because of this (sane)
> policy, we are keeping back a whole bunch of changes. We can't just
> silently abandon backwards compatibility.
Hey, you keeped backwards compatibility _only_ for those compiling
the non debug version of the package. I believe this remains however
a half-bug...
Stelian.
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|
On Fri, Feb 08, 2002 at 11:12:18AM +0100, Stelian Pop wrote:
> > The code you are quoting is only defined if debugging is compiled into
> > the iptables package. The default distribution of the iptables package
> > does _not_ ship with debugging enabled.
>
> Right, upon further analysis the redhat RPM is overriding COPT_FLAGS
> and removes the -DNDEBUG from the compile line.
hm. bad coincidence :(
> > We always want to make sure that nobody needs to update the iptables
> > package during the 2.4.x stable kernel series. Because of this (sane)
> > policy, we are keeping back a whole bunch of changes. We can't just
> > silently abandon backwards compatibility.
>
> Hey, you keeped backwards compatibility _only_ for those compiling
> the non debug version of the package. I believe this remains however
> a half-bug...
Well, it is a bug in the debugging code, yes. We missed to updated the
debugging code when changing the mangle table. The reason for this is
that not even the developers are using the debugging code.
But when I do compatibility checks / tests for something I want to submit to
the kernel, I use plain unmodified iptables sources - new and old.
And I really didn't expect anybody to run debugging code on production
systems, sorry.
I'm not going to pull this change back out of the kernel because
one (or more) distributors/vendors ship a compiled-with-debug iptables.
I don't think this was by RedHat's intention.
> Stelian.
> Stelian Pop <[email protected]>
--
Live long and prosper
- Harald Welte / [email protected] http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)
On Fri, Feb 08, 2002 at 11:30:14AM +0100, Harald Welte wrote:
> Well, it is a bug in the debugging code, yes. We missed to updated the
> debugging code when changing the mangle table. The reason for this is
> that not even the developers are using the debugging code.
One may wonder then who is using this debugging code... :-)
Especially when you must pass an option to the cc line to _disable_ it...
> I'm not going to pull this change back out of the kernel because
> one (or more) distributors/vendors ship a compiled-with-debug iptables.
Of course, never said that.
> I don't think this was by RedHat's intention.
I don't think so, and anyway, the latest kernel is not supported
officially by RedHat either. When (if) they release an updated kernel
containing the mangle patch, they will need to update the iptables
userspace tools too. That's all.
--
Stelian Pop <[email protected]>
|---------------- Free Software Engineer -----------------|
| Alc?ve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alc?ve, liberating software ---------------|
On Fri, 8 Feb 2002, Harald Welte wrote:
> On Fri, Feb 08, 2002 at 01:08:39AM -0800, David Miller wrote:
>
> > Stelian has analyzed the bug already.
>
> This is strange.
>
> The code you are quoting is only defined if debugging is compiled into
> the iptables package. The default distribution of the iptables package
> does _not_ ship with debugging enabled.
>
> The Makefile of all iptables versions between 1.1.1 (released way before
> the linux 2.4.0 kernel came out!) and 1.2.5 (current) have the following
> line in the Makefile:
What is the first thing anyone would do if they had a problem with
iptables? Turn on debugging, obviously.
1 - that explains why I have no problem, I build from source, since I'm
always trying features in the new versions for better firewalls.
2 - it really should work, debug should find errors, not cause them.
3 - Perhaps debug could be disabled but default, so instead of needing
NDEBUG in production, you would use -DDEBUG when you had a problem
(and it might even work ;-).
--
bill davidsen <[email protected]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
On Mon, Feb 11, 2002 at 01:11:51PM -0500, Bill Davidsen wrote:
> What is the first thing anyone would do if they had a problem with
> iptables? Turn on debugging, obviously.
yes, I totally agree. I'm not arguing that the current behaviour is OK -
of course it should work with debugging enabled. All I said is that under
normal circumstances a production system is not supposed to have debugging
enabled.
> 2 - it really should work, debug should find errors, not cause them.
of course. That is why debugging does extra checks, which are disabled
in production use. Unfortunately we missed one check...
> 3 - Perhaps debug could be disabled but default, so instead of needing
> NDEBUG in production, you would use -DDEBUG when you had a problem
> (and it might even work ;-).
Yes, this is what I'm doing for the iptables-1.2.6 release. The current
-DNDEBUG stuff has historical reasons which are no longer valid.
> bill davidsen <[email protected]>
--
Live long and prosper
- Harald Welte / [email protected] http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M+
V-- PS++ PE-- Y++ PGP++ t+ 5-- !X !R tv-- b+++ !DI !D G+ e* h--- r++ y+(*)