netdev
[Top] [All Lists]

Re: skb_checksum_help

To: David Coulson <david@xxxxxxxxxxxxxxxx>
Subject: Re: skb_checksum_help
From: Thomas Graf <tgraf@xxxxxxx>
Date: Mon, 24 Jan 2005 16:15:10 +0100
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, kaber@xxxxxxxxx, netdev@xxxxxxxxxxx
In-reply-to: <41F50B6C.6010107@davidcoulson.net>
References: <20050124005348.GL23931@postel.suug.ch> <E1Cst4o-0007bD-00@gondolin.me.apana.org.au> <20050123202715.281ac87c.davem@davemloft.net> <20050124121610.GP23931@postel.suug.ch> <41F50B6C.6010107@davidcoulson.net>
Sender: netdev-bounce@xxxxxxxxxxx
* David Coulson <41F50B6C.6010107@xxxxxxxxxxxxxxxx> 2005-01-24 09:51
> Thomas Graf wrote:
> >Yes, this might clear things up.
> 
> 10.1.1.5 is a production NS, so there is >500kbit/sec of DNS traffic to 
> the box. Do you want me to restrict tcpdump to the /24 we were seeing 
> traffic from which broke the kernel, or dump everything and send the 
> part from around when the kernel fails?

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.

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