[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-users] TCP Checksum = 0xFFFF

From: Niall Donovan
Subject: [lwip-users] TCP Checksum = 0xFFFF
Date: Tue, 13 May 2014 13:17:51 +0100

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...

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

Thanks for your time

Attachment: bad_TCP_Checksum.pcap
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]