From owner-freebsd-current@FreeBSD.ORG Sun Dec 10 01:08:25 2006 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0D6EB16A542 for ; Sun, 10 Dec 2006 01:08:25 +0000 (UTC) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: from daemon.egr.msu.edu (daemon.egr.msu.edu [35.9.44.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E58043C9E for ; Sun, 10 Dec 2006 01:07:17 +0000 (GMT) (envelope-from mcdouga9@daemon.egr.msu.edu) Received: by daemon.egr.msu.edu (Postfix, from userid 21281) id 47BC71CE6F; Sat, 9 Dec 2006 20:08:24 -0500 (EST) Date: Sat, 9 Dec 2006 20:08:24 -0500 From: Adam McDougall To: freebsd-current@freebsd.org Message-ID: <20061210010823.GS81923@egr.msu.edu> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="CNfT9TXqV7nd4cfk" Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Fwd: Re: pf: BAD state happens often with portsnap fetch update X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Dec 2006 01:08:25 -0000 --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 To: cperciva@FreeBSD.org Cc: Adam McDougall 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--