Date: Sat, 9 Dec 2006 20:08:24 -0500 From: Adam McDougall <mcdouga9@egr.msu.edu> To: freebsd-current@freebsd.org Subject: Fwd: Re: pf: BAD state happens often with portsnap fetch update Message-ID: <20061210010823.GS81923@egr.msu.edu>
next in thread | raw e-mail | index | archive | help
--CNfT9TXqV7nd4cfk
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
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@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.
--CNfT9TXqV7nd4cfk
Content-Type: message/rfc822
Content-Disposition: inline
Date: Thu, 5 Oct 2006 15:27:25 -0400
From: Adam McDougall <mcdouga9@egr.msu.edu>
To: cperciva@FreeBSD.org
Cc: Adam McDougall <mcdouga9@egr.msu.edu>
Subject: Re: pf: BAD state happens often with portsnap fetch update
Message-ID: <20061005192725.GN46920@egr.msu.edu>
References: <20061005160827.GB46920@egr.msu.edu>
<20061005162021.GD21693@insomnia.benzedrine.cx>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20061005162021.GD21693@insomnia.benzedrine.cx>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Original-Status: RO
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.
--CNfT9TXqV7nd4cfk--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061210010823.GS81923>