This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

SYN - SYNACK- RST Reason

0

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's gravatar image

Krishnaraj
6113
accept rate: 0%


4 Answers:

5

The reason for the reset is the timestamp. Because the TSecr in the SYN/ACK should match the TSVal value of the first SYN.

alt text

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. alt text

But I just can guess some possible reasons for this behaviour:

  1. The server implemantion of the RFC1323 is wrong

  2. There is a FW, Loadbalncer or something else which manipulates the timestamps wrongly.

  3. There is some kind of man in the middle attack or something going on.

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's gravatar image

Christian_R
1.8k2625
accept rate: 16%

edited 07 Dec '16, 12:52

1

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?

(07 Dec '16, 13:18) SYN-bit ♦♦

@SYN-bit: Thanks. But nice catch, too. Didn´t notice that.

(07 Dec '16, 13:29) Christian_R

Didn't look at timestamp values, too, so nice one, both of you ;-)

(08 Dec '16, 11:25) Jasper ♦♦

Should we have an Expert info for that?

(08 Dec '16, 13:23) grahamb ♦

I was thinking the same, although it is a very uncommon situation...

(08 Dec '16, 15:06) SYN-bit ♦♦

Can't hurt to have it though, maybe the crappy IoT stacks will do similar things more often in the future ;-)

(08 Dec '16, 15:58) Jasper ♦♦

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 ?

(11 Dec '16, 21:18) Krishnaraj

Yes that is true.

(11 Dec '16, 22:04) Christian_R
showing 5 of 8 show 3 more comments

1

To me it looks like there is a filter on the client (172.18.0.122). If you look at the packets with filter tcp.stream eq 3 && tcp.flags==2, you can see the TCP backoff machanism, the SYN is retransmitted after 1, 2, 4 and 8 seconds (with the same sequence number).

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's gravatar image

SYN-bit ♦♦
17.1k957245
accept rate: 20%

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

0

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's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

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 ♦♦

0

This looks more like a monitoring software checking for availability of the server. alt text 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/ .
Regards Matthias

answered 02 Dec '16, 14:09

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

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