From owner-freebsd-current@FreeBSD.ORG Tue Dec 26 10:42:47 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 DB20916A407 for ; Tue, 26 Dec 2006 10:42:47 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.188]) by mx1.freebsd.org (Postfix) with ESMTP id 6917613C466 for ; Tue, 26 Dec 2006 10:42:47 +0000 (UTC) (envelope-from max@love2party.net) Received: from [88.66.9.85] (helo=amd64.laiers.local) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gz9Z91JAf-0006um; Tue, 26 Dec 2006 11:29:52 +0100 From: Max Laier Organization: FreeBSD To: freebsd-current@freebsd.org Date: Tue, 26 Dec 2006 11:29:39 +0100 User-Agent: KMail/1.9.4 References: <20061210010823.GS81923@egr.msu.edu> <20061214172323.GP1011@egr.msu.edu> <45908ED3.4040503@freebsd.org> In-Reply-To: <45908ED3.4040503@freebsd.org> X-Face: ,,8R(x[kmU]tKN@>gtH1yQE4aslGdu+2]; R]*pL,U>^H?)gW@49@wdJ`H<=?utf-8?q?=25=7D*=5FBD=0A=09U=5For=3D=5CmOZf764=26nYj=3DJYbR1PW0ud?=>|!~,,CPC.1-D$FG@0h3#'5"k{V]a~.<=?utf-8?q?mZ=7D44=23Se=7Em=0A=09Fe=7E=5C=5DX5B=5D=5Fxj?=(ykz9QKMw_l0C2AQ]}Ym8)fU MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2553211.7bMH0X5CNR"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200612261129.48173.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: Adam McDougall , Mike Silbersack , 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: Tue, 26 Dec 2006 10:42:47 -0000 --nextPart2553211.7bMH0X5CNR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Tuesday 26 December 2006 03:54, Colin Percival wrote: > Adam McDougall wrote: > > On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote: > > Try setting net.inet.ip.portrange.randomized=3D0. 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=3D1, portsnap will use random ports > > for the first portion of connections [...] > > Then regardless of randomized=3D0 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=3D1? 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. One idea would be to use something in the spirit of OpenBSD's IPID=20 randomization. i.e. fix one bit in the randomization range and toggle=20 between the resulting halves. If we feel that we can't do randomization=20 anymore, we would toggle and hand out the other half range in linear=20 fashion. This certainly needs some thinking to support arbitrary ranges,=20 but I think it might work. Another sollution, of course, would be to: Don't do that then. It really=20 seems wrong for a program to exhaust the outgoing port pool. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --nextPart2553211.7bMH0X5CNR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQBFkPmcXyyEoT62BG0RAkpcAJ0ZIQgdTQ7OXlFTPnbRS2DZIta+iACeLP1S vcB8M0m282odBnHShm1M2bM= =oy87 -----END PGP SIGNATURE----- --nextPart2553211.7bMH0X5CNR--