The following reply was made to PR kern/121668; it has been
noted by GNATS.
From: Laurent Frigault <lfrigault agneau.org>
To: Kian Mohageri <kianrestek.wwu.edu>
Cc: bug-followupFreeBSD.org
Subject: Re: kern/121668: connect randomly fails with EPERM
with some pf rules
Date: Thu, 13 Mar 2008 23:49:43 +0100
On Thu, Mar 13, 2008 at 12:44:48PM -0700, Kian Mohageri
wrote:
> >> I remember similar behavior and it was caused
by source port reuse
> >> on the client (so the new connection caused a
state mismatch on an
> >> old state).
> >
> > The previous connection are closed.
> > If the source port can't be reused yet, then the
kernel should use an
> > other one for the new connection. If it can, then
pf should allow it.
> >
> > If the connect (SYN) does not match an existing
state, The pf rule
> > should create a new state.
>
> It does "match" a state (source/dest is
same), which is the problem.
ok.
> Even though the connection is closed, the state hasn't
yet been purged.
> Refer to pf.conf(5) for how to adjust tcp.closed so
the state is purged
> sooner, or adjust the available dynamic port range
(sysctl
> net.inet.ip.portrange).
I try to disable net.inet.ip.portrange.randomized and set
tcp.closed
timeout to 0.
That seems to work arround the problem in most cases.
Are there any risk at setting the timeout to 0 ?
> I don't know if this is intended behavior or not.
I've never run into
> it on OpenBSD, but pf is integrated much more tightly
into their
> system obviously and I'm guessing their port reuse
code is pretty
> different too.
Maybe the port randomization is different too.
--
Laurent Frigault | <url:http://www.agneau.org/>
_______________________________________________
freebsd-pffreebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to
"freebsd-pf-unsubscribefreebsd.org"
|
