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

Posting to get more exposure, due to the below errors:

FreeBSD ice 6.2-PRERELEASE FreeBSD 6.2-PRERELEASE #2: Sat Dec  9 16:50:47 EST 2006     
root_at_ice:/usr/obj/usr/src/sys/PE2650  i386

# portsnap fetch update
Looking up portsnap.FreeBSD.org mirrors... 2 mirrors found.
Fetching snapshot tag from portsnap2.FreeBSD.org... done.
Fetching snapshot metadata... done.
Updating from Tue Oct 24 13:57:53 EDT 2006 to Sat Dec  9 18:34:57 EST 2006.
Fetching 4 metadata patches... done.
Applying metadata patches... done.
Fetching 4 metadata files... done.
Fetching 2597 
patches.....10....20....30....40....50....60....70....80....90....100....110....120....130....140....150....160....170....180....190....200....210....220....230....240....250....260....270....280....290....300....310....320....330....340....350....360....370....380....390....400....410.... 
done.
Applying patches... done.
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.
Thanks for any help, and let me know how to help.  

attached mail follows:

On Thu, Oct 05, 2006 at 06:20:21PM +0200, Daniel Hartmeier wrote:

  On Thu, Oct 05, 2006 at 12:08:27PM -0400, Adam McDougall wrote:
  
  > (44.18 is the squid server (trident), 37.163 is the system running portsnap (ice))
  > 
  > Oct  5 11:22:03 jolly-fw1 kernel: pf: BAD state: TCP 35.9.44.18:3128 35.9.44.18:3128 35.9.37.163:55357 
  > [lo=646710754 high=646777361 win=33304 modulator=0 wscale=1] [lo=4033525074 high=4033590770 win=33304 
  > modulator=0 wscale=1] 9:9 S seq=650709460 ack=4033525074 len=0 ackskew=0 pkts=5:4 dir=in,fwd
  > Oct  5 11:22:03 jolly-fw1 kernel: pf: State failure on: 1       | 5
  
  The client (37.163) is running out of random high source ports, and
  starts re-using ports from previous connections, violating 2MSL.
  
  pf keeps states of closed connections around for a while (default is
  90s), so late packets related to the old connection can be associated
  with the state. Creating a second, concurrent state entry for the same
  source/destination address:port quadruple is not possible.
  
  You can
  
    a) lower pf's tcp.closed timeout, so states of closed connections get
       purged sooner.
  
    b) give the client more random high ports (sysctl net.inet.ip.portrange.*)
       or add aliases, if the client can make use of them concurrently.
  
    c) reduce the connection establishment rate of the client. if portsnap
       needs one connection for every single file, that's a poor protocol,
       if you expect a single client to fetch thousands of files in a few
       seconds.
  
  Daniel

It seems like portsnap doesn't use client ports sequentially but rather skips
many ports at a time, 100 or more, and once it wraps around to the bottom of the
range, it tries to reuse an old port.  When I test using a simple while script
to fetch a file from a local web server through the same proxy, it appears 
to be almost strictly sequential.  Do you have any comment on the local port
assignment method or the reuse of ports that ought to be avoided?  Thanks.

BTW Thanks for writing portsnap, I find it enjoyable to use and beneficial.