Unexpected ARP response and RST,ACK packet from W5500

Question

Hi, 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. TCP-spontaneous-reset1108×1050 125 KB

Eugeny · Answer

I think filtered Wireshark output is not enough. If there’re other devices in between (e.g. router, proxy, firewall), they may disrupt the communication and data flow. At which physical point you gather Wireshark logs - at server? What is the topology of the network? Why Wireshark identifies packet contents as VNC/RFB protocol? Note that it is server who seems to forget MAC address of the W5500 and asks for it again through broadcast. It may be well not a server, but a router. And this router may have some timeout settings. RST packet from W5500 Wireshark showing may well come not from W5500, but from some intermediary device, which thinks time is out. And while W5500 does not know about it, it tries transmitting data in packet 27, but as server was already informed by RST, it does not accept this packet (as well as Wireshark labeling it as “spurious” because it is out of TCP protocol). The best way for you to figure out what is going on: you must review whole Wireshark log, probably there’s something else causing this behavior; put another PC in bridge mode just before W5500 with another Wireshark running, so that you can compare Wireshark outputs at the server side and at the W5500 side and match packets, and see if there’s any other device interference, or all packets flowing are in order and non-modified.

faberd · Answer

Hi Eugeny, Thank you for your quick response. The wireshark logs are gathered at the server, which is connected via a switch to our internal network. The W5500 is connected to that same switch. That Wireshark labels our packets as VNC has to do with the port number in use (5500). Using another port marks the packets as ‘regular’ TCP. Your pointer that some other device could send the messages has proven valuable. After connecting the W5500 to my server using only a hub and no other devices connected, the problem did not occur! After some more searching and testing we finally cleared up this issue: we had a duplicate MAC address in our network. So both machines were responding to the ARP requests. And ‘the other’ caused the RST,ACK packet to be sent. Changing the MAC address assigned to the W5500 solved it.