On 21. Jan 2012, at 23:26 , Greg Hennessy wrote: >>> >> 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). > > Shades of the versioning/maintenance issues surrounding putting Perl in the > base way back in the day. > >> What is there now makes it 'trivial' to go to the latest pf(4) version in > > Does that include the performance improvements which came with new version? > Would be interesting to know what impact if any they would have on the > FreeBSD PF port.
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. > > As a one off translation when someone upgrades Major version numbers to the > FreeBSD version hosting the new PF code? > Or run every time when someone loads the security policy for now and the > foreseeable future? 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. > > I can see the issues, hope it's not intractable. > 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="yes"'' in rc.conf or a single 'use' line at the top of > pf.conf to switch to the new syntax? 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 -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do!_______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
