Re: [lwip-users] TCP Checksum = 0xFFFF

[Niall Donovan]

To follow up on this issue. The offending piece of code that is generating the 0xFFFF as the TCP checksum is this (lines 1137-1147 in tcp_out.c):

    /* rebuild TCP header checksum (TCP header changes for retransmissions!) */

    acc = inet_chksum_pseudo_partial(seg->p, &(pcb->local_ip),

             &(pcb->remote_ip),

             IP_PROTO_TCP, seg->p->tot_len, TCPH_HDRLEN(seg->tcphdr) * 4);

    /* add payload checksum */

    if (seg->chksum_swapped) {

      seg->chksum = SWAP_BYTES_IN_WORD(seg->chksum);

      seg->chksum_swapped = 0;

    }

    acc += (u16_t)~(seg->chksum);

    seg->tcphdr->chksum = FOLD_U32T(acc);

If acc happens to have a value equal to seg->checksum, for example acc=0x8E93 & seg->checksum=0x8E93, (which can happen given the right set of values) one gets  acc += ~acc, which always results in 0xFFFF. The FOLD_U32T has nothing to do and the 0xFFFF is set as the seg->tcphdr->chksum. Which is wrong? Am in missing something?

Anyone able to enlighten me as why this isn't a coding error?

Shouldn't there be something to ensure 0xFFFF is converted to 0x0000?!

Thanks.

Niall.

On 13 May 2014 13:17, Niall Donovan <address@hidden> wrote:

Hi All,

   I'd appreciate some help on my problem. I occasionally have seen my TCP socket connection hang and when I captured the fault on Wireshark I could see, on the packet causing the hang, that the calculated TCP Checksum value was 0xFFFF, which Wireshark indicated was incorrect. Wireshark says it should be 0x0000. It also helpfully pointed to RFC1624 for further information. 

The socket hangs because the recipient of the packet (Win 7 PC) sees a checksum error and discards the packet and resends its previous packet. LwIP sends a duplicate Ack then resends (and keeps sending) the offending packet, with the same erroneous checksum. Hence my ping-pong type link gets stuck.

I don't modify the packet content after handing it to lwIP and my MAC device driver simply copies the packet from pbuf(s) to a tx buffer verbatim. I depend on lwIP to calculate the Checksum and CRC.

I've attached the offending packet in a pcap file. I hand calculated the checksum and the one's compliment sum is 0xFFFF hence the one's compliment of that is 0x0000. 

Why is lwIP inserting a checksum of 0xFFFF? It should have inserted 0x0000 right? Is this a known issue, I didn't see any mention of it in the mail archives. If this is a known issue hopefully someone can point me in the right direction for a fix/workaround so I don't have to debug and/or re-code the checksum code of lwIP!! While I'm awaiting a reply I'll start that process...

FYI:

I am using lwIP 1.4.1 and have LWIP_CHKSUM_ALGORITHM = 3 in lwipopts.h

Thanks for your time

Regards

Niall.