Date: Mon, 23 Jan 2012 00:42:13 -0500 From: Walt Elam <wrelam@gmail.com> To: "freebsd-pf@freebsd.org" <freebsd-pf@freebsd.org> Subject: Re: Getting Involved Message-ID: <CAConN%2Bkq8kHZGNUHP9vgZDNYbQWVAcWRsWS89iXASffsPDMCEg@mail.gmail.com> In-Reply-To: <CAConN%2Bke5h3V6fponKgKc_Yc_XgQ%2BGXo9p_Pqqg85NKkbW158w@mail.gmail.com> References: <CAConN%2BkZquK7MJ_6YPtEV=sJdqC%2BniRqMmp2ZgQL%2Bo2m1wvXSQ@mail.gmail.com> <CAPBZQG2S9T4v_4g09mXaukG4o3_4w8h51py6-iPoA%2BgmsuenUw@mail.gmail.com> <9EB23F6C23A8B6488E8BCC92A48E832612A5BC03A9@PEMEXMBXVS04.jellyfishnet.co.uk.local> <E0053250-530D-4ADA-8230-E506814E475D@lists.zabbadoz.net> <CAConN%2Bke5h3V6fponKgKc_Yc_XgQ%2BGXo9p_Pqqg85NKkbW158w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
I didn't intend to stir things up, too much. But was just hoping to get involved in helping get something ported over to use the new syntax. I was thinking exactly what someone else posted earlier, where there could be something placed in rc.conf to indicated what syntax you wanted to use. I searched a bit this weekend and couldn't figure out where exactly to download the code for OpenBSDs PF. I'm honestly not sure where to start on porting something but was hoping this list may be able to get me going in the right direction. Also, if it is all written in C, then I don't understand why we couldn't just install the right ports/packages and have the OpenBSD code work in FreeBSD. Could someone explain that, please? Lastly, I didn't really understand the reason given for using the old syntax. Even if we focused on porting over pf 4.7 then that would technically be enough to get in to the new syntax for rules. -Walt On Sat, Jan 21, 2012 at 9:50 PM, Bjoern A. Zeeb < bzeeb-lists@lists.zabbadoz.net> wrote: > > > 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!
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAConN%2Bkq8kHZGNUHP9vgZDNYbQWVAcWRsWS89iXASffsPDMCEg>