Re: ipfilter(4) needs maintainer
2013/4/14 Gary Palmer gpal...@freebsd.org: On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits My $0.02, Regards -- Demelier David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote: 2013/4/14 Gary Palmer gpal...@freebsd.org: Do we honestly need three packet filters? No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). IPFW. It is more logical and easy to use in complex context. Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 19 Apr 2013 10:46, David Demelier demelier.da...@gmail.com wrote: 2013/4/14 Gary Palmer gpal...@freebsd.org: On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? No, for me only one should be present. I completely understand that some users still use IPFilter and IPFW but why providing three packet filters? The answer should be: use one and document only one. If at the beginning we started documenting only one all users should have used the only one present. Now we really need to remove the ancestral ipfilter and tell people switching to pf(4). Everything in life change, if we need to maintain all code from the past we will have a lot of compat code that pollute the full source tree and we will never improve the code just because of old bits These so called old bits are both maintained, and have different strengths. Removing dead unmaintained code yes, but having choice makes transition easier from other OSes; the fewer parts to change at a time, the better. Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 15 April 2013 16:12, Cy Schubert cy.schub...@komquats.com wrote: The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. There's a plan[1] to remove the remaining GPL components from base over time. Updating to the last ipfilter that's under the current license is probably the path forward, unless it moves out to ports. [1] https://wiki.freebsd.org/GPLinBase -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message CAPyFy2BaoF-7t-skTUPt97hkRgdjO-KbB2-vhjOus-nutNO5Fw@mail.gmail.c om , Ed Maste writes: On 15 April 2013 16:12, Cy Schubert cy.schub...@komquats.com wrote: The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. There's a plan[1] to remove the remaining GPL components from base over time. Updating to the last ipfilter that's under the current license is probably the path forward, unless it moves out to ports. [1] https://wiki.freebsd.org/GPLinBase That's been pointed out to me. IPF's build/install scripts place header files in /usr/include, IMO unacceptable for a port. Going forward we go to 4.1.34 (still under the old license) then look at options. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 15.04.2013 19:48, Cy Schubert wrote: I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Actually it shouldn't touch many if any pieces of src/sys. Everything should happen via sorta published API's the other firewall packages use as well. Most important pfil hooks. The hardest part probably is to get the locking right. Please run changes to src/sys/net* through glebius@ and me (andre@) first before committing. In most, if not all cases, it is possible to find a generic way of doing things or to standardize on a common one for all of our packet filters. -- Andre ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, 15 Apr 2013 12:15:49 -0700, Cy Schubert cy.schub...@komquats.com wrote: It was pointed out to me that Darren Reed has changed licenses from his IP Filter license that's been in IPF since 2005 or so, when he joined Sun, to GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF already lives in src/contrib and src/sys/contrib due to the 2005 license change, would that be a problem? If it's OK then I'll maintain it in src. If not then a port is in order. Having said that, a port would be messy as IPF's own install scripts update src/sys/netinet, among other locations. That would be a big 'no', right there. Ports should never update kernel headers. If not for any other reason, because which kernel?. I regularly keep 2-3 different source trees of the kernel around, and build them from non-standard locations. Having to remember to run ipfilter_hack.sh on each of them before doing a successful build and ending up with kernel sources which are always 'unclean svn checkouts' would suck -- and I suspect I'm not the only one doing builds of kernels outside of /usr/src. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Fri, Apr 12, 2013 at 11:33:30PM -0700, Rui Paulo wrote: It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Realy? pf do FTP nat translation w/o contexst switching? Multiple GRE nat translation? I am use from ipfilter only ipnat. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote: wishmaster wrote: --- Original message --- From: Gary Palmer gpal...@freebsd.org Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... Does anyone even use ipf? it doesn't even work on Linux anymore, junk it and keep pf+ipfw, job done. m0n0wall uses ipfilter: http://m0n0.ch/wall/facts.php pgpHApUzGDDwu.pgp Description: PGP signature
Re: ipfilter(4) needs maintainer
Hello, Mark. You wrote 15 апреля 2013 г., 2:25:07: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Mark. You wrote 15 апреля 2013 г., 2:25:07: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! -- // Black Lion AKA Lev Serebryakov l...@freebsd.org Things like ftp-proxy(8) will need address translation even with IPv6. Also certain scrub options require a NAT like functionalities. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:26:40: MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:26:40: MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. You're forgetting set ups where outgoing traffic is controlled by filter rules, outgoing passive mode ftp needs help from the proxy to open holes for arbitrary ports. This is not limited to IPv4 and NAT. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! You disallow anonymization? NAT do anonymisation also. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:38 PM, Slawa Olhovchenkov s...@zxy.spb.ru wrote: On Mon, Apr 15, 2013 at 02:15:36PM +0400, Lev Serebryakov wrote: Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! You disallow anonymization? NAT do anonymisation also. ___ Please stop it already, NAT has never done any real anonymisation. it's just one of the myths that just refuse to die. Use a real anonymiser like Tor if you want to keep your identity hidden. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:36:27: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. KP You're forgetting set ups where outgoing traffic is controlled by KP filter rules, outgoing passive mode ftp needs help from the proxy to KP open holes for arbitrary ports. This is not limited to IPv4 and NAT. It could be done without IPv6 prefix mapping. Yes, firewall should have ability to expect some connections fro FTP commands (some flag on rule, for sure), but it is not prefix rewriting (there are some other protocols, which need similar treatment, like SIP)! I was shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own problems and complications, but one REALLY GOOD side of it, that we don't need NAT for it anymore! Some special tricks in firewall -- yes, maybe, for bad-designed, but widely-deployed application level protocols, but not address translations! I, personally, don't see any problems to enable all outbound connections for dedicated FTP server, though. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:36:27: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. KP You're forgetting set ups where outgoing traffic is controlled by KP filter rules, outgoing passive mode ftp needs help from the proxy to KP open holes for arbitrary ports. This is not limited to IPv4 and NAT. It could be done without IPv6 prefix mapping. Yes, firewall should have ability to expect some connections fro FTP commands (some flag on rule, for sure), but it is not prefix rewriting (there are some other protocols, which need similar treatment, like SIP)! I was shocked by idea of true NAT from IPv6 to IPv6. IPv6 has its own problems and complications, but one REALLY GOOD side of it, that we don't need NAT for it anymore! Some special tricks in firewall -- yes, maybe, for bad-designed, but widely-deployed application level protocols, but not address translations! I, personally, don't see any problems to enable all outbound connections for dedicated FTP server, though. Server side is the easy part, no need for proxy because you know the passive mode data ports and you can open holes in your firewall using the known port numbers. I'm however talking about an ftp client behind a very restrictive firewall making an IPv6 connection an ftp server that uses passive mode data ports that can't be known in advance. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Mmm, are you thinking of the way Linux iptables handles this scenario with a kernel mode helper? I don't think any of the three packet filters in FreeBSD has a functionality like that yet. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Not heavy. But error-prone, yes. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
MM ... and as far as I can tell none of them is currently usable MM on an IPv6-only FreeBSD (like protecting a host with sshguard), MM none of them supports stateful NAT64, nor IPv6 prefix translation :( IPv6 prefix translation?! AGAIN!? FML. I've thought, that IPv6 will render all that NAT nightmare to void. I hope, IPv6 prefix translation will not be possible never ever! KP Things like ftp-proxy(8) will need address translation even with IPv6. ftp-proxy is solution to help IPv4 NAT. Why do we need it when every device could have routable IPv6? Of course, _every_ device should be protected by border firewall (stateful and IPv6-enabled), but FTP server should have special rules for it to allow traffic pass, not some proxy. And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. We are *way* too late in the game to completely avoid IPv6 NAT. Various flavors already exist in the form of RFCs, e.g. NPTv6: http://tools.ietf.org/html/rfc6296 Steinar Haug, Nethelp consulting, sth...@nethelp.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 14.04.13 21:55, Joe Holden wrote: For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... And, best of all, it still is buggy. At lest, it's tables handling is unusable. I have been very stubborn IPFW user for very long time, but finally gave up in favor of PF. Nothing like that ever since. I am also not convinced IPFW is any faster than PF. Daniel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala kpaas...@gmail.com wrote: On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov l...@freebsd.org wrote: Hello, Kimmo. You wrote 15 апреля 2013 г., 14:47:24: KP I'm however talking about an ftp client behind a very restrictive KP firewall making an IPv6 connection an ftp server that uses passive KP mode data ports that can't be known in advance. Same solution -- inspection of connections to 21 port, without any address translation. And if FTP server uses non-standard control port, yes, here is a problem, but it cannot be solved with NAT too (or your NAT/firewall should expect each and every connection for FTP commands, which is heavy and error-prone task). Mmm, are you thinking of the way Linux iptables handles this scenario with a kernel mode helper? I don't think any of the three packet filters in FreeBSD has a functionality like that yet. -Kimmo To elaborate on this, Linux iptables has a related qualifier for rules and the related traffic is identified by kernel mode helpers, ftp is one example for their use. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Monday April 15 2013 12:32:37 Lev Serebryakov wrote: And, yes, NAT64 will be useful for sure, but it is another story, not IPv6-IPv6 translation. Fear not, NPT66 prefix translation is stateless, this is nothing like NAT44 / NAPT. On Monday April 15 2013 12:51:00 sth...@nethelp.no wrote: We are *way* too late in the game to completely avoid IPv6 NAT. Various flavors already exist in the form of RFCs, e.g. NPTv6: http://tools.ietf.org/html/rfc6296 Prefix translation is useful for SOHO or branch offices with more than one uplink, unless one wants to invest into AS and BGP or start building tunnels: http://blog.ioshints.info/2011/12/we-just-might-need-nat66.html Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
I have been very stubborn IPFW user for very long time, but finally gave up in favor of PF. Nothing like that ever since. I am also not convinced IPFW is any faster than PF. Hi Daniel, I know that measuring PPS for a firewall is not enought for comparing firewall performance (rfc3511 details lot's of the parameters, but on my smalldirty bench lab with an old server (one core Intel Pentium4 3.00GHz with a dual NIC 82546GB connected to the PCI-X Bus) I've got theses differences (value are in Kpps, small packet size) on FreeBSD 9.1: - forwarding-only: 405 Kpps - IPFW enabled: 320 Kpps - PF enabled: 274 Kpps IPFW was configured with only one line: add 3000 allow ip from any to any And PF with one line too: pass = On this simple test, IPFW is faster than PF regarding the forwarding rate. But without ipfwsync feature, IPFW is useless for our use case... Regards, Olivier ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
However it would of been better if said person asked me as I already offered to take it on but whatever. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message 8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org, c...@sdf.org writes: Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_. Adrian On 15 April 2013 09:55, Cy Schubert cy.schub...@komquats.com wrote: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message 8adc8f0961dd8f7972300837db7403ce.squir...@ma.sdf.org, c...@sdf.org writes: Ok, seems someone has taken the job. In message alpine.bsf.2.00.1304140946440.10...@wonkity.com, Warren Block writ es: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Sorry, I'm coming in late on this discussion. I'm willing to take it on as I've been planning on updating it for a while. Would a src committer like to take me on for mentorship? -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should be in the base system. Perhaps you can work on it as a port? Why do you want to work on something that people have been trying to remove since 2005? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8(B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
To my knowledge it is already off by default and you need these options to enable it options IPFILTER options IPFILTER_LOG so to those that wish to have it removed from base, if it has a maintainer whats the trouble? On Mon, Apr 15, 2013 at 2:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_with_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbFjtAAoJECXpabHZMqHOSFkIAK72iLtzb1py01/A+SbX8ejn hi5eh8ri6QQ2Kh4K96b/R5oHk5PoGNpc7xX7Kbp1wyJ2OrdNvAPnElwMDpPCjnRC rKPXiS25Km9D1e18E2pLB4iTweb/AOf87bGRz6skm3Rq0D4XOX9dwRndj1vqRxmH V/Rrdlzprx4EvDmgmfAfSZwGTGit6fVXqHHj5LtONURNKe4qAliVIdxB1vQFQBqB BnHF1gN7tIJVCrn+4yKSVsv6vqRSXp5LOIRBw2ooURKEkkKqVIapboEU+pGitN4g dbVZkoBol7V+LfqBBpsG7JH+OboUvdvWJ7hqeNtAV4YerBBBbePvx9D5iehmRUk= =/mAG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C done much with IPF while employed with Sun. Since then there has been some C development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. C I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C I did consider a port but given it would has to touch bits and pieces of C the source tree (/usr/src), a port would be messy and the decision was made C to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 20130415195544.gy76...@freebsd.org, Gleb Smirnoff writes: Cy, good news that you volunteered to work on this! On Mon, Apr 15, 2013 at 10:48:43AM -0700, Cy Schubert wrote: C The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't C done much with IPF while employed with Sun. Since then there has been some C development that is long overdue for HEAD. The problem is that v5.1.2 is under GPL. I'm afraid we should update to v4.1.34 only, and then stick to it. So the nearest TODO list is smth like: - update to v4.1.34 - cleanse old kernel APIs (timeout(9) at least) - fix VIMAGE - review open PRs (some might should be closed) - since we do not expect more imports, may be cleanse non-FreeBSD stuff from there? - maybe move it into sys/netpfil? Need to consult imp@ on that. License is very closed to BSD, but has some additions. A small step in the right direction is a good thing. I'll run the patches by you first. The existing license isn't that BSD-friendly either, which is why it lives in contrib/. I think the 5.1.X GPLv2 is about the same friendliness as Darren's IPF 4.1.X license. As long as it's not in GENERIC should be fine. A person can always load it anyway. C I'm not sure if I'd MFC it into 9 or not. This is up to you, but be adviced that head already differs from stable/9, for example network stack is entirely in network byte order. So merging would require a lot of attention and testing. C I did consider a port but given it would has to touch bits and pieces of C the source tree (/usr/src), a port would be messy and the decision was mad e C to work on importing it into base. Port isn't an option. IPFilter is too close to many kernel APIs, that can change quickly. Agreed. I looked at it a few months ago and determined that src is where it should be. (I put it aside, getting ACER WMI/ACPI working on my new Acer laptop was my priority at the time.) -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
The desire to remove it stems from the inability to give it adequate engineering service as the network stack evolves. Simply taking it out of a kernel config file doesn't address that problem at all. If it's going to stay in FreeBSD at all, it needs to be maintained. This could be set about a fair amount of stuff in FreeBSD, but IPFilter stands out since there's a high rate of needed change happening in the network stack, and it shouldn't be left to rot nor to be a stumbling block for those changes. Scott On Apr 15, 2013, at 12:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55、Cy Schubert cy.schub...@komquats.com のメッセージ: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8(B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentions from well meaning people. What is your timeline for getting it back into shape and re-integrating yourself into the committer community? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
It was pointed out to me that Darren Reed has changed licenses from his IP Filter license that's been in IPF since 2005 or so, when he joined Sun, to GPLv2 (probably when Darren left when Oracle took over Sun). Given that IPF already lives in src/contrib and src/sys/contrib due to the 2005 license change, would that be a problem? If it's OK then I'll maintain it in src. If not then a port is in order. Having said that, a port would be messy as IPF's own install scripts update src/sys/netinet, among other locations. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org In message d6ade9c6-868a-4524-a6d7-4eb88f9d6...@yahoo.com, Scott Long writes: The desire to remove it stems from the inability to give it adequate engineer ing service as the network stack evolves. Simply taking it out of a kernel confi g file doesn't address that problem at all. If it's going to stay in FreeBSD at all , it needs to be maintained. This could be set about a fair amount of stuff in Fr eeBSD, but IPFilter stands out since there's a high rate of needed change happening in the network stack, and it shouldn't be left to rot nor to be a stumbling bloc k for those changes. Scott On Apr 15, 2013, at 12:49 PM, Sam Fourman Jr. sfour...@gmail.com wrote: Thank you to those that have expressed interest in maintaining IP Filter.. My thoughts are, could we consider putting a option in the kernel config, and leaving it off by default for GENERIC? I think this is a acceptable compromise, considering some people wish for it to be removed. Sam Fourman Jr. On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert cy.schub...@komquats.comwrot e: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55ãCy Schubert cy.schub...@komquats.com ã®ã¡ãã»ã¼ã¸: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it should b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was mad e to work on importing it into base. Why do you want to work on something that people have been trying to remove s ince 2005? I and others have been using it in FreeBSD for over decade. For the longes t of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 15, 2013, at 1:27 PM, Cy Schubert cy.schub...@komquats.com wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). I would assume that the license change would be OK, especially since the other option is to remove it (or let it continue to rot and be an eyesore) but I'll defer to those like Gleb and Rui with a more vested interest in it. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 516c58ed.40...@freebsd.org, Jung-uk Kim writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_wi th_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) I'm always (or usually) one for more than fewer choices. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote: c However it would of been better if said person asked me as I already c offered to take it on but whatever. More manpower - the better. Why can't you work together? -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Mon, Apr 15, 2013 at 01:32:48PM -0600, Scott Long wrote: S Given that IPF already lives in src/contrib and src/sys/contrib, would the S change in License from Darren Reed's own not so BSD friendly IPF license to S GPLv2 be of concern. I recall there was a lot of concern over IPF's license S change at the time. (FreeBSD moved it to contrib while OpenBSD removed it S completely and wrote PF -- I'm not sure what NetBSD did). S S I would assume that the license change would be OK, especially since the other S option is to remove it (or let it continue to rot and be an eyesore) but I'll defer to those like S Gleb and Rui with a more vested interest in it. I'm not a licensing guru, so I can't tell whether GPL ipfilter can live in src/ and if it can, where should it be. So I expect someone else to comment on licensing. My personal, biased towards BSD, wish, is to import only the last BSD-licensed version, move it out of contrib to netpfil, remove zillions of compatibility (towards other OSes) code and just maintain it. Maintaining means fixing bugs and catching up on kernel changes. We can ask Darren whether we can switch the license to pure BSD. Since he himself switched the entire license to GPL, the insisting on the following clause seems strange, and expect he won't insist on it. The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied, in part or in whole, and put under another distribution licence [including the GNU Public Licence.] -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
In message 20130415212826.ga76...@freebsd.org, Gleb Smirnoff writes: On Mon, Apr 15, 2013 at 04:47:33PM -, c...@sdf.org wrote: c However it would of been better if said person asked me as I already c offered to take it on but whatever. Sorry, I didn't see your posting. I had a permissions issue on my gateway which caused the loss of a few emails (still sorting through the list of bounces). More manpower - the better. Why can't you work together? I don't mind working with others. I know there's more than enough to keep everyone busy. My main goal is to make sure IPF doesn't disappear nor go into disrepair and to make sure it's well maintained. Let's work together. -- Cheers, Cy Schubert cy.schub...@komquats.com FreeBSD UNIX: c...@freebsd.org Web: http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01、Scott Long scott4l...@yahoo.com のメッセージ: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Rui Paulo wrote: 2013/04/13 16:01、Scott Longscott4l...@yahoo.com のメッセージ: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html 1.1 ipftest PF rules can be checked with pfctl -n: -n Do not actually load rules, just parse them For example: pfctl -nvf /etc/pf.conf.tmp 3 Examples 3.1 Filtering ipf.conf and pf.conf has the same syntax for basic filtering rules, so you can use it on the right side to: block in on le0 proto tcp from 10.1.1.1/32 to any pass in proto tcp from 10.1.0.0/16 port = 23 to 10.2.0.0/16 flags A/A Miroslav Lachman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Rui Paulo wrote: On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Regards, -- Rui Paulo Wow boys, This conversation has gotten way off track. Looking for a maintainer for ipfilter is totally different than opening the dead subject of removing ipfilter from the system. Look at openbsd's pf, its been forked and is now freebsd maintained. New upstream versions of Ipfilter have always needed tweaking before it can be included in the base system. If your unsatisfied with the lack of bug fixes, then ask the author for special permission to create a fork if his license don't allow it now. The point is: ipfilter is part of FreeBSD and you are never going to remove it. Accept that fact. So look for alternate ways to address your concerns about ipfilter bug fixs getting applied and/or updating ipfilter to function with vimage or changes to the Freebsd network stack and kernel APIs. Finding a maintainer is the purpose of this post, and the solution to your concerns, so lets stay on subject, OK. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 14, 2013, at 7:20 AM, Joe fb...@a1poweruser.com wrote: Rui Paulo wrote: On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Regards, -- Rui Paulo Wow boys, This conversation has gotten way off track. Looking for a maintainer for ipfilter is totally different than opening the dead subject of removing ipfilter from the system. The project has been in search of a maintainer for ipfilter for many years. Gleb's most recent plea is just the latest round in this loose battle. Look at openbsd's pf, its been forked and is now freebsd maintained. New upstream versions of Ipfilter have always needed tweaking before it can be included in the base system. If your unsatisfied with the lack of bug fixes, then ask the author for special permission to create a fork if his license don't allow it now. The point is: ipfilter is part of FreeBSD and you are never going to remove it. Accept that fact. Negative, amigo. Without passionate interest in developing ipfilter, it's just a roadblock and an eyesore. Abandonware needs to be culled. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
I do not stand in any good stead to comment on this, but I have used IPFilter more extensively than PF when it comes to FreeBSD and packet manipulations. As a user, what I can say is this: 1. The only firewall that seems 'native' to FreeBSD is ipfw and I believe it works very well for some users who are able to adapt to it's syntax. 2. PF is being felt to be part of FreeBSD, but it too lags far behind OpenBSD implementation - almost like it's unmaintained. There has been debates about this which were never concluded. Most of you will agree with me on this. IPFilter is obviously NOT going to make it in 10.x and never releases because of those changes which have led to this thread/debate. So my take is there is a very simple answer/solution to this debate, which conforms to the K.I.S.S principle: 3. There is NO need to look for a maintainer. Simply DEPRECATE IPFilter from 10.x and put out a BIG Notice/Billboard somewhere where whoever needs to run FreeBSD because of IPFilter will find it. I doubt there is such a person anywhere because there are firewall implementations out there that can address this. Just put it out somewhere that IPFilter is NOT AVAILABLE on FreeBSD 10.x upwards and go ahead and remove it from the system. Nobody will complain. If anyone does, tell them that IPFilter is supported on FreeBSD upto 8.x (or is it 9.x? On my 9.x systems I use PF). 4. It's pretty easy for a newcomer to adopt and adapt to a firewall that is properly supported. Newcomers don't have much choice anyway. They decide to go with a system after finding out that it meets their requirements. Let's remember that there are other Unix variants out there with Firewall implementations too. I hope this helps you big boys settle this debate. On 14 April 2013 16:25, Scott Long sco...@samsco.org wrote: On Apr 14, 2013, at 7:20 AM, Joe fb...@a1poweruser.com wrote: Rui Paulo wrote: On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Regards, -- Rui Paulo Wow boys, This conversation has gotten way off track. Looking for a maintainer for ipfilter is totally different than opening the dead subject of removing ipfilter from the system. The project has been in search of a maintainer
Re: ipfilter(4) needs maintainer
On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Is it possible to move ipfilter into a port? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
It's NOT possible, because someone has to handle the kernel hooks, which is the contention. Mark as deprecated, remove the HandBook section, but only for 10.x On 14 April 2013 18:48, Warren Block wbl...@wonkity.com wrote: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~**rpaulo/ipf-deprecation/**article.htmlhttp://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~**crees/patches/remove-ipf.diffhttp://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Is it possible to move ipfilter into a port? __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org freebsd-current-unsubscr...@freebsd.org -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 I can't hear you -- I'm using the scrambler. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 14 April 2013 16:48, Warren Block wbl...@wonkity.com wrote: On Sun, 14 Apr 2013, Chris Rees wrote: On 14 April 2013 01:41, Rui Paulo rpa...@felyko.com wrote: 2013/04/13 16:01?Scott Long scott4l...@yahoo.com ??: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html If you're really serious about deprecating ipf, we absolutely have to remove instructions for it from the Handbook as soon as possible; every time a new user comes across instructions you're going to have yet another annoyed party. http://www.bayofrum.net/~crees/patches/remove-ipf.diff This should probably be done like we did for CVS for ports. Mark it as deprecated, then remove the Handbook section once the code is removed. Is it possible to move ipfilter into a port? There isn't really a point in moving it to a port, because it still needs the same level of commitment to make it work; many kernel/net changes cause it to break, and Rui has already pointed out that no-one knows if it even works at all on HEAD. Moving kernel stuff like this to ports isn't really an option :/ Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Hi, I will see what I can do when I come back from work. PF is based on ipfilter so having 3 is indeed a bit much. Chris On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Regards, Gary ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re[2]: ipfilter(4) needs maintainer
--- Original message --- From: Gary Palmer gpal...@freebsd.org Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Odhiambo Washington odhia...@gmail.com writes: 2. PF is being felt to be part of FreeBSD, but it too lags far behind OpenBSD implementation - almost like it's unmaintained. There has been debates about this which were never concluded. Most of you will agree with me on this. FreeBSD's version of pf is actively maintained by Gleb. IIUC, the reason why it lags behind OpenBSD is partly that OpenBSD keep making changes to the filter syntax which break existing rulesets, and partly that FreeBSD's and OpenBSD's network stacks and locking primitives are so different that we can't easily plug OpenBSD's code into our kernel without significant performance issues. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
wishmaster wrote: --- Original message --- From: Gary Palmer gpal...@freebsd.org Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, For non-nat ipfw is still superior in every way, numbered rules (think: scripts), dummynet, much faster than pf, syntax is a lot nicer and predictable... Does anyone even use ipf? it doesn't even work on Linux anymore, junk it and keep pf+ipfw, job done. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
A migration *guide*, yes. Tools to convert one syntax to another: no. ok, so what is the brief migraiton advice? The Handbook mentions PF and IPFW. I gather from your mails that PF is the recommended choice. Is that so? If I choose PF, can I just follow the Handbook PF section, and once it's working, remove all IPF related kernel options and config files? Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Re[2]: ipfilter(4) needs maintainer
I agree with this, we dont need 3 packet filters, it seems like we should focus the people interested in working on packet filters,toward the packet filter most actively maintained, the fact that there is 3 in base is overkill, Just depreciate it and be done with it a new email, asking for help to bring pf closer to OpenBSD, is more of a productive conversation. On Sun, Apr 14, 2013 at 1:30 PM, wishmaster artem...@ukr.net wrote: --- Original message --- From: Gary Palmer gpal...@freebsd.org Date: 14 April 2013, 19:06:59 On Sun, Apr 14, 2013 at 09:48:33AM -0600, Warren Block wrote: Is it possible to move ipfilter into a port? That may work short term, but the ENOMAINTAINER problem will quickly creep up again as kernel APIs change. If the author has lost interest in maintaining the FreeBSD port of ipfilter then unless someone steps forward to carry on the work, I don't see much of a future for ipfilter in FreeBSD Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. Cheers, ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-unsubscr...@freebsd.org -- Sam Fourman Jr. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 2013/04/14, at 12:11, Anton Shterenlikht me...@bris.ac.uk wrote: A migration *guide*, yes. Tools to convert one syntax to another: no. ok, so what is the brief migraiton advice? It's still being written. The Handbook mentions PF and IPFW. I gather from your mails that PF is the recommended choice. Is that so? Yes, because of how much easier it is to convert from ipf to pf version ipf to ipfw. If I choose PF, can I just follow the Handbook PF section, and once it's working, remove all IPF related kernel options and config files? Yes, that will be the plan. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Sunday April 14 2013 19:30:22 wishmaster wrote: Do we honestly need three packet filters? Yes! This is the most clever thought in this thread. Why we need 3 firewalls? Two packet filters it's excess too. We have two packet filters: one with excellent syntax and functionality but with outdated bandwidth control mechanism (aka ALTQ); another - with nice traffic shaper/prioritization (dummynet)/classification (diffused) but with complicated implementation in not trivial tasks. May be the next step will be discussion about one packet filter in the system?.. ... and as far as I can tell none of them is currently usable on an IPv6-only FreeBSD (like protecting a host with sshguard), none of them supports stateful NAT64, nor IPv6 prefix translation :( Mark ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 14, 2013, at 5:25 PM, Mark Martinec mark.martinec+free...@ijs.si wrote: ... and as far as I can tell none of them is currently usable on an IPv6-only FreeBSD (like protecting a host with sshguard), none of them supports stateful NAT64, nor IPv6 prefix translation :( pfSense 2.1 has a lot of work to make this happen for pf, so it should be possible for pf with some attention. Jim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. ++ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 13, 2013, at 12:33 AM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. You target audience for this isn't people who track CURRENT, it's people who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Please believe me that no matter how trivial you think the switch is, a migration guide still needs to be written. Scott \ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Sat, Apr 13, 2013 at 3:03 PM, Scott Long sco...@samsco.org wrote: On Apr 13, 2013, at 12:33 AM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/12, at 22:31, Scott Long sco...@samsco.org wrote: On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. I agree with the deprecation path, but given the amount of changes that happened in the last 6 months, I'm not even sure ipfilter is working fine in FreeBSD CURRENT, but I haven't tested it. You target audience for this isn't people who track CURRENT, it's people who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Please believe me that no matter how trivial you think the switch is, a migration guide still needs to be written. Scott \ The migration guide is best written by the current users of ipfilter, not those who have no interest in doing so because their interests are completely elsewhere. Please don't try to defer to an authority that does not exist here. -Kimmo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
Scott, On Fri, Apr 12, 2013 at 11:31:09PM -0600, Scott Long wrote: S One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. S S So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. The task to write a migration guide is already a task for maintainer, and the thread is to search one. If lack of migration guide doesn't allow us to remove in 10.x cycle, I doubt the guide will appear in 11.x cycle, 12.x, etc. So we will live with ipfilter forever. What I can do, is to resend email to the stable@ list. Also, I can add the deprecation WARNING to stable/9 unless we find maintainer prior to 9.2 branching. -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 2013/04/13, at 5:03, Scott Long sco...@samsco.org wrote: You target audience for this isn't people who track CURRENT, it's people who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. Yes, I'm aware of that, but the problem remains. If ipfilter is broken or gets broken because of the networking stack changes, we'll have to fix it to keep the deprecation path going... So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Please believe me that no matter how trivial you think the switch is, a migration guide still needs to be written. A migration *guide*, yes. Tools to convert one syntax to another: no. Regards, -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 13, 2013, at 11:43 AM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/13, at 5:03, Scott Long sco...@samsco.org wrote: You target audience for this isn't people who track CURRENT, it's people who are on 7, 8, or 9 and looking to update to 10.x sometime in the future. Yes, I'm aware of that, but the problem remains. If ipfilter is broken or gets broken because of the networking stack changes, we'll have to fix it to keep the deprecation path going... Welcome to the challenges of maintaining a whole OS :-) So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. It's not very difficult to switch an ipf.conf/ipnat.conf to a pf.conf, but I'm not sure automated tools exist. I'm also not convinced we need to write them and I think the issue can be deal with by writing a bunch of examples on how to do it manually. Then we can give people 1y to switch. Please believe me that no matter how trivial you think the switch is, a migration guide still needs to be written. A migration *guide*, yes. Tools to convert one syntax to another: no. Ok, so in response to this and to Glebs email, lets rephrase the call for help into a call for someone with ipfilter experience to help write a migration guide. Like I said, this isn't about migrating from 10-current to 10-current prime, it about migrating from 7/8/9 where up ipfilter does work. Maybe look for old openbsd docs and mailing list items from when they did their forced migration. Maybe fish for help by announcing the deprecation and removal schedule and hook whomever complains into helping instead. Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
2013/04/13 16:01、Scott Long scott4l...@yahoo.com のメッセージ: Maybe something else, but whatever it is, it should be done. If you and Gleb don't want to do this, I will. I already started writing a guide. See here for a very incomplete version: http://people.freebsd.org/~rpaulo/ipf-deprecation/article.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. -- Rui Paulo ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
On Apr 12, 2013, at 7:43 PM, Rui Paulo rpa...@freebsd.org wrote: On 2013/04/11, at 13:18, Gleb Smirnoff gleb...@freebsd.org wrote: Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. This has been discussed in the past. Every time someone came up and said I'm still using ipfilter! and the idea to remove it dies with it. I've been saying we should remove it for 4 years now. Not only it's outdated but it also doesn't not fit well in the FreeBSD roadmap. Then there's the question of maintainability. We gave the author a commit bit so that he could maintain it. That doesn't happen anymore and it sounds like he has since moved away from FreeBSD. I cannot find any reason to burden another FreeBSD developer with maintaining ipfilter. One thing that FreeBSD is bad about (and this really applies to many open source projects) when deprecating something is that the developer and release engineering groups rarely provide adequate, if any, tools to help users transition and cope with the deprecation. The fear of deprecation can be largely overcome by giving these users a clear and comprehensive path forward. Just announcing ipfilter is going away. EOM is inadequate and leads to completely justified complaints from users. So with that said, would it be possible to write some tutorials on how to migrate an ipfilter installation to pf? Maybe some mechanical syntax docs accompanied by a few case studies? Is it possible for a script to automate some of the common mechanical changes? Also essential is a clear document on what goes away with ipfilter and what is gained with pf. Once those tools are written, I suggest announcing that ipfilter is available but deprecated/unsupported in FreeBSD 10, and will be removed from FreeBSD 11. Certain people will still pitch a fit about it departing, but if the tools are there to help the common users, you'll be successful in winning mindshare and general support. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ipfilter(4) needs maintainer
Hello, here is brief status on ipfilter(4) packet filtering facility, written by Darren Reed, that is shipped with FreeBSD kernel. o The version of the software is v4.1.28. The license is BSD, .. erm the license is very close to BSD, but with some additions, most notable is: The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied, in part or in whole, and put under another distribution licence [including the GNU Public Licence.] The version we have is v4.1.28, it was released 16 October 2007. Suprisingly, the author has switched ipfilter license to GPL. :) The last release under BSD license was v4.1.34, released 11 MArch 2010. The author is now working on v5, licensed under GPL. o There are 29 open bug reports tagged with [ipfilter] in GNATS. Actually this is not a lot, since there 95 closed PRs with this tag. Anyway, these 29 need care. o Apart from filed PRs, there is knowledge that ipfilter(4) isn't compatible with VIMAGE. o ipfilter(4) uses old outdated kernel APIs that we want to cleanse away from the kernel. And we don't have responsive users, willing to test patches. For example, this request for testing wasn't answered by anyone: http://lists.freebsd.org/pipermail/freebsd-net/2012-August/033139.html Due to license change and inactivity of the author in our tree and GNATS, there is clear evidence that author do not plan to update or take care of ipfilter in our source tree. Thus, ipfilter(4) should be assigned status of our code, that should be taken care of ourselves. This means it needs maintainer, and this email is a call for one. Any takers? Lack of maintainer in a near future would lead to bitrot due to changes in other areas of network stack, kernel APIs, etc. This already happens, many changes during 10.0-CURRENT cycle were only compile tested wrt ipfilter. If we fail to find maintainer, then a correct decision would be to remove ipfilter(4) from the base system before 10.0-RELEASE. P.S. The project homepage: http://coombs.anu.edu.au/~avalon/ -- Totus tuus, Glebius. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
