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

On Sat, Dec 09, 2006 at 06:27:16PM -0800, Colin Percival wrote:

  Adam McDougall wrote:
  > I just tested tcp.closed with 3 seconds, down from 15 earlier but both were 
  > unsuccessful.  I will look at the other options as well, but do you have any explanation 
  > for why portsnap would use wildly randomish local ports that overlap too quickly
  > when fetch does not?  Is that a kernel controlled behavior that I can adjust?
  
  Try setting net.inet.ip.portrange.randomized=0.  This shouldn't make any
  difference, but it might.
  
  Colin Percival

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:

# portsnap fetch
Looking up portsnap.FreeBSD.org mirrors... using portsnap1.FreeBSD.org.
Fetching snapshot tag... done.
Fetching snapshot metadata... done.
Updating from Sat Mar 25 06:58:08 EST 2006 to Thu Dec 14 09:39:43 EST 2006.
Fetching 4 metadata patches... done.
Applying metadata patches... done.
Fetching 4 metadata files... done.

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:

Fetching 8765 patches.....10....20....3(etc)

When I have randomized=0, the first portion uses sequential ports and after
several runs of re-downloading the same 8765 patches, it seems to work fine
every time.  I made a backup copy of /var/db/portsnap so I could repeat the
fetch over and over for testing.  

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.