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

Mike Silbersack silby at silby.com
Tue Dec 26 23:45:25 PST 2006


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


More information about the freebsd-current mailing list