From owner-freebsd-current@FreeBSD.ORG Wed Dec 27 02:59:18 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 72ABC16A403 for ; Wed, 27 Dec 2006 02:59:18 +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 53C8613C47C for ; Wed, 27 Dec 2006 02:59:18 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 033681CE6F; Tue, 26 Dec 2006 21:33:31 -0500 (EST) Date: Tue, 26 Dec 2006 21:33:30 -0500 From: Adam McDougall To: Mike Silbersack Message-ID: <20061227023330.GJ66966@egr.msu.edu> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2472.68.253.24.139.1167151819.squirrel@webmail11.pair.com> User-Agent: Mutt/1.5.13 (2006-08-11) 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 02:59:18 -0000 On Tue, Dec 26, 2006 at 11:50:19AM -0500, Mike Silbersack wrote: > 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 Colin's description is accurate, but I haven't read up to this point in the thread, and I need more information. To prove whether or not this is really port randomization's fault for using ports excessively quickly (say, within 1ms) or whether something is going wrong due to ports being used relatively quickly (say, within 1 seconds), please do the following: 1. Disable randomization 2. Set the ephemeral port range to something small like 49152 to 49352. 3. Re-run the test in question. Tell me how it goes. Mike "Silby" Silbersack 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 and it seems to be plugging along slowly and probably would have worked to completion. I still have the tcpdump capture, and the pf logfile, should I post them for evaluation, or look at them for something specific, or run more tests? I'm on the road for the holidays but I can probably check my email tonight and/or tomorrow. portsnap shows almost 200 ports downloaded, a pause, continue to download another 200, pause, etc. Example: Fetching 8881 patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190[wait here]....200....210....220....230....240....250....260....270....280....290....300....310....320....330....340....350....360....370....380....390.[wait here]...400....410.(etc) _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"