From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rick Jones Date: Wed, 06 May 2015 16:00:09 +0000 Subject: Re: SYN+ACK responded to with RST Message-Id: <554A3A89.8060800@hp.com> List-Id: References: <554A1405.10601@conversis.de> In-Reply-To: <554A1405.10601@conversis.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: lartc@vger.kernel.org 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 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 Win600 >> Len=0 MSS60 SACK_PERM=1 TSval660943802 TSecr=0 WS8 >> 2140 74.153741 10.0.0.10 10.1.0.13 TCP 74 [TCP Retransmission] 33298→80 >> [SYN] Seq=0 Win600 Len=0 MSS60 SACK_PERM=1 TSval660944802 >> TSecr=0 WS8 >> 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 MSS60 SACK_PERM=1 TSval342367258 >> TSecr660943802 WS8 >> 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 >