From owner-freebsd-ipfw Mon Aug 5 18:21:31 2002 Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DDCBF37B400 for ; Mon, 5 Aug 2002 18:21:28 -0700 (PDT) Received: from gw.pelleg.org (dpelleg.dsl.telerama.com [205.201.13.235]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1055543E4A for ; Mon, 5 Aug 2002 18:21:28 -0700 (PDT) (envelope-from dpelleg@cs.cmu.edu) Received: from lank.auton.cs.cmu.edu (lank.wburn [192.168.3.41]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (Client CN "dpelleg.dsl.telerama.com", Issuer "Dan Pelleg" (verified OK)) by gw.pelleg.org (Postfix) with ESMTP id 2F96C57E0; Mon, 5 Aug 2002 21:21:25 -0400 (EDT) Received: by lank.auton.cs.cmu.edu (Postfix, from userid 7675) id 2742C118; Mon, 5 Aug 2002 21:21:24 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15695.9363.277821.568101@gargle.gargle.HOWL> Date: Mon, 5 Aug 2002 21:21:23 -0400 To: Luigi Rizzo Cc: ipfw@FreeBSD.ORG Subject: Re: IPFW2 keep-alive In-Reply-To: <20020731152806.B69266@iguana.icir.org> References: <20020731152806.B69266@iguana.icir.org> X-Mailer: VM 7.00 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid From: Dan Pelleg Reply-To: Dan Pelleg Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG ok, my problem was that I had net.inet.ip.fw.dyn_rst_lifetime set to 10 (I don't even remember why I did that). This would explain all that we've seen (so you can disregard the personal mail I just sent you). The remote server does send a RST, which (in my case) bumps the timeout on the rule *up*. The next question is if it's worth fixing somehow or is it just another feature :) Luigi Rizzo writes: > The logic works as follows: > when a O_LIMIT or O_KEEP_STATE rule has less than 20 seconds left, > the firewall will send a keepalive packet to both sides every 5 seconds. > > If any of the two responds, then the timeout will be updated > accordingly -- i.e. a regular data packet will reset it up > to 300 seconds or whatever the default is, a RST will put it > down to 1 which is below the threshold for generating a > new keepalive. > > If none responds, the timeout will be left untouched. > > Now i wonder if in your case what happens is that the > remote server is not sending RST for invalid packets, and > you do have a socket in some closing state (or even a mozilla > about to close) still handling the keepalives and replying to them. > > cheers > luigi > > On Sun, Jul 28, 2002 at 10:25:25AM -0400, Dan Pelleg wrote: > > > > What's the exact mechanism to expire dynamic rules under IPFW2? I > > understand it's sending keep-alive packets as the rule is about to > > expire. Is there any way for these to result in the rule being removed? The > > behaviour I'm seeing is this: > > > > During a network partition, the application program (Mozilla) retried to > > connect to remote hosts and opened many connections, eventually hitting the > > LIMIT count. > > > > Now the network is back up. However there is no way to open new > > connections since the appropriate rule's LIMIT is met. Repeated ipfw -d > > show that the rules are refreshed when they have 5-6 seconds to live (and > > go back to 10 seconds or so). I'm not sure what's doing that - the local > > application is long terminated. The only workaround I found was to flush > > the ruleset (I guess replacing just that rule would have also worked). > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message