Recently I observed one strange issue with a connection with two devices. Client(172.18.0.122) tries to connect to server(172.18.50.1). Then server replies with SYN-ACK. Soon after receiving the same, client sends RST and tries for connection after some time. This gets repeated. I could not find any reason for the same. The sequence numbers are correct as. Could someone help me to understand the problem.
The wireshark capture is available in https://drive.google.com/file/d/0B_4tKpFyEeS-UGoyajdJWEdoNTQ/view?usp=sharing.
asked 01 Dec '16, 21:24
The reason for the reset is the timestamp. Because the TSecr in the SYN/ACK should match the TSVal value of the first SYN.
But in your case the TSval of the first SYN and the TSecr of the SYN/ACK does not match. So the client MUST react with a RST to the SYN ACK.
But I just can guess some possible reasons for this behaviour:
If number 1 or number 2 is your problem, the workaround is easy. Disable timestamping at client and server side or at least at one side.
If number 3 is your problem, you should really not disable timestamping as it has protect you in that case.
answered 07 Dec '16, 12:47
edited 07 Dec '16, 12:52
To me it looks like there is a filter on the client (172.18.0.122). If you look at the packets with filter
Each SYN/ACK has a different sequence number, so the server is considering these SYN's to be of a different TCP session due to the fact that each previous SYN/ACK was answered with a TCP/RST.
The TCP/RST packets all have a ip.id of 0x0000, while the TCP/SYN packets have ip.id's increasing by 1.
All-in-all, I think there is a filtering rule on the client that rejects the SYN/ACK's, causing the retransmissions. Is iptables active on the client? Or any other filter mechanism? I should check the rules to fix this problem.
answered 04 Dec '16, 03:34
This usually happens when the client software is not working correctly. It sends a SYN and closes the port so fast that the SYN-ACK hits a closed port, leading to a reset. The common reason for this behavior is that the programmer of the client software set a socket timeout that is way too low. You should try to find out what the code does when it opens a socket and fix the behavior.
answered 02 Dec '16, 01:03
This looks more like a monitoring software checking for availability of the server. Notice that the TTL if the SYN packets is 64 so it has not been decremented and is coming from the local device with an an ethernet prefix that is assigned to http://www.kalkitech.com/ .
answered 02 Dec '16, 14:09