Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update

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=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.

One idea would be to use something in the spirit of OpenBSD's IPID 
randomization. i.e. fix one bit in the randomization range and toggle 
between the resulting halves.  If we feel that we can't do randomization 
anymore, we would toggle and hand out the other half range in linear 
fashion.  This certainly needs some thinking to support arbitrary ranges, 
but I think it might work.

Another sollution, of course, would be to: Don't do that then.  It really 
seems wrong for a program to exhaust the outgoing port pool.

-- 
/"\  Best regards,                      | mlaier_at_freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier_at_EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News