Date: Sun, 22 Jan 2012 02:50:40 +0000 From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: Greg Hennessy <Greg.Hennessy@nviz.net> Cc: freebsd-pf@freebsd.org Subject: Re: Getting Involved Message-ID: <E0053250-530D-4ADA-8230-E506814E475D@lists.zabbadoz.net> In-Reply-To: <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local> References: <CAConN%2BkZquK7MJ_6YPtEV=sJdqC%2BniRqMmp2ZgQL%2Bo2m1wvXSQ@mail.gmail.com> <CAPBZQG2S9T4v_4g09mXaukG4o3_4w8h51py6-iPoA%2BgmsuenUw@mail.gmail.com> <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local>
next in thread | previous in thread | raw e-mail | index | archive | help
On 21. Jan 2012, at 23:26 , Greg Hennessy wrote: >>>=20 >> There is one catch. >> FreeBSD does not want to break compatibility of old syntax and that = is why >> i did not port the latest version of pf(4). >=20 > Shades of the versioning/maintenance issues surrounding putting Perl = in the base way back in the day.=20 >=20 >> What is there now makes it 'trivial' to go to the latest pf(4) = version in >=20 > Does that include the performance improvements which came with new = version?=20 > Would be interesting to know what impact if any they would have on the = FreeBSD PF port.=20 Whatever performance improvements you are talking about is basically = irrelevant the way pf is written and designed, which is just another = obstacle in tracking Open. FreeBSD is no longer a UP-like operating = system. We'd need a larger mix of (just to name some) fine grained = locking (currently the 1 lock basically halts the network stack per = packet going through pf), a lot more cache friendly data structures, = affinity, ... in that area. Taking it to 10G or eventually 40G is = really a different step than squeezing another 50Mbit/s out of it by = some optimization and entangling it more and more with the rest of the = network stack etc. >> Open but there needs to be a layer of translation >> for the old syntax to new syntax. >=20 > As a one off translation when someone upgrades Major version numbers = to the FreeBSD version hosting the new PF code?=20 > Or run every time when someone loads the security policy for now and = the foreseeable future?=20 Let's say pf ruleset instead of security policy (which is also used in = various other ways). The basic problem is that the syntax is known to = management tools but also the user space-kernel API is exposed to 3rd = party tools. Breaking any is bad. The latter we can break with major = versions though preferably we'd love not to. The way things are written = it's basically not possible not to break it even when bringing in cherry = picked features like NAT64 etc. It's an obstacle to some of our = consumers though. The moment you update your kernel and pfctl doesn't = speak the same language anymore you lost your firewall. And it's not = uncommon to upgrade a kernel going from x.y to x.y+n for example, wait a = week or two before updating all user land etc. It's the same problem with pfsync; you can have two old version ones, = reboot the first, not able to sync things to the new as it doesn't = understand the old anymore and by the time you reboot the 2nd things = *oops*. That's not an upgrade path for a HA setup unfortunately and we = had that happen way too often to our users - once again with 9. >> That is the only reason its not been done. >=20 > I can see the issues, hope it's not intractable.=20 > The new syntax is a significant improvement, shame about lack of = thought given to backward compatibility. You are preaching to the wrong choir:( > With your expert knowledge on this Ermal, is it possible to run both = old and new PF parsers in there to generate a policy which would run = against the newer packet filtering engine code? If you write the translation stub you might succeed. Have fun... = *cough* > Defaulting to the old syntax, with say something like a ' = later_pf_enable=3D"yes"'' in rc.conf or a single 'use' line at the top = of pf.conf to switch to the new syntax?=20 You can even have two different pf's loadable by the kernel (at least = one at a a time) if doing it clever given pfil hooks. But maintaining = more than 1 is not going to happen for and in Free. There are basically two options: 1) we can make it work well or 2) you = can always have the newest syntax and regularly break and not perform. = Pick any single one at this point and let us know which one you'd = prefer. A couple of developers lately had this discussion (though not everyone = was present). I'll however be curious which way our users want it to be = ... /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E0053250-530D-4ADA-8230-E506814E475D>