Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 26 Dec 2006 11:29:39 +0100
From:      Max Laier <max@love2party.net>
To:        freebsd-current@freebsd.org
Cc:        Adam McDougall <mcdouga9@egr.msu.edu>, Mike Silbersack <silby@silby.com>, Colin Percival <cperciva@freebsd.org>
Subject:   Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update
Message-ID:  <200612261129.48173.max@love2party.net>
In-Reply-To: <45908ED3.4040503@freebsd.org>
References:  <20061210010823.GS81923@egr.msu.edu> <20061214172323.GP1011@egr.msu.edu> <45908ED3.4040503@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612261129.48173.max>