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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox