Hi,
I’m using w5500 as a TCP client. While communication with the TCP server, sometimes TCP timeout happens even if TCP server sends ACK within TCP time period (i.e. 200 ms ). w5500 doesn’t receive it and does re-transmissions and finally sends RST to the server. Wireshark logs clearly shows that the TCP server responded correctly but w5500 fails to receive the ACK and so does re-transmit and finally breaks the connection by sending RST.
Please find attached wireshark log having above mentioned behavior. (TCP client: 159.100.67.10 and TCP server: 37.97.179.237. Please use filter tcp.port==21408 )
I can not understand, why is w500 not able to receive the ACK? poort-28460.zip (117 KB)
TCP conversation between nodes seem to be fine, I suspect that first ACK #2049 has been lost, the W5500 unexpectedly receives ACK for #2051, and resends all 4 bytes remaining in the buffer from previous ACK (7e472142). Then IMHO server properly responds.
Do you take this Wireshark log at the server side? Then you may not see whole picture. I advise you to put Windows 7 machine configured as network bridge with Wireshark connected directly to W5500, and then you will be able to see what is going on at the chip’s side. I think you may be surprised that some proxy or router confuses packets or decides for the involved communicating nodes that they need to break up, and instructs W5500 to close its connection from its side and then of course W5500 responds RST on any further packets from the server as its socket is closed.
Thanks for the post!
I have found the fix for this issue. I was using TCP re-transmission counter to value 2. As per RFC the minimum value for TCP re-transmission counter should be 3. If it is not then the behavior could be unpredictable. And that’s the reason W5500 was sometime sending reset request. I have set the re-transmission counter to default value ( 7) as per w5500 datasheet. Every things works fine. No abnormal reset is found.
