lkml.org 
[lkml]   [2003]   [Sep]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Incremental update of TCP Checksum

    Richard B. Johnson wrote:
    > On Tue, 16 Sep 2003, Vishwas Raman wrote:
    >
    >
    >>Hi all,
    >>
    >>I have a very simple question, which a lot of you would have solved. I
    >>am intercepting a TCP packet, which I would like to change slightly.
    >>
    >>Let's say, I change the doff field of the tcp-header (for eg: increase
    >>it by 1). I know it is wrong just to change the doff field without
    >>increasing the packet length, but lets say I do it just as a test. Since
    >>I changed a portion of the tcp header, I have to update the tcp checksum
    >>too right!!! If so, what is the best way to do so, without having to
    >>recalculate the entire tcp checksum (I know how to recalculate the
    >>checksum from scratch).
    >>
    >>Can anyone out there tell me the algorithm to update the checksum
    >>without having to recalculate it.
    >>
    >>I tried the following algorithm but it didnt work. The packet got
    >>rejected as a packet with bad cksum.
    >>
    >>void changePacket(struct sk_buff* skb)
    >>{
    >> struct tcphdr *tcpHdr = skb->h.th;
    >> // Verifying the tcp checksum works here...
    >> tcpHeader->doff += 1;
    >> long cksum = (~(tcpHdr->check))&0xffff;
    >> cksum += 1;
    >> while (cksum >> 16)
    >> {
    >> cksum = (cksum & 0xffff) + (cksum >> 16);
    >> }
    >> tcpHeader->check = ~cksum;
    >> // Verifying tcp checksum here fails with bad cksum
    >>}
    >>
    >>Any pointers/help in this regard will be highly appreciated...
    >
    >
    > The TCP/IP checksum is a WORD sum (unsigned short) in which
    > any overflow out of the word causes the word to be incremented.
    > The final sum is then inverted to become the checksum. Note that
    > many algorithms sum into a long then fold-back the bits. It's
    > the same thing, different method.
    >
    > Therefore:
    > Given an existing checksum of 0xffff, if the
    > next word to be summed is 0x0001, the result
    > will be 0x0001 because adding 1 to 0xffff makes
    > it 0, causing an overflow which propagates to
    > become 0x0001.
    > So:
    > Clearly, information is lost because one doesn't
    > know how the 0x0001 was obtained.
    >
    > 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.
    >
    > This presents a problem when trying to modify existing checksums.
    > It's certainly easier to set the existing checksum to 0, then
    > re-checksum the whole packet. It's probably faster than some
    > looping algorithm that attempts to unwind a previous checksum.

    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?

    >
    >
    > Cheers,
    > Dick Johnson
    > Penguin : Linux version 2.4.22 on an i686 machine (794.73 BogoMips).
    > Note 96.31% of all statistics are fiction.
    >
    >
    >



    --
    --
    Vishwas Raman
    Software Engineer, Eternal Systems, Inc,
    5290 Overpass Rd, Bldg D, Santa Barbara. CA 93111
    Email: vishwas@eternal-systems.com
    Tel: (805) 696-9051 x246
    Fax: (805) 696-9083
    URL: http://www.eternal-systems.com/

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:48    [W:3.435 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site