All of lore.kernel.org
 help / color / mirror / Atom feed
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
>


  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.