We are getting 7% reset messages for our TCP layer messages.
We have two sets of logs.
The first of Wireshark logs shows a good request and response
Here the client was replied with sync acknowledgement such as
[syn, ack] seq=0 ack=1
[syn, ack] seq=0 ack=1
The second set of log show that the server replied with SEQ=1 directly and ACK had a large ACK number to which the client which posting sent a reset message.
[ACK] seq=1 ack= large ack number
What server setting should we change on our Linux server to change the ACK messages so these resets can stop.
Best Answer
What you are seeing is normal behavior if a previous TCP connection did not get shut down properly.
If the port numbers match a previous connection which was completely closed on the client but remains established on the server, the sequence you see will happen.
The client will send a
SYN
, because it does not recall the old connection. The server will see theSYN
arriving on a connection in established state, which is unexpected. But since it is a valid connection, the server cannot respond with aRST
. Instead it will send anACK
corresponding to the current sequence numbers known to the server.The client will receiver an
ACK
for a connection that is not yet established. First packet in each direction is required to have theSYN
bit set. So the client knows theACK
is for a previous connection and will respond with aRST
. TheRST
will clear the old connection from the server.After the
SYN
,ACK
, andRST
packets have been send, the client can retransmit theSYN
packet. This time the handshake will work.There are multiple possible reasons for the old connection ending up in the broken state in the first place. Here are a few possibilities: