Date: Mon, 26 Nov 2012 15:02:29 +0100 From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= <eri@freebsd.org> To: Andre Oppermann <andre@freebsd.org> Cc: Gleb Smirnoff <glebius@freebsd.org>, src-committers@freebsd.org, svn-src-user@freebsd.org Subject: Re: svn commit: r243458 - in user/andre/tcp_workqueue/sys: net netinet Message-ID: <CAPBZQG0rrN_gXJUG1Q-n2WMGf6QXhXeus-OmtJ=AvGmktrua8A@mail.gmail.com> In-Reply-To: <50B36A38.7040603@freebsd.org> References: <201211231453.qANErSKF034907@svn.freebsd.org> <20121123152741.GZ84121@FreeBSD.org> <CAPBZQG3cWBfgwXR_1Q%2BZjSOsE13PeOK12AjqFkgYay%2Bh-Xcpig@mail.gmail.com> <50B36A38.7040603@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Nov 26, 2012 at 2:10 PM, Andre Oppermann <andre@freebsd.org> wrote: > On 23.11.2012 17:11, Ermal Lu=E7i wrote: > > On Fri, Nov 23, 2012 at 4:27 PM, Gleb Smirnoff <glebius@freebsd.org<mail= to: >> glebius@freebsd.org>> wrote: >> >> Frankly speaking, the fact that the list can't be set directly >> in one sysctl oid: >> >> sysctl net.inet.pfil_in.hooks=3D"pf,**ipfw,ipfilter" >> >> , but can only be set via suppling pointless numeric values to N >> oids looks very poor from perspective of an average user. He might >> think something like "oh, FreeBSD developers were too lazy to parse >> a string", or "they designed an interface not for people but for >> nerds". >> >> Interface must be easier! If you don't like parsing strings in >> kernel, >> then /sbin/pfilctl can be introduced. The utility eventually may gro= w >> more functionality. >> >> I already gave a link to already existing patch for this. >> Not sure why andre@ decided the other way around. >> > > I wanted to have a pre-determined default order of pfil modules > especially with the IPSec pfil hook I've started working on. > That's the reason for the ordering value. This ordering value > has to be carried along somehow. Also I'm no fan of kernel side > parsing, even if there are instances where it can't be avoided. > > So the default pfil hook ordering should lessen the need to reorder > pfil hooks at runtime. > > Would you mind having a pfilctl at Gleb suggested? That way we could > abstract the whole thing away and also gain flexibility in the kernel > implementation for the future. > > Its flexibility added but its just another step people will have to take care when configuring staff. Using sysctl people are familiar with and specifying just strings seems easier when the parsing is simple. With some good documentation that is easier, than having priorities and unsolved problem of what happens at the same priority level! Though the utility has some value if pfil hooks gain ability to be enabled disabled by interface. This can be taken as a micro-optimization to not send every packet over the hooks if people deem its not useful. For example people want ipsec usually only at specific interface(s) and being able to tune the hook at only where needed seems as a feature to me while retaining the default ability of a hook for all packets. In this case the policy tool is needed since the parsing is more complicated. As a scenario in pfSense ipfw is used for captive portal functionality and its needed active only on selected interface(s). I added a flag per interface to control this otherwise the rule sets become unmanageable and introduce measurable overhead. > Another question: In your patch you have a pfil hook disable option > directly in the hook mechanism. What is the reason for that versus > having the pfil consumer unhook itself when not enabled or in use? The use case of it is for disabling ipfw hook at ip level(layer3) while keeping it active for layer2. It seems more natural to control this policy as a pfil interface rather than having pfil consumers having to deal with this kind of policies. > > -- > Andre > > --=20 Ermal
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPBZQG0rrN_gXJUG1Q-n2WMGf6QXhXeus-OmtJ=AvGmktrua8A>