Closed MathieuBordere closed 4 years ago
@MathieuBordere Thank you for sharing the finding with us. We reviewed the code and I am able to confirm that is an issue in the TCP logic. I have forwarded this information to the NetX team for further analysis the issue and fix it. Feel free to re-open this ticket if you have additional information.
Is there a way to keep me posted when a fix is issued, or should I seek support through my employer who owns a ThreadX & NetX license?
https://github.com/azure-rtos/netxduo/blob/35a977685463af4b756d5396b9bcb73f33eae9ff/common/src/nx_tcp_socket_state_ack_check.c#L232-L235
If I'm not mistaken the
socket_ptr -> nx_tcp_socket_duplicated_ack_received
is also increased on segments that contain data, from my understanding a 'real' DUPACK is a pure ACK packet that does not contain data,socket_ptr -> nx_tcp_socket_duplicated_ack_received
should therefore only be increased if the segment contains no data. We have observed this behaviour where NetX initiates a fast retransmit without the receiver explicitly signaling packet loss by sending DUPACKs.