Replying to the top of the thread, but the text is actually reply to those people in the thread, who eager for import of new pf from OpenBSD. So, I claim that there is a vast and silent majority of people who simply use pf and do not want the hassle with broken pf.conf. I also claim that there is number of people who utilize pf at larger installations and they were very glad to see pf to scale on multiple CPUs and at least not to freeze the entire traffic for seconds during expiry run. And you claim that there is another large number of people, who want to run newest pf from OpenBSD on FreeBSD, and they do not care about syntax change problems. Unfortunately, we cannot compare our large numbers. Well, you can tell that your number is at least four times bigger than mine, but you will not provide details on how can we check that. :) What can we do in this situation? Thanks to the pfil(9) framework, we can have as much firewalls as we want. You can import new pf keeping the current version intact. There could be some minor problems on decision how to manage two different pfctls, and other utilities, but these are solvable. Let me restate. The FreeBSD version of pf IS NOT on your way of putting OpenBSD version of pf to FreeBSD. What IS your main obstacle in this task is the porting process itself. Try it. Fork FreeBSD in git, mercurial, or simply checkout subversion working directory, then: # cd sys/netpfil # mkdir openbsd-pf # cd openbsd-pf And start working. When you got a buildable and working version[*], post call for testing email to current_at_ and pf_at_. After several rounds of testing you will end up with something working. And if we see that the demand for second pf in FreeBSD is real, and you are willing to take maintainership of it, you will be welcome as committer and second pf will be welcome to the tree[**]. Any takers? === [*] Spoiler: usually by that time both FreeBSD tree and pf taken from OpenBSD would diverge and you would need to sync up :) [**] This is my personal opinion, not an official project statement, neither a core team member statement. I expect that there would be resistance against yet-another-packet-filter, that you would need to deal with. But if you got a working code, and you got a userbase of the code, then you have chances to overcome the resistance. And please don't start bikeshedding right now with no code at hand. -- Totus tuus, Glebius.Received on Tue Jul 29 2014 - 09:05:15 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:51 UTC