Received: with ECARTIS (v1.0.0; list netdev); Sat, 28 Feb 2004 21:50:44 -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 i1T5oNKO020425
	for <netdev@oss.sgi.com>; Sat, 28 Feb 2004 21:50:25 -0800
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id i1T5oEb16125;
	Sun, 29 Feb 2004 00:50:14 -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 i1T5oE826335;
	Sun, 29 Feb 2004 00:50:14 -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 i1T5o9eF015642;
	Sun, 29 Feb 2004 00:50:09 -0500
Date: Sat, 28 Feb 2004 21:50:13 -0800
From: "David S. Miller" <davem@redhat.com>
To: James Morris <jmorris@redhat.com>
Cc: mika.penttila@kolumbus.fi, laforge@netfilter.org, netdev@oss.sgi.com,
        sds@epoch.ncsc.mil
Subject: Re: [PATCH] Fix checksum bug for multicast/broadcast packets on
 postrouting hook
Message-Id: <20040228215013.28a61c76.davem@redhat.com>
In-Reply-To: <Xine.LNX.4.44.0402231713310.21153-100000@thoron.boston.redhat.com>
References: <20040218172441.2eb117a7.davem@redhat.com>
	<Xine.LNX.4.44.0402231713310.21153-100000@thoron.boston.redhat.com>
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: 3651
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

On Mon, 23 Feb 2004 17:19:03 -0500 (EST)
James Morris <jmorris@redhat.com> wrote:

> This does not seem to be the correct approach.  If you drop packets in 
> the ipsec cases at least, the retransmits just keep feeding packets back 
> in with hardware checksumming set.

Ok, so TCP retransmits do this.

There is a check missing somewhere in the TCP output path then.
Or maybe, it refuses to mess with checksum state after the SKB
has been created, even for further retransmits.

More brainpower needed...