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

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.

Colin Percival