[Top] [All Lists]

Re: skb_checksum_help

To: Thomas Graf <tgraf@xxxxxxx>
Subject: Re: skb_checksum_help
From: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Date: Tue, 25 Jan 2005 09:54:23 +1100
Cc: David Coulson <david@xxxxxxxxxxxxxxxx>, "David S. Miller" <davem@xxxxxxxxxxxxx>, kaber@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <20050124151510.GV23931@xxxxxxxxxxxxxx>
References: <20050124005348.GL23931@xxxxxxxxxxxxxx> <E1Cst4o-0007bD-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050123202715.281ac87c.davem@xxxxxxxxxxxxx> <20050124121610.GP23931@xxxxxxxxxxxxxx> <41F50B6C.6010107@xxxxxxxxxxxxxxxx> <20050124151510.GV23931@xxxxxxxxxxxxxx>
Sender: netdev-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.6+20040722i
On Mon, Jan 24, 2005 at 04:15:10PM +0100, Thomas Graf wrote:
> After inspecting your iptables rule set I think it is a general UDP DNAT
> problem under some circumstances. Some defragmentation weirdness in
> prerouting might be invovled. It would definitely help to have a dump
> of a complete ip fragments sequence causing this bug but I can't tell
> what exactly is the cause just now so yes it might be a good idea to
> limit the dump to the above subnet and hope the dodgy traffic comes
> from the same subnet again.

OK, I think I've found the problem.  It's a totally innocuous bug
in ip_fragment/ip6_fragment.  When we're in the fast path and use
the pre-existing frag_list skb's, we forgot to clear ip_summed.

Signed-off-by: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>

However, the problem that Patrick identified is very serious and
we should fix that as a matter of urgency.

Visit Openswan at
Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page:
PGP Key:

Attachment: p
Description: Text document

<Prev in Thread] Current Thread [Next in Thread>