Date: Wed, 27 Dec 2006 01:18:39 -0600 (CST) From: Mike Silbersack <silby@silby.com> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: freebsd-current@freebsd.org, Colin Percival <cperciva@freebsd.org> Subject: Re: Fwd: Re: pf: BAD state happens often with portsnap fetch update Message-ID: <20061227011612.Q99056@odysseus.silby.com> In-Reply-To: <20061227023330.GJ66966@egr.msu.edu> References: <20061210010823.GS81923@egr.msu.edu> <457B621E.3020100@freebsd.org> <20061210014924.GU81923@egr.msu.edu> <457B7084.9070409@freebsd.org> <20061214172323.GP1011@egr.msu.edu> <45908ED3.4040503@freebsd.org> <2472.68.253.24.139.1167151819.squirrel@webmail11.pair.com> <20061227023330.GJ66966@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 26 Dec 2006, Adam McDougall wrote: > After about 13 seconds of active fetching, portsnap cycles sequentially > through the remainder of the available ephermal range set as above (200 > ports) and it goes ahead and tries to reuse 49152 as soon as it got done > using 49352. tcpdump shows the client host sending SYNs to the squid server > periodically for about 56 seconds, until pf allows it through and a response > completes. A few more ports are allowed through somewhat rapidly, then > at times there are additional waits while the new connections bump up > against pf's enforced timeouts. I let portsnap go on to at least 2600 ports Argh, I forgot to ask for one more critical piece of information. Can you run netstat -n on both the client and server to verify on which side the TIME_WAIT sockets are accumulating? No need to re-capture the data that you have already captured, just find out if the TIME_WAIT sockets are all ending up on one side, or if they're showing up both. Mike "Silby" Silbersack
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061227011612.Q99056>