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...
next prev parent 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 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.