From owner-freebsd-current@FreeBSD.ORG Tue Dec 26 03:54:14 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 B879816A5AD for ; Tue, 26 Dec 2006 03:54:14 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mo2so.prod.shaw.ca (shawidc-mo1.cg.shawcable.net [24.71.223.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8C56913C46E for ; Tue, 26 Dec 2006 03:54:14 +0000 (UTC) (envelope-from cperciva@freebsd.org) Received: from pd3mr7so.prod.shaw.ca (pd3mr7so-qfe3.prod.shaw.ca [10.0.141.23]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with ESMTP id <0JAV00D041EE0530@l-daemon> for freebsd-current@freebsd.org; Mon, 25 Dec 2006 19:54:14 -0700 (MST) Received: from pn2ml3so.prod.shaw.ca ([10.0.121.147]) by pd3mr7so.prod.shaw.ca (Sun Java System Messaging Server 6.2-2.05 (built Apr 28 2005)) with ESMTP id <0JAV004WB1EECB61@pd3mr7so.prod.shaw.ca> for freebsd-current@freebsd.org; Mon, 25 Dec 2006 19:54:14 -0700 (MST) Received: from hexahedron.daemonology.net ([24.82.18.31]) by l-daemon (Sun ONE Messaging Server 6.0 HotFix 1.01 (built Mar 15 2004)) with SMTP id <0JAV00JTK1ED2VN6@l-daemon> for freebsd-current@freebsd.org; Mon, 25 Dec 2006 19:54:14 -0700 (MST) Received: (qmail 7103 invoked from network); Tue, 26 Dec 2006 02:54:11 +0000 Received: from unknown (HELO ?127.0.0.1?) (127.0.0.1) by localhost with SMTP; Tue, 26 Dec 2006 02:54:11 +0000 Date: Mon, 25 Dec 2006 18:54:11 -0800 From: Colin Percival In-reply-to: <20061214172323.GP1011@egr.msu.edu> To: Adam McDougall Message-id: <45908ED3.4040503@freebsd.org> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Enigmail-Version: 0.94.0.0 References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org> <20061214172323.GP1011@egr.msu.edu> User-Agent: Thunderbird 1.5.0.8 (X11/20061207) Cc: Mike Silbersack , 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: Tue, 26 Dec 2006 03:54:14 -0000 Adam McDougall wrote: > On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote: > Try setting net.inet.ip.portrange.randomized=0. This shouldn't make any > difference, but it might. > > 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 [...] > 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: Ok, now I understand what's going on... > 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. The random port allocation, because it is completely random, runs into the birthday problem if it tries to allocate too many ports: Within a few hundred port allocations, there's almost certainly going to be a collision. To get around this problem, the port allocator watches how many ports are being allocated, and switches to sequential allocations if it thinks that the rate of port allocation is likely to result in collisions occurring. Unfortunately, this switch isn't occurring quickly enough to avoid problems; I'm not sure if this can be easily fixed (except via the workaround of turning off randomized port allocations), but maybe Mike Silbersack (CCed) will have some ideas. Colin Percival