All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jarek Poplawski <jarkao2@o2.pl>
To: Michael Tokarev <mjt@tls.msk.ru>
Cc: netdev@vger.kernel.org, Patrick McHardy <kaber@trash.net>,
	Herbert Xu <herbert@gondor.apana.org.au>
Subject: [PATCH] tcp_output: Re: rare bad TCP checksum with 2.6.19?
Date: Fri, 19 Jan 2007 12:06:41 +0100	[thread overview]
Message-ID: <20070119110641.GA3135@ff.dom.local> (raw)
In-Reply-To: <45AE2EDF.4060709@tls.msk.ru>

On 17-01-2007 15:12, Michael Tokarev wrote:
> 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 216.168.29.244 - the requesting/receiving side -- and
>>> 81.13.94.6 -- our sending side (the file being transferred is some
>>> trojan horse I found on a friend's PC, so be careful ;)
>> I'll have a look at this tomorrow.
>>
>> 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.
> 
> 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 (82.84.172.37 -- a zombie machine trying to send us spam
> in this case) connects to a port 25 here (81.13.94.6:25).  SYN+ACK
> sequence completes.  Next, our server send an initial SMTP greething
> message, but almost right after that, the client sends a FIN packet,
> WITHOUT acknowleging that it received the (first and only) data
> packet.  So some time later our machine re-sends the data, AND adds
> FIN flag to the packet (also replying to the FIN received from the
> client).  And *that* packet - original data packet which is modified
> to also include FIN - has incorrect checksum.
> 
> So it looks like the checksum isn't being updated WHEN ADDING MORE
> FLAGS to the original data packet.
> 

Hi,

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.

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 of ip_summed field from collapsed
skb. This patch reverts this change.   

All substantial work including heavy testing and diagnosing by:
Michael Tokarev <mjt@tls.msk.ru>

Signed-off-by: Jarek Poplawski <jarkao2@o2.pl>
---

diff -Nurp linux-2.6.19-/net/ipv4/tcp_output.c linux-2.6.19/net/ipv4/tcp_output.c
--- linux-2.6.19-/net/ipv4/tcp_output.c	2006-11-29 22:57:37.000000000 +0100
+++ linux-2.6.19/net/ipv4/tcp_output.c	2007-01-19 07:58:39.000000000 +0100
@@ -1590,7 +1590,8 @@ static void tcp_retrans_try_collapse(str
 
 		memcpy(skb_put(skb, next_skb_size), next_skb->data, next_skb_size);
 
-		skb->ip_summed = next_skb->ip_summed;
+		if (next_skb->ip_summed == CHECKSUM_PARTIAL)
+			skb->ip_summed = CHECKSUM_PARTIAL;
 
 		if (skb->ip_summed != CHECKSUM_PARTIAL)
 			skb->csum = csum_block_add(skb->csum, next_skb->csum, skb_size);

  reply	other threads:[~2007-01-19 11:04 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-14 22:59 rare bad TCP checksum with 2.6.19? Michael Tokarev
2007-01-15  9:39 ` Herbert Xu
2007-01-15 13:34   ` Michael Tokarev
2007-01-15 14:25     ` Michael Tokarev
2007-01-15 18:13     ` Eric Dumazet
2007-01-15 19:33       ` Michael Tokarev
2007-01-15 23:36         ` Eric Dumazet
2007-01-15 20:10     ` Herbert Xu
2007-01-15 21:46       ` Michael Tokarev
2007-01-15 23:35         ` Herbert Xu
2007-01-16  3:27         ` Herbert Xu
2007-01-16  3:38           ` Herbert Xu
2007-01-16  8:08             ` Michael Tokarev
2007-01-16 11:50               ` Herbert Xu
2007-01-16 12:15                 ` Patrick McHardy
2007-01-16 14:38                   ` Michael Tokarev
2007-01-17 14:12                 ` Michael Tokarev
2007-01-19 11:06                   ` Jarek Poplawski [this message]
2007-01-19 12:14                     ` [PATCH] tcp_output: " Patrick McHardy
2007-01-19 13:23                       ` Michael Tokarev
2007-01-19 14:32                       ` Jarek Poplawski
2007-01-19 13:20                     ` Michael Tokarev
2007-01-19 14:08                       ` Jarek Poplawski
2007-01-22  7:13                         ` Jarek Poplawski
2007-01-22  7:19                           ` Michael Tokarev
2007-01-22  8:03                             ` Jarek Poplawski
2007-01-19 21:10                     ` Herbert Xu
2007-01-22  6:52                       ` Jarek Poplawski
2007-01-22  7:45                         ` Herbert Xu
2007-01-22  8:48                           ` Jarek Poplawski
2007-01-22 13:46                           ` Patrick McHardy
2007-01-24  6:08                         ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070119110641.GA3135@ff.dom.local \
    --to=jarkao2@o2.pl \
    --cc=herbert@gondor.apana.org.au \
    --cc=kaber@trash.net \
    --cc=mjt@tls.msk.ru \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.