Re: SYN+ACK responded to with RST

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06.05.2015 18:00, Rick Jones wrote:
> 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.


Yep, apparently a library the client uses has a default timeout of 1
second which is... optimistic.
The server side apparently has occasional performance issues that delay
the syn+ack sometimes of up to several seconds.
What initially confused me was the syn retransmissions after one second
because I remembered the initial RTO value to be three seconds but
apparently that has changed a while ago.

Thanks for the pointer in the right direction!

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




[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux