Ruediger Pluem wrote: >>> >>> According to the Microsoft >>> (http://support.microsoft.com/default.aspx/kb/314053) >>> >>> TcpMaxConnectRetransmissions >>> Key: Tcpip\Parameters >>> Value Type: REG_DWORD - Number >>> Valid Range: 0 - 0xFFFFFFFF >>> Default: 2 >>> Description: This parameter determines the number of times that TCP >>> retransmits a connect request (SYN) before aborting the attempt. The >>> retransmission timeout is doubled with each successive retransmission >>> in a particular connect attempt. The initial timeout value is three >>> seconds. >>> >>> >>> So, looks like with default of 2 retransmits there is at least 9 >>> second delay. >>> >> I thought the problem was with local connects to a port, to which no >> process listens to. In this case the OS should immediately sending a RST >> (reset) and the client should not resend the SYN. I expect this >> TcpMaxConnectRetransmissions to be used in the case, were the remote >> server doesn't send any answer (neither RST nor SYN/ACK) and the client >> needs to retry the connection establishment after some timeout. That >> shouldn't be the case here, because the local system should always be >> able to send a RST if nothing is listening on the port. >> >> Except there's a local firewall with packet drop coming into the game >> (or name resolution timeouts, or ...). >> > > Exactly my understanding of the problem. So I see no use in > TcpMaxConnectRetransmissions > for this case. > > Regards > > Rüdiger > > > Looks like it might be the retry issue: 3963 13.831213 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 4087 14.280717 source destination TCP 2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 4088 14.280735 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 4238 14.827581 source destination TCP 2608 > 1230 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 4239 14.827603 source destination TCP 1230 > 2608 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0
The RSTs occur remotely and Windows retries twice. 1428 4.025656 unixsource destination TCP 57864 > 1230 [SYN] Seq=0 Win=32768 Len=0 MSS=1460 WS=0 1429 4.025674 unixsource destination TCP 1230 > 57864 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 That's the same exchange from an HP-UX source to a linux destination. I'm assuming that windows pulls the same crap for localhost traffic even though we can't capture it to prove the case. Oh the joys of TCP/IP troubleshooting on Windows :) Andy
