On Thu, May 10, 2007 at 02:31:54AM -0400, Daniel Ouellet wrote:

quoted text
> Ted Unangst wrote:

> >On 5/9/07, Daniel Ouellet  wrote:

> >>I try to stay safe in my choices and comments are welcome, but I have to

> >>point out as well that ALL the values below needs to be changes to that

> >>new value to get working well. If even only one of them is not at the

> >>level below, the results in the tests start to be affected pretty bad at

> >>times.

> >>net.bpf.bufsize=524288

> >>net.inet.ip.redirect=0

> >

> >never mind the rest, but these two really make no sense.  none.

>

> Make no sense in the test and improving results, or make no sense in

> setting them as such here?

>

> net.inet.ip.redirect=0

>

> Is to disable ICMP routing redirects. Otherwise, your system could have

> its routing table misadjusted by an attacker. Wouldn't be wise to do so?

> May be if PF is turn on, then there is no reason for this, but with PF

> ON, I get drop and need to address that. Didn't pursue it yet as dead

> however.

> 

net.inet.ip.redirect has only an effect if you enable

net.inet.ip.forwarding. As you are running a server and not a router I

doubt this is the case. Additionally net.inet.ip.redirect does not modify

the routing table. Your are probably looking at net.inet.icmp.rediraccept.
> As for the net.bpf.bufsize, I am looking again in my notes and tests,

quoted text
> it's use for Berkeley Packet Filter (BPF), to maintains an internal

> kernel buffer for storing packets received off the wire.

>

> Yes in that case it make sense not to have that here. I redid the tests

> with the default value and yes you are right! This one is wrong here.

> May be lack of sleep. (;> Thanks for correcting me!

>

> I also have the revise my statement on the net.inet.ip.portfirst=32768

> effect. In a series of new tests, it doesn't have the impact noted the

> first test runs. So, I would keep it as default value as well now. May

> be it was when PF was enable that I have more of an impact then. But my

> notes are not clear on that specific one.

> 

With many shortliving connections you have a lot of sockets in TIME_WAIT.

Because you are testing from one host only you start to hit these entries

more and more often this often results in a retry from the client.

Additionally by filling all available ports the port allocation algorithm

is starting to get slower but that's a problem that you will only see on

the host :) The accept behaviour of OpenBSD should be fine.
> Anything else you see that may be questionable in what I sent? I am

quoted text
> doing more tests with different hardware to be sure it's all sane value

> in the end.

>

> Other wise many thanks for having taken the time to look it over and

> give me your feedback on it!

> 

I think there are a few knobs that you should reconsider. I will write an

other mail about that.
--

:wq Claudio