From owner-freebsd-current@FreeBSD.ORG Thu Dec 14 17:40:17 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 4D9D116A5D0; Thu, 14 Dec 2006 17:40:17 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 45A774469C; Thu, 14 Dec 2006 17:22:03 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id E80811CC2F; Thu, 14 Dec 2006 12:23:23 -0500 (EST) Date: Thu, 14 Dec 2006 12:23:23 -0500 From: Adam McDougall To: Colin Percival Message-ID: <20061214172323.GP1011@egr.msu.edu> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <457B7084.9070409@freebsd.org> User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-current@freebsd.org 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: Thu, 14 Dec 2006 17:40:18 -0000 On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote: Adam McDougall wrote: > I just tested tcp.closed with 3 seconds, down from 15 earlier but both were > unsuccessful. I will look at the other options as well, but do you have any explanation > for why portsnap would use wildly randomish local ports that overlap too quickly > when fetch does not? Is that a kernel controlled behavior that I can adjust? Try setting net.inet.ip.portrange.randomized=0. This shouldn't make any difference, but it might. Colin Percival Actually that did work, I thought I had tried it before but maybe not. What I've found is when randomized=1, portsnap will use random ports for the first portion of connections: # portsnap fetch Looking up portsnap.FreeBSD.org mirrors... using portsnap1.FreeBSD.org. Fetching snapshot tag... done. Fetching snapshot metadata... done. Updating from Sat Mar 25 06:58:08 EST 2006 to Thu Dec 14 09:39:43 EST 2006. Fetching 4 metadata patches... done. Applying metadata patches... done. Fetching 4 metadata files... done. Then regardless of randomized=0 or 1, the next part will use sequential local port allocations which are likely to conflict with the previous batch of connections: Fetching 8765 patches.....10....20....3(etc) When I have randomized=0, the first portion uses sequential ports and after several runs of re-downloading the same 8765 patches, it seems to work fine every time. I made a backup copy of /var/db/portsnap so I could repeat the fetch over and over for testing. Any idea why portsnap uses sequential ports foe the Fetching stage when the kernel has randomized=1? I am pleased that the workaround functions, but it would be nice to understand if something needs to be fixed so I don't need it.