On 26.10.2012 15:24, Andre Oppermann wrote:
On 26.10.2012 14:29, Andrey V. Elsukov wrote:
On 26.10.2012 15:43, Andre Oppermann wrote:
A> If you can show with your performance profiling that the sysctl
A> isn't even necessary, you could leave it completely away and have
A> pfil_forward enabled p
On 26.10.2012 14:29, Andrey V. Elsukov wrote:
On 26.10.2012 15:43, Andre Oppermann wrote:
A> If you can show with your performance profiling that the sysctl
A> isn't even necessary, you could leave it completely away and have
A> pfil_forward enabled permanently. That would be even better for
A>
On 26.10.2012 15:43, Andre Oppermann wrote:
>> A> If you can show with your performance profiling that the sysctl
>> A> isn't even necessary, you could leave it completely away and have
>> A> pfil_forward enabled permanently. That would be even better for
>> A> everybody.
>>
>> I'd prefer to have
On 26.10.2012 13:26, Gleb Smirnoff wrote:
On Thu, Oct 25, 2012 at 10:29:51PM +0200, Andre Oppermann wrote:
A> On 25.10.2012 18:25, Andrey V. Elsukov wrote:
A> > On 25.10.2012 19:54, Andre Oppermann wrote:
A> >> I still don't agree with naming the sysctl net.pfil.forward. This
A> >> type of forwa
On Thu, Oct 25, 2012 at 10:29:51PM +0200, Andre Oppermann wrote:
A> On 25.10.2012 18:25, Andrey V. Elsukov wrote:
A> > On 25.10.2012 19:54, Andre Oppermann wrote:
A> >> I still don't agree with naming the sysctl net.pfil.forward. This
A> >> type of forwarding is a property of IPv4 and IPv6 and thu
On 25.10.2012 18:25, Andrey V. Elsukov wrote:
On 25.10.2012 19:54, Andre Oppermann wrote:
I still don't agree with naming the sysctl net.pfil.forward. This
type of forwarding is a property of IPv4 and IPv6 and thus should
be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and
who know
On 25.10.2012 19:54, Andre Oppermann wrote:
> I still don't agree with naming the sysctl net.pfil.forward. This
> type of forwarding is a property of IPv4 and IPv6 and thus should
> be put there. Pfil hooking can be on layer 2, 2-bridging, 3 and
> who knows where else in the future. Forwarding w
On 25.10.2012 11:39, Andrey V. Elsukov wrote:
Author: ae
Date: Thu Oct 25 09:39:14 2012
New Revision: 242079
URL: http://svn.freebsd.org/changeset/base/242079
Log:
Remove the IPFIREWALL_FORWARD kernel option and make possible to turn
on the related functionality in the runtime via the sysc
On 25.10.2012 17:28, John Baldwin wrote:
>> Remove the IPFIREWALL_FORWARD kernel option and make possible to turn
>> on the related functionality in the runtime via the sysctl variable
>> net.pfil.forward. It is turned off by default.
>
> Certainly for MFC's I think it makes sense to retain
On Thursday, October 25, 2012 5:39:15 am Andrey V. Elsukov wrote:
> Author: ae
> Date: Thu Oct 25 09:39:14 2012
> New Revision: 242079
> URL: http://svn.freebsd.org/changeset/base/242079
>
> Log:
> Remove the IPFIREWALL_FORWARD kernel option and make possible to turn
> on the related functiona
Author: ae
Date: Thu Oct 25 09:39:14 2012
New Revision: 242079
URL: http://svn.freebsd.org/changeset/base/242079
Log:
Remove the IPFIREWALL_FORWARD kernel option and make possible to turn
on the related functionality in the runtime via the sysctl variable
net.pfil.forward. It is turned off b
11 matches
Mail list logo