From owner-freebsd-net@FreeBSD.ORG Wed Jun 2 21:59:28 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8CB916A4CF for ; Wed, 2 Jun 2004 21:59:28 -0700 (PDT) Received: from relay.pair.com (relay.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 16E7843D58 for ; Wed, 2 Jun 2004 21:59:28 -0700 (PDT) (envelope-from silby@silby.com) Received: (qmail 98165 invoked from network); 3 Jun 2004 04:59:22 -0000 Received: from niwun.pair.com (HELO localhost) (209.68.2.70) by relay.pair.com with SMTP; 3 Jun 2004 04:59:22 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 2 Jun 2004 23:59:21 -0500 (CDT) From: Mike Silbersack To: Andre Oppermann In-Reply-To: <40BDAEEF.2AECC3F0@freebsd.org> Message-ID: <20040602061131.O35216@odysseus.silby.com> References: <20040602093940.N99493@atlantis.atlantis.dp.ua> <40BDAEEF.2AECC3F0@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Dmitry Pryanishnikov cc: freebsd-net@freebsd.org Subject: Re: net.inet.ip.portrange.randomized=1 hurts X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jun 2004 04:59:28 -0000 On Wed, 2 Jun 2004, Andre Oppermann wrote: > The random generator indeed works badly. If it was truely random it > should generate a collision only every (1/range) on average. Maybe > the arc4random function reuses the same or small number of initial vectors > all over again leading to the same small set of 'randomized' ports. > > -- > Andre Or it's being seeded poorly by 4.x's inferior random number generator? (I don't know if it could be THAT bad.) It looks like we're really bumping into two things: 1. The need for something more suited to this purpose than arc4random (I'll have to check out Don's code in BIND.) 2. General port recycling issues. It sounds like sequential port allocation was masking problems of type #2 in the past. Mike "Silby" Silbersack