| 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.txtI 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> |
|---|---|---|
| ||
| Previous by Date: | Re: skb_checksum_help, Thomas Graf |
|---|---|
| Next by Date: | [2.6 patch] kernel-api.sgml references removed file net_init.c, Adrian Bunk |
| Previous by Thread: | Re: skb_checksum_help, Thomas Graf |
| Next by Thread: | Re: skb_checksum_help, Herbert Xu |
| Indexes: | [Date] [Thread] [Top] [All Lists] |