netdev.vger.kernel.org archive mirror
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).