public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Vishwas Raman <vishwas@eternal-systems.com>
To: Jamie Lokier <jamie@shareable.org>
Cc: root@chaos.analogic.com, linux-kernel@vger.kernel.org
Subject: Re: Incremental update of TCP Checksum
Date: Tue, 16 Sep 2003 16:32:39 -0700	[thread overview]
Message-ID: <3F679D97.5030400@eternal-systems.com> (raw)
In-Reply-To: 20030916224151.GC30188@mail.jlokier.co.uk

Jamie Lokier wrote:
> Richard B. Johnson wrote:
> 
>>If I were to modify a low byte somewhere by subtracting 1,
>>would I know that the new checksum, excluding the inversion,
>>was 0x0000? No. It could be 0xffff.
> 
> 
> You're right about information being thrown away, but wrong because IP
> checksums are more rigidly defined than that.
> 
> RFC1624 was written because the earlier RFC actually got this wrong.
> 
> As long as at least one of the checksummed words is known to be
> non-zero, 0x0000 is not a possible value.  This is true of all IP checksums.
> 
> There is only one possible value of the non-complemented sum: 0xffff.
> 
> So when you subtract 1 from 0x0001, you get 0xffff.
> 
> To do this right, instead of subtracting a word, you add the
> complement of the word.  After carry-folding, this works out right.
> 
> Vishwas Raman wrote:
> 
>>Are you then suggesting that instead of trying to do an incremental 
>>update of the tcp checksum, I set it to 0 and recalculate it from 
>>scratch? But I thought that doing that was a big performance hit. Isn't it?
> 
> 
> You don't need to recalculate the sum.  All routers modify the IP
> header checksum when they decrement the TTL of a packet - it's a
> widely used algorithm.  Equation 3 from RFC1624 is correct :)

I was also under the belief that RFC1624 was handling this correctly.

> 
> Your code looks fine to me.  Are you sure you're verifying the
> checksum correctly?


This is how I am verifying the checksum. It seems to work in other 
cases. (by the way, I am working with the 2.4.20 kernel src code)

/* I do this check for only packets that are less than or equal to 76 
bytes in length. And I make sure the packets that I am dealing with are 
less than this length */

int tcpFailoverVerifyChecksum(struct sk_buff* skb)
{
     int len = skb->len - sizeof(struct iphdr);
     retValue = tcp_v4_check(skb->h.th, len,
                             skb->nh.iph->saddr, skb->nh.iph->daddr,
                             csum_partial((char *)skb->h.th, len, 0));
     return retValue;
}

Is the above function right? If not, what is the right way to verify the 
checksum of a tcp packet?


> 
> 
>>    while (cksum >> 16)
>>    {
>>        cksum = (cksum & 0xffff) + (cksum >> 16);
>>    }
> 
> 
> In general you need to add back the carry bits at most twice, btw.
> 
> 	cksum = (cksum & 0xffff) + (cksum >> 16);
> 	cksum += (cksum >> 16);

Ok...I will make the change... Thks...





  reply	other threads:[~2003-09-16 23:33 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-08-14 22:06 Netfiltering - NF_IP_LOCAL_OUT - how it works??? Vishwas Raman
2003-08-21 13:49 ` Harald Welte
2003-08-21 16:44   ` Vishwas Raman
2003-09-16 18:50   ` Incremental update of TCP Checksum Vishwas Raman
2003-09-16 19:00     ` Valdis.Kletnieks
2003-09-16 20:32       ` Vishwas Raman
2003-09-16 20:47         ` Leo Mauro
2003-09-17  3:28         ` Raf D'Halleweyn
2003-09-17  4:43           ` David S. Miller
2003-09-17 13:20           ` Richard B. Johnson
2003-09-17 20:34             ` Jamie Lokier
2003-09-16 19:47     ` Richard B. Johnson
2003-09-16 20:21       ` Vishwas Raman
2003-09-16 20:34         ` Richard B. Johnson
2003-09-16 20:35         ` Jesper Juhl
2003-09-17  1:37           ` Lincoln Dale
2003-09-17  1:39             ` Jesper Juhl
2003-09-16 22:41         ` Jamie Lokier
2003-09-16 23:32           ` Vishwas Raman [this message]
2003-09-16 20:33     ` Patrick McHardy
     [not found] <kysi.5h.17@gated-at.bofh.it>
     [not found] ` <mZy6.3NX.7@gated-at.bofh.it>
     [not found]   ` <wtdD.3EP.13@gated-at.bofh.it>
     [not found]     ` <wtnf.3Zv.9@gated-at.bofh.it>
     [not found]       ` <wuMz.65Q.15@gated-at.bofh.it>
     [not found]         ` <wBkH.7Sv.3@gated-at.bofh.it>
     [not found]           ` <wKxN.5h0.7@gated-at.bofh.it>
2003-09-17 14:06             ` Ihar 'Philips' Filipau

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=3F679D97.5030400@eternal-systems.com \
    --to=vishwas@eternal-systems.com \
    --cc=jamie@shareable.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=root@chaos.analogic.com \
    /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