SYN+ACK responded to with RST

SYN+ACK responded to with RST

[Dennis Jacobfeuerborn]

Hi,
I have a strange case where sometimes a client responds to a SYN+ACK
packet with a RST. This only seems to happen though after a
retransmission of the SYN packet. My question is why would that matter
given that sequence numbers and other parameters all are correct? I
would expect the client to properly acknowledge the SYN+ACK packet
instead of sending a RST. Are there any other reasons besides sequence
number or TSval/TSecr issues that could cause the client side to repond
with a RST to a SYN+ACK?

Here is a wireshark summary of such a failed handshake:

2139	73.154288	10.0.0.10	10.1.0.13	TCP	74	33298→80 [SYN] Seq=0 Win\x14600
Len=0 MSS\x1460 SACK_PERM=1 TSval660943802 TSecr=0 WS\x128
2140	74.153741	10.0.0.10	10.1.0.13	TCP	74	[TCP Retransmission] 33298→80
[SYN] Seq=0 Win\x14600 Len=0 MSS\x1460 SACK_PERM=1 TSval660944802
TSecr=0 WS\x128
2141	74.166255	10.1.0.13	10.0.0.10	TCP	74	80→33298 [SYN, ACK] Seq=0
Ack=1 Win(960 Len=0 MSS\x1460 SACK_PERM=1 TSval342367258
TSecr660943802 WS\x128
2142	74.166266	10.0.0.10	10.1.0.13	TCP	54	33298→80 [RST] Seq=1 Win=0 Len=0

Regards,
  Dennis

Re: SYN+ACK responded to with RST

[Kevin Mason]

I would say you are looking in the wrong direction. Your question should be why is 10.1.0.13 taking so long to reply? the TSecr660943802 in frame 2141 says the syn/ack is to frame 2139. Since the client already did a retransmission of the Syn with TSval660944802 in frame 2140, this shows 10.1.0.13 has something very wrong with it.


Kevin
———————
> On May 6, 2015, at 09:15, Dennis Jacobfeuerborn <dennisml@conversis.de> wrote:
> 
> Hi,
> I have a strange case where sometimes a client responds to a SYN+ACK
> packet with a RST. This only seems to happen though after a
> retransmission of the SYN packet. My question is why would that matter
> given that sequence numbers and other parameters all are correct? I
> would expect the client to properly acknowledge the SYN+ACK packet
> instead of sending a RST. Are there any other reasons besides sequence
> number or TSval/TSecr issues that could cause the client side to repond
> with a RST to a SYN+ACK?
> 
> Here is a wireshark summary of such a failed handshake:
> 
> 2139	73.154288	10.0.0.10	10.1.0.13	TCP	74	33298→80 [SYN] Seq=0 Win\x14600
> Len=0 MSS\x1460 SACK_PERM=1 TSval660943802 TSecr=0 WS\x128
> 2140	74.153741	10.0.0.10	10.1.0.13	TCP	74	[TCP Retransmission] 33298→80
> [SYN] Seq=0 Win\x14600 Len=0 MSS\x1460 SACK_PERM=1 TSval660944802
> TSecr=0 WS\x128
> 2141	74.166255	10.1.0.13	10.0.0.10	TCP	74	80→33298 [SYN, ACK] Seq=0
> Ack=1 Win(960 Len=0 MSS\x1460 SACK_PERM=1 TSval342367258
> TSecr660943802 WS\x128
> 2142	74.166266	10.0.0.10	10.1.0.13	TCP	54	33298→80 [RST] Seq=1 Win=0 Len=0
> 
> Regards,
>  Dennis
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: SYN+ACK responded to with RST

[Rick Jones]

On 05/06/2015 07:23 AM, Kevin Mason wrote:
> I would say you are looking in the wrong direction. Your question
> should be why is 10.1.0.13 taking so long to reply?

Or why is the client application so impatient :)  It could be the client 
application isn't willing to wait all that long for the connection to be 
established.  So, if that timer pops in the application before the 
SYN|ACK arrives, the client application's closing of the socket would 
likely mean there is no TCP endpoint when the SYN|ACK arrives and so an 
RST is emitted.

rick jones

> the
> TSecr660943802 in frame 2141 says the syn/ack is to frame 2139.
> Since the client already did a retransmission of the Syn with
> TSval660944802 in frame 2140, this shows 10.1.0.13 has something
> very wrong with it.
>
>
> Kevin
> ———————
>> On May 6, 2015, at 09:15, Dennis Jacobfeuerborn <dennisml@conversis.de> wrote:
>>
>> Hi,
>> I have a strange case where sometimes a client responds to a SYN+ACK
>> packet with a RST. This only seems to happen though after a
>> retransmission of the SYN packet. My question is why would that matter
>> given that sequence numbers and other parameters all are correct? I
>> would expect the client to properly acknowledge the SYN+ACK packet
>> instead of sending a RST. Are there any other reasons besides sequence
>> number or TSval/TSecr issues that could cause the client side to repond
>> with a RST to a SYN+ACK?
>>
>> Here is a wireshark summary of such a failed handshake:
>>
>> 2139	73.154288	10.0.0.10	10.1.0.13	TCP	74	33298→80 [SYN] Seq=0 Win\x14600
>> Len=0 MSS\x1460 SACK_PERM=1 TSval660943802 TSecr=0 WS\x128
>> 2140	74.153741	10.0.0.10	10.1.0.13	TCP	74	[TCP Retransmission] 33298→80
>> [SYN] Seq=0 Win\x14600 Len=0 MSS\x1460 SACK_PERM=1 TSval660944802
>> TSecr=0 WS\x128
>> 2141	74.166255	10.1.0.13	10.0.0.10	TCP	74	80→33298 [SYN, ACK] Seq=0
>> Ack=1 Win(960 Len=0 MSS\x1460 SACK_PERM=1 TSval342367258
>> TSecr660943802 WS\x128
>> 2142	74.166266	10.0.0.10	10.1.0.13	TCP	54	33298→80 [RST] Seq=1 Win=0 Len=0
>>
>> Regards,
>>   Dennis
>> --
>> To unsubscribe from this list: send the line "unsubscribe lartc" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
> --
> To unsubscribe from this list: send the line "unsubscribe lartc" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: SYN+ACK responded to with RST

[Dennis Jacobfeuerborn]

On 06.05.2015 18:00, Rick Jones wrote:
> On 05/06/2015 07:23 AM, Kevin Mason wrote:
>> I would say you are looking in the wrong direction. Your question
>> should be why is 10.1.0.13 taking so long to reply?
> 
> Or why is the client application so impatient :)  It could be the client
> application isn't willing to wait all that long for the connection to be
> established.  So, if that timer pops in the application before the
> SYN|ACK arrives, the client application's closing of the socket would
> likely mean there is no TCP endpoint when the SYN|ACK arrives and so an
> RST is emitted.


Yep, apparently a library the client uses has a default timeout of 1
second which is... optimistic.
The server side apparently has occasional performance issues that delay
the syn+ack sometimes of up to several seconds.
What initially confused me was the syn retransmissions after one second
because I remembered the initial RTO value to be three seconds but
apparently that has changed a while ago.

Thanks for the pointer in the right direction!

Regards,
  Dennis