On 2009-Mar-26 11:02:55 -0500, Pierre Lamy wrote:
>A 1 day default timeout for established connections is retarded, since
>virtually all client apps and OSs as well as intervening stateful
>firewalls will lose state after 1 hour.
With respect, this is nonsense. An app or OS should never "lose
Hi,
On Thu, Mar 26, 2009 at 5:02 PM, Pierre Lamy wrote:
> stateshard limit1
>
> If I want to dos this box all I need to do is hold 10k tcp connections open
> in established.
>
> A 1 day default timeout for established connections is retarded, since
> virtually all client apps and
stateshard limit1
If I want to dos this box all I need to do is hold 10k tcp connections
open in established.
A 1 day default timeout for established connections is retarded, since
virtually all client apps and OSs as well as intervening stateful
firewalls will lose state aft
Hi,
On Wed, Mar 25, 2009 at 11:21 PM, Shawn Everett wrote:
> > tcp.established 86400s
> >
> > ^^ This should be 3600.
> >
> > Pierre
>
> That's an interesting thought. Why would that matter?
It's the PF TCP established session timeout, which defaults to 1 day. This
is relevant only
> tcp.established 86400s
>
> ^^ This should be 3600.
>
> Pierre
That's an interesting thought. Why would that matter?
Shawn
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send a
tcp.established 86400s
^^ This should be 3600.
Pierre
Shawn Everett wrote:
Any error messages in dmesg output ?
Significant changes in "netstat -m" output before and after ?
The same for "pfctl -s all" output...
The box has been up for about 12 hours now. As a point of dis
Hi,
On Fri, Feb 27, 2009 at 9:04 AM, Shawn Everett wrote:
> On Thursday 26 February 2009, Adrian Penisoara wrote:
> > pfctl -v -s state
>
> It's midnight here. There should be very little active traffic from
> workstations at this hour. I was just about to head off to bed.
>
OK, then check w
On Thursday 26 February 2009, Adrian Penisoara wrote:
> pfctl -v -s state
It's midnight here. There should be very little active traffic from
workstations at this hour. I was just about to head off to bed.
#pfctl -v -s state
No ALTQ support in kernel
ALTQ related functions disabled
all tcp 63
Hi,
On Fri, Feb 27, 2009 at 8:41 AM, Shawn Everett wrote:
> > Any error messages in dmesg output ?
> > Significant changes in "netstat -m" output before and after ?
> > The same for "pfctl -s all" output...
>
> The box has been up for about 12 hours now. As a point of discussion here
> is th
> Any error messages in dmesg output ?
> Significant changes in "netstat -m" output before and after ?
> The same for "pfctl -s all" output...
The box has been up for about 12 hours now. As a point of discussion here
is the output from netstat and pfctl in case anything obvious jumps out.
38
On Feb 26, 2009, at 3:43 PM, Shawn Everett wrote:
Here's a weird one... I set up FreeBSD 5.2 to act as a router.
[ ... ]
Any suggestions would be appreciated.
Try upgrading to a supported version of the OS, first, then work on
debugging any deadlocks if they still reoccur.
Early 5.x ver
Hi Guys,
Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used
the pf.conf script shown at:
http://www.openbsd.org/faq/pf/pools.html#outgoing
Everything works just fine. Traffic is appropriately load balanced and
things work as expected.
Strangely after a few hours something j
Hi,
On Fri, Feb 27, 2009 at 1:06 AM, Shawn Everett wrote:
> Sorry I meant to say FreeBSD 7.0 :)
>
> > Hi Guys,
> >
> > Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used
> > the pf.conf script shown at:
> > http://www.openbsd.org/faq/pf/pools.html#outgoing
> >
> > Everything
Sorry I meant to say FreeBSD 7.0 :)
> Hi Guys,
>
> Here's a weird one... I set up FreeBSD 5.2 to act as a router. I used
> the pf.conf script shown at:
> http://www.openbsd.org/faq/pf/pools.html#outgoing
>
> Everything works just fine. Traffic is appropriately load balanced and
> things work as
14 matches
Mail list logo
