Niall,
This final line in tcp_out sets the check sum and includes the ~ in the call.
seg->tcphdr->chksum = inet_chksum_pseudo(seg->p, &(pcb->local_ip),
&(pcb->remote_ip),
IP_PROTO_TCP, seg->p->tot_len);
>From an empirical standpoint, lwIP is used in far too many places for there to
>be this significant of a bug. I’d look for a compiler bug or some other
>issue. I seriously doubt it’s a bug in lwIP. Some of my company’s users run
>our systems 24/7 sending lots of data through lwIP and I’d hear about it
>really fast if there was this kind of a TCP lockup.
Regards,
Bill
From: lwip-users-bounces+bauerbach=arrayonline....@nongnu.org
[mailto:lwip-users-bounces+bauerbach=arrayonline....@nongnu.org] On Behalf Of
Niall Donovan
Sent: Tuesday, May 13, 2014 11:09 AM
To: Mailing list for lwIP users
Subject: Re: [lwip-users] TCP Checksum = 0xFFFF
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 <nfdono...@gmail.com> 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
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
