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

On Sat, Dec 09, 2006 at 05:25:50PM -0800, Colin Percival wrote:

  Adam McDougall wrote:
  > # portsnap fetch update
  > [...]
  > Fetching 2688 new ports or files... /usr/sbin/portsnap: cannot open 
  > 3f115cb168a8e51fd0d19798f005ab7a251a1de6a5b9eda60cd327b60aa48799.gz: No such file or 
  > directory
  > snapshot is corrupt.
  > 
  > 2597 should have been fetched, but there was a stall at 30.. and after about a minute,
  > it continued on to 410...... and gave up apparently.  For all my servers without
  > direct internet access, I have to run portsnap several times until it succeeds.
  
  You have four options:
  (a) Lower pf's tcp.closed timeout,
  (b) Increase the high port range,
  (c) Fix squid so that it groks HTTP/1.1 properly, or
  (d) Stop using squid.
  
  The problem here is that your proxy is closing portsnap's HTTP connection after
  each file is downloaded.
  
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?

65535-49152=16383 (unless I am looking at the wrong sysctl for the default values)
and I would think there are many less connections involved for 2597 fetches than
16363.  If 16363 isn't enough ports for 2597 fetches then it seems like a crapshoot to 
try doubling or tripling the range.