Client socket not in Connection Established state despite sending ACK in response to SYN ACK packet

Question

Hello team, I use W6100 for a client application where it connects to a server, sends data, disconnects and closes the socket. For one of my tests, I disconnect the server from the network, trigger an action on the client application that attempts to send some data to server and retries about 600 times to send data. While the client application is retrying to send data, I connect the server back in the network. In this case, I see that client sends some SYN packets (for different sockets) and there is SYN-ACK from server for one of the sockets and the client responds with ACK to the SYN-ACK but the client does not go CONNECTION ESTABLISHED state but the server goes to CONNECTION ESTABLISHED state. What could be the possible reason for this and how can I avoid this? Here is a snapshot of the log (130.10.2.211 is the client and 130.10.2.218 is the server). image1799×877 173 KB I am unable to share the Wireshark log as it is not part of the supported file types that can be uploaded. Thanks, Anusha

Eugeny · Answer

The possible cause of the RST is closed socket at the W6100 side. You are expected to issue CONNECT command and then wait for status change in the status (and/or interrupt) register. If you issue CLOSE, or W6100 for some reason auto-close the socket, before it receives ack for syn for the connection, W6100 will respond with RST, and remote node must drop the connection.

Eugeny · Answer

Anusha: but the client is not (as I could not see any data being exchanged The only way you can know W6100 is connected or not is reading the status register. Anusha: (as I could not see any data being exchanged) This may be another problem caused by the connection process. Anusha: So, I would like to understand if it is possible for W6100 to not go into CONNECTION Established state even after sending ACK? Without any causes - of course not. But you can mistakenly close socket by youself, or W6100 receives RST packet. There may be other causes I do not list, but there’re causes. And generally what are you doing? From the list it seems you continuously send CONNECT command to the command register for different port numbers. Anusha: Since I use only one 1 socket 0 on server application And if it is the case, what connection you expect to get? For which port, if you constantly reconfigure the socket for another port? You can use one socket for only one TCP connection to one port number.

Anusha · Answer

Hi Eugeny, Thanks for your response. The only way you can know W6100 is connected or not is reading the status register. - Yes this is what I’m doing in the client application to know if it is connected. I can see that the status is not Connection Established. But from the Wireshark log for port 49288, we can see that it has sent ACK (Packet number: 204 highlighted in blue): image1406×685 253 KB As per the state diagram, if the client sends ACK, it must go into connection established state (highlighted in yellow): image823×593 101 KB But for some reason, this is not happening. Without any causes - of course not. But you can mistakenly close socket by youself, or W6100 receives RST packet. There may be other causes I do not list, but there’re causes. My client application first checks if the connection is established. If it is not, only then it closes the socket. However, the question is why the connection is not established even though it sent ACK to SYN,ACK packet as highlighted in blue in Wireshark log snapshot above. And generally what are you doing? From the list it seems you continuously send CONNECT command to the command register for different port numbers. And if it is the case, what connection you expect to get? For which port, if you constantly reconfigure the socket for another port? You can use one socket for only one TCP connection to one port number. My client application opens connections on 7 different sockets to send data packets. This is why we see several SYN packets. Since the destination IP is same for all the 7 sockets, 6 of the sockets return RST because the server is already connected to the 1st data socket on port 49288. I hope my explanation of the issue is clear and hope you can provide a possible cause for this. Please let me know if you need more details. Thanks, Anusha

Eugeny · Answer

It seems your mistake is you thinking in synchronous way. What is going at the W6100 driver side and at its networking side is not synchronous, thus your driving code task is to synchronize with the network. Anusha: My client application first checks if the connection is established. If it is not, only then it closes the socket. When you issue CONNECT command status is not established → leading to you immediately closing the socket. Socket becomes “established” only when ACK is received. Therefore when ACK is received you set your W6100 in the state when it is not able to receive ACK/achieve established state any more. Probably you have mistake in driver which is unable to reach established state and tries to reconnect instead. You did not share the code so no idea how to help you. Anusha: My client application opens connections on 7 different sockets to send data packets. But before you said you use only one socket? Anusha: Since the destination IP is same for all the 7 sockets, 6 of the sockets return RST because the server is already connected to the 1st data socket on port 49288. This is illogical. Your server, if it is properly programmed and is able to accept multiple connections from several clients, must establish all 7 connections given they have different source ports. Is it the case that “server” is another W6100?

Anusha · Answer

Hi Eugeny, Thanks for your response. Eugeny: When you issue CONNECT command status is not established → leading to you immediately closing the socket. Socket becomes “established” only when ACK is received. Therefore when ACK is received you set your W6100 in the state when it is not able to receive ACK/achieve established state any more. Probably you have mistake in driver which is unable to reach established state and tries to reconnect instead. You did not share the code so no idea how to help you. Here is the portion of client application code: //open the socket connection for(i=0;i<1000;i++) { vTaskDelay(0); if connection is ESTABLISHED { Send data over socket for(x=0;x<200;x++) { //check if the transmission is performed if data transfer done { break; } vTaskDelay(0); } for(x=0;x<1000;x++) { vTaskDelay(0); //check if there is an incoming packet if(packet received) /*wait to receive a packet*/ { break; } } //disconnect the socket vTaskDelay(0); break; } } //Double check if socket is in established state if(connection == ESTABLISHED) { //disconnect the socket } //close the socket Eugeny: But before you said you use only one socket? My server application uses only 1 socket. My client application uses 7 sockets. Eugeny: This is illogical. Your server, if it is properly programmed and is able to accept multiple connections from several clients, must establish all 7 connections given they have different source ports. In my test, I have one client and one server only. Since server uses only 1 socket, it sends RST for other SYN packets coming from different port numbers. Yes, my server is another W6100. Thanks, Anusha

Anusha · Answer

Eugeny: So the loop takes nanoseconds and 1000 times elapse before sockets gets SYN/ACK. My application uses FreeRTOS, so vTaskDelay(0) causes the task to reschedule after RTOS Tick. In my application, one RTOS tick is 0.1 ms. So, the loop is called every 0.1 ms approximately.

Eugeny · Answer

Anusha: so vTaskDelay(0) causes the task to reschedule after RTOS Tick RTOS documentation: void vTaskDelay( const TickType_t xTicksToDelay ); Delay a task for a given number of ticks. The actual time that the task remains blocked depends on the tick rate. No word about “scheduling” (link). So literally the execution is blocked for 0 ticks, for me it means the call returns immediately and takes zero ticks. Read monotonic timer before doing the cycle and after you exit it and measure time difference.