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).
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.
Thanks for your response. Yes, I understand that server sends RST if it is already connected to another client or socket is closed. However, if you look at the traffic only for port 49288, it can be seen that client sends SYN packet, server sends SYN, ACK and client sends ACK. In this case, the server is connected using this port 49288 but the client is not (as I could not see any data being exchanged). Since I use only one 1 socket 0 on server application, RST is sent for subsequent SYN packets as the server is still connected using port 49288.
So, I would like to understand if it is possible for W6100 to not go into CONNECTION Established state even after sending ACK?
The only way you can know W6100 is connected or not is reading the status register.
This may be another problem caused by the connection process.
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.
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.
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):
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.
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.
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.
But before you said you use only one socket?
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.
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
My server application uses only 1 socket. My client application uses 7 sockets.
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.
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.
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.
