We have embedded the W5500 in one of our products where it is configured to use a single TCP client socket. The socket connects succesfully to a server and data exchange is fine initially. But after some time without communication over the socket the W5500 will terminate the connection with a RST,ACK packet for no apparent reason.
The Sn_IR does not indicate a timeout interrupt. However, I can work around this issue by setting the keep-alive socket option with a transmit every 25 seconds. If I set it to 30 seconds, the issue still occurs. The default values of the RTR (2000) and RCR (8) registers are active.
I have opened the socket with the (SF_IO_NONBLOCK | SF_TCP_NODELAY) flags set.
I’ve attached a (filtered) wireshark trace. 172.17.100.1 is the W5500, 172.17.100.24 is the server running on port 5500. In the trace the following happens:
- up to packet 20 communication between W5500 and server is just fine.
- packet 21 is the data transmission from W5500 to the server (after more than one minute without communication)
- packets 22 and 23 are a subsequent ARP request/response initiated by the server
- packet 24 is the server response to the payload in packet 21, with a correct piggybacked TCP ACK of packet 21.
Now the strange stuff happens:
- packet 25 is retransmit of packet 23 (ARP response). Why is it retransmitted? And why withing a half millisecond delay?
- packet 26 shows the W5500 terminating the the socket connection? For what reason? The socket still allowed transmission of the data and the ack came within one millisecond.
- packet 27 is a retransmit of packet 21. Didn’t the W5500 just terminate this connection itself?
- packet 28 is the server acknowledging the RST.
The remaining packets are the W5500 reconnecting to the server, but in this case our server did not accept the new connection.