Unexpected SYN,ACK (from W5500) during connection to server

Question

Hi, Sometimes (*) during connection initiated from W5500 I got following sequence: wireshark1123×278 87.1 KB For me it looks that Wiznet chip reports to server (using RST,ACK packet) that port is closed. Interesting is that before I start sending “POST …” request the socket reports its state as ESTABLISHED. Why can be reason for this? Another mysterious (for me) fact is sending of TCP retries with POST request. Because to my SW socket looks like in state ESTABLISHED then I try to send POST request and after 1.5 s socket is explicitely disconnected (see: FIN, ACK packet) and closed because of (application) timeout. But why in such case it still tries to resend TCP packet? Additional info: there is only one socket used during this test. (*) Sometimes means that few times per hour when there is established a few tens of connections per hour. For this internet connection most of TCP connections have to resend packets but usually it is does not cause problem like above.

Eugeny · Answer

I do not think there’s sufficient information to troubleshoot the issue in whole. Per packet list in your attached image, I would say W5500 sends connect request, and it gets lost somewhere. Then it performs two retransmissions, and then finally receives SYN/ACK response from the server. But as there were retransmissions, it seems server sends another SYN/ACK for retransmitted packet, which W5500 treats as out of order TCP packet. Thus W5500 closes the socket because it received unexpected SYN packet when connection is already established. So it will respond with RST to any further packets to this socket. To prove my guess you need to look into packet contents matching sequences and other control information. The issue you describe is somehow similar to one I reported more than year ago. In general W5x00 family seem not performing well in erratic and heavy loaded environments. There’re known workarounds for these problems, but they slow down the communication and make code more complicated.

Eugeny · Answer

Ar2r: Assuming that Wiznet socket has been closed (after receiving out-of-order packet) No, invalid packet is being discarded by the W5x00, but remote host may still think that this packet was processed - this is an issue I explain in my post. Ar2r: why socket status is not reported as CLOSED (before POST is sent application checks socket status and it is read as ESTABLISHED) I have no answer to this question because have no overview of your code, do not know at which point you collect wireshark logs, no info on network topology and its configuration; when node/socket sends RST packet it means it does not want to communicate any more through that connection. Do you check for connection being ESTABLISHED (0x17) before sending data, or you exit sending data loop when connection is in some specific non-ESTABLISHED state (e.g. CLOSED)? Next, confirm that you do not reuse same source port all the time. I do not think it is the case because first pic shows 49198, and second 49194. You must use new port for every connection, not reusing old number within TIME_WAIT of the server.

Ar2r · Answer

Thanks again for your advices. My problem is that Wiznet sometimes is sending RST,ACK packet for unknown reason and after that socket is still reported as being in ESTABLISHED state. After that I cannot send data to server which is logical because it received RST,ACK from Wiznet chip. I suspect that Wiznet just does not discard all invalid packets because this RST,ACK is visible only when there are retries and some out of order packets. I check socket status a few lines of C code before issuing SEND command and status is all the time ESTABLISHED. This RST,ACK is showing only a 2-3 times per hour (during this time there is about 30 identical connections without problems) but without any visible periodicity. You mentioned network topology - it is very simple: Wiznet ← 100MB Eth → Router ← 4G/LTE → Internet I do not observe any problems for other connected devices in this network. BTW> Socket ports are different for each socket and connection.

Eugeny · Answer

To my understanding you get Wireshark logs on the server, right? Then you see things which server receives, and they might not be exactly those another end is sending. Ar2r: Wiznet <- 100MB Eth -> Router <- 4G/LTE -> Internet Set up Windows or Linux PC device as a network bridge, connect it in between of W5500 and 100 MB Ethernet device, and run Wireshark on that device to see what W5500 really says from its first hands. I would not be surprised if you will see different picture than that you see at the another end.

Ar2r · Answer

The log is gathered from PC attached to (managed) switch in router, so in fact it is what exactly W5500 is seeing.