netdev
[Top] [All Lists]

Re: skb_checksum_help

To: Thomas Graf <tgraf@xxxxxxx>
Subject: Re: skb_checksum_help
From: David Coulson <david@xxxxxxxxxxxxxxxx>
Date: Mon, 24 Jan 2005 10:27:47 -0500
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>, 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: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217
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.

cr1:~# tcpdump -nxxli vlan102 net 211.32.117.0/24 and port 53 > tcpdump.txt

I assume that 'xx' is sufficient to dump all of the packet/link information we need?

David

--
David J. Coulson
email: david@xxxxxxxxxxxxxxxx
web: http://www.davidcoulson.net/
phone: (216) 920-3100 / (216) 258-4942

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