| 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@xxxxxxxxxxxxxxxx> |
| References: | <20050124005348.GL23931@xxxxxxxxxxxxxx> <E1Cst4o-0007bD-00@xxxxxxxxxxxxxxxxxxxxxxxx> <20050123202715.281ac87c.davem@xxxxxxxxxxxxx> <20050124121610.GP23931@xxxxxxxxxxxxxx> <41F50B6C.6010107@xxxxxxxxxxxxxxxx> |
| 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> |
|---|---|---|
| ||
| Previous by Date: | Re: [RFC] batched tc to improve change throughput, Thomas Graf |
|---|---|
| Next by Date: | Re: skb_checksum_help, David Coulson |
| Previous by Thread: | Re: skb_checksum_help, David Coulson |
| Next by Thread: | Re: skb_checksum_help, David Coulson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |