From owner-freebsd-current@FreeBSD.ORG Wed Dec 27 07:45:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3538916A403 for ; Wed, 27 Dec 2006 07:45:25 +0000 (UTC) (envelope-from silby@silby.com) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id C8B6F13C47A for ; Wed, 27 Dec 2006 07:45:24 +0000 (UTC) (envelope-from silby@silby.com) Received: (qmail 80440 invoked from network); 27 Dec 2006 07:18:42 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 27 Dec 2006 07:18:42 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 27 Dec 2006 01:18:39 -0600 (CST) From: Mike Silbersack To: Adam McDougall In-Reply-To: <20061227023330.GJ66966@egr.msu.edu> Message-ID: <20061227011612.Q99056@odysseus.silby.com> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org> <20061214172323.GP1011@egr.msu.edu> <45908ED3.4040503@freebsd.org> <2472.68.253.24.139.1167151819.squirrel@webmail11.pair.com> <20061227023330.GJ66966@egr.msu.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@freebsd.org, Colin Percival Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Dec 2006 07:45:25 -0000 On Tue, 26 Dec 2006, Adam McDougall wrote: > After about 13 seconds of active fetching, portsnap cycles sequentially > through the remainder of the available ephermal range set as above (200 > ports) and it goes ahead and tries to reuse 49152 as soon as it got done > using 49352. tcpdump shows the client host sending SYNs to the squid server > periodically for about 56 seconds, until pf allows it through and a response > completes. A few more ports are allowed through somewhat rapidly, then > at times there are additional waits while the new connections bump up > against pf's enforced timeouts. I let portsnap go on to at least 2600 ports Argh, I forgot to ask for one more critical piece of information. Can you run netstat -n on both the client and server to verify on which side the TIME_WAIT sockets are accumulating? No need to re-capture the data that you have already captured, just find out if the TIME_WAIT sockets are all ending up on one side, or if they're showing up both. Mike "Silby" Silbersack