On Tue 2010-09-14 (13:54), Gareth de Vaux wrote:
> On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote:
> > Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
> > improvement at all? That's a bit strange. There's probably something
>
> If there was an improvement it was subtle (I wa
On Tue, Sep 14, 2010 at 01:12:00PM +0200, Gareth de Vaux wrote:
> On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote:
> > You're absolutely certain these are all in FIN_WAIT_2 state and not
> > TIME_WAIT?
>
> Yup,
>
> $ netstat -an | grep FIN_WAIT_1 | wc -l
> 57
> $ netstat -an | grep FIN_WAI
On Tue 2010-09-14 (04:30), Jeremy Chadwick wrote:
> Regarding net.inet.tcp.finwait2_timeout=15000 -- you don't see any
> improvement at all? That's a bit strange. There's probably something
If there was an improvement it was subtle (I was doing sporadic
measurements), just that in the end my fir
On Tue 2010-09-14 (04:03), Jeremy Chadwick wrote:
> You're absolutely certain these are all in FIN_WAIT_2 state and not
> TIME_WAIT?
Yup,
$ netstat -an | grep FIN_WAIT_1 | wc -l
57
$ netstat -an | grep FIN_WAIT_2 | wc -l
431
$ netstat -an | grep TIME_WAIT | wc -l
17
_
On Tue, Sep 14, 2010 at 12:36:57PM +0200, Gareth de Vaux wrote:
> On Fri 2010-09-10 (13:49), Gareth de Vaux wrote:
> > > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you
> > > should consider adjusting the following sysctl:
> > >
> > > net.inet.tcp.finwait2_timeout
> > >
> >
On Fri 2010-09-10 (13:49), Gareth de Vaux wrote:
> > Thirdly, if you feel FIN_WAIT2 is the cause of your problem, then you
> > should consider adjusting the following sysctl:
> >
> > net.inet.tcp.finwait2_timeout
> >
> > Try something like 15000 (15 seconds) instead of the default (6).
>
> O
On Fri, 10 Sep 2010, Marat N.Afanasyev wrote:
> Ian Smith wrote:
> > On Thu, 9 Sep 2010, Vlad Galu wrote:
> > > 2010/9/9 Marat N.Afanasyev:
> > > > I wonder, are these dynamic rules really necessary? let's see, a
> > client
> > > > connects to your web-server and you immediately sh
On Fri 2010-09-10 (03:18), Ian Smith wrote:
> Try using 'limit' rather than the unlimited 'keep-state' for inbound
> dynamic connections to your server/s. eg, derived from ipfw(8):
These are mostly legitimate connections though, they just aren't being
closed properly. So if limit were to have an
On 09/09/10 17:39, Gareth de Vaux wrote:
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in
On Thu 2010-09-09 (09:20), Jeremy Chadwick wrote:
> Secondly, I'm fairly certain HTTP KeepAlive (re: KeepAliveTimeout) are
> unrelated to TCP keepalives[1]. I mention this because you're focusing
> on netstat, which will give you indication of TCP session state, not
> HTTP protocol statefulness.
Ian Smith wrote:
On Thu, 9 Sep 2010, Vlad Galu wrote:
> 2010/9/9 Marat N.Afanasyev:
> > I wonder, are these dynamic rules really necessary? let's see, a client
> > connects to your web-server and you immediately should create a new
dynamic
> > rule, therefore you participate in th
On Thu, 9 Sep 2010, Vlad Galu wrote:
> 2010/9/9 Marat N.Afanasyev :
> > I wonder, are these dynamic rules really necessary? let's see, a client
> > connects to your web-server and you immediately should create a new dynamic
> > rule, therefore you participate in this DoS attack as well as attac
2010/9/9 Marat N.Afanasyev :
> I wonder, are these dynamic rules really necessary? let's see, a client
> connects to your web-server and you immediately should create a new dynamic
> rule, therefore you participate in this DoS attack as well as attacker. ;)
With a stateless firewall, you help the
> Date: Thu, 09 Sep 2010 22:03:10 +0400
> From: "Marat N.Afanasyev"
> Sender: owner-freebsd-sta...@freebsd.org
>
> Gareth de Vaux wrote:
> > Hi again, I use some keep-state rules in ipfw, but get the following
> > kernel message:
> >
> > kernel: ipfw: install_state: Too many dynamic rules
> >
> >
Gareth de Vaux wrote:
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in FIN_WAIT_2 state,
On Thu, 9 Sep 2010, Gareth de Vaux wrote:
> Hi again, I use some keep-state rules in ipfw, but get the following
> kernel message:
>
> kernel: ipfw: install_state: Too many dynamic rules
>
> when presumably my state table reaches its limit (and I effectively
> get DoS'd).
>
> netstat sh
On Thu, Sep 09, 2010 at 05:39:02PM +0200, Gareth de Vaux wrote:
> Hi again, I use some keep-state rules in ipfw, but get the following
> kernel message:
>
> kernel: ipfw: install_state: Too many dynamic rules
>
> when presumably my state table reaches its limit (and I effectively
> get DoS'd).
>
Hi again, I use some keep-state rules in ipfw, but get the following
kernel message:
kernel: ipfw: install_state: Too many dynamic rules
when presumably my state table reaches its limit (and I effectively
get DoS'd).
netstat shows tons of connections in FIN_WAIT_2 state, mostly to
my webserver.
18 matches
Mail list logo