Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*skb_checksum

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*skb_checksum_help\s*$/: 92 ]

Total 92 documents matching your query.

61. Re: skb_checksum_help (score: 1): Author: David Coulson <david@xxxxxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 09:25:24 -0500; Yes, this explains the repetive payload. Can you provide your complete netfilter rule set? iptables-save + .config + /var/log/dmesg output (in that order) *raw COMMIT *nat -A PREROUTING -m mark --ma; /archives/netdev/2005-01/msg02548.html (70,871 bytes)
62. Re: skb_checksum_help (score: 1): Author: David Coulson <david@xxxxxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 09:49:12 -0500; No kernel module support on the box. Only non-standard patch, was the mppe/mppc patch which isn't being used right now (It's turned on in the kernel config however). I attached the .config to a previ; /archives/netdev/2005-01/msg02549.html (10,979 bytes)
63. Re: skb_checksum_help (score: 1): Author: David Coulson <david@xxxxxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 09:51:24 -0500; 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 a; /archives/netdev/2005-01/msg02550.html (10,970 bytes)
64. Re: skb_checksum_help (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Mon, 24 Jan 2005 16:15:10 +0100; * David Coulson <41F50B6C.6010107@xxxxxxxxxxxxxxxx> 2005-01-24 09:51 After inspecting your iptables rule set I think it is a general UDP DNAT problem under some circumstances. Some defragmentation we; /archives/netdev/2005-01/msg02553.html (10,707 bytes)
65. Re: skb_checksum_help (score: 1): Author: David Coulson <david@xxxxxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 10:27:47 -0500; 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; /archives/netdev/2005-01/msg02554.html (11,228 bytes)
66. Re: skb_checksum_help (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 25 Jan 2005 09:54:23 +1100; 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. Signe; /archives/netdev/2005-01/msg02561.html (11,824 bytes)
67. Re: skb_checksum_help (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 25 Jan 2005 00:45:15 +0100; * Herbert Xu <20050124225423.GA15405@xxxxxxxxxxxxxxxxxxx> 2005-01-25 09:54 I don't quite understand how this solves the problem. How could ip_summed be non zero after ip_forward? The earliest possibl; /archives/netdev/2005-01/msg02563.html (11,403 bytes)
68. Re: skb_checksum_help (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 25 Jan 2005 11:07:59 +1100; ip_forward only sets ip_summed for the packet at the head. It does not clear ip_summed for the fragments themselves. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~}; /archives/netdev/2005-01/msg02565.html (11,326 bytes)
69. Re: skb_checksum_help (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 16:40:49 -0800; Yes, there exists all of this weird logic in ip_fragment.c trying to preserve the checksumming done on RX by the hardware. When we reassemble an ipv4 set of frags, we do this in ip_frag_reasm() for (; /archives/netdev/2005-01/msg02567.html (13,053 bytes)
70. Re: skb_checksum_help (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 25 Jan 2005 02:45:38 +0100; * David S. Miller <20050124164049.3b939791.davem@xxxxxxxxxxxxx> 2005-01-24 16:40 You are indeed right, I actually thought it would be like this first but tricked myself into not believeing in this an; /archives/netdev/2005-01/msg02568.html (13,014 bytes)
71. Re: skb_checksum_help (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 25 Jan 2005 12:48:38 +1100; Didn't he say that he cleared the features bits in the acenic driver? BTW, is he using acenic for both the LAN and the WAN? If he's only using it on the WAN side, then the LAN side might not be CSUM; /archives/netdev/2005-01/msg02569.html (11,758 bytes)
72. Re: skb_checksum_help (score: 1): Author: David Coulson <david@xxxxxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 20:59:20 -0500; I'm using the original acenic.c driver right now. BTW, is he using acenic for both the LAN and the WAN? If he's only using it on the WAN side, then the LAN side might not be CSUM capable. I've got th; /archives/netdev/2005-01/msg02570.html (11,945 bytes)
73. Re: skb_checksum_help (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 25 Jan 2005 03:01:18 +0100; * Herbert Xu <20050125014838.GA16637@xxxxxxxxxxxxxxxxxxx> 2005-01-25 12:48 He changed it back to the original version, I just checked with him. The packets get routed back over the same physical inte; /archives/netdev/2005-01/msg02571.html (11,453 bytes)
74. Re: skb_checksum_help (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 18:02:05 -0800; I looked this up too, and your list of drivers actually using CHECKSUM_HW on RX seems accurate.; /archives/netdev/2005-01/msg02572.html (11,002 bytes)
75. Re: skb_checksum_help (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 18:03:54 -0800; I think I see what is happening, it's the virtual VLAN device which has dev->features set to zero not the acenic's netdev struct.; /archives/netdev/2005-01/msg02573.html (11,970 bytes)
76. Re: skb_checksum_help (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 25 Jan 2005 13:07:49 +1100; I don't think the vlan code actually sets the features bits... -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.; /archives/netdev/2005-01/msg02574.html (11,440 bytes)
77. Re: skb_checksum_help (score: 1): Author: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>; Date: Tue, 25 Jan 2005 13:14:59 +1100; Well the BUG() only triggers if skb->csum + 2 > offset, which is not necessarily true for every skb. -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxx; /archives/netdev/2005-01/msg02576.html (11,353 bytes)
78. Re: skb_checksum_help (score: 1): Author: Patrick McHardy <kaber@xxxxxxxxx>; Date: Tue, 25 Jan 2005 03:15:42 +0100; However, the problem that Patrick identified is very serious and we should fix that as a matter of urgency. I'll send a patch later tonight. Regards Patrick; /archives/netdev/2005-01/msg02577.html (10,085 bytes)
79. Re: skb_checksum_help (score: 1): Author: Thomas Graf <tgraf@xxxxxxx>; Date: Tue, 25 Jan 2005 03:24:31 +0100; * David S. Miller <20050124180354.63ae600d.davem@xxxxxxxxxxxxx> 2005-01-24 18:03 This of course explains it, didn't think of that. I thought it would inherit the checksumming features.; /archives/netdev/2005-01/msg02578.html (11,212 bytes)
80. Re: skb_checksum_help (score: 1): Author: "David S. Miller" <davem@xxxxxxxxxxxxx>; Date: Mon, 24 Jan 2005 19:43:28 -0800; It should, but only in very limited cases. For example, it probably only works properly when HW vlan assist is being used on TX. It's likely that the chips which don't support VLAN assist also can't; /archives/netdev/2005-01/msg02592.html (11,461 bytes)

Current List: 61 - 80
Page: [1] [2] [3] [4] [5]