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: DTrace of radeonkms on 9.1
On Mon, 1 Apr 2013 14:36:52 +0200 Alexander Leidinger alexan...@leidinger.net wrote: On Wed, 27 Mar 2013 18:07:14 -0400 J.R. Oldroyd f...@opal.com wrote: Is there any known magic involved in getting DTrace to do its thing on 9.1-release? I am trying to use it to debug a memory leak problem with the radeonkms driver under 9.x. Can you check if you have the same dtrace-problem with -current? I would expect that 9.1 already has some dtrace-fixes regarding new probes in run-time loaded modules, this is just to verify this assumption. Assuming there is some kind of dead-lock in this module-load interaction with dtrace, you could modify the radeonkms module to do it's initialization magic once a sysctl is set to 1, instead of doing this magic at module-load time. This way you could load the module, start the dtrace script and then issue the magic sysctl. Bye, Alexander. Thanks for the suggestion. The problem I was hoping to use DTrace to debug turned out to be an incompletely back-ported vm_alloc_page_contig() function. This was discovered using careful code analysis. Having improved the back-port of this function, the radeonkms driver is now running fine on 9.1-release. The need for DTtrace has therefore gone away for the time being. That said, the back-port of the VM function is not 100%, yet. I've had to put this on hold due to other commitments, but when I get back to this, I probably need to talk to our VM experts to get a list of commits that will be needed to properly merge that function into 9-stable. -jr signature.asc Description: PGP signature
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: ipv6_addrs_IF aliases in rc.conf(5)
I would also like to see this committed. I started on my own patch about 4 months ago but got sidetracked. This would be very, very valuable to the sysadmins at my workplace. ___ 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: Problems with axe(4) and checksum offloading
On Sat, Apr 13, 2013 at 03:25:11PM +0200, Spil Oss wrote: Hi YongHyeon, Will post on freebsd-ipfw@ as well... Does your engineering sample function normally with rxcsum/txcsum disabled? Yes. Kind regards, Spil. On Thu, Apr 11, 2013 at 3:11 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Wed, Apr 10, 2013 at 07:48:00PM +0200, Spil Oss wrote: Hi YongHyeon, With the original unmodified .ko... ifconfig output as requested at bottom Static IP-configuration does not make a difference with the ipfw behaviour. ipfw ruleset (based on /etc/rc.firewall simple ruleset) 00010 allow ip from any to me dst-port 22 recv ue0 00010 allow tcp from me 22 to any xmit ue0 00100 allow ip from any to any via lo0 00200 deny ip from any to 127.0.0.0/8 00300 deny ip from 127.0.0.0/8 to any 00400 deny ip from any to ::1 00500 deny ip from ::1 to any 00600 allow ipv6-icmp from :: to ff02::/16 00700 allow ipv6-icmp from fe80::/10 to fe80::/10 00800 allow ipv6-icmp from fe80::/10 to ff02::/16 00900 allow ipv6-icmp from any to any ip6 icmp6types 1 01000 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136 01100 deny ip from 10.16.2.1 to any in via ue0 01200 deny ip from 172.17.2.111 to any in via re0 01300 deny ip from any to 10.0.0.0/8 via ue0 01500 deny ip from any to 192.168.0.0/16 via ue0 01600 deny ip from any to 0.0.0.0/8 via ue0 01700 deny ip from any to 169.254.0.0/16 via ue0 01800 deny ip from any to 192.0.2.0/24 via ue0 01900 deny ip from any to 224.0.0.0/4 via ue0 02000 deny ip from any to 240.0.0.0/4 via ue0 02100 divert 8668 ip4 from any to any via ue0 02200 deny ip from 10.0.0.0/8 to any via ue0 02400 deny ip from 192.168.0.0/16 to any via ue0 02500 deny ip from 0.0.0.0/8 to any via ue0 02600 deny ip from 169.254.0.0/16 to any via ue0 02700 deny ip from 192.0.2.0/24 to any via ue0 02800 deny ip from 224.0.0.0/4 to any via ue0 02900 deny ip from 240.0.0.0/4 to any via ue0 03000 allow tcp from any to any established 03100 allow ip from any to any frag 03200 allow tcp from any to me dst-port 22 setup 03300 allow tcp from any to me dst-port 25 setup 03400 allow tcp from any to me dst-port 465 setup 03500 allow tcp from any to me dst-port 587 setup 03600 allow tcp from any to me dst-port 80 setup 03700 allow tcp from any to me dst-port 443 setup 03800 deny log logamount 5 ip4 from any to any in via ue0 setup proto tcp 03900 allow tcp from any to any setup 04000 allow udp from me to any dst-port 53 keep-state 04100 allow udp from me to any dst-port 123 keep-state 04200 allow ip from any to any dst-port 22 recv ue0 65535 deny ip from any to any If I remove rule 10 it will NOT work with ue0, the ruleset without rule 10 DOES work with re0. Found an older PR about em or fxp having trouble with natd when rxcsum/txcsum was enabled, that is why I started fiddling with rxcsum/txcsum and found that the NIC would be unusable without rxcsum/txcsum enabled. If only I could find that PR now (kern/170081???)... Was fixed in base... If you don't use ipfw/natd, checksum offloading of axe(4) work? If yes, you'd get better answer from ipfw mailing list. Some other post reported fake AX88772A chips (32-pin packaging vs 64 in the original) on cheap USB NICs so I checked the hardware as well and could not AX88772A does not support TX/RX checksum offloading. see an issue (64-pin packaging). # ifconfig ue0 ue0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active # dhclient ue0 DHCPDISCOVER on ue0 to 255.255.255.255 port 67 interval 4 DHCPOFFER from 172.17.2.1 DHCPREQUEST on ue0 to 255.255.255.255 port 67 DHCPACK from 172.17.2.1 bound to 172.17.2.111 -- renewal in 43200 seconds. # ifconfig ue0 ue0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=8000bRXCSUM,TXCSUM,VLAN_MTU,LINKSTATE ether 00:60:6e:42:5b:53 inet6 fe80::260:6eff:fe42:5b53%ue0 prefixlen 64 scopeid 0x7 inet 172.17.2.111 netmask 0xff00 broadcast 172.17.2.255 nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (100baseTX full-duplex) status: active I can see TX/RX checksum offloading is active and it successfully got a IP address via DHCP. On Wed, Apr 10, 2013 at 4:14 AM, YongHyeon PYUN pyu...@gmail.com wrote: On Mon, Apr 08, 2013 at 08:45:58PM +0200, Spil Oss wrote: Hi YongHyeon, output from verbose boot ugen3.2: vendor 0x0b95 at usbus3 axe0: vendor 0x0b95 product 0x772b, rev 2.00/0.01, addr 2 on
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: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013
On 4/11/13 5:18 PM, Andre Oppermann wrote: Excuse me for being slightly spammy but I've received feedback that we haven't spread this information widely enough outside the inner circles and interested people missed the announcement. EuroBSDcon 2013: September 28-29 in Malta = EuroBSDcon is the European technical conference for users and developers of BSD-based systems. The conference will take place Saturday and Sunday 28-29 September at the Hilton Conference Centre in St. Julian's, Malta (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, talks on Saturday and Sunday). [Yes, very nice weather at that time of year, about 26/19C sunny no rain, Social event on Saturday evening is going to be a sunset beach BBQ] The web page suggest I bring my wife AND my spouse.. what if they don't know about each other? ___ 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
