[SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Harald Welte]

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 <stelian.pop@fr.alcove.com>
> To: "H. Peter Anvin" <hpa@zytor.com>
> Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
> Subject: Re: 2.4.18-pre9: iptables screwed?
> Reply-To: Stelian Pop <stelian.pop@fr.alcove.com>
> In-Reply-To: <a3vjts$r7l$1@cesium.transmeta.com>
> 
> 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 <stelian.pop@fr.alcove.com>


-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               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+(*)

Re: [SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Stelian Pop]

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 <stelian.pop@fr.alcove.com>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|

Re: [SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Harald Welte]

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 <stelian.pop@fr.alcove.com>

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               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+(*)

Re: [SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Stelian Pop]

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 <stelian.pop@fr.alcove.com>
|---------------- Free Software Engineer -----------------|
| Alcôve - http://www.alcove.com - Tel: +33 1 49 22 68 00 |
|------------- Alcôve, liberating software ---------------|

Re: [SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Bill Davidsen]

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 <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.

Re: [SOLUTION] Re: Fw: 2.4.18-pre9: iptables screwed?

[Harald Welte]

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 <davidsen@tmr.com>

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               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+(*)