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 <[email protected]> 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.
>
>
>
_______________________________________________
lwip-users mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/lwip-users
