From: Jarek Poplawski [EMAIL PROTECTED]
Date: Mon, 22 Jan 2007 07:52:14 +0100
[PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
The patch Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE
changed to unconditional copying of ip_summed field from collapsed
skb. This patch
On Mon, Jan 22, 2007 at 10:19:18AM +0300, Michael Tokarev wrote:
...
I was only running tcpdump - yes, it was running almost the
whole day, with different options. I did almost nothing.
You over-estimate my contribution, really ;)
The very good thing is that this bug is now found, and
On Mon, Jan 22, 2007 at 06:45:57PM +1100, Herbert Xu wrote:
On Mon, Jan 22, 2007 at 07:52:14AM +0100, Jarek Poplawski wrote:
I was so impressed by the amount of work done by Michael
that I magnified his merit and forgot to mention the role
of Patrick and Herbert, particularly here:
Herbert Xu wrote:
On Mon, Jan 22, 2007 at 07:52:14AM +0100, Jarek Poplawski wrote:
I was so impressed by the amount of work done by Michael
that I magnified his merit and forgot to mention the role
of Patrick and Herbert, particularly here:
You don't need to be so modest!
While no
On Sat, Jan 20, 2007 at 08:10:27AM +1100, Herbert Xu wrote:
On Fri, Jan 19, 2007 at 12:06:41PM +0100, Jarek Poplawski wrote:
[PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
The patch Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE
changed to unconditional copying
On Fri, Jan 19, 2007 at 03:08:20PM +0100, Jarek Poplawski wrote:
...
You are welcome! But you probably didn't read this with
attention: if it works, you should thank mainly to that
other guy...
Btw. I can't remember I've seen such ferocious testing
ever!
After checking in the dictionary I
Jarek Poplawski wrote:
On Fri, Jan 19, 2007 at 03:08:20PM +0100, Jarek Poplawski wrote:
...
You are welcome! But you probably didn't read this with
attention: if it works, you should thank mainly to that
other guy...
Btw. I can't remember I've seen such ferocious testing
ever!
After
On Mon, Jan 22, 2007 at 07:52:14AM +0100, Jarek Poplawski wrote:
I was so impressed by the amount of work done by Michael
that I magnified his merit and forgot to mention the role
of Patrick and Herbert, particularly here:
You don't need to be so modest!
While no doubt Patrick helped in
packet and changes
its ip_summed field to CHECKSUM_NONE.
Regards,
Jarek P.
PS: probably there are also other possibilities...
---
[PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
The patch Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE
changed to unconditional copying
Jarek Poplawski wrote:
Here is my patch proposal. If I'm not totally wrong,
there is a possibility that, during collapsing, empty
skb with FIN is added to normal packet and changes
its ip_summed field to CHECKSUM_NONE.
diff -Nurp linux-2.6.19-/net/ipv4/tcp_output.c
Jarek Poplawski wrote:
On 17-01-2007 15:12, Michael Tokarev wrote:
[]
Here's another sample, which may be more useful. I've seen quite
alot of very similar stuff while running tcpdump.
http://www.corpit.ru/mjt/bad-cksum-session3-dmp.bin
The scenario looks like this.
A client
Patrick McHardy wrote:
Jarek Poplawski wrote:
Here is my patch proposal. If I'm not totally wrong,
there is a possibility that, during collapsing, empty
skb with FIN is added to normal packet and changes
its ip_summed field to CHECKSUM_NONE.
diff -Nurp linux-2.6.19-/net/ipv4/tcp_output.c
On Fri, Jan 19, 2007 at 04:20:01PM +0300, Michael Tokarev wrote:
...
Well.. I just tried it - with this patch applied, no more bad checksums
are shown. Tried from the network that triggers it most reliable - and
wasn't able to reproduce the bad behavior.
I'm running a tcpdump right now,
On Fri, Jan 19, 2007 at 01:14:52PM +0100, Patrick McHardy wrote:
Jarek Poplawski wrote:
Here is my patch proposal. If I'm not totally wrong,
there is a possibility that, during collapsing, empty
skb with FIN is added to normal packet and changes
its ip_summed field to CHECKSUM_NONE.
On Fri, Jan 19, 2007 at 12:06:41PM +0100, Jarek Poplawski wrote:
[PATCH][NET] tcp_output: rare bad TCP checksum with 2.6.19
The patch Replace CHECKSUM_HW by CHECKSUM_PARTIAL/CHECKSUM_COMPLETE
changed to unconditional copying of ip_summed field from collapsed
skb. This patch reverts
Herbert Xu wrote:
On Tue, Jan 16, 2007 at 11:08:51AM +0300, Michael Tokarev wrote:
Ok. Here's another trace, from that remote network that triggers
this thing more-or-less reliable (every 2nd transfer at least) --
http://www.corpit.ru/mjt/bh-bad-cksum-dmp.bin . It's a full session
between
Herbert Xu wrote:
On Tue, Jan 16, 2007 at 02:27:39PM +1100, Herbert Xu wrote:
I'm sorry but this dump does NOT look like it was taken from an
intermediate box. I verified two bad checksums (chosen randomly)
and they were both correct but partial checksums. This means that
this dump was most
On Tue, Jan 16, 2007 at 11:08:51AM +0300, Michael Tokarev wrote:
Ok. Here's another trace, from that remote network that triggers
this thing more-or-less reliable (every 2nd transfer at least) --
http://www.corpit.ru/mjt/bh-bad-cksum-dmp.bin . It's a full session
between 216.168.29.244 -
Herbert Xu wrote:
On Tue, Jan 16, 2007 at 11:08:51AM +0300, Michael Tokarev wrote:
Ok. Here's another trace, from that remote network that triggers
this thing more-or-less reliable (every 2nd transfer at least) --
http://www.corpit.ru/mjt/bh-bad-cksum-dmp.bin . It's a full session
between
Patrick McHardy wrote:
Herbert Xu wrote:
[]
Since you're certain that this is being seen on the wire, one
possibility is that we've got a bug somewhere that's zeroing
skb-ip_summed on a packet with a partial checksum.
One potential spot where this could happen is netfilter.
Patrick, do you
Michael Tokarev [EMAIL PROTECTED] wrote:
Note there's no funny/interesting hardware involved, like network cards with
tcp checksumming offload capabilities (this is plain dumb 8139 card).
The 8139 card might be dumb, but the driver isn't :) It emulates
checksum offload in software, meaning
Herbert Xu wrote:
Michael Tokarev [EMAIL PROTECTED] wrote:
Note there's no funny/interesting hardware involved, like network cards with
tcp checksumming offload capabilities (this is plain dumb 8139 card).
The 8139 card might be dumb, but the driver isn't :) It emulates
checksum offload in
Michael Tokarev a e'crit :
Any idea how to force sending FIN-with-data?
int flag_on = 1;
setsockopt(fd, SOL_TCP, TCP_CORK, flag_on, sizeof(int));
send(fd, data, datalen, 0);
close(fd);
Eric Dumazet
-
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to
On Mon, Jan 15, 2007 at 04:34:41PM +0300, Michael Tokarev wrote:
# ethtool -k eth0
Offload parameters for eth0:
Cannot get device rx csum settings: Operation not supported
Cannot get device tx csum settings: Operation not supported
Cannot get device scatter-gather settings: Operation not
Herbert Xu wrote:
On Mon, Jan 15, 2007 at 04:34:41PM +0300, Michael Tokarev wrote:
[]
So I guess the problem is not related to hw checksumming offloading.
Nope, it just means that 8139too doesn't provide ethtool handlers to
disable checksum offloading.
So I suggest that you try doing the
On Tue, Jan 16, 2007 at 12:46:08AM +0300, Michael Tokarev wrote:
I'm doing the capture on an intermediate host - the whole day today ;)
Cool, I was just trying to make sure :)
The trace is here: http://www.corpit.ru/mjt/bad-tcp-cksum-dmp.bin
I'll take a look.
Are you using anything extra
Michael Tokarev a écrit :
Eric Dumazet wrote:
Michael Tokarev a e'crit :
Any idea how to force sending FIN-with-data?
int flag_on = 1;
setsockopt(fd, SOL_TCP, TCP_CORK, flag_on, sizeof(int));
send(fd, data, datalen, 0);
close(fd);
That produces two packets - one (or more - depending on the
On Tue, Jan 16, 2007 at 12:46:08AM +0300, Michael Tokarev wrote:
The trace is here: http://www.corpit.ru/mjt/bad-tcp-cksum-dmp.bin
I'm sorry but this dump does NOT look like it was taken from an
intermediate box. I verified two bad checksums (chosen randomly)
and they were both correct but
On Tue, Jan 16, 2007 at 02:27:39PM +1100, Herbert Xu wrote:
I'm sorry but this dump does NOT look like it was taken from an
intermediate box. I verified two bad checksums (chosen randomly)
and they were both correct but partial checksums. This means that
this dump was most likely taken
29 matches
Mail list logo
