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 TSecr=3660943802 in frame 2141 says the syn/ack is to frame 2139. Since the client already did a retransmission of the Syn with TSval=3660944802 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@xxxxxxxxxxxx> 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=14600 > Len=0 MSS=1460 SACK_PERM=1 TSval=3660943802 TSecr=0 WS=128 > 2140 74.153741 10.0.0.10 10.1.0.13 TCP 74 [TCP Retransmission] 33298→80 > [SYN] Seq=0 Win=14600 Len=0 MSS=1460 SACK_PERM=1 TSval=3660944802 > TSecr=0 WS=128 > 2141 74.166255 10.1.0.13 10.0.0.10 TCP 74 80→33298 [SYN, ACK] Seq=0 > Ack=1 Win=28960 Len=0 MSS=1460 SACK_PERM=1 TSval=3342367258 > TSecr=3660943802 WS=128 > 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@xxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
