From: Rick Jones <rick.jones2@hp.com>
To: lartc@vger.kernel.org
Subject: Re: SYN+ACK responded to with RST
Date: Wed, 06 May 2015 16:00:09 +0000 [thread overview]
Message-ID: <554A3A89.8060800@hp.com> (raw)
In-Reply-To: <554A1405.10601@conversis.de>
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
>
next prev parent reply other threads:[~2015-05-06 16:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-06 13:15 SYN+ACK responded to with RST Dennis Jacobfeuerborn
2015-05-06 14:23 ` Kevin Mason
2015-05-06 16:00 ` Rick Jones [this message]
2015-05-09 13:10 ` Dennis Jacobfeuerborn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=554A3A89.8060800@hp.com \
--to=rick.jones2@hp.com \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.