TCP server don't update the ack num

[kyliuxing]

@kjbracey-arm
hi kjbracey-arm，
I met a issue when made TCP test. I built a TCP server on PC and make my device to connect it, they sent data to each other.
Device send two segments 77576223 ~ 77576649, 77576650 ~ 77578110, and PC ACK 77576223 firstly , then ack 77577683, but in lwip stack, 77577683 can't ack the second segments(6650 ~ 8110), lwip will retransmission it, but PC still ack 77577683 and device do retransmission one more time, it seems a dead loop, until reached the max retry times and device stop the socket.
So why the PC will ack a number 77577683(77577683 - 77576223 = 1460, is it related?) between the 77576650 ~ 77578110? why the PC don't update the ack num even PC receive the retransmission? could you give some advice?
I make capture on PC by wireshark, so i'm sure PC received the retransmission packet.
By the way, i can't uploading attachment, is it has restriction?

[kyliuxing]

I reproduced this issue one more time, from the capture of PC(TCP server), firstly, device send seq 6825983(len 1447), PC ack 6827430, but device may be not receive the ack, so device retransmit seq 6825983(len 1457), the len is larger. then the PC still ack 6827430 and the lwip stack retransmit 6825983(len 1457), until reached max retry times.
So is it the conflict between the PC TCP stack and lwip stack?
Thank you!

[kjbracey]

This is fairly deep in the lwIP TCP implementation, which has not been changed in mbed OS - this is unlikely to be anything to do with mbed OS integration, so submitting a query to the lwIP project would be most effective.

Don't quite understand the first example, but in the last one, lwIP is permitted to send overlapping segments due to retransmissions - retransmissions don't have to be segmented the same way.

In normal circumstances the PC should be acking 6827440 when it gets the 1457-byte packet; it should ignore the 1447 bytes it already has and accept the following 10, and ack them.

I don't know if lwIP is resending the whole 1457 just because that's the way it's implemented, or if it hasn't seen/accepted any acks at all. Are you sure the device is getting the acks? Maybe a firewall is doing something weird.

[kyliuxing]

sorry for my late reply because of my holiday and thank you for your help.
i'm sure device has seen the acks and PC have receive the retransmissions also.
i feel firewall should be upper than tcp/ip stack in windows.
i will try to find help from lwip project.

Thank you!

[kyliuxing]

@kjbracey-arm
I submit a query to lwip project and get feedback. TCP_CHECKSUM_ON_COPY still has some defect so should be set 0 as default.
you can refer it at https://savannah.nongnu.org/bugs/?50914.
Thanks!

[kjbracey]

Thanks for investigating - I'll make a PR to turn that off, and we can discuss whether to do that now or wait for a lwIP patch to cherry-pick.

[ciarmcom]

ARM Internal Ref: MBOTRIAGE-354

[kjbracey]

Original issue solved here, by disabling the checksum-on-copy. We can close this.

For the record, the bug was apparently fixed on lwIP's master in February, but has yet to make it to a release.