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