Received: with ECARTIS (v1.0.0; list netdev); Mon, 29 Mar 2004 20:30:57 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [66.187.233.31]) by oss.sgi.com (8.12.10/8.12.9) with SMTP id i2U4UsKO009074 for ; Mon, 29 Mar 2004 20:30:55 -0800 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i2U4Uo1X031742; Mon, 29 Mar 2004 23:30:50 -0500 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [172.16.58.1]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i2U4Uoj01348; Mon, 29 Mar 2004 23:30:50 -0500 Received: from cheetah.davemloft.net (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.10/8.12.10) with SMTP id i2U4UT1n031135; Mon, 29 Mar 2004 23:30:29 -0500 Date: Mon, 29 Mar 2004 20:30:25 -0800 From: "David S. Miller" To: Bart De Schuymer Cc: netdev@oss.sgi.com, netfilter-devel@lists.netfilter.org Subject: Re: [PATCH] don't require ip_forwarding for reset on a bridge Message-Id: <20040329203025.4d272b55.davem@redhat.com> In-Reply-To: <200403292314.12855.bdschuym@pandora.be> References: <200403292314.12855.bdschuym@pandora.be> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; sparc-unknown-linux-gnu) X-Face: "_;p5u5aPsO,_Vsx"^v-pEq09'CU4&Dc1$fQExov$62l60cgCc%FnIwD=.UF^a>?5'9Kn[;433QFVV9M..2eN.@4ZWPGbdi<=?[:T>y?SD(R*-3It"Vj:)"dP Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-archive-position: 4337 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: davem@redhat.com Precedence: bulk X-list: netdev Content-Length: 527 Lines: 11 On Mon, 29 Mar 2004 23:14:12 +0200 Bart De Schuymer wrote: > Currently, to be able to send a reset in the FORWARD chain of iptables > for bridged traffic, ip forwarding must be enabled. This causes confusion > and in some situations people really don't want to enable ip forwarding. > The patch below lets the user send reset packets for bridged frames in > the FORWARD chain, with ip forwarding disabled (as long as there is a > route). I want an ACK from the netfilter folks before applying this one.