Hi, 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  Krishnaraj |
4 Answers:
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  Christian_R edited 07 Dec '16, 12:52 showing 5 of 8 show 3 more comments |
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  SYN-bit ♦♦ I checked the client end. There is no filtering active. iptables is empty. (05 Dec '16, 20:51) Krishnaraj Where did you take the capture? Is there a few between the point of captureand the client? (06 Dec '16, 01:57) Christian_R The RST packets have a length of 54 bytes which means they have not been padded (yet) when they were captured. I assume the capture was made on the host with the mac address KalkiCom_00:aa:1d (00:25:97:00:aa:1d). Is that the client with IP address 172.18.0.122? Or is it a transparent L2 firewall, loadbalancer or other kind of device? (06 Dec '16, 13:01) SYN-bit ♦♦ The capture is taken from the client device (172.18.0.122). I have used filter for connection to 172.18.50.1. The client device is an embedded linux device. (06 Dec '16, 21:41) Krishnaraj |
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  Jasper ♦♦ I agree with you even if am not sure if client does that.I shall check at the client side (05 Dec '16, 20:50) Krishnaraj If the client closed the TCP connection just after opening it, it would not send retransmissions of the SYN packet. So I don't think this is the case... (06 Dec '16, 13:02) SYN-bit ♦♦ |
This looks more like a monitoring software checking for availability of the server. answered 02 Dec '16, 14:09  mrEEde Yes it looks strange. And the second strange thing is the kalki system use the same src and dst port combination a few times in a row. For example for SRC port 51016 I can see 5 SYN packets. (02 Dec '16, 15:37) Christian_R |
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 
Nice catch @Christian_R !
One additional note, it looks like the server is indeed copying the low order two bytes of the TSval, but puts them in the high order two bytes. It seems there is a bug in the server software in handling the TS option. Maybe this is due to the fact that SACK was permitted by the client (two bytes option) and not by the server, messing up the offset by two.
What kind of OS is running on the server?
@SYN-bit: Thanks. But nice catch, too. Didn´t notice that.
Didn't look at timestamp values, too, so nice one, both of you ;-)
Should we have an Expert info for that?
I was thinking the same, although it is a very uncommon situation...
Can't hurt to have it though, maybe the crappy IoT stacks will do similar things more often in the future ;-)
Just out of curiosity, this is optional right. So what if the server does not support it. Whether the SYN-ACK will not have timestamp information and the client will accept it ?
Yes that is true.