From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: TCP connection tracking timeout Date: Wed, 30 Jul 2008 12:07:49 +0200 Message-ID: <48903D75.2040908@trash.net> References: <20080729030104.GA15915@gondor.apana.org.au> <488EA0F1.2050906@trash.net> <488EA3FE.7050503@trash.net> <20080729060105.GA16797@gondor.apana.org.au> <488EB4F1.60806@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: Herbert Xu , Netfilter Developer Mailing List To: Jozsef Kadlecsik Return-path: Received: from stinky.trash.net ([213.144.137.162]:43911 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752648AbYG3KHx (ORCPT ); Wed, 30 Jul 2008 06:07:53 -0400 In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: Jozsef Kadlecsik wrote: > Hi, > > On Tue, 29 Jul 2008, Patrick McHardy wrote: > >> Herbert Xu wrote: >>> On Tue, Jul 29, 2008 at 07:00:46AM +0200, Patrick McHardy wrote: >>>>> That sounds like a pretty neat idea. I'm testing a patch now, I'll >>>>> send it over in a few minutes if it survives :) >>> >>>> This seems to work. I'm wondering however if this will really help. >>>> We already track retransmissions and decrease the timeout on the >>>> 3rd retransmission, so this should only help if both the sender and >>>> the receiver went down. >>> The problem with requiring a 3rd retransmit is that once a socket >>> is orphaned (closed) on Linux, we fast-track the retransmit timeout >>> process. In particular, if it's already maxed out the RTO prior >>> to closing, we'll kill it straight away. >>> >>> This is in violation of the RFCs but it's an important optimisation. >> Thanks for this explanation. Unless Jozsef sees something wrong with this >> patch, I'll queue it with a proper changelog. Its small enough, so perhaps >> we can even put this in 2.6.27. > > Seems to be fine - as we cannot assume everything runs Linux (;-), the > only risk is that we may kill the conntrack entry too early and then it'll > mark packets as INVALID unnecessarily. But 5min timeout when there are > unacknowledged data should be enough to avoid it. Thanks, I've queued the patch.