From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 00:41:39 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0927FE46; Sun, 14 Apr 2013 00:41:39 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id E260A1A9B; Sun, 14 Apr 2013 00:41:38 +0000 (UTC) Received: from [10.249.237.150] (mobile-166-137-186-177.mycingular.net [166.137.186.177]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id AACEE3981E; Sat, 13 Apr 2013 17:41:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1365900098; bh=dsZ+/nqmoTgXE5nDl3DmzzTldHUxbn6A8eFlPszgJbw=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=jzodYpsG0p2kVReRg59fWF3+koMiX2Ki3swgyaDDAiIgjql1gKwN1I3B1suSIPSf+ QX7L3Ph05M0uXbhxd8euqj/cVzCAKC0ywoiR+ZvY2j1CrfHpUhEE7TDrlUsVh+Mxj2 bH2TKsBOBO3t686PYYuetMsPboF2R4A1YAh3LjWE= References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> Mime-Version: 1.0 (1.0) In-Reply-To: <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> Message-Id: X-Mailer: iPhone Mail (10B329) From: Rui Paulo Subject: Re: ipfilter(4) needs maintainer Date: Sat, 13 Apr 2013 17:41:35 -0700 To: Scott Long X-Mailman-Approved-At: Sun, 14 Apr 2013 01:48:23 +0000 Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Scott Long , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 00:41:39 -0000 2013/04/13 16:01=1B$B!"=1B(BScott Long =1B$B$N%a%C%;!= <%8=1B(B: > Maybe something else, but whatever it is, it should be done. If you and G= leb 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= From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 08:40:36 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D1333D0F; Sun, 14 Apr 2013 08:40:36 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 9AF4C74B; Sun, 14 Apr 2013 08:40:36 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so4740453ieb.17 for ; Sun, 14 Apr 2013 01:40:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=j6CYPWbmUIJ9tIyfIuVujfLw+s4CdoYucG5iMRLWAkU=; b=xEyI/CSe7QCYcOOlpXLUJMF+mVQmOxZqxJ4GHkENPonmrr7ylt0F2AW4N6DynUmPTE rLrJExSbZ/3Iq97MDTyLeYvm3FGKEAPaNoGdLI6Mo4wQj3wH72OWiBK3SqCSwnNK3Bdx dbVgMka00FhSZu1gT2Sw5roJa+Q64OCNyaREzpGsh7dpPjx76Iu3DeWFJpu36EqfUi/y z4yAGePF99HwGkZOjuO2FopiHUngxtdDpFXc6c5gIYUqPAA/Bz8XQBXCxEGGGuBKWQUQ wgAttrf/sOvtpM+2L6IQJSMe2sf0mpk7LUjsyE9FDzSlunMJ8zSUOETvBYpWlqpPUWCp Rmyw== X-Received: by 10.50.13.175 with SMTP id i15mr2922926igc.75.1365928836044; Sun, 14 Apr 2013 01:40:36 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Sun, 14 Apr 2013 01:40:04 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Chris Rees Date: Sun, 14 Apr 2013 09:40:04 +0100 X-Google-Sender-Auth: ihKLwSBt2G9ZOR1EEAWe6oNhbzg Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Rui Paulo Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: Scott Long , "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 08:40:36 -0000 On 14 April 2013 01:41, Rui Paulo wrote: > 2013/04/13 16:01$B!"(BScott Long $B$N%a%C%;!<%8(B: > >> 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 09:54:48 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1C03AC01; Sun, 14 Apr 2013 09:54:48 +0000 (UTC) (envelope-from 000.fbsd@quip.cz) Received: from elsa.codelab.cz (elsa.codelab.cz [94.124.105.4]) by mx1.freebsd.org (Postfix) with ESMTP id D07748DB; Sun, 14 Apr 2013 09:54:47 +0000 (UTC) Received: from elsa.codelab.cz (localhost [127.0.0.1]) by elsa.codelab.cz (Postfix) with ESMTP id C14A728423; Sun, 14 Apr 2013 11:54:39 +0200 (CEST) Received: from [192.168.1.2] (ip-89-177-49-222.net.upcbroadband.cz [89.177.49.222]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by elsa.codelab.cz (Postfix) with ESMTPSA id AC2EC28429; Sun, 14 Apr 2013 11:54:38 +0200 (CEST) Message-ID: <516A7CDD.7080201@quip.cz> Date: Sun, 14 Apr 2013 11:54:37 +0200 From: Miroslav Lachman <000.fbsd@quip.cz> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.19) Gecko/20110420 Lightning/1.0b1 SeaMonkey/2.0.14 MIME-Version: 1.0 To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 09:54:48 -0000 Rui Paulo wrote: > 2013/04/13 16:01$B!"(BScott Long $B$N%a%C%;!<%8(B: > >> 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 12:48:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A410FAAA for ; Sun, 14 Apr 2013 12:48:51 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (unknown [IPv6:2001:470:1f09:14c0::2]) by mx1.freebsd.org (Postfix) with ESMTP id 5A282E56 for ; Sun, 14 Apr 2013 12:48:50 +0000 (UTC) Received: from [192.168.248.33] ([192.168.248.33]) by elf.hq.norma.perm.ru (8.14.5/8.14.5) with ESMTP id r3ECmiEq028542 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 14 Apr 2013 18:48:46 +0600 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <516AA5AA.1070003@norma.perm.ru> Date: Sun, 14 Apr 2013 18:48:42 +0600 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: kern/165903: mbuf leak References: <201304111942.r3BJg1Eh085644@freefall.freebsd.org> <20130412115443.GU76816@glebius.int.ru> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (elf.hq.norma.perm.ru [192.168.3.10]); Sun, 14 Apr 2013 18:48:47 +0600 (YEKT) X-Spam-Status: No hits=-101.0 bayes=0.5 testhits ALL_TRUSTED=-1, USER_IN_WHITELIST=-100 autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on elf.hq.norma.perm.ru X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 12:48:51 -0000 Hi. On 12.04.2013 20:13, Olivier Cochard-Labbé wrote: > On Fri, Apr 12, 2013 at 1:54 PM, Gleb Smirnoff wrote: >> On Fri, Apr 12, 2013 at 01:45:51PM +0200, Olivier Cochard-Labb? wrote: >> O> PR closed too soon ? >> >> It isn't closed, it is in patched state. This means that problem >> is considered solve in the head branch, but not in any stable branch. > Ok, thanks for this clarification ! > > More information of my mbuf leak problem now: > > I've got a firewall (FreeBSD 9.0, nanobsd with pf+pfsync, no tunning) in my lab. > Why 9.0 ? Upgrade at least to 9.1-PRERELEASE. 9.0 just doesn't fit to production. Besides mbuf leak - ipsec is also broken in 9.0. Eugene. From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 13:20:06 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD8FC21F; Sun, 14 Apr 2013 13:20:06 +0000 (UTC) (envelope-from fbsd8@a1poweruser.com) Received: from mail-03.name-services.com (mail-03.name-services.com [69.64.155.195]) by mx1.freebsd.org (Postfix) with ESMTP id 62878F20; Sun, 14 Apr 2013 13:20:04 +0000 (UTC) Received: from [10.0.10.1] ([173.88.202.176]) by mail-03.name-services.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 14 Apr 2013 06:20:05 -0700 Message-ID: <516AAD01.1090201@a1poweruser.com> Date: Sun, 14 Apr 2013 09:20:01 -0400 From: Joe User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> In-Reply-To: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Apr 2013 13:20:05.0164 (UTC) FILETIME=[C706F6C0:01CE3912] X-Sender: fbsd8@a1poweruser.com X-Authenticated-Sender: fbsd8@a1poweruser.com X-EchoSenderHash: [fbsd8]-[a1poweruser*com] Cc: Scott Long , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:20:06 -0000 Rui Paulo wrote: > On 2013/04/12, at 22:31, Scott Long wrote: > >> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >> >>> On 2013/04/11, at 13:18, Gleb Smirnoff 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. From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 13:26:00 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0AA583E4; Sun, 14 Apr 2013 13:26:00 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id C0F23F5E; Sun, 14 Apr 2013 13:25:59 +0000 (UTC) Received: from [127.0.0.1] (Scott4long@pooker.samsco.org [168.103.85.57]) (authenticated bits=0) by pooker.samsco.org (8.14.5/8.14.5) with ESMTP id r3EDPn9K002035; Sun, 14 Apr 2013 07:25:49 -0600 (MDT) (envelope-from scottl@samsco.org) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <516AAD01.1090201@a1poweruser.com> Date: Sun, 14 Apr 2013 07:25:49 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> To: Joe X-Mailer: Apple Mail (2.1503) X-Spam-Status: No, score=-50.0 required=3.8 tests=ALL_TRUSTED, T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on pooker.samsco.org Cc: Rui Paulo , current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:26:00 -0000 On Apr 14, 2013, at 7:20 AM, Joe wrote: > Rui Paulo wrote: >> On 2013/04/12, at 22:31, Scott Long wrote: >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: >>>=20 >>>> On 2013/04/11, at 13:18, Gleb Smirnoff wrote: >>>>=20 >>>>> 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. >>>>=20 >>> 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 >=20 > 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. >=20 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. >=20 > The point is: ipfilter is part of FreeBSD and you are never going to = remove it. Accept that fact. >=20 Negative, amigo. Without passionate interest in developing ipfilter, = it's just a roadblock and an eyesore. Abandonware needs to be culled. Scott From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 13:49:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C26C639; Sun, 14 Apr 2013 13:49:20 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) by mx1.freebsd.org (Postfix) with ESMTP id 200D4FCD; Sun, 14 Apr 2013 13:49:18 +0000 (UTC) Received: by mail-la0-f47.google.com with SMTP id eh20so2591374lab.6 for ; Sun, 14 Apr 2013 06:49:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=yGHs6ot0jCTDCIITcy6xcXi3uFPB7IiAlnkfkUHOXRw=; b=CoYySB/ziHTaPj8aJogTg5CguUZjO/gqbnCpQv9MNniz6NQaH2GkjFrSnGDz+5DNhV 5MQOLZbf1p17tKduly7YT3NnXSG9i8u67ceYipLdTrke1lk/3mG2+OEqDo7860RXo3kZ PhyRyfUuZPLJ8ySrdnEWpI+C5Sesen7+nvwYgO3DxeRKR6tzAECamQwfJqI+xwwd+uzc GMlrUjdYgMdG41zcjoZDGQunILmypn9eqPUuhJxQPXoHs3cTVaBVWcgtO93upVVG4Wkb vsW1hXZ4h35zdTZbUcLDriDglJJ1sbp8TtBheST1N8F+pQuGAFNXQTphLCf7xNVSWnqr ldlA== X-Received: by 10.152.135.205 with SMTP id pu13mr4693876lab.48.1365947357996; Sun, 14 Apr 2013 06:49:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.60.196 with HTTP; Sun, 14 Apr 2013 06:48:36 -0700 (PDT) In-Reply-To: <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> From: Odhiambo Washington Date: Sun, 14 Apr 2013 16:48:36 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Scott Long Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: net@freebsd.org, Joe , Rui Paulo , "freebsd-current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 13:49:20 -0000 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 wrote: > > On Apr 14, 2013, at 7:20 AM, Joe wrote: > > > Rui Paulo wrote: > >> On 2013/04/12, at 22:31, Scott Long wrote: > >>> On Apr 12, 2013, at 7:43 PM, Rui Paulo wrote: > >>> > >>>> On 2013/04/11, at 13:18, Gleb Smirnoff 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-unsubscribe@freebsd.org" > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 15:48:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E456BAAB; Sun, 14 Apr 2013 15:48:41 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 7562C364; Sun, 14 Apr 2013 15:48:41 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r3EFmXTe010600; Sun, 14 Apr 2013 09:48:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r3EFmXn2010597; Sun, 14 Apr 2013 09:48:33 -0600 (MDT) (envelope-from wblock@wonkity.com) Date: Sun, 14 Apr 2013 09:48:33 -0600 (MDT) From: Warren Block To: Chris Rees Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message-ID: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Sun, 14 Apr 2013 09:48:33 -0600 (MDT) Cc: "net@freebsd.org" , Scott Long , Rui Paulo , "current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:48:42 -0000 On Sun, 14 Apr 2013, Chris Rees wrote: > On 14 April 2013 01:41, Rui Paulo wrote: >> 2013/04/13 16:01?Scott Long ??????: >> >>> 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? From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 15:52:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25BF7CC1; Sun, 14 Apr 2013 15:52:30 +0000 (UTC) (envelope-from odhiambo@gmail.com) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 40773397; Sun, 14 Apr 2013 15:52:29 +0000 (UTC) Received: by mail-la0-f41.google.com with SMTP id er20so3730908lab.28 for ; Sun, 14 Apr 2013 08:52:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xm7wVX3Jbkg0iGoCFAfLmc0uDn94rPvxjXPXNJMdqKM=; b=WecU7kMSxnX+lrUOIJ50t6OnUMg4UhLhMPy9W/jF3ZQReOA8lJj5sQR0KlXoUQmmwW rDgmGwWf/wysfHiOc5uwteiQPYJqyQvCoUUlkK82GjAHiXhLjJXoBeUGnU5cQogLu3q/ XXoBO2dB4TammDUYrlfIcDD0hnaY6Jjmnk1k5sIsPRCRiCIKVs3DRX/Wod1UbnOpAi8p npt+sbR2kInvRsXOseNLpYY7W1H3RBFYLuXtHtuDRVo8zn6ZYQLtOkMFhEA17y4vQKR8 eR5AB4CZnUAbIGFgTYjJHh65GlM9K6OrXDJOoS4FcVgJGpvxvRtI696ok6u2WzXQpbwZ 48xA== X-Received: by 10.112.168.5 with SMTP id zs5mr4649761lbb.66.1365954748052; Sun, 14 Apr 2013 08:52:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.60.196 with HTTP; Sun, 14 Apr 2013 08:51:47 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Odhiambo Washington Date: Sun, 14 Apr 2013 18:51:47 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:52:30 -0000 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 wrote: > On Sun, 14 Apr 2013, Chris Rees wrote: > > On 14 April 2013 01:41, Rui Paulo wrote: >> >>> 2013/04/13 16:01?Scott Long ??????: >>> >>> >>> 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-unsubscribe@** > freebsd.org " > -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254733744121/+254722743223 "I can't hear you -- I'm using the scrambler." From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 15:53:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 96984E64; Sun, 14 Apr 2013 15:53:05 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by mx1.freebsd.org (Postfix) with ESMTP id 5FB7E3DB; Sun, 14 Apr 2013 15:53:05 +0000 (UTC) Received: by mail-ie0-f171.google.com with SMTP id e14so4963060iej.2 for ; Sun, 14 Apr 2013 08:53:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=QVz0sLjFxVr5CRAkLAvgVSpFsn7WfVIkm1lqrVKRjyQ=; b=p4qoapX3FlDQhtQEB6/pKURj4O/u0svwtyLzp/Bf+OmSNYiiabVRmeM/i3UUUL+EzN PzS10xaeMXrtOgtSrgBjk9UobXMx8EGoe1cLai8Xh+qAY5oXaNP079hkH/UFejvfDTrx 4AfEbz0CUX9kyCr9ZXzh6xVmt02VCFzOWeIXMw479wRd7UmLvb3Zom2/PFDtTrcnhgaV ENzeJfwCk3Bd5QwzI/0o6wqIcK+L3Asn//flLHF12oUP5pSLaErL4Rd2+p8vi6rGamwu TdBLohoPKglup8mOPpeHcgW2bVTIvhF4uLk8JvieGajtFZpLhTXXIN2gbJmA+LOTBDCq tinw== X-Received: by 10.50.197.170 with SMTP id iv10mr3254220igc.62.1365954785041; Sun, 14 Apr 2013 08:53:05 -0700 (PDT) MIME-Version: 1.0 Sender: utisoft@gmail.com Received: by 10.64.58.52 with HTTP; Sun, 14 Apr 2013 08:52:34 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> From: Chris Rees Date: Sun, 14 Apr 2013 16:52:34 +0100 X-Google-Sender-Auth: VrhDYlCmWDVtZ2W7G8E7ed42Ibw Message-ID: Subject: Re: ipfilter(4) needs maintainer To: Warren Block Content-Type: text/plain; charset=ISO-8859-1 Cc: "net@freebsd.org" , Scott Long , Rui Paulo , "current@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 15:53:05 -0000 On 14 April 2013 16:48, Warren Block wrote: > On Sun, 14 Apr 2013, Chris Rees wrote: > >> On 14 April 2013 01:41, Rui Paulo wrote: >>> >>> 2013/04/13 16:01?Scott Long ??????: >>> >>> >>>> 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 16:06:51 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4ECB439A; Sun, 14 Apr 2013 16:06:51 +0000 (UTC) (envelope-from gpalmer@freebsd.org) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 13B1765B; Sun, 14 Apr 2013 16:06:51 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1URPS5-000DUI-0E; Sun, 14 Apr 2013 12:06:49 -0400 Date: Sun, 14 Apr 2013 12:06:48 -0400 From: Gary Palmer To: Warren Block Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: gpalmer@freebsd.org X-SA-Exim-Scanned: No (on noop.in-addr.com); SAEximRunCond expanded to false Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 16:06:51 -0000 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 17:17:04 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4AFD8B29; Sun, 14 Apr 2013 17:17:04 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 01A899A8; Sun, 14 Apr 2013 17:17:03 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX1+j9OdE9eP/0PwTB2geKrkRat3E00vTR8g@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3EGPNkq013418; Sun, 14 Apr 2013 16:25:23 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Sun, 14 Apr 2013 16:25:23 -0000 Message-ID: In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Sun, 14 Apr 2013 16:25:23 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Gary Palmer" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 17:17:04 -0000 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-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 17:53:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C05C0184; Sun, 14 Apr 2013 17:53:43 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe10.ukr.net (ffe10.ukr.net [195.214.192.60]) by mx1.freebsd.org (Postfix) with ESMTP id 42A63AC0; Sun, 14 Apr 2013 17:53:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=etrq1yVHCoBkAEn3prd7kSDf+mQ6qMXLk8XtLM480Dw=; b=MVwLCqEeGyhChkDjRopy0PLNHqvTZeT+3VCAfBpciS3RM3Xi6J5JVnFpHuvh4oqoT38z4xaKN2ux3R9KK4epj532o5fAJRjDu7HGNVqnX7sS31wVqTU589gEYGwZo+/MQ2aWQ+pEp71kJIMctnEd9VelhxyGQ9dzoTXvoCB34Ik=; Received: from mail by ffe10.ukr.net with local ID 1URQkw-000DrL-J1 ; Sun, 14 Apr 2013 20:30:22 +0300 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re[2]: ipfilter(4) needs maintainer In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> To: "Gary Palmer" From: "wishmaster" X-Mailer: freemail.ukr.net 4.0 Message-Id: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Date: Sun, 14 Apr 2013 20:30:22 +0300 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 17:53:43 -0000 --- Original message --- From: "Gary Palmer" 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, From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 18:31:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3A457999; Sun, 14 Apr 2013 18:31:01 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id F091CCBB; Sun, 14 Apr 2013 18:31:00 +0000 (UTC) Received: from ds4.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id D03578D7A; Sun, 14 Apr 2013 18:30:59 +0000 (UTC) Received: by ds4.des.no (Postfix, from userid 1001) id 82E939260; Sun, 14 Apr 2013 20:30:59 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Odhiambo Washington Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <516AAD01.1090201@a1poweruser.com> <1D28D213-BB43-4538-A1D5-FC396A7025D5@samsco.org> Date: Sun, 14 Apr 2013 20:30:59 +0200 In-Reply-To: (Odhiambo Washington's message of "Sun, 14 Apr 2013 16:48:36 +0300") Message-ID: <861uadc6cc.fsf@ds4.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 18:31:01 -0000 Odhiambo Washington 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 --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 18:55:50 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF6D3F1D; Sun, 14 Apr 2013 18:55:50 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from abby.lhr1.as41113.net (hosted.mx.as41113.net [91.208.177.22]) by mx1.freebsd.org (Postfix) with ESMTP id 83136D88; Sun, 14 Apr 2013 18:55:49 +0000 (UTC) Received: from [IPv6:2001:b70:201:300::397] (unknown [IPv6:2001:b70:201:300::397]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by abby.lhr1.as41113.net (Postfix) with ESMTPSA id 3Zphqx5yNPz1Q2; Sun, 14 Apr 2013 19:55:41 +0100 (BST) Message-ID: <516AFB99.2040007@rewt.org.uk> Date: Sun, 14 Apr 2013 19:55:21 +0100 From: Joe Holden User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: wishmaster Subject: Re: ipfilter(4) needs maintainer References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 18:55:50 -0000 wishmaster wrote: > --- Original message --- > From: "Gary Palmer" > 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. From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 19:12:00 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8E732436 for ; Sun, 14 Apr 2013 19:12:00 +0000 (UTC) (envelope-from mexas@bristol.ac.uk) Received: from eu1sys200aog119.obsmtp.com (eu1sys200aog119.obsmtp.com [207.126.144.147]) by mx1.freebsd.org (Postfix) with ESMTP id D5166E20 for ; Sun, 14 Apr 2013 19:11:59 +0000 (UTC) Received: from mail-lb0-f197.google.com ([209.85.217.197]) (using TLSv1) by eu1sys200aob119.postini.com ([207.126.147.11]) with SMTP ID DSNKUWr/X/qUDt/cQ/fb047qdC5KkqjOk7bR@postini.com; Sun, 14 Apr 2013 19:11:59 UTC Received: by mail-lb0-f197.google.com with SMTP id z13so5809226lbh.8 for ; Sun, 14 Apr 2013 12:11:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:sender:date:from:message-id:to:subject:cc :reply-to:in-reply-to:x-gm-message-state; bh=gP3s534UcnNLFCAU1rw7n2xAY+Xzw4+Jr3rxUJJMpjw=; b=XbV5KVqfmklkbKtZmNtKjLItTtHI+9BOGwQbRkRCGuv5g3I6psAItmhe2KqoFauSn9 VA816E7t3XLhEiingC4KuaSdpI6Ec6mOXM6iW6vV1mdcfsd5EJMu2V+WEj30X7poTDhA i3wkOOC67+hSxy3GAB1pD2153O3u7DTRwEWs9KDVZ5IPUjI6JhWQPYhGJUYo5cA0Acps BMKQCSZ6r+8YUdLMLUnWsXQtaaoDxRlCdKzoEljPdWP1L6uwEgsvf2PwNnzxFFd67T9r 1nIwpDMPHmKtaSyTBruEuSFnuPetDRJBYAxoDTQCGWYRzp52aTCdkTe4jsYue+6l39lZ Wiyw== X-Received: by 10.180.109.197 with SMTP id hu5mr7844912wib.22.1365966687152; Sun, 14 Apr 2013 12:11:27 -0700 (PDT) X-Received: by 10.180.109.197 with SMTP id hu5mr7844897wib.22.1365966686983; Sun, 14 Apr 2013 12:11:26 -0700 (PDT) Received: from mech-cluster241.men.bris.ac.uk (mech-cluster241.men.bris.ac.uk. [137.222.187.241]) by mx.google.com with ESMTPS id bo1sm10645332wib.0.2013.04.14.12.11.24 (version=TLSv1.2 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 12:11:25 -0700 (PDT) Sender: Anton Shterenlikht Received: from mech-cluster241.men.bris.ac.uk (localhost [127.0.0.1]) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6) with ESMTP id r3EJBMkr084883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 14 Apr 2013 20:11:23 +0100 (BST) (envelope-from mexas@mech-cluster241.men.bris.ac.uk) Received: (from mexas@localhost) by mech-cluster241.men.bris.ac.uk (8.14.6/8.14.6/Submit) id r3EJBMOb084882; Sun, 14 Apr 2013 20:11:22 +0100 (BST) (envelope-from mexas) Date: Sun, 14 Apr 2013 20:11:22 +0100 (BST) From: Anton Shterenlikht Message-Id: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> To: rpaulo@FreeBSD.org, scottl@samsco.org Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> X-Gm-Message-State: ALoCoQl2xzepFNPViLSkSCD9o0C8w6ldcC/CQ2ttruva+czhOPcI0Gok8s8iK2Qbf/vgE2aqOxN80oz8mgvnKDK33nsRsoPB5B5UJ9hgBkfQWkrPKtjIjv6YrmZeH2U8tbZy9BBezvL//aMGY6/Agi6MyB5szGZoEQ== Cc: current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: mexas@bristol.ac.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 19:12:00 -0000 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 19:58:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E6A72C5D; Sun, 14 Apr 2013 19:58:55 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id 8073BF77; Sun, 14 Apr 2013 19:58:55 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id ib11so3344407vcb.6 for ; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ze/1KuWFhUcRIDSdz4w6Y6tPgTgz6W8Rb6qLUAKmYhY=; b=HXvzZdDIkn50hyJnoJyfFKcoBIeeHg5wed14UQ47pgxRECT+dzd0zTBjCtdGDsV2Dn byR3ckpuPsEswt3pwI0IBa9QpATm67OKSe4yEJ0gUNEIfQNFCl3C8Z9lXMmQPLAbyofg k4OPZNivAF9lJt8xJqM05rGGS5L9BxANKsJgzK8BxkATnVEAvlLWU6/tsuFGXn+7gGr7 exZNSIUrbwmqlJzwZcW1JKaHWACB98UI/tLMPN+CrJRqa5AKDgtWHiKlS6N0zoRbbEh0 DC07+XTe8NM6xzFPkU07MTQgd+EPtwSt/EdgZwTaB3vpoTrSkqTPoLSuKc2IQGvccEAI Sg7Q== MIME-Version: 1.0 X-Received: by 10.58.146.195 with SMTP id te3mr103487veb.33.1365969534359; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Sun, 14 Apr 2013 12:58:54 -0700 (PDT) In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> Date: Sun, 14 Apr 2013 15:58:54 -0400 Message-ID: Subject: Re: Re[2]: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: wishmaster Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 19:58:56 -0000 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 wrote: > > > --- Original message --- > From: "Gary Palmer" > 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-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > -- Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 20:33:23 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E00EB5AC; Sun, 14 Apr 2013 20:33:23 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id CE42FFA; Sun, 14 Apr 2013 20:33:23 +0000 (UTC) Received: from [IPv6:2601:9:4d00:3c:3169:d5a4:db0a:888b] (unknown [IPv6:2601:9:4d00:3c:3169:d5a4:db0a:888b]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id CC1533981E; Sun, 14 Apr 2013 13:33:22 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Rui Paulo In-Reply-To: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> Date: Sun, 14 Apr 2013 13:33:21 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9ED46F7A-8A5A-4668-8B00-D58278C9A0DA@FreeBSD.org> References: <201304141911.r3EJBMOb084882@mech-cluster241.men.bris.ac.uk> To: mexas@bristol.ac.uk X-Mailer: Apple Mail (2.1503) Cc: scottl@samsco.org, current@FreeBSD.org, net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 20:33:24 -0000 On 2013/04/14, at 12:11, Anton Shterenlikht wrote: > A migration *guide*, yes. Tools to convert one syntax to = another: no. >=20 > 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 22:25:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 118044DA; Sun, 14 Apr 2013 22:25:14 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id BF7A35FE; Sun, 14 Apr 2013 22:25:13 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3ZpnTf6GNLzGMf1; Mon, 15 Apr 2013 00:25:10 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:organization:in-reply-to:references:user-agent :date:date:subject:subject:from:from:received:received:received :vbr-info; s=jakla2; t=1365978308; x=1368570309; bh=ERuCSN/R29Tv d448E63be+NM6qgx9Uc4v8XSyOdm/qk=; b=ALgzQDf1ua27wVCUM9K5U1kFCYJ6 iACaHQpqSuajJF77bAEp6JJ5N5xRX6A1uxXP5l4DFd4dYXq90vyqQRN5UHccTpQq lzvw0PiigJsjbsg/0QNw+MVZS3AmeqpaBmzB7uaoN4qxmNBz8+JM3COuYg6FlDvY zt/eHrr8nsAStZE= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 2df5AFYu6xoJ; Mon, 15 Apr 2013 00:25:08 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Mon, 15 Apr 2013 00:25:07 +0200 (CEST) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id CC42C330; Mon, 15 Apr 2013 00:25:07 +0200 (CEST) From: Mark Martinec To: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 00:25:07 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> In-Reply-To: <36562.1365960622.5652758659450863616@ffe10.ukr.net> Organization: J. Stefan Institute MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 22:25:14 -0000 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 From owner-freebsd-net@FreeBSD.ORG Sun Apr 14 23:10:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1F5C0A1B for ; Sun, 14 Apr 2013 23:10:46 +0000 (UTC) (envelope-from jim@netgate.com) Received: from mail-oa0-f46.google.com (mail-oa0-f46.google.com [209.85.219.46]) by mx1.freebsd.org (Postfix) with ESMTP id DF53377F for ; Sun, 14 Apr 2013 23:10:45 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id h2so2597995oag.5 for ; Sun, 14 Apr 2013 16:10:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=VLd5GuH6Bexi+xL7oBouEgRxls8tF3SOi/ABxA7rquA=; b=IP3wjzCGNgIvqWZLhmWSQxHPSDjsDz/zWeNzHo6U2xodADyzhJTw5SGquiCPBRmohQ 9o0DIsrG76ji06kIvwFq82glv02BrM5hLPW4UiyLtDaxAjHSiqHIeHhcQxrkVwiyJjP6 W3KpTOj7Ul8DL+j4rPfoaeNnIyTsjMMJnpAMBwkiff5KAPexvpxpUMNm9gaU9BYhiXJi X9AKkNZTGJbCaaAWTAGV2yM4LtSRtjaNS1092NkrDpZ41DEagHmsmxOBtiq6lnjIBjvS qLxc9pekqYTNw/MdQ4n5SR8EpdNkjnOGm3wgbWMx5Vc7PvRAzI5UiYCSNSx1PXq/1qyv n8oQ== X-Received: by 10.60.102.73 with SMTP id fm9mr7005287oeb.110.1365981044967; Sun, 14 Apr 2013 16:10:44 -0700 (PDT) Received: from jims-mini.office.pfmechanics.net ([192.207.126.228]) by mx.google.com with ESMTPS id do4sm3814137oeb.0.2013.04.14.16.10.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 14 Apr 2013 16:10:44 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Jim Thompson In-Reply-To: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> Date: Sun, 14 Apr 2013 18:10:39 -0500 Message-Id: <35D4CCA3-1981-4825-B83F-70217B11672D@netgate.com> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> To: Mark Martinec X-Mailer: Apple Mail (2.1503) X-Gm-Message-State: ALoCoQlUfhfoMD8U9uO5F6jRxnP1oCmyu2d7/a+JQSpljTf13T5KTFPeoZaeF5j6Z9MJGFSBA1QD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 23:10:46 -0000 On Apr 14, 2013, at 5:25 PM, Mark Martinec = 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 01:52:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5AE4A479; Mon, 15 Apr 2013 01:52:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 324ABA6A; Mon, 15 Apr 2013 01:52:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3F1qnc0010775; Mon, 15 Apr 2013 01:52:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3F1qnDx010774; Mon, 15 Apr 2013 01:52:49 GMT (envelope-from linimon) Date: Mon, 15 Apr 2013 01:52:49 GMT Message-Id: <201304150152.r3F1qnDx010774@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177618: [bridge] Problem with bridge firewall with trunk ports and vlans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 01:52:49 -0000 Old Synopsis: Bridge firewall with trunk ports and vlans New Synopsis: [bridge] Problem with bridge firewall with trunk ports and vlans Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Apr 15 01:49:58 UTC 2013 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=177618 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:15:29 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36DDE82B; Mon, 15 Apr 2013 10:15:29 +0000 (UTC) (envelope-from lars@e-new.0x20.net) Received: from mail.0x20.net (mail.0x20.net [217.69.76.211]) by mx1.freebsd.org (Postfix) with ESMTP id E8B83F2; Mon, 15 Apr 2013 10:15:28 +0000 (UTC) Received: from e-new.0x20.net (mail.0x20.net [IPv6:2001:aa8:fffb:1::3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.0x20.net (Postfix) with ESMTPS id 036B86A6002; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) Received: from e-new.0x20.net (localhost [127.0.0.1]) by e-new.0x20.net (8.14.5/8.14.5) with ESMTP id r3FAFQh7078878; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) (envelope-from lars@e-new.0x20.net) Received: (from lars@localhost) by e-new.0x20.net (8.14.5/8.14.5/Submit) id r3FAFQ0C077927; Mon, 15 Apr 2013 12:15:26 +0200 (CEST) (envelope-from lars) Date: Mon, 15 Apr 2013 12:15:26 +0200 From: Lars Engels To: Joe Holden Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415101526.GA65341@e-new.0x20.net> References: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <516AFB99.2040007@rewt.org.uk> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SUOF0GtieIMvvwua" Content-Disposition: inline In-Reply-To: <516AFB99.2040007@rewt.org.uk> X-Editor: VIM - Vi IMproved 7.3 X-Operation-System: FreeBSD 8.3-RELEASE-p5 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "net@freebsd.org" , "current@freebsd.org" , wishmaster X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:15:29 -0000 --SUOF0GtieIMvvwua Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 14, 2013 at 07:55:21PM +0100, Joe Holden wrote: > wishmaster wrote: >=20 > > --- Original message --- > > From: "Gary Palmer" > > Date: 14 April 2013, 19:06:59 > >=20 > > =20 > >> 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 c= reep > >> up again as kernel APIs change. If the author has lost interest in > >> maintaining the FreeBSD port of ipfilter then unless someone steps for= ward > >> to carry on the work, I don't see much of a future for ipfilter in > >> FreeBSD > >> > >> Do we honestly need three packet filters? > > =20 > > 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?.. > >=20 > > Cheers, > For non-nat ipfw is still superior in every way, numbered rules (think:= =20 > scripts), dummynet, much faster than pf, syntax is a lot nicer and=20 > predictable... >=20 > Does anyone even use ipf? it doesn't even work on Linux anymore, junk it= =20 > and keep pf+ipfw, job done. m0n0wall uses ipfilter: http://m0n0.ch/wall/facts.php --SUOF0GtieIMvvwua Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFr0z4ACgkQKc512sD3afigkgCgklyPLcaWJH3qt5S0U8iXp6xR j1EAn1zbodljf60/M7bXSjT2C1rFF0bz =faym -----END PGP SIGNATURE----- --SUOF0GtieIMvvwua-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:15:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B40C09AD; Mon, 15 Apr 2013 10:15:41 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7D36CF7; Mon, 15 Apr 2013 10:15:41 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 38D2D4AC57; Mon, 15 Apr 2013 14:15:38 +0400 (MSK) Date: Mon, 15 Apr 2013 14:15:36 +0400 From: Lev Serebryakov Organization: FreeBSD X-Priority: 3 (Normal) Message-ID: <951943801.20130415141536@serebryakov.spb.ru> To: Mark Martinec Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <201304150025.07337.Mark.Martinec+freebsd@ijs.si> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:15:41 -0000 Hello, Mark. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 filter= s: >> 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! --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:26:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 926E0C23; Mon, 15 Apr 2013 10:26:42 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id D406B18F; Mon, 15 Apr 2013 10:26:41 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so3493357wey.11 for ; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=vXjvTQOwUK2MIjRVTZ9U7h2i+i0KDEYnsDYC/R0Z1AU=; b=e3TWytJ2sWkCROK1i0WXC2Zup8J7nRH9oB1ACv0BnrDNBvJkw/hH5r6a9L4el2mrR+ K/SI15iNUS0AjSays/q3dLZmPIG365mHNTP1rDRYQPQqTTYUolgrSs0nPLDBHpITfA2O l2ieqsQXf3lugFiYkjobfFp1XrteNFbhxZ3Z1fyMnI8RKYVI+y7oWonCLOciQudbrK4E DDpP5mN56TH7ulCDoZwb4xnnxMLDA/2x9FXAAM5ExcEelSjNLzLliN8S51pFogdOg0wC ukhQ1kESy/QEh9vbhpeid87MYoF34xyUQbG09usKJeX9L6JlS4aXdw/0V3mgUu5c4wJP CfAA== MIME-Version: 1.0 X-Received: by 10.180.38.105 with SMTP id f9mr10989707wik.15.1366021600468; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:26:40 -0700 (PDT) In-Reply-To: <951943801.20130415141536@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:26:40 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:26:42 -0000 On Mon, Apr 15, 2013 at 1:15 PM, Lev Serebryakov wrote: > Hello, Mark. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 filte= rs: >>> 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 > Things like ftp-proxy(8) will need address translation even with IPv6. Also certain scrub options require a NAT like functionalities. -Kimmo From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:32:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 149E3EE1; Mon, 15 Apr 2013 10:32:47 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id CB88120A; Mon, 15 Apr 2013 10:32:46 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id C821F4AC57; Mon, 15 Apr 2013 14:32:38 +0400 (MSK) Date: Mon, 15 Apr 2013 14:32:37 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <195468703.20130415143237@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:32:47 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:36:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C4B916F; Mon, 15 Apr 2013 10:36:30 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 4C490252; Mon, 15 Apr 2013 10:36:29 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id k13so4392088wgh.17 for ; Mon, 15 Apr 2013 03:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=lWIihVDyaEQidvIpRrySs0QzOajjsdOFteimd9vq8f4=; b=v5br8GHqduhbC/hZpRw1jTkMvC7LHXmKewmUqnm1JZHy/0zTonxK6M97HwmXGR//nx jurps8341cKITV8qx/KUZfkk0Y6bTR5c4iT/QKcNgdh2iszdYYx3pkpQwWuSPJL5tzn1 AtUQMf7N5IKd/XBFydcVu8w2sXnXzfGtQTKSinuvNg44VCcrbnZ4l6LdP5GEop1gK8EW Mq1FNKnrlxBPc6nyc8nWqMBb/KBP6lBM12qoqrvfVuJNYQpwEvWYaDhfBvpNDj0QnmNV rAbS484EpsqA480HCqo4BtchVSsY9AZmKPkRHEgrgAyW57obnDmY1QxCiIuEGO635HwL pTcQ== MIME-Version: 1.0 X-Received: by 10.180.19.39 with SMTP id b7mr11064061wie.15.1366022187931; Mon, 15 Apr 2013 03:36:27 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:36:27 -0700 (PDT) In-Reply-To: <195468703.20130415143237@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:36:27 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:36:30 -0000 On Mon, Apr 15, 2013 at 1:32 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:44:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5AD16AD; Mon, 15 Apr 2013 10:44:31 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 6AC7B2FC; Mon, 15 Apr 2013 10:44:31 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 0A63A4AC57; Mon, 15 Apr 2013 14:44:29 +0400 (MSK) Date: Mon, 15 Apr 2013 14:44:28 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <621849003.20130415144428@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:44:31 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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. --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:47:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id ED04A97E; Mon, 15 Apr 2013 10:47:25 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by mx1.freebsd.org (Postfix) with ESMTP id 384F0349; Mon, 15 Apr 2013 10:47:25 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id c10so1382245wiw.13 for ; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=P1ZKwYwb92Sbj62ZjZpl4ffRTg7lVPe6GykMxQTfN5I=; b=klasYIv8EfrQ91mYeWpsmoPtt/R3gpycHmcO+8ralOKI6llbBm2x8VPmMFHVTdp0I9 bujt82gd56vVwx1RGvWZ+Cc2fVOCvz7vIYoW55pD9aD2pSV9VjkkiVMzYF3GyWPzOt/2 iPPvI43gKprmtA/ltdmH1gVxyyq/HpcBeuBx5rGVgUioTyQC4uBFmhU62fHYVOg2G0aR YOHcYTAXtuF2nVBhtyeangTjsJHNaAmaIIOrPvCTz9mvcgopx9UfnMaF/eMyzak63AY7 2HgWyUXMB6sZ5KXQk/sAoMXLIwUhgyFtYAbCohyVQnTJKk1XH5kxI/smwZE9brcIpYIc rZqA== MIME-Version: 1.0 X-Received: by 10.194.157.138 with SMTP id wm10mr10133324wjb.28.1366022844442; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:47:24 -0700 (PDT) In-Reply-To: <621849003.20130415144428@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:47:24 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:47:26 -0000 On Mon, Apr 15, 2013 at 1:44 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:50:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E33A1BED; Mon, 15 Apr 2013 10:50:25 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id A777138F; Mon, 15 Apr 2013 10:50:25 +0000 (UTC) Received: from lion.home.serebryakov.spb.ru (unknown [IPv6:2001:470:923f:1:d051:3b46:4a53:4fdc]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPA id 57FF24AC57; Mon, 15 Apr 2013 14:50:24 +0400 (MSK) Date: Mon, 15 Apr 2013 14:50:23 +0400 From: Lev Serebryakov Organization: FreeBSD Project X-Priority: 3 (Normal) Message-ID: <66408799.20130415145023@serebryakov.spb.ru> To: Kimmo Paasiala Subject: Re: ipfilter(4) needs maintainer In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: lev@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:50:26 -0000 Hello, Kimmo. You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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). --=20 // Black Lion AKA Lev Serebryakov From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:54:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7D845DE2; Mon, 15 Apr 2013 10:54:50 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by mx1.freebsd.org (Postfix) with ESMTP id BA2743FD; Mon, 15 Apr 2013 10:54:49 +0000 (UTC) Received: by mail-wi0-f181.google.com with SMTP id hj19so334837wib.8 for ; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=zA9LvDmKcJZOtlFnL79gdLDn0H3qjNSSSzgHsuaKF28=; b=mUpuHrBM+/K6/KGLlZUkRK/zdlb7aFjo9Cc7Ys3+JCpOmEDpWGPDLxv5xCy91wQwTB sQMQeB7l2HbfEcjRuyX8JMkVOg+j/rDa2xwbXiDgsM7/+DB7gJ+Z2A+bkjM7UknZWeuT ut+VSEdzQ3VVhSXCipPfaoU8jPUiqTWheRxh3vPNXaHSa4emHI0BJYYEG738n/LLU1PN l1oj6KVFyU37YxicQnZoxV7Gb/lX6m/CfTpPi89aLqxlpIew1gf0v7PYHOJdAi/jQxOM XEtzGddpIs2we09Nc8aRWRgQpEpTkevmhLy26Y8RQGKAR8cXKuNmFA5yZ9HcXtCT4oQ9 ETIw== MIME-Version: 1.0 X-Received: by 10.194.60.195 with SMTP id j3mr31172222wjr.33.1366023288898; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 03:54:48 -0700 (PDT) In-Reply-To: <66408799.20130415145023@serebryakov.spb.ru> References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 13:54:48 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:54:50 -0000 On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote: > Hello, Kimmo. > You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 10:57:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76D6D172 for ; Mon, 15 Apr 2013 10:57:44 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id B3CD0628 for ; Mon, 15 Apr 2013 10:57:43 +0000 (UTC) Received: (qmail 91373 invoked from network); 15 Apr 2013 10:51:00 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 15 Apr 2013 10:51:00 -0000 Date: Mon, 15 Apr 2013 12:51:00 +0200 (CEST) Message-Id: <20130415.125100.74672975.sthaug@nethelp.no> To: lev@FreeBSD.org Subject: Re: ipfilter(4) needs maintainer From: sthaug@nethelp.no In-Reply-To: <195468703.20130415143237@serebryakov.spb.ru> References: <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Mark.Martinec+freebsd@ijs.si, kpaasial@gmail.com, current@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:57:44 -0000 > >> 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, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 11:01:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A07C9629; Mon, 15 Apr 2013 11:01:59 +0000 (UTC) (envelope-from kpaasial@gmail.com) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by mx1.freebsd.org (Postfix) with ESMTP id DEF5C693; Mon, 15 Apr 2013 11:01:58 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so1395721wib.16 for ; Mon, 15 Apr 2013 04:01:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=LMuPrt462S9z9AkXH3kvHdYSkGOhjzIYZGD51/6lLnU=; b=GFyZycfgLGW4imyNjNF/9bO4uSfdE/wvAtuP+rimb1KXC7DW3DDJIpVpkdSUG0ayan VbJ1Y8w5p8ZbYTUQQwy316d+nJxGX1fTVdipeScpic/7lg+CmVLXlf3BAuF19Abfp4e7 Ic7+pRQ+2rXhELr7nmEM4+yls7t//wnsTahx7deMEibTa9/PzZeWOkYXehl6IAF7NlR4 NvwakhCv2nS1yPWkLWsF+saFHDJKEuq07/Z9fweU/O/dNdhOEMROeA1hyYQyhZY5NTt/ cur9O4xbUfUqv+RuSuYf1qS0a9Vz2tNVljKWDyR9iWKa6AuU15Ypj8cWuSEPTiMDlK+P b6FQ== MIME-Version: 1.0 X-Received: by 10.180.97.233 with SMTP id ed9mr10955574wib.32.1366023718020; Mon, 15 Apr 2013 04:01:58 -0700 (PDT) Received: by 10.216.139.72 with HTTP; Mon, 15 Apr 2013 04:01:57 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> Date: Mon, 15 Apr 2013 14:01:57 +0300 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Kimmo Paasiala To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Mark Martinec , freebsd-net@freebsd.org, current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:01:59 -0000 On Mon, Apr 15, 2013 at 1:54 PM, Kimmo Paasiala wrote: > On Mon, Apr 15, 2013 at 1:50 PM, Lev Serebryakov wrote: >> Hello, Kimmo. >> You wrote 15 =D0=B0=D0=BF=D1=80=D0=B5=D0=BB=D1=8F 2013 =D0=B3., 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 11:06:48 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F340696B for ; Mon, 15 Apr 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id E4D9E7A8 for ; Mon, 15 Apr 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3FB6lL3015179 for ; Mon, 15 Apr 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3FB6lN0015177 for freebsd-net@FreeBSD.org; Mon, 15 Apr 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 15 Apr 2013 11:06:47 GMT Message-Id: <201304151106.r3FB6lN0015177@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/177618 net [bridge] Problem with bridge firewall with trunk ports o kern/177417 net [ip6] Invalid protocol value in ipsec6_common_input_cb o kern/177402 net [igb] [pf] problem with ethernet driver igb + pf / alt o kern/177400 net [jme] JMC25x 1000baseT establishment issues o kern/177366 net [ieee80211] negative malloc(9) statistics for 80211nod o kern/177362 net [netinet] [patch] Wrong control used to return TOS o kern/177194 net [netgraph] Unnamed netgraph nodes for vlan interfaces o kern/177184 net [bge] [patch] enable wake on lan o kern/177139 net [igb] igb drops ethernet ports 2 and 3 o kern/176884 net [re] re0 flapping up/down o kern/176671 net [epair] MAC address for epair device not unique o kern/176667 net [libalias] [patch] libalias locks on uninitalized data o kern/176596 net [firewire] [ip6] Crash with IPv6 and Firewire o kern/176484 net [ipsec] [enc] [patch] panic: IPsec + enc(4); device na o kern/176446 net [netinet] [patch] Concurrency in ixgbe driving out-of- o kern/176420 net [kernel] [patch] incorrect errno for LOCAL_PEERCRED o kern/176419 net [kernel] [patch] socketpair support for LOCAL_PEERCRED o kern/176401 net [netgraph] page fault in netgraph o kern/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173871 net [gif] process of 'ifconfig gif0 create hangs' when if_ o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] [ipfilter] drops UDP packets with zero checksu o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipfilter] ipfilter/nat NULL pointer deference p kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155680 net [multicast] problems with multicast s kern/155642 net [new driver] [request] Add driver for Realtek RTL8191S o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [new driver] [request]: Port brcm80211 driver from Lin o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipfilter] There is no ippool start script/ipfilter ma o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [ipfilter] [rc.d] [patch] No good way to set ipfilter o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipfilter] FreeBSD 6.1+VPN+ipnat+ipf: port mapping doe o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipfilter] [panic] Kernel Panic Trap No 12 Page Fault o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipfilter] [patch] ipfilter drops OOW packets under 6. o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipfilter] [patch] wrong behaviour with skip rule insi o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipfilter] [panic] using ipfilter "auth" keyword leads o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipfilter] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipfilter] [patch] ipfilter ioctl SIOCGNATL does not m o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipfilter] ipfilter ipnat problem with h323 proxy supp o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipfilter] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipfilter] [ppp] Interactive use of user PPP and ipfil f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 462 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 12:12:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8D289EF9; Mon, 15 Apr 2013 12:12:24 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (mail.ijs.si [IPv6:2001:1470:ff80::25]) by mx1.freebsd.org (Postfix) with ESMTP id 477AACC4; Mon, 15 Apr 2013 12:12:24 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3Zq7r60C8ZzGN2P; Mon, 15 Apr 2013 14:12:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:in-reply-to:references:user-agent:date:date :subject:subject:organization:from:from:received:received :received:vbr-info; s=jakla2; t=1366027936; x=1368619937; bh=CDS SV0jzTciporXtxv/xcn/uck9EX9P4mogmf/LFhDk=; b=CjJTrAGAls+g7exQjQW IRp+Zb2lkAiaQbHmYPEE9pdxCMqcRwSiuzu0Dov3bsm88Glki3O07C71kLO/xHMg +y6jLgtyvog/tFG78A3CVGVNTH+kyYH0i8AmUnTKeihyPTXZ3TWZupa22l5oH0TT dIKmeB8cb8VaDe4p7ucrJk8c= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id Dal7cfbi-S8Y; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) Received: from sleepy.ijs.si (sleepy.ijs.si [IPv6:2001:1470:ff80:e001::1:1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 9AB15B68; Mon, 15 Apr 2013 14:12:16 +0200 (CEST) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-net@freebsd.org Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 14:12:16 +0200 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.9.5; amd64; ; ) References: <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <20130415.125100.74672975.sthaug@nethelp.no> In-Reply-To: <20130415.125100.74672975.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304151412.16246.Mark.Martinec+freebsd@ijs.si> Cc: current@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 12:12:24 -0000 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 sthaug@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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 14:33:11 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BA5DB7B; Mon, 15 Apr 2013 14:33:11 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-04.shaw.ca (smtp-out-04.shaw.ca [64.59.134.12]) by mx1.freebsd.org (Postfix) with ESMTP id 5C554362; Mon, 15 Apr 2013 14:33:11 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=HUoWN8sqH4wajA0WKpKyUV7G7o/UpN4YSPso/+twBIs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=s1O25tkdAAAA:8 a=MyE6jBz-AAAA:8 a=CjxXgO3LAAAA:8 a=6I5d2MoRAAAA:8 a=ZB5LerlCAAAA:8 a=BWvPGDcYAAAA:8 a=d8jxi4gjFzhM9obhgiUA:9 a=CjuIK1q_8ugA:10 a=6oEG72nUbxYA:10 a=OyOq_G8mXAEA:10 a=aLekXsIfG0IA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-04.shaw.ca with ESMTP; 15 Apr 2013 08:33:33 -0600 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id A782C192; Mon, 15 Apr 2013 07:33:04 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FEX3c3005916; Mon, 15 Apr 2013 07:33:04 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151433.r3FEX3c3005916@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Warren Block Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Warren Block of "Sun, 14 Apr 2013 09:48:33 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 07:33:03 -0700 Cc: Chris Rees , "current@freebsd.org" , Scott Long , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 14:33:11 -0000 In message , Warren Block writ es: > On Sun, 14 Apr 2013, Chris Rees wrote: > > > On 14 April 2013 01:41, Rui Paulo wrote: > >> 2013/04/13 16:01?Scott Long ??????: > >> > >>> 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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 16:37:53 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1BA677B9; Mon, 15 Apr 2013 16:37:53 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id F22F8C1C; Mon, 15 Apr 2013 16:37:52 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX19ZCZpLg3X25ygaCjqzq9Mlk8Alxk7jxeo@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3FGbh7R017217; Mon, 15 Apr 2013 16:37:43 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Mon, 15 Apr 2013 16:37:43 -0000 Message-ID: <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> In-Reply-To: <201304151433.r3FEX3c3005916@slippy.cwsent.com> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> Date: Mon, 15 Apr 2013 16:37:43 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Cy Schubert" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:37:53 -0000 Ok, seems someone has taken the job. > In message , Warren Block > writ > es: >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >>> 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 > FreeBSD UNIX: 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-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 16:47:36 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24BBBA31; Mon, 15 Apr 2013 16:47:36 +0000 (UTC) (envelope-from cpet@sdf.org) Received: from sdf.org (ma.sdf.org [192.94.73.31]) by mx1.freebsd.org (Postfix) with ESMTP id 07F85D0A; Mon, 15 Apr 2013 16:47:35 +0000 (UTC) Received: from ma.sdf.org (IDENT:U2FsdGVkX18HA453t2DQ4GHFc0QTQWZlzFPaXd1WQos@localhost [127.0.0.1]) by sdf.org (8.14.4/8.14.3) with ESMTP id r3FGlX98018902; Mon, 15 Apr 2013 16:47:33 GMT Received: from 62-145-73-234.mach-six.com ([62.145.73.234]) (SquirrelMail authenticated user cpet) by ma.sdf.org with HTTP; Mon, 15 Apr 2013 16:47:33 -0000 Message-ID: <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> In-Reply-To: <201304151433.r3FEX3c3005916@slippy.cwsent.com> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> Date: Mon, 15 Apr 2013 16:47:33 -0000 Subject: Re: ipfilter(4) needs maintainer From: cpet@sdf.org To: "Cy Schubert" User-Agent: SquirrelMail/1.4.22 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:47:36 -0000 However it would of been better if said person asked me as I already offered to take it on but whatever. > In message , Warren Block > writ > es: >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >>> 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 > FreeBSD UNIX: 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-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 16:55:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2EC53EEF; Mon, 15 Apr 2013 16:55:22 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id CBA44DFF; Mon, 15 Apr 2013 16:55:21 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=oX08kPI8AAAA:8 a=s1O25tkdAAAA:8 a=MyE6jBz-AAAA:8 a=CjxXgO3LAAAA:8 a=ZB5LerlCAAAA:8 a=No9LUIqVyjyxOwiwL1sA:9 a=CjuIK1q_8ugA:10 a=6oEG72nUbxYA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=4wfsiePOASQA:10 a=OyOq_G8mXAEA:10 a=aLekXsIfG0IA:10 a=rC2wZJ5BpNYA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 10:56:17 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 31050D1; Mon, 15 Apr 2013 09:55:20 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FGtJqI003143; Mon, 15 Apr 2013 09:55:19 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151655.r3FGtJqI003143@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: cpet@sdf.org Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from cpet@sdf.org of "Mon, 15 Apr 2013 16:37:43 -0000." <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 09:55:19 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , Cy Schubert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 16:55:22 -0000 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 FreeBSD UNIX: Web: http://www.FreeBSD.org In message <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org>, cpet@sdf.org writes: > Ok, seems someone has taken the job. > > > > In message , Warren Block > > writ > > es: > >> On Sun, 14 Apr 2013, Chris Rees wrote: > >> > >> > On 14 April 2013 01:41, Rui Paulo wrote: > >> >> 2013/04/13 16:01?Scott Long ??????: > >> >> > >> >>> 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 > > FreeBSD UNIX: 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-unsubscribe@freebsd.org" > > > > From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 17:09:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3AF4E579; Mon, 15 Apr 2013 17:09:22 +0000 (UTC) (envelope-from rpaulo@felyko.com) Received: from felyko.com (felyko.com [174.136.100.2]) by mx1.freebsd.org (Postfix) with ESMTP id EC413EC5; Mon, 15 Apr 2013 17:09:21 +0000 (UTC) Received: from [IPv6:2620:149:f01:247:50e9:8e57:ccae:d65f] (unknown [IPv6:2620:149:f01:247:50e9:8e57:ccae:d65f]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 03A013981E; Mon, 15 Apr 2013 10:09:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=felyko.com; s=mail; t=1366045755; bh=pqDCn48SpNxdoy5ftWA+lZSZ4FANDTy8S34LqKgkueE=; h=References:In-Reply-To:Cc:From:Subject:Date:To; b=GxsrFfQgZnqVkU30u94OTwKGEq1JvHE/bvhwhjjaxS4AK6tJ9AtYPktITZVQCa3CP +P8f0ej7vk5c3kp59Qk41jjBJh7kLMpJd1GtLidMuf4GalxW1Q15k0LQZ4ZY3ZDRwO yU8j1lBPYXVbOJW83IpSj2fZEsXYZXrsDfKcouzo= References: <201304151655.r3FGtJqI003143@slippy.cwsent.com> Mime-Version: 1.0 (1.0) In-Reply-To: <201304151655.r3FGtJqI003143@slippy.cwsent.com> Content-Type: text/plain; charset=iso-2022-jp Content-Transfer-Encoding: quoted-printable Message-Id: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> X-Mailer: iPhone Mail (10B329) From: Rui Paulo Subject: Re: ipfilter(4) needs maintainer Date: Mon, 15 Apr 2013 10:09:17 -0700 To: Cy Schubert Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:09:22 -0000 2013/04/15 9:55=1B$B!"=1B(BCy Schubert =1B$B$N%a%= C%;!<%8=1B(B: > I've been planning on taking on IP Filter for quite some time.=20 > Unfortunately I've left my src commit bit lapse (my ports commit bit is=20= > alive and well though) thus I'm looking for a mentor. In addition I'm=20 > working on an ACER WMI/ACPI kld. One mentor would be preferred but two=20 > 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? Why do you want to work on something that people have been trying to remove s= ince 2005? From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 17:10:30 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA1ED678; Mon, 15 Apr 2013 17:10:30 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 61546EEC; Mon, 15 Apr 2013 17:10:30 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1URmyb-000DO2-RQ; Mon, 15 Apr 2013 21:13:58 +0400 Message-ID: <516C3462.30501@FreeBSD.org> Date: Mon, 15 Apr 2013 21:09:54 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , hackers@freebsd.org Subject: VLANHWFILTER "upgrade" X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------000509050108030808090809" Cc: Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:10:30 -0000 This is a multi-part message in MIME format. --------------000509050108030808090809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Hello list. We currently have VLAHWFILTER functionality allowing underlying physical/virtual interfaces to be aware of vlans stacked on them. However, this knowledge is only used to program NIC hw filter (or to broadcast to member ifaces in lagg case). Proposed idea is to save vlan ifp pointer inside the driver and push packet to given vlan directly. This changes removes 1 read lock on RX fast path. Additionally, we can do the same in more popular case of ix -> lagg [ -> lagg -> lagg ] -> vlan if we solve 1) lagg interface counters issue (trivial) 2) IFF_MONITOR on lagg interface issue (not so trivial, unfortunately). Patch to ixgbe driver attached (maybe it is better to put ixgbe_vlan_get() and struct ifvlans directly to if_vlan.[ch]). -- WBR, Alexander --------------000509050108030808090809 Content-Type: text/plain; charset=UTF-8; name="ixgbe_vlans2.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="ixgbe_vlans2.diff" Index: sys/dev/ixgbe/ixgbe.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/ixgbe/ixgbe.c (revision 248704) +++ sys/dev/ixgbe/ixgbe.c (working copy) @@ -2880,6 +2880,14 @@ ixgbe_allocate_queues(struct adapter *adapter) error =3D ENOMEM; goto err_rx_desc; } + + if ((rxr->vlans =3D malloc(sizeof(struct ifvlans), M_DEVBUF, + M_NOWAIT | M_ZERO)) =3D=3D NULL) { + device_printf(dev, + "Critical Failure setting up vlan index\n"); + error =3D ENOMEM; + goto err_rx_desc; + } } =20 /* @@ -4271,6 +4279,11 @@ ixgbe_free_receive_buffers(struct rx_ring *rxr) rxr->ptag =3D NULL; } =20 + if (rxr->vlans !=3D NULL) { + free(rxr->vlans, M_DEVBUF); + rxr->vlans =3D NULL; + } + return; } =20 @@ -4303,7 +4316,7 @@ ixgbe_rx_input(struct rx_ring *rxr, struct ifnet * return; } IXGBE_RX_UNLOCK(rxr); - (*ifp->if_input)(ifp, m); + (*ifp->if_input)(m->m_pkthdr.rcvif, m); IXGBE_RX_LOCK(rxr); } =20 @@ -4360,6 +4373,7 @@ ixgbe_rxeof(struct ix_queue *que) u16 count =3D rxr->process_limit; union ixgbe_adv_rx_desc *cur; struct ixgbe_rx_buf *rbuf, *nbuf; + struct ifnet *ifp_dst; =20 IXGBE_RX_LOCK(rxr); =20 @@ -4522,9 +4536,19 @@ ixgbe_rxeof(struct ix_queue *que) (staterr & IXGBE_RXD_STAT_VP)) vtag =3D le16toh(cur->wb.upper.vlan); if (vtag) { - sendmp->m_pkthdr.ether_vtag =3D vtag; - sendmp->m_flags |=3D M_VLANTAG; - } + ifp_dst =3D rxr->vlans->idx[EVL_VLANOFTAG(vtag)]; + + if (ifp_dst !=3D NULL) { + ifp_dst->if_ipackets++; + sendmp->m_pkthdr.rcvif =3D ifp_dst; + } else { + sendmp->m_pkthdr.ether_vtag =3D vtag; + sendmp->m_flags |=3D M_VLANTAG; + sendmp->m_pkthdr.rcvif =3D ifp; + } + } else + sendmp->m_pkthdr.rcvif =3D ifp; + if ((ifp->if_capenable & IFCAP_RXCSUM) !=3D 0) ixgbe_rx_checksum(staterr, sendmp, ptype); #if __FreeBSD_version >=3D 800000 @@ -4625,7 +4649,32 @@ ixgbe_rx_checksum(u32 staterr, struct mbuf * mp, u= return; } =20 +/* + * This routine gets real vlan ifp based on + * underlying ifp and vlan tag. + */ +static struct ifnet * +ixgbe_get_vlan(struct ifnet *ifp, uint16_t vtag) +{ =20 + /* XXX: IFF_MONITOR */ +#if 0 + struct lagg_port *lp =3D ifp->if_lagg; + struct lagg_softc *sc =3D lp->lp_softc; + + /* Skip lagg nesting */ + while (ifp->if_type =3D=3D IFT_IEEE8023ADLAG) { + lp =3D ifp->if_lagg; + sc =3D lp->lp_softc; + ifp =3D sc->sc_ifp; + } +#endif + /* Get vlan interface based on tag */ + ifp =3D VLAN_DEVAT(ifp, vtag); + + return (ifp); +} + /* ** This routine is run via an vlan config EVENT, ** it enables us to use the HW Filter table since @@ -4637,7 +4686,9 @@ static void ixgbe_register_vlan(void *arg, struct ifnet *ifp, u16 vtag) { struct adapter *adapter =3D ifp->if_softc; - u16 index, bit; + u16 index, bit, j; + struct rx_ring *rxr; + struct ifnet *ifv; =20 if (ifp->if_softc !=3D arg) /* Not our event */ return; @@ -4645,7 +4696,20 @@ ixgbe_register_vlan(void *arg, struct ifnet *ifp, if ((vtag =3D=3D 0) || (vtag > 4095)) /* Invalid */ return; =20 + ifv =3D ixgbe_get_vlan(ifp, vtag); + IXGBE_CORE_LOCK(adapter); + + if (ifp->if_capenable & IFCAP_VLAN_HWFILTER) { + rxr =3D adapter->rx_rings; + + for (j =3D 0; j < adapter->num_queues; j++, rxr++) { + IXGBE_RX_LOCK(rxr); + rxr->vlans->idx[vtag] =3D ifv; + IXGBE_RX_UNLOCK(rxr); + } + } + index =3D (vtag >> 5) & 0x7F; bit =3D vtag & 0x1F; adapter->shadow_vfta[index] |=3D (1 << bit); @@ -4663,7 +4727,8 @@ static void ixgbe_unregister_vlan(void *arg, struct ifnet *ifp, u16 vtag) { struct adapter *adapter =3D ifp->if_softc; - u16 index, bit; + u16 index, bit, j; + struct rx_ring *rxr; =20 if (ifp->if_softc !=3D arg) return; @@ -4672,6 +4737,15 @@ ixgbe_unregister_vlan(void *arg, struct ifnet *ifp= return; =20 IXGBE_CORE_LOCK(adapter); + + rxr =3D adapter->rx_rings; + + for (j =3D 0; j < adapter->num_queues; j++, rxr++) { + IXGBE_RX_LOCK(rxr); + rxr->vlans->idx[vtag] =3D NULL; + IXGBE_RX_UNLOCK(rxr); + } + index =3D (vtag >> 5) & 0x7F; bit =3D vtag & 0x1F; adapter->shadow_vfta[index] &=3D ~(1 << bit); @@ -4686,8 +4760,8 @@ ixgbe_setup_vlan_hw_support(struct adapter *adapte { struct ifnet *ifp =3D adapter->ifp; struct ixgbe_hw *hw =3D &adapter->hw; + u32 ctrl, j; struct rx_ring *rxr; - u32 ctrl; =20 =20 /* @@ -4713,6 +4787,15 @@ ixgbe_setup_vlan_hw_support(struct adapter *adapte= if (ifp->if_capenable & IFCAP_VLAN_HWFILTER) { ctrl &=3D ~IXGBE_VLNCTRL_CFIEN; ctrl |=3D IXGBE_VLNCTRL_VFE; + } else { + /* Zero vlan table */ + rxr =3D adapter->rx_rings; + + for (j =3D 0; j < adapter->num_queues; j++, rxr++) { + IXGBE_RX_LOCK(rxr); + memset(rxr->vlans->idx, 0, sizeof(struct ifvlans)); + IXGBE_RX_UNLOCK(rxr); + } } if (hw->mac.type =3D=3D ixgbe_mac_82598EB) ctrl |=3D IXGBE_VLNCTRL_VME; Index: sys/dev/ixgbe/ixgbe.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- sys/dev/ixgbe/ixgbe.h (revision 248704) +++ sys/dev/ixgbe/ixgbe.h (working copy) @@ -284,6 +284,11 @@ struct ix_queue { u64 irqs; }; =20 +struct ifvlans { + struct ifnet *idx[4096]; +}; + + /* * The transmit ring, one per queue */ @@ -307,7 +312,6 @@ struct tx_ring { } queue_status; u32 txd_cmd; bus_dma_tag_t txtag; - char mtx_name[16]; #ifndef IXGBE_LEGACY_TX struct buf_ring *br; struct task txq_task; @@ -324,6 +328,7 @@ struct tx_ring { unsigned long no_tx_dma_setup; u64 no_desc_avail; u64 total_packets; + char mtx_name[16]; }; =20 =20 @@ -346,8 +351,8 @@ struct rx_ring { u16 num_desc; u16 mbuf_sz; u16 process_limit; - char mtx_name[16]; struct ixgbe_rx_buf *rx_buffers; + struct ifvlans *vlans; bus_dma_tag_t ptag; =20 u32 bytes; /* Used for AIM calc */ @@ -363,6 +368,7 @@ struct rx_ring { #ifdef IXGBE_FDIR u64 flm; #endif + char mtx_name[16]; }; =20 /* Our adapter structure */ --------------000509050108030808090809-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 17:10:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AC59B783; Mon, 15 Apr 2013 17:10:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id EDFF6EEE; Mon, 15 Apr 2013 17:10:43 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id o7so1692107wea.36 for ; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=APEofcB5mBL0ZyW0fk7N3C0sGPVmTsHwLEli09CrBBg=; b=OISbCgmXYsI6OH0fdshyDLlOvGSoK3zlbiTl1AiRnOSqLglvVWICeAdYn/R0eWYXBo vu1yRels+XWY9bZCfU1hmoRLSgA7gNwm6QF/+vk0Rp3Q+zXPjTxT3V40oOyhSemYxWxy mLnGDm5iXp6uPtFZB7dwvoGUtMzf26I1aRId8Y/Dd2/lgax1WppXsfuAc+HKXwEYTSMC SnyB7HxAHjb3c/rZ7I47v95vrY45sQsIH/acfMx4EGWftuTn3wJcnq1NnsqvGV6MlGxC briUSVV6qY8U6Xc7PrjIdBL8FeffckEHmUtH5fwtyjCUWrKvgpBAaenhzVAKZkIIYL9w 9PQg== MIME-Version: 1.0 X-Received: by 10.181.11.164 with SMTP id ej4mr13670725wid.29.1366045842552; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.217.121.136 with HTTP; Mon, 15 Apr 2013 10:10:42 -0700 (PDT) In-Reply-To: <201304151655.r3FGtJqI003143@slippy.cwsent.com> References: <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org> <201304151655.r3FGtJqI003143@slippy.cwsent.com> Date: Mon, 15 Apr 2013 10:10:42 -0700 X-Google-Sender-Auth: 9_w36DVJwWKnPcKSQPG7065O28Y Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Adrian Chadd To: Cy Schubert Content-Type: text/plain; charset=ISO-8859-1 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , cpet@sdf.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:10:44 -0000 ACER WMI/ACPI? Sure, i'll mentor you if you're going to do _that_. Adrian On 15 April 2013 09:55, Cy Schubert 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 > FreeBSD UNIX: Web: http://www.FreeBSD.org > > > In message <8adc8f0961dd8f7972300837db7403ce.squirrel@ma.sdf.org>, > cpet@sdf.org > writes: >> Ok, seems someone has taken the job. >> >> >> > In message , Warren Block >> > writ >> > es: >> >> On Sun, 14 Apr 2013, Chris Rees wrote: >> >> >> >> > On 14 April 2013 01:41, Rui Paulo wrote: >> >> >> 2013/04/13 16:01?Scott Long ??????: >> >> >> >> >> >>> 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 >> > FreeBSD UNIX: 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-unsubscribe@freebsd.org" >> > >> >> > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 17:48:56 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E33F7EB; Mon, 15 Apr 2013 17:48:56 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7AA3B10C3; Mon, 15 Apr 2013 17:48:55 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=MyE6jBz-AAAA:8 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=WboiWaibMC_ph7dsMDUA:9 a=CjuIK1q_8ugA:10 a=aLekXsIfG0IA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 11:49:12 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 8D5B480; Mon, 15 Apr 2013 10:48:44 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FHmhC3002734; Mon, 15 Apr 2013 10:48:43 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151748.r3FHmhC3002734@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Rui Paulo Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Rui Paulo of "Mon, 15 Apr 2013 10:09:17 -0700." <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 10:48:43 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:48:56 -0000 In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo writes: > 2013/04/15 9:55$B!"(BCy Schubert $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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 17:52:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEAACB7E for ; Mon, 15 Apr 2013 17:52:39 +0000 (UTC) (envelope-from sodynet1@gmail.com) Received: from mail-pa0-f52.google.com (mail-pa0-f52.google.com [209.85.220.52]) by mx1.freebsd.org (Postfix) with ESMTP id C473D111A for ; Mon, 15 Apr 2013 17:52:39 +0000 (UTC) Received: by mail-pa0-f52.google.com with SMTP id fb10so2688514pad.11 for ; Mon, 15 Apr 2013 10:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=aloX4L2ZJmy8mCPAgU9PneZ7L1/UzszCvfX0ZhhjzIQ=; b=LENIxoVtYlzMhv3TywTZ81EbHRy/LMtohy8JiDyQ/wcVB/ah8GWqEKR8HktJU4pyM6 ZPw1yGsSQim2RAdoPphCMAx6VbzC+2Iw4WbHgKOV0EGUx8fKZxMPL0Yu7cIylVcNGRBH ZukBjmR0leD1AWblyshK446ED6pBmGgq3jphTbFpVsl6TAReoX1/RerXXVUbtRKY/mCC jKrZR8e+buSe5pAnZpchZIXE1rxFiZdj0tmF5oLOWd11X4TzjTSEVQUAstfp6QYBqjlw Ez2xPqnYdMfaN1URXZeMaIPWq/hI4hFyuZMIH1GQv1UippqiwR64RQZV0ci7Eh1SCj0s a80g== MIME-Version: 1.0 X-Received: by 10.68.44.169 with SMTP id f9mr17820797pbm.29.1366048358950; Mon, 15 Apr 2013 10:52:38 -0700 (PDT) Received: by 10.70.100.132 with HTTP; Mon, 15 Apr 2013 10:52:38 -0700 (PDT) Date: Mon, 15 Apr 2013 20:52:38 +0300 Message-ID: Subject: using netmap From: Sami Halabi To: Luigi Rizzo , "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 17:52:40 -0000 Hi, I would like to start using netmap. as a start i copied the example from netmap page: #include #include #include #include int main() { struct netmap_if *nifp; struct nmreq req; int i, len; char *buf; FILE* fd; fd = open("/dev/netmap", 0); strcpy(req.nr_name, "em1"); // register the interface ioctl(fd, NIOCREG, &req); // offset of the structure mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0); nifp = NETMAP_IF(mem, req.nr_offset); for (;;) { struct pollfd x[1]; struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0); x[0].fd = fd; x[0].events = POLLIN; poll(x, 1, 1000); for ( ; ring->avail > 0 ; ring->avail--) { i = ring->cur; buf = NETMAP_BUF(ring, i); use_data(buf, ring->slot[i].len); ring->cur = NETMAP_NEXT(ring, i); } } return 0; } and tried to compile: root@fbsd1:~/netmap # gcc -O2 -pipe -Werror -Wall -I ../sys -Wextra -c n.c In file included from n.c:4: /usr/include/net/netmap.h:139: error: expected specifier-qualifier-list before 'uint32_t' /usr/include/net/netmap.h:228: error: expected ':', ',', ';', '}' or '__attribute__' before 'num_slots' /usr/include/net/netmap.h:255: error: 'IFNAMSIZ' undeclared here (not in a function) /usr/include/net/netmap.h:256: error: expected ':', ',', ';', '}' or '__attribute__' before 'ni_version' /usr/include/net/netmap.h:292: error: expected specifier-qualifier-list before 'uint32_t' cc1: warnings being treated as errors n.c: In function 'main': n.c:14: warning: implicit declaration of function 'open' n.c:14: warning: assignment makes pointer from integer without a cast n.c:15: warning: implicit declaration of function 'strcpy' n.c:15: warning: incompatible implicit declaration of built-in function 'strcpy' n.c:16: warning: implicit declaration of function 'ioctl' n.c:16: error: 'NIOCREG' undeclared (first use in this function) n.c:16: error: (Each undeclared identifier is reported only once n.c:16: error: for each function it appears in.) n.c:17: error: 'mem' undeclared (first use in this function) n.c:17: error: 'struct nmreq' has no member named 'nr_memsize' n.c:17: error: 'PROT_READ' undeclared (first use in this function) n.c:17: error: 'PROT_WRITE' undeclared (first use in this function) n.c:17: warning: passing argument 5 of 'mmap' makes integer from pointer without a cast n.c:18: error: 'struct nmreq' has no member named 'nr_offset' n.c:20: error: array type has incomplete element type n.c:21: warning: implicit declaration of function 'NETMAP_RX_RING' n.c:21: warning: initialization makes pointer from integer without a cast n.c:24: error: 'POLLIN' undeclared (first use in this function) n.c:25: warning: implicit declaration of function 'poll' n.c:26: error: 'struct netmap_ring' has no member named 'avail' n.c:26: error: 'struct netmap_ring' has no member named 'avail' n.c:27: error: 'struct netmap_ring' has no member named 'cur' n.c:28: error: 'struct netmap_ring' has no member named 'nr_buf_size' n.c:29: warning: implicit declaration of function 'use_data' n.c:29: error: 'struct netmap_ring' has no member named 'slot' n.c:30: error: 'struct netmap_ring' has no member named 'cur' n.c:30: warning: implicit declaration of function 'NETMAP_NEXT' n.c:20: warning: unused variable 'x' n.c:10: warning: unused variable 'len' root@fbsd1:~/netmap # can you help me figure it out? Thanks in advance, -- Sami Halabi Information Systems Engineer NMS Projects Expert FreeBSD SysAdmin Expert From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 18:15:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D33D12C6 for ; Mon, 15 Apr 2013 18:15:51 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) by mx1.freebsd.org (Postfix) with ESMTP id A0F7611FD for ; Mon, 15 Apr 2013 18:15:51 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id ta14so1136435obb.14 for ; Mon, 15 Apr 2013 11:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=JzpUJDYqDbVz87Qym7fIy/WDya009wh2Ej3JKgJaZ18=; b=F7O1emhIchS1vhvhQoYW1osRFpKMoK1A69Nrjul6J5uisCznVg6zhMc+s3m4odKxmB ptTUwiDXJJKlGl6GdzOTPoQeziYUKoCT8S2kbIcvshm4L8E2jGh50Ga0AjvhkmSFSrwl Era/DnP1DV5ed935ZQl3VIFQ2jkFDAObgGACzgSbhrmLtvf6QaB5ySCjEhY1mKLkOH1E Q5TjpbcB7ugL8rGBkEATV7UtshaW9VILX/kVotqoYhFdYBGStDEe528tu+RhDNeei9TS 0SeG7cv0oRUH/07XTjc4zs0GwSU8IcUIbzRWfmr6MVVzabI5ZnYqbPQpchinVW6LSVsY 8tUg== MIME-Version: 1.0 X-Received: by 10.60.76.234 with SMTP id n10mr7862907oew.63.1366049751156; Mon, 15 Apr 2013 11:15:51 -0700 (PDT) Received: by 10.76.122.81 with HTTP; Mon, 15 Apr 2013 11:15:51 -0700 (PDT) In-Reply-To: References: Date: Mon, 15 Apr 2013 20:15:51 +0200 Message-ID: Subject: Re: using netmap From: Andreas Nilsson To: Sami Halabi Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Luigi Rizzo X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:15:51 -0000 On Mon, Apr 15, 2013 at 7:52 PM, Sami Halabi wrote: > Hi, > I would like to start using netmap. > > as a start i copied the example from netmap > page: > #include > #include > #include > #include > > int main() { > > struct netmap_if *nifp; > struct nmreq req; > int i, len; > char *buf; > FILE* fd; > > fd = open("/dev/netmap", 0); > strcpy(req.nr_name, "em1"); // register the interface > ioctl(fd, NIOCREG, &req); // offset of the structure > mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0); > nifp = NETMAP_IF(mem, req.nr_offset); > for (;;) { > struct pollfd x[1]; > struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0); > > x[0].fd = fd; > x[0].events = POLLIN; > poll(x, 1, 1000); > for ( ; ring->avail > 0 ; ring->avail--) { > i = ring->cur; > buf = NETMAP_BUF(ring, i); > use_data(buf, ring->slot[i].len); > ring->cur = NETMAP_NEXT(ring, i); > } > } > > return 0; > } > > > and tried to compile: > root@fbsd1:~/netmap # gcc -O2 -pipe -Werror -Wall -I ../sys -Wextra -c n.c > In file included from n.c:4: > /usr/include/net/netmap.h:139: error: expected specifier-qualifier-list > before 'uint32_t' > /usr/include/net/netmap.h:228: error: expected ':', ',', ';', '}' or > '__attribute__' before 'num_slots' > /usr/include/net/netmap.h:255: error: 'IFNAMSIZ' undeclared here (not in a > function) > /usr/include/net/netmap.h:256: error: expected ':', ',', ';', '}' or > '__attribute__' before 'ni_version' > /usr/include/net/netmap.h:292: error: expected specifier-qualifier-list > before 'uint32_t' > cc1: warnings being treated as errors > n.c: In function 'main': > n.c:14: warning: implicit declaration of function 'open' > n.c:14: warning: assignment makes pointer from integer without a cast > n.c:15: warning: implicit declaration of function 'strcpy' > n.c:15: warning: incompatible implicit declaration of built-in function > 'strcpy' > n.c:16: warning: implicit declaration of function 'ioctl' > n.c:16: error: 'NIOCREG' undeclared (first use in this function) > n.c:16: error: (Each undeclared identifier is reported only once > n.c:16: error: for each function it appears in.) > n.c:17: error: 'mem' undeclared (first use in this function) > n.c:17: error: 'struct nmreq' has no member named 'nr_memsize' > n.c:17: error: 'PROT_READ' undeclared (first use in this function) > n.c:17: error: 'PROT_WRITE' undeclared (first use in this function) > n.c:17: warning: passing argument 5 of 'mmap' makes integer from pointer > without a cast > n.c:18: error: 'struct nmreq' has no member named 'nr_offset' > n.c:20: error: array type has incomplete element type > n.c:21: warning: implicit declaration of function 'NETMAP_RX_RING' > n.c:21: warning: initialization makes pointer from integer without a cast > n.c:24: error: 'POLLIN' undeclared (first use in this function) > n.c:25: warning: implicit declaration of function 'poll' > n.c:26: error: 'struct netmap_ring' has no member named 'avail' > n.c:26: error: 'struct netmap_ring' has no member named 'avail' > n.c:27: error: 'struct netmap_ring' has no member named 'cur' > n.c:28: error: 'struct netmap_ring' has no member named 'nr_buf_size' > n.c:29: warning: implicit declaration of function 'use_data' > n.c:29: error: 'struct netmap_ring' has no member named 'slot' > n.c:30: error: 'struct netmap_ring' has no member named 'cur' > n.c:30: warning: implicit declaration of function 'NETMAP_NEXT' > n.c:20: warning: unused variable 'x' > n.c:10: warning: unused variable 'len' > root@fbsd1:~/netmap # > > > can you help me figure it out? > > Thanks in advance, > > -- > Sami Halabi > Information Systems Engineer > NMS Projects Expert > FreeBSD SysAdmin Expert > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > Hello Sami, First, I'm by no means an expert on NETMAP, but the url you provided says that it's a snapshot, not a ready progam. There are a few fully working examples in tools/tools/netmap/ subdir of at least 9-STABLE and 10-CURRENT. Maybe you can find an example to start with there instead? Quite a few of the errors are from regular syscalls, and each of them have a manpage that says which files to include, and compiling stuff with -Werror assumes you can deal with "picky" compilers. Hope you come up with a working example. Best regards Andreas From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 18:49:21 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EFAA3C2D; Mon, 15 Apr 2013 18:49:20 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vb0-x235.google.com (mail-vb0-x235.google.com [IPv6:2607:f8b0:400c:c02::235]) by mx1.freebsd.org (Postfix) with ESMTP id 8D146132D; Mon, 15 Apr 2013 18:49:20 +0000 (UTC) Received: by mail-vb0-f53.google.com with SMTP id i3so3982107vbh.26 for ; Mon, 15 Apr 2013 11:49:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=FjVV7VOsNjGtJCWgVclbNWEX2Wdf0BAhoFTKy4HyTY8=; b=skhejkY0dHHPB8NDe2rA5bEdCZ14UeAliEEw/63/8B1DwqsmdBhsf0ua7I1//WsHw4 nr12fcmz2ErB1zsxRRMsAAyV//dwA0jGSEdpTbb1NJZ3P/f7CnNU9vn21f5niqXB2otB UjRdyjzhYhuMOPfrKXFhu+bvjVP4ZLBfiLqxbxObZg1TcxlBBgZlsp23i2rt0srByvqz wWFOvvrgnSdRZwaKZCNFRu8bestG9Yoi8URsot7LW0jDGaKaVKanZkLmx7j2GsC/iYG9 z6VrEw63Eq5EKBeNlm2FTRjlabHdlXSxH8opeJAo0CtYtw0ve4mnkn1nLfOkAckESekx Wd0A== MIME-Version: 1.0 X-Received: by 10.220.106.14 with SMTP id v14mr17014585vco.2.1366051760054; Mon, 15 Apr 2013 11:49:20 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Mon, 15 Apr 2013 11:49:19 -0700 (PDT) In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 14:49:19 -0400 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: Cy Schubert Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:49:21 -0000 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 wrot= e: > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo > writes: > > 2013/04/15 9:55=E3=80=81Cy Schubert =E3=81= =AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > > > > > 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 tw= o > > > 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 som= e > 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 ma= de > 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 longe= st > 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 woul= d > be a loss. > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: 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-unsubscribe@freebsd.org= " > --=20 Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 18:54:21 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3339FDF0 for ; Mon, 15 Apr 2013 18:54:21 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm11-vm3.bullet.mail.ne1.yahoo.com (nm11-vm3.bullet.mail.ne1.yahoo.com [98.138.91.141]) by mx1.freebsd.org (Postfix) with ESMTP id E8F621362 for ; Mon, 15 Apr 2013 18:54:20 +0000 (UTC) Received: from [98.138.90.49] by nm11.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 Received: from [98.138.226.125] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 Received: from [127.0.0.1] by smtp204.mail.ne1.yahoo.com with NNFMP; 15 Apr 2013 18:54:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366052053; bh=V/xNCL3BbI6r2ZxwodymFOu0kCpQSC5l15IWEoXIFuY=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=yi8RhwxL3JQK9oCGh7IytdVXfuFbUZGL2EZvauipAU3wLC3qIvbbXK9CGgzN7XrOICiKA5uC8o4oWP2NHNj37ZilhtRFVXBChGKQ0z3D7VeVw0ytI5gjuzBHWvbCerTOXjS2sOiIqt4wLZtC+Ine6z/vecLx7otht69QnKmDQLY= X-Yahoo-Newman-Id: 804993.13129.bm@smtp204.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: WHZN.SwVM1kdI99PkbAVnxVr4v78xA4Xst1WwRVWlnXYzFa fFQ7iAMZ.UO514xAUrqi2hMg4JpihDswZopfd6SkiJSt5aau7BWuO4tHzDJb ly8Ra0939r0uL40lezOFSY0O_itQTqYtvuN6DL6A0INy6x32vhSsvIPZ2TX8 6WYPB7wdC7PQoK.BRAlpRw9fQklMknXKmkOYV8PpjJYrM7uD80hmtm2mCF3h .k9hpZrb.xxgaPMQiFoXwjcFyoS8KfyjbHWgjrEwMInucKoPFbdtgcT34dHW 48ExickgcGfDMlhm7BLwUMjj.0ztsSKovW2BIkYY.AoaO5oqyr16uVokvTqq clbWezqNHjWX6cTTRiMKzgiqY7Vn7qLUrA0L1VdkxUWsLSBhbExcJ0hV7iBV N.x07rdnVGOLEf1lvydEW4Wl4LQauVHkcm2iq2Aelc6QIcQeNOav8vJv9U8p hJFobkO8UJZOi X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with plain) by smtp204.mail.ne1.yahoo.com with SMTP; 15 Apr 2013 11:54:13 -0700 PDT Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: Date: Mon, 15 Apr 2013 12:54:12 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> To: "Sam Fourman Jr." X-Mailer: Apple Mail (2.1503) Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:54:21 -0000 The desire to remove it stems from the inability to give it adequate = engineering=20 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." = wrote: > Thank you to those that have expressed interest in maintaining IP = Filter.. >=20 > 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. >=20 > Sam Fourman Jr. >=20 >=20 > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert = wrote: >=20 >> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo >> writes: >>> 2013/04/15 9:55=E3=80=81Cy Schubert = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: >>>=20 >>>> 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. >>>=20 >>> 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? >>=20 >> 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. >>=20 >> I'm not sure if I'd MFC it into 9 or not. >>=20 >> 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. >>=20 >>>=20 >>> Why do you want to work on something that people have been trying to >> remove s >>> ince 2005? >>=20 >> 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. >>=20 >>=20 >> -- >> Cheers, >> Cy Schubert >> FreeBSD UNIX: Web: http://www.FreeBSD.org >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" >>=20 >=20 >=20 >=20 > --=20 >=20 > Sam Fourman Jr. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 18:54:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BC83E86; Mon, 15 Apr 2013 18:54:44 +0000 (UTC) (envelope-from sfourman@gmail.com) Received: from mail-vc0-f176.google.com (mail-vc0-f176.google.com [209.85.220.176]) by mx1.freebsd.org (Postfix) with ESMTP id ADB16136D; Mon, 15 Apr 2013 18:54:43 +0000 (UTC) Received: by mail-vc0-f176.google.com with SMTP id hf12so4124080vcb.7 for ; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=b11ecb/K+a8WPRlSgj3UFo4QpM0Qg2eo3TCnuKuc8Yo=; b=qfWHoNlTBke+WuD+BkrpzETt2gu1Dp+pHKNRVyI/dByGuDJkND+7CaFtOMBfN6t+Ei AoOe/Pegj21UK4YXJZimOjsBW3bfYC/atXbs6U1OHS0Oz5XTToOLBS++uiqSK6QKXWoY 0uY9z9hAlNo1ArWx4ci1CThCNm88nSFjnLgs9xhGNAxyLb4ohjYO+nUrZvXTutnzjfjF 9DNt83bc5hEKNbhGqcqjNcpO2pPhXU3AGfvYRHU7B5gd4hUgkL7U0468KsIYTL92gxTF xwO57LdK5BkxbgnhRK3ESGU1FJzE9aUerKempvdr7GjTzycMWbA62/kjKzJia+uYmwmr 23pw== MIME-Version: 1.0 X-Received: by 10.52.89.229 with SMTP id br5mr7580751vdb.24.1366052077614; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) Received: by 10.220.61.11 with HTTP; Mon, 15 Apr 2013 11:54:37 -0700 (PDT) In-Reply-To: References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 14:54:37 -0400 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: "Sam Fourman Jr." To: Cy Schubert Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:54:44 -0000 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. 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 wrote: > >> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo >> writes: >> > 2013/04/15 9:55$B!"(BCy Schubert $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 >> FreeBSD UNIX: 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-unsubscribe@freebsd.org >> " >> > > > > -- > > Sam Fourman Jr. > -- Sam Fourman Jr. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 18:56:14 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 00BF9318 for ; Mon, 15 Apr 2013 18:56:13 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm4-vm0.bullet.mail.bf1.yahoo.com (nm4-vm0.bullet.mail.bf1.yahoo.com [98.139.213.129]) by mx1.freebsd.org (Postfix) with SMTP id 7DC4A13AA for ; Mon, 15 Apr 2013 18:56:12 +0000 (UTC) Received: from [98.139.215.142] by nm4.bullet.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 Received: from [98.139.213.2] by tm13.bullet.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 Received: from [127.0.0.1] by smtp102.mail.bf1.yahoo.com with NNFMP; 15 Apr 2013 18:56:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366052166; bh=w7UvLY2kbxUpjeDCeAOpS2Mt4voXIkP6UxbCCukEFFE=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=NpA30B7wvZWKXKqIyKd24QAHUkcPbrIk3Xw42T+bvGOXGav6nz39pJ+i+ZwHP1xpXIy1DcgsP4FSIKzGlTyAekexMcOkh30pTiZOpjLaB3oJzV5I1AVSEY3GpTD59TuXIYlwGUq7MF4tjSk7/pov+A1TZ7fpQkZH0HoWTONa09M= X-Yahoo-Newman-Id: 463229.98655.bm@smtp102.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ewwQPWAVM1kM2PPbK8Bs92HNlKp8xz.ZqWqDaOIW5QdeI_q gH_52h3rleY_0F94nkeyyP_7l9VCKEhk0nlvleojJTLRVN4EcUr9lF9sQLnl JZXSkBBysXdnrygWVDWKEbt8lzkDB6yYu2fY_dTa4n_Y2eqbxB7w1ETCIfig kf5rWdz5TyfeaehI0VgbOcNofORHiyDHk6M77OElsQendKrTNlJAS7sftFDC qafVDlNhWq3JxbcpCovay8HeCb25LWoWmsAlb8CRdWMDrwyuYlRvCtJL4dkz ruMrsl54D5BJK7WY55bmMP.beEG5yHiXhcewd3Fzxt4cRXbEzRLmVB5__VtR Iq07YA28tzL4aKiNehnbkR.slVyJD4Bb9zmFpYP6G3elOuuZeJ4s0gbgxHv8 98o8KfdnaIXlSFjCAH1MBbVSRVIbtYNSPWyoHkc_qNeInlp03ehNUPDLjaEV nS2teePsck9tt X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with ) by smtp102.mail.bf1.yahoo.com with SMTP; 15 Apr 2013 11:56:06 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> Date: Mon, 15 Apr 2013 12:56:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201304151748.r3FHmhC3002734@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1503) Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 18:56:14 -0000 On Apr 15, 2013, at 11:48 AM, Cy Schubert = wrote: > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo=20 > writes: >> 2013/04/15 9:55=1B$B!"=1B(BCy Schubert = =1B$B$N%a%C%;!<%8=1B(B: >>=20 >>> I've been planning on taking on IP Filter for quite some time.=20 >>> Unfortunately I've left my src commit bit lapse (my ports commit bit = is=20 >>> alive and well though) thus I'm looking for a mentor. In addition = I'm=20 >>> working on an ACER WMI/ACPI kld. One mentor would be preferred but = two=20 >>> would be fine too. >>=20 >> 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? >=20 > The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ = hadn't=20 > done much with IPF while employed with Sun. Since then there has been = some=20 > development that is long overdue for HEAD. >=20 > I'm not sure if I'd MFC it into 9 or not. >=20 > I did consider a port but given it would has to touch bits and pieces = of=20 > the source tree (/usr/src), a port would be messy and the decision was = made=20 > to work on importing it into base. >=20 >>=20 >> Why do you want to work on something that people have been trying to = remove s >> ince 2005? >=20 > I and others have been using it in FreeBSD for over decade. For the = longest=20 > of time we'd use a common set of rules across a FreeBSD and Solaris = farm=20 > (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).=20 > Interoperability with other systems which use IP Filter is a plus. If=20= > there's a maintainer, it only makes FreeBSD richer. Losing IP Filter = would=20 > be a loss. >=20 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= From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:27:57 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5625692E; Mon, 15 Apr 2013 19:27:57 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id C6E3315CE; Mon, 15 Apr 2013 19:27:56 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=CjxXgO3LAAAA:8 a=BWvPGDcYAAAA:8 a=MyE6jBz-AAAA:8 a=6I5d2MoRAAAA:8 a=VjTKFRfQl6pNXV81uPAA:9 a=CjuIK1q_8ugA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=aLekXsIfG0IA:10 a=SV7veod9ZcQA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 13:28:23 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id B1CE180; Mon, 15 Apr 2013 12:27:55 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJRtq9002799; Mon, 15 Apr 2013 12:27:55 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151927.r3FJRtq9002799@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Scott Long Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Scott Long of "Mon, 15 Apr 2013 12:56:04 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 12:27:55 -0700 Cc: Warren Block , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:27:57 -0000 In message , Scott Long writes: > > On Apr 15, 2013, at 11:48 AM, Cy Schubert wrote: > > > In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui Paulo > > writes: > >> 2013/04/15 9:55$B!"(BCy Schubert $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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:39:21 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EDA2EECE for ; Mon, 15 Apr 2013 19:39:21 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm15-vm1.bullet.mail.gq1.yahoo.com (nm15-vm1.bullet.mail.gq1.yahoo.com [98.137.176.73]) by mx1.freebsd.org (Postfix) with SMTP id C4A0E1653 for ; Mon, 15 Apr 2013 19:39:21 +0000 (UTC) Received: from [98.137.12.59] by nm15.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 Received: from [208.71.42.192] by tm4.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 Received: from [127.0.0.1] by smtp203.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 19:32:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366054369; bh=Kk7m3nLVDM0MkNiUhi/dfXMTZv2Mi0EAIB4MzrrfzDw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=h4aw3r9Y8bYtF908foPPVPjEicfLpH5gvdA0P9nNvoY5oglKpWZl0eNEJEpfOZqmuWojOiSu0FZGPQm443E2yplS3BiehpdCrmPn6WGs8POUdgSXm9hUbpul45aQ/Ad3daObiDMwvGPP3K8JXnNfSHXutGhWkqqwMviebgarbbA= X-Yahoo-Newman-Id: 407737.54732.bm@smtp203.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MMg.9N0VM1ntHCRxlyk7F7vdB4eTuNecSUnPLzijZCHmTka 0jYwo2NdLiNDzYIcEuz.1fdpGSCCBxxshQxphmCfSinXlwnYhWH0P0qFZiXp 7rBspGhPAclGENhKw05yDOsNGK9WPCztv1UWaGo_YvGRZnufnV.nm3mZ2bIH o5eHkAvkNFXhrZXCDICIB2sGh57_ZT_m2BdSm82yy9Ba8OpWiCq.AMlX3Fp_ iCRsXOdLIy0UZDQgjeO0cu9PgyyCXuPQTT1ULvJo2yy5gEbd_yOc6x7tWm1T vs0tYlxjtP0FQI_3cPMatE4HOz1kqozzxh_yPsACiMeQMz4dwMCajoDv7w9F J4OFaDsKPAz_cYPq0qnQMCFQBhc8sXuwQ8NIX3c9lSHnHf7MxbO3uQmWJuNX A5Lo4vaC31baO_SpfultBqqXNLGf67TMHMzvtIl53Z8BdEfPq1aWgqegHnTD cCtW9klYqf0lQMpMw6TOc3swanRmAM.u2pL8QOGvemC3R7tzvxQY- X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- X-Rocket-Received: from [192.168.254.206] (scott4long@168.103.85.57 with plain) by smtp203.mail.gq1.yahoo.com with SMTP; 15 Apr 2013 12:32:49 -0700 PDT Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Subject: Re: ipfilter(4) needs maintainer From: Scott Long In-Reply-To: <201304151927.r3FJRtq9002799@slippy.cwsent.com> Date: Mon, 15 Apr 2013 13:32:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.1503) Cc: Warren Block , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:39:22 -0000 On Apr 15, 2013, at 1:27 PM, Cy Schubert = wrote: > In message , Scott = Long=20 > writes: >>=20 >> On Apr 15, 2013, at 11:48 AM, Cy Schubert = wrote: >>=20 >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, Rui = Paulo=20 >>> writes: >>>> 2013/04/15 9:55=1B$B!"=1B(BCy Schubert = =1B$B$N%a%C%;!<%8=1B >> (B: >>>>=20 >>>>> I've been planning on taking on IP Filter for quite some time.=20 >>>>> Unfortunately I've left my src commit bit lapse (my ports commit = bit is=20 >>>>> alive and well though) thus I'm looking for a mentor. In addition = I'm=20 >>>>> working on an ACER WMI/ACPI kld. One mentor would be preferred but = two=20 >>>>> would be fine too. >>>>=20 >>>> 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? >>>=20 >>> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ = hadn't=20 >>> done much with IPF while employed with Sun. Since then there has = been some=20 >>> development that is long overdue for HEAD. >>>=20 >>> I'm not sure if I'd MFC it into 9 or not. >>>=20 >>> I did consider a port but given it would has to touch bits and = pieces of=20 >>> the source tree (/usr/src), a port would be messy and the decision = was made >>=20 >>> to work on importing it into base. >>>=20 >>>>=20 >>>> Why do you want to work on something that people have been trying = to remov >> e s >>>> ince 2005? >>>=20 >>> I and others have been using it in FreeBSD for over decade. For the = longest >>=20 >>> of time we'd use a common set of rules across a FreeBSD and Solaris = farm=20 >>> (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo).=20 >>> Interoperability with other systems which use IP Filter is a plus. = If=20 >>> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter = would=20 >>> be a loss. >>>=20 >>=20 >>=20 >> 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? >=20 > I would think this would be my top priority right now. I'd like to see = it=20 > at the latest level in HEAD. I would like to MFC to 9-STABLE at some = point. >=20 > Given that IPF already lives in src/contrib and src/sys/contrib, would = the=20 > change in License from Darren Reed's own not so BSD friendly IPF = license to=20 > GPLv2 be of concern. I recall there was a lot of concern over IPF's = license=20 > change at the time. (FreeBSD moved it to contrib while OpenBSD removed = it=20 > completely and wrote PF -- I'm not sure what NetBSD did). >=20 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 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:48:38 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8036B2D4; Mon, 15 Apr 2013 19:48:38 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id A5FD816A8; Mon, 15 Apr 2013 19:48:37 +0000 (UTC) Message-ID: <516C58ED.40505@FreeBSD.org> Date: Mon, 15 Apr 2013 15:45:49 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130408 Thunderbird/17.0.5 MIME-Version: 1.0 To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> In-Reply-To: <201304151927.r3FJRtq9002799@slippy.cwsent.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:48:38 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: > In message , Scott > Long writes: >> >> On Apr 15, 2013, at 11:48 AM, Cy Schubert >> wrote: >> >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, >>> Rui Paulo writes: >>>> 2013/04/15 9:55$B!"(BCy Schubert >>>> $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----- From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:55:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 905EC520; Mon, 15 Apr 2013 19:55:55 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1BF1616F3; Mon, 15 Apr 2013 19:55:54 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FJtiRO001999; Mon, 15 Apr 2013 23:55:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FJtiq6001998; Mon, 15 Apr 2013 23:55:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 15 Apr 2013 23:55:44 +0400 From: Gleb Smirnoff To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415195544.GY76816@FreeBSD.org> References: <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com> <201304151748.r3FHmhC3002734@slippy.cwsent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:55:55 -0000 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. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 20:12:47 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 94120AD9; Mon, 15 Apr 2013 20:12:47 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 20D1817AC; Mon, 15 Apr 2013 20:12:47 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=BWvPGDcYAAAA:8 a=N9rBXh7b3HRsED3skiAA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 14:11:33 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 872BE80; Mon, 15 Apr 2013 13:12:40 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FKCdI3085567; Mon, 15 Apr 2013 13:12:39 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304152012.r3FKCdI3085567@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Gleb Smirnoff of "Mon, 15 Apr 2013 23:55:44 +0400." <20130415195544.GY76816@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 13:12:39 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 20:12:47 -0000 In message <20130415195544.GY76816@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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:15:53 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D147B730; Mon, 15 Apr 2013 19:15:53 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by mx1.freebsd.org (Postfix) with ESMTP id 4F7C71569; Mon, 15 Apr 2013 19:15:53 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=PW5KkOyi2N+7koGLNuH5QW2TYwO584XWNobLzFE45Rc= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=8nJEP1OIZ-IA:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=BWvPGDcYAAAA:8 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=pGLkceISAAAA:8 a=MyE6jBz-AAAA:8 a=1CH5QDEJChWIyTtZLrIA:9 a=wPNLvfGTeEIA:10 a=V7tsTZBp22UA:10 a=SV7veod9ZcQA:10 a=rC2wZJ5BpNYA:10 a=MSl-tDqOz04A:10 a=aLekXsIfG0IA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by idcmail-mo2no.shaw.ca with ESMTP; 15 Apr 2013 13:16:19 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id CAC5E80; Mon, 15 Apr 2013 12:15:50 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJFnM1002686; Mon, 15 Apr 2013 12:15:49 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151915.r3FJFnM1002686@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Scott Long Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Scott Long of "Mon, 15 Apr 2013 12:54:12 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Mon, 15 Apr 2013 12:15:49 -0700 X-Mailman-Approved-At: Mon, 15 Apr 2013 20:39:07 +0000 Cc: Warren Block , "current@freebsd.org" , darrenr@freebsd.org, Chris Rees , Cy Schubert , Rui Paulo , "net@freebsd.org" , "Sam Fourman Jr." , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:15:53 -0000 It was pointed out to me that Darren Reed has changed licenses from his I= P=20 Filter license that's been in IPF since 2005 or so, when he joined Sun, t= o=20 GPLv2 (probably when Darren left when Oracle took over Sun). Given that I= PF=20 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.= =20 If not then a port is in order. Having said that, a port would be messy a= s=20 IPF's own install scripts update src/sys/netinet, among other locations. --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org In message , Scott Long= =20 writes: > The desire to remove it stems from the inability to give it adequate en= gineer > ing=20 > 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 happ= ening=20 > in > the network stack, and it shouldn't be left to rot nor to be a stumblin= g bloc > k for > those changes. >=20 > Scott >=20 > On Apr 15, 2013, at 12:49 PM, =22Sam Fourman Jr.=22 wrote: >=20 > > Thank you to those that have expressed interest in maintaining IP Fil= ter.. > >=20 > > My thoughts are, could we consider putting a option in the kernel con= fig, > > and leaving it off by default for GENERIC? > > I think this is a acceptable compromise, considering some people wish= for > > it to be removed. > >=20 > > Sam Fourman Jr. > >=20 > >=20 > > On Mon, Apr 15, 2013 at 1:48 PM, Cy Schubert wrot > e: > >=20 > >> In message <18DF99B0-6E66-4906-A233-7778451B8A92=40felyko.com>, Rui = Paulo > >> writes: > >>> 2013/04/15 9:55=E3=80=81Cy Schubert = =E3=81=AE=E3=83=A1=E3=83=83=E3=82=BB=E3=83=BC=E3=82=B8: > >>>=20 > >>>> 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 b= it 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. > >>>=20 > >>> What are your plans regarding ipfilter? I remain unconvinced that i= t > >> should b > >>> e in the base system. Perhaps you can work on it as a port? > >>=20 > >> The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr=40= hadn't > >> done much with IPF while employed with Sun. Since then there has bee= n some > >> development that is long overdue for HEAD. > >>=20 > >> I'm not sure if I'd MFC it into 9 or not. > >>=20 > >> I did consider a port but given it would has to touch bits and piece= s of > >> the source tree (/usr/src), a port would be messy and the decision w= as mad > e > >> to work on importing it into base. > >>=20 > >>>=20 > >>> Why do you want to work on something that people have been trying t= o > >> remove s > >>> ince 2005? > >>=20 > >> 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. I= f > >> there's a maintainer, it only makes FreeBSD richer. Losing IP Filter= would > >> be a loss. > >>=20 > >>=20 > >> -- > >> Cheers, > >> Cy Schubert > >> FreeBSD UNIX: Web: http://www.FreeBSD.org > >>=20 > >>=20 > >> _______________________________________________ > >> freebsd-current=40freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to =22freebsd-current-unsubscribe=40fr= eebsd.org=22 > >>=20 > >=20 > >=20 > >=20 > > --=20 > >=20 > > Sam Fourman Jr. > > _______________________________________________ > > freebsd-net=40freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to =22freebsd-net-unsubscribe=40freebsd= .org=22 >=20 >=20 From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 19:52:46 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C62104EA; Mon, 15 Apr 2013 19:52:46 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-01.shaw.ca (smtp-out-01.shaw.ca [64.59.136.137]) by mx1.freebsd.org (Postfix) with ESMTP id 323E016DE; Mon, 15 Apr 2013 19:52:46 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=SNukfclIDc7GjKe+LHtSoPUBJt/gHPuqMk7EpfoOdzs= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=CjxXgO3LAAAA:8 a=BWvPGDcYAAAA:8 a=MyE6jBz-AAAA:8 a=_ctWjzdLAAAA:8 a=j8UoxrQNBuIlFuJTPtQA:9 a=CjuIK1q_8ugA:10 a=FvmvQ9K01c4A:10 a=fzi2j93kHG4A:10 a=SV7veod9ZcQA:10 a=rC2wZJ5BpNYA:10 a=V7tsTZBp22UA:10 a=aLekXsIfG0IA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-01.shaw.ca with ESMTP; 15 Apr 2013 13:51:37 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 2CE3880; Mon, 15 Apr 2013 12:52:44 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3FJqhh5003278; Mon, 15 Apr 2013 12:52:43 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304151952.r3FJqhh5003278@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Jung-uk Kim Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Jung-uk Kim of "Mon, 15 Apr 2013 15:45:49 -0400." <516C58ED.40505@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 12:52:43 -0700 X-Mailman-Approved-At: Mon, 15 Apr 2013 20:39:19 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 19:52:46 -0000 In message <516C58ED.40505@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 , Scott > > Long writes: > >> > >> On Apr 15, 2013, at 11:48 AM, Cy Schubert > >> wrote: > >> > >>> In message <18DF99B0-6E66-4906-A233-7778451B8A92@felyko.com>, > >>> Rui Paulo writes: > >>>> 2013/04/15 9:55$B!"(BCy Schubert > >>>> $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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 21:28:42 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B5C52547; Mon, 15 Apr 2013 21:28:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 42DFB1C09; Mon, 15 Apr 2013 21:28:41 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FLSRUZ002620; Tue, 16 Apr 2013 01:28:27 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FLSQRL002619; Tue, 16 Apr 2013 01:28:26 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 16 Apr 2013 01:28:26 +0400 From: Gleb Smirnoff To: cpet@sdf.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415212826.GA76816@FreeBSD.org> References: <201304151433.r3FEX3c3005916@slippy.cwsent.com> <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <6c9262f9ddbd3b86824a43f76de513fa.squirrel@ma.sdf.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , Cy Schubert X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:28:42 -0000 On Mon, Apr 15, 2013 at 04:47:33PM -0000, cpet@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. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 21:34:35 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B53D84B; Mon, 15 Apr 2013 21:34:35 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 919EB1C55; Mon, 15 Apr 2013 21:34:33 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r3FLYVNp002671; Tue, 16 Apr 2013 01:34:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r3FLYVS7002670; Tue, 16 Apr 2013 01:34:31 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 16 Apr 2013 01:34:31 +0400 From: Gleb Smirnoff To: Scott Long Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415213431.GB76816@FreeBSD.org> References: <201304151927.r3FJRtq9002799@slippy.cwsent.com> <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <38F315FF-07D3-451C-9811-D4CF89E9EB8E@yahoo.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Warren Block , "current@freebsd.org" , Chris Rees , darrenr@freebsd.org, Rui Paulo , "net@freebsd.org" , Cy Schubert , "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 21:34:35 -0000 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. From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 22:41:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12FA9211 for ; Mon, 15 Apr 2013 22:41:37 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm3-vm2.bullet.mail.gq1.yahoo.com (nm3-vm2.bullet.mail.gq1.yahoo.com [98.136.218.145]) by mx1.freebsd.org (Postfix) with SMTP id BA1821E48 for ; Mon, 15 Apr 2013 22:41:36 +0000 (UTC) Received: from [98.137.12.56] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 22:35:57 -0000 Received: from [98.136.185.44] by tm1.bullet.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 22:35:57 -0000 Received: from [127.0.0.1] by smtp105.mail.gq1.yahoo.com with NNFMP; 15 Apr 2013 22:35:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366065357; bh=QiwxVM+Y3xbFbeuFHPQ/ChqZyBDFy3C05zVLVSoGOFs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=o77T5jZZhDk8f729UFTNhufH/TRnT+u+7Uud3irxz0/hgmVgkbs58og6E0CRUQOPKOtLyDhWb4ZIynB5K/YNSA5LQbDr36QS4G0BCVkWgvy0iDunMxcv3uHNXprF3Eb0KkNX0ICrBLxJIvr5etczJUvhoCZ9TaOnYJeBhI+99rU= X-Yahoo-Newman-Id: 617353.97245.bm@smtp105.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: VuzUH6cVM1m00yKBOJSGhJtIgz6lmRoZWajPpLqCUCJFzMz 7gpRI7qi2UFdeJn907zRUTwW6_onzC2maEpCuqEDk2N8a6fNCePsYTrdPrWB 26w628Ai_leNVnY1j_ljlboddXQb94AzCnOzELUJvttevPRy8nyYNQocgcHn zd0H0ttGQt3ufBeVo2DJ7it5KEIaFrXpy2TMRSNcQ2Bo76UMn6UL3A_DPgND mnsKDbhUBOpomBCFMZSXOoBZn4YaV.roAAUQvTAFK6t0WR.6Gi3lF1xUAUeY dyg69N33kcTcRymKy1J.fB5L_w1Mfutzw0DwtW8w.16OJ.HJgcm49p8f4tSy z.8xf8eaFkZfRNdPWBtmV9RYlP7nd0PE6oMzOIjRs4cxtgNwHfDw_cGtpRup hgvaByL9Wul9RuNmhYrZtG_l2VwOefBjslECP7UE7Z4YbXHKRo71TYJvTGgd Z0NTTwJrqIqmRXcUfJvYWsyUCyOOun0V5xyle704pZpvKE30p3ICqChkzi5_ jNYy5tmGryf5NDnyCh6s48C0WTsj79OpOtgggw6_U0TH6wiwA5IMdMV4- X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.11.14.166] (sean_bruno@69.38.217.10 with plain) by smtp105.mail.gq1.yahoo.com with SMTP; 15 Apr 2013 15:35:57 -0700 PDT Subject: Re: bge(4) sysctl tuneables -- a blast from the past. From: Sean Bruno To: bde In-Reply-To: <20130413200512.G1165@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-v2hvLVEMpGXQ9XXq5AkG" Date: Mon, 15 Apr 2013 15:35:56 -0700 Message-ID: <1366065356.1350.7.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 22:41:37 -0000 --=-v2hvLVEMpGXQ9XXq5AkG Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > FreeBSD has too many knobs, but it would be nice if the bge defaults were= n't > so broken, so that they don't need overriding. >=20 > Bruce So many knobs ... well here's more. :-) http://people.freebsd.org/~sbruno/bge_config_update.txt At least this gets a man page update with references to manuals. Sean --=-v2hvLVEMpGXQ9XXq5AkG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRbIDMAAoJEBkJRdwI6BaHov8IAIZy00pC7a/U/6w3TDFTr2oa 0+GYeo18mzzHMxuHShHwnOxtMn3sumVeOyvoFBvP6el1HfqOMSBAehfB3yHWHRjf 2znxDCbpesVx0L+ClqV6udNhEXqOiGUgQd1flRIMt+SFR5F9pWBmHZ1FqjdaOfaf YU8K6A57uF9UUkHiI0BlHJfoF6xWYIfbAbMsJmDRNa8qIf0tcCkulkQr0ARPdaZE fIQQApQSnvg5DpVz9QYYGyqW1xRG3ljonFItsJ3YGfXn9w4j773KeOxXliax6kX8 wxxKc9zi6z65mWiWuwM6ifz31Upba/hNTIqtSjGiTu0tko4OtIBKmGZSwf0szCc= =V5q5 -----END PGP SIGNATURE----- --=-v2hvLVEMpGXQ9XXq5AkG-- From owner-freebsd-net@FreeBSD.ORG Mon Apr 15 23:17:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B6DDD99C; Mon, 15 Apr 2013 23:17:55 +0000 (UTC) (envelope-from ambrisko@ambrisko.com) Received: from mail.ambrisko.com (mail.ambrisko.com [70.91.206.90]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFAC1F8E; Mon, 15 Apr 2013 23:17:55 +0000 (UTC) X-Ambrisko-Me: Yes Received: from server2.ambrisko.com (HELO internal.ambrisko.com) ([192.168.1.2]) by ironport.ambrisko.com with ESMTP; 15 Apr 2013 16:20:26 -0700 Received: from ambrisko.com (localhost [127.0.0.1]) by internal.ambrisko.com (8.14.4/8.14.4) with ESMTP id r3FNHmt5098465; Mon, 15 Apr 2013 16:17:48 -0700 (PDT) (envelope-from ambrisko@ambrisko.com) Received: (from ambrisko@localhost) by ambrisko.com (8.14.4/8.14.4/Submit) id r3FNHmfa098464; Mon, 15 Apr 2013 16:17:48 -0700 (PDT) (envelope-from ambrisko) Date: Mon, 15 Apr 2013 16:17:48 -0700 From: Doug Ambrisko To: d@delphij.net Subject: Re: bce(4) on the Dell PE 2950 Message-ID: <20130415231748.GA82230@ambrisko.com> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <516877F0.9080301@delphij.net> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , davidch@freebsd.org, Sean Bruno X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 23:17:55 -0000 On Fri, Apr 12, 2013 at 02:09:04PM -0700, Xin Li wrote: | (Added David to Cc) | | On 04/12/13 13:56, Sean Bruno wrote: | > A note from clusteradm@freebsd.org | > | > It looks like there is some amount of instability or bugginess in | > some of the Broadcom firmware(management) on the bce(4) chipeset | > shipped on later generations of the Poweredge 2950 from Dell: | > | > bce0: | > | > Specifically, we've seen that newer (9 and higher) have issues with | > the doing initial setup and negotiation and that Dell did indeed | > release newer firmware to fix the issues. This requires a full | > reboot into Linux (probably centos6) to get the update to execute. | | I could be wrong but I *think* that the firmware is loaded on device | initialization, so there may be a chance that the driver can do it | when starting? Additionally, maybe one can leverage the kernel | firmware(9) framework so that the firmware can be more easily updated | by user? What we created at work was a tool to dump the NIC's "firmware" via the BCE_DEBUG and BCE_NVRAM_WRITE_SUPPORT. It's totally unsupported but works well :-) The usage is to flash it via Linux etc, boot FreeBSD then dump the NVRAM contents. Then use a "flashing" tool that first saves the MAC address info, write the new image and then restore the MAC address ... otherwise all of your NICs get the same MAC addresses! If someone wants to make a decent tool out of it let me know. It's hacky but works. This is why we added the BCE_NVRAM_WRITE_SUPPORT. This means you need these options enabled in the kernel. It's trivial code based on public data. I tossed it up at: http://www.ambrisko.com/doug/bce_firmware.c It needs a correct usage :-) -r reads the NVRAM and -w writes it. There is no error checking "flashing" the firmware since it isn't done via the chip so if you write trash, then you break your NIC. It's a starting point. I put a header file up at: http://www.ambrisko.com/doug/bce_struct.h We've had issues with bce(4) devices since day one in which the BIOS, BMC and NIC firmware had to be in some type of sync. or things break. For a while we actually had to use a cobbled together NIC firmware image from a couple of releases of firmware. Doug A. From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 00:41:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDDBF1F6; Tue, 16 Apr 2013 00:41:48 +0000 (UTC) (envelope-from Cy.Schubert@komquats.com) Received: from smtp-out-02.shaw.ca (smtp-out-02.shaw.ca [64.59.136.138]) by mx1.freebsd.org (Postfix) with ESMTP id 4E9EF207; Tue, 16 Apr 2013 00:41:48 +0000 (UTC) X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=3f4U5fHrZLLPCzJ96ldNbjtja1zQ0ih230F6vdsLr5s= c=1 sm=1 a=QrugwKR0C_UA:10 a=wAGQQ9Az6v0A:10 a=BLceEmwcHowA:10 a=ICAaq7hcmGcA:10 a=kj9zAlcOel0A:10 a=IbtKDeXwb2+SRU442/pi3A==:17 a=6I5d2MoRAAAA:8 a=oX08kPI8AAAA:8 a=BWvPGDcYAAAA:8 a=CYQVMFuZM2fOKkw8t2cA:9 a=CjuIK1q_8ugA:10 a=SV7veod9ZcQA:10 a=4wfsiePOASQA:10 a=V7tsTZBp22UA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO spqr.komquats.com) ([96.50.7.119]) by smtp-out-02.shaw.ca with ESMTP; 15 Apr 2013 18:42:38 -0600 Received: from slippy.cwsent.com (slippy8 [10.2.2.6]) by spqr.komquats.com (Postfix) with ESMTP id 4236580; Mon, 15 Apr 2013 17:41:41 -0700 (PDT) Received: from slippy (localhost [127.0.0.1]) by slippy.cwsent.com (8.14.6/8.14.6) with ESMTP id r3G0fdWM005771; Mon, 15 Apr 2013 17:41:39 -0700 (PDT) (envelope-from Cy.Schubert@komquats.com) Message-Id: <201304160041.r3G0fdWM005771@slippy.cwsent.com> X-Mailer: exmh version 2.8.0 04/21/2012 with nmh-1.5 From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.komquats.com/ To: Gleb Smirnoff Subject: Re: ipfilter(4) needs maintainer In-Reply-To: Message from Gleb Smirnoff of "Tue, 16 Apr 2013 01:28:26 +0400." <20130415212826.GA76816@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 15 Apr 2013 17:41:39 -0700 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" , Cy Schubert , cpet@sdf.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Cy Schubert List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 00:41:48 -0000 In message <20130415212826.GA76816@FreeBSD.org>, Gleb Smirnoff writes: > On Mon, Apr 15, 2013 at 04:47:33PM -0000, cpet@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 FreeBSD UNIX: Web: http://www.FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 01:48:46 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6907EF42; Tue, 16 Apr 2013 01:48:46 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4279E603; Tue, 16 Apr 2013 01:48:46 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3G1mkVH032393; Tue, 16 Apr 2013 01:48:46 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3G1mk4p032392; Tue, 16 Apr 2013 01:48:46 GMT (envelope-from linimon) Date: Tue, 16 Apr 2013 01:48:46 GMT Message-Id: <201304160148.r3G1mk4p032392@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177878: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes on kern/177873 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 01:48:46 -0000 Synopsis: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes on kern/177873 Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 16 01:48:37 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177878 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 05:25:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BE467631; Tue, 16 Apr 2013 05:25:09 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by mx1.freebsd.org (Postfix) with ESMTP id 95425D97; Tue, 16 Apr 2013 05:25:09 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id md4so89397pbc.30 for ; Mon, 15 Apr 2013 22:25:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=OS99moBMGkxH2tA6F/vftfoCEVaeZAHweIH2qn4bEqU=; b=DsIiq7woR/poEZqZaSSllUH9xrMDK9OBTDv1UqIzAjLYKtR3ljK71xqMNt79dIhE+6 2bnmDASuxhNMUFIgsmQNZ/oPnsLBfrhsS0LifLmBZLuHpN+4v87rhOVNdSkRAmx1kvwX HNw09hrKR0oeYNiU8+j/Jfl3tYfJXJlUmt1kMpateb/O8DaYbUQwsIXdBLQ8NuHnUlbC Ajp5WuzzK64aQMJ07l9WYFP2aFzAAMIqjFJQUoIj54dJAX+NFcxE5vBX8SHOIw/tCEwa z+AVUeiRflC41ErNWraU6JojpmIXpXPlYexocDSybtw0bcJdl5AJOEoZOBvG+NE3xAFh G8sA== X-Received: by 10.66.122.167 with SMTP id lt7mr1517754pab.168.1366089909020; Mon, 15 Apr 2013 22:25:09 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id be7sm1094332pad.20.2013.04.15.22.25.05 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 15 Apr 2013 22:25:07 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 16 Apr 2013 14:25:00 +0900 From: YongHyeon PYUN Date: Tue, 16 Apr 2013 14:25:00 +0900 To: Sean Bruno Subject: Re: bge(4) sysctl tuneables -- a blast from the past. Message-ID: <20130416052500.GA1428@michelle.cdnetworks.com> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1366065356.1350.7.camel@localhost> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:25:09 -0000 On Mon, Apr 15, 2013 at 03:35:56PM -0700, Sean Bruno wrote: > > > FreeBSD has too many knobs, but it would be nice if the bge defaults weren't > > so broken, so that they don't need overriding. > > > > Bruce > > > So many knobs ... well here's more. :-) > > http://people.freebsd.org/~sbruno/bge_config_update.txt > > At least this gets a man page update with references to manuals. You have to change BGE_STD_RX_RING_CNT to change number of RX descriptors. It's hard-coded and it needs much more work to change that. And I don't see any reason to modify that though(Max # of RX descriptor is 512). I think bge(4) touches minimal set of coalescing parameters but publicly available bge(4) data sheet shows more coalescing parameters. These parameters could be programmed with different values(BDs & ticks) during interrupt. And some parameters are not applicable to certain controllers. In addition, the allowed value range for certain parameters vary on controller models. So I think it's good idea to mention allowed value range for each parameters as well as a warning that mentions possible connection lost caused by wrongly programmed value(i.e. no RX interrupt for bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0) It's common to see multiple instances of bge(4) in a box so I think it would be better to implement them as sysctl tunables rather than loader tunables(i.e. each controller may need different coalescing parameters). Except hw.bge.allow_asf tunable, all others were implemented to support multiple bge(4) instances. sysctl tunables also allow dynamic change so you don't have to reboot your box to change coalescing parameters. > > Sean From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 05:57:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 16D78980; Tue, 16 Apr 2013 05:57:01 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx08.syd.optusnet.com.au (fallbackmx08.syd.optusnet.com.au [211.29.132.10]) by mx1.freebsd.org (Postfix) with ESMTP id A72F7E1D; Tue, 16 Apr 2013 05:56:59 +0000 (UTC) Received: from mail10.syd.optusnet.com.au (mail10.syd.optusnet.com.au [211.29.132.191]) by fallbackmx08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3G5urRE026761; Tue, 16 Apr 2013 15:56:53 +1000 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail10.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3G5ueud025474 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 15:56:42 +1000 Date: Tue, 16 Apr 2013 15:56:40 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sbruno@freebsd.org Subject: Re: bge(4) sysctl tuneables -- a blast from the past. In-Reply-To: <1366065356.1350.7.camel@localhost> Message-ID: <20130416152121.G904@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=HfxM1V48 c=1 sm=1 a=vYrNp6gXSs8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=_Js9cBt6JEEA:10 a=6I5d2MoRAAAA:8 a=ff2JBTCXWveTg0XuEZwA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 05:57:01 -0000 On Mon, 15 Apr 2013, Sean Bruno wrote: >> FreeBSD has too many knobs, but it would be nice if the bge defaults weren't >> so broken, so that they don't need overriding. > > So many knobs ... well here's more. :-) Yes, adding more knobs would subtract value. > http://people.freebsd.org/~sbruno/bge_config_update.txt > > At least this gets a man page update with references to manuals. I didn't notice before that these are tunables and not sysctls. That's much more broken. Actually tuning using them like I do with sysctls would take ~10000 reboots. Tunables are bogus for anything that isn't needed for booting. Optimizations are needed for booting. Technical bugs include: - wrong defaults are claimed for *coal_ticks. The defaults are 150, but are claimed to be 150 milliseconds. These values are dimensionless, but since ticks take 1 microsecond each, 150 gives 150 microseconds, not 150 milliseconds. - *coal_bds is claimed to be a count of packes (sic). Actually, it is a count of buffer descriptors. Small packets take 1 bd, but normal packets take 2, and jumbo packets many (?). The best tuning may be depend on the average bds/packet. - the new tunables are in the wrong namespace (hw instead of dev) - the new tunables are too global (bge instead of bge.N) There are only 2 bge tunables now, and they only have half of these bugs: - hw.bge.allow_asf is in the wrong namespace - hw.bge.allow_asf is too global - dev.bge.%d.msi seems to be correct. Both of the old tunables are needed for boot-time configuration. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 07:15:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14C71579; Tue, 16 Apr 2013 07:15:00 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.freebsd.org (Postfix) with ESMTP id 586B9173; Tue, 16 Apr 2013 07:14:58 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail03.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3G7Esg3009676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 17:14:55 +1000 Date: Tue, 16 Apr 2013 17:14:54 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: YongHyeon PYUN Subject: Re: bge(4) sysctl tuneables -- a blast from the past. In-Reply-To: <20130416052500.GA1428@michelle.cdnetworks.com> Message-ID: <20130416162150.X1106@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416052500.GA1428@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Ov0XUFDt c=1 sm=1 a=vYrNp6gXSs8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=_Js9cBt6JEEA:10 a=6I5d2MoRAAAA:8 a=EWqSjITiPiIkDsICxhwA:9 a=CjuIK1q_8ugA:10 a=toNXImXXFF3NoEUH:21 a=6uPaEQV4qV6FqJR_:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: Sean Bruno , bde , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 07:15:00 -0000 On Tue, 16 Apr 2013, YongHyeon PYUN wrote: > On Mon, Apr 15, 2013 at 03:35:56PM -0700, Sean Bruno wrote: >> >>> FreeBSD has too many knobs, but it would be nice if the bge defaults weren't >>> so broken, so that they don't need overriding. >> >> So many knobs ... well here's more. :-) >> >> http://people.freebsd.org/~sbruno/bge_config_update.txt >> >> At least this gets a man page update with references to manuals. > > You have to change BGE_STD_RX_RING_CNT to change number of RX > descriptors. It's hard-coded and it needs much more work to change > that. And I don't see any reason to modify that though(Max # of RX > descriptor is 512). I thought that at first too, but a simple change along these lines must be OK since old versions had it. There was a BGE_SSLOTS "option" that was 256. This was used instead of BGE_STD_RX_RING_CNT in much the same places that the tunable is now used, since 512 bds used to be a lot. From FreeBSD-~5.2: @ /* @ * The standard receive ring has 512 entries in it. At 2K per mbuf cluster, @ * that's 1MB or memory, which is a lot. For now, we fill only the first @ * 256 ring entries and hope that our CPU is fast enough to keep up with @ * the NIC. @ */ "1MB or (sic) memory" wasn't actually a lot when this code was written in 2001. @ static int @ bge_init_rx_ring_std(sc) @ struct bge_softc *sc; @ { @ int i; @ @ /* XXX dishonour the above comment and the misplaced def of BGE_SSLOTS. */ @ #undef BGE_SSLOTS @ #define BGE_SSLOTS BGE_STD_RX_RING_CNT The above 3 lines are from ~5.2, to blow away the BGE_SSLOTS. It was easier to edit here than the header file. @ for (i = 0; i < BGE_SSLOTS; i++) { @ if (bge_newbuf_std(sc, i, NULL) == ENOBUFS) @ return(ENOBUFS); @ }; We intentionally removed this "option" other SSLOTS "options", and changed the default to the maximum possible (BGE_STD_RING_CNT here). No one knew how to tune these options, especially since they weren't in conf/options. Not many more than one one knew that these options existed. I don't see how this tunable is useful. The default of the maximum value optimizes for throughput and for minimizing dropped packets. Smaller values would only save a little RAM, but everyone has plenty of RAM. Reducing RAM footprint may reduce (~L2) cache pressure, but it takes _very_ delicate tuning to take advantage of that. > I think bge(4) touches minimal set of coalescing parameters but > publicly available bge(4) data sheet shows more coalescing > parameters. I don't remember any others except a different set for interrupt mode. > These parameters could be programmed with different > values(BDs & ticks) during interrupt. And some parameters are not No, these are worse than useless, except possibly with with a different interrupt handler organization. I looked at a linux driver using them. They just gave pessimizations, even in the Linux driver. IIRC, this is because using them complicates synchronization, so that an extra PIO read or two is needed to synchronize. All this for a change in the settings that is useless for most interrupt handler organizations. You could try reducing the interrupt moderation while in interrupt mode, so as to see all new activity before returning. That is unlikely to be good. In other interrupt handlers, it is an optimization to not check for new activity before returning, because the (PIO) read of the status register is slower than taking another interrupt. bge only needs a read from the status block, so it would not be so slow (but yongari thought that trusting the status block on entry to the interrupt handler like my version does is too fragile). Also, only a small amount of new activity can occur while in interrupt mode (else the interrupt handler can't keep up), and handling in small batches (perhaps 1 bd at a time) would be slow. You could try increasing the interrupt moderation while in interrupt mode. I can't see any point in that. Perhaps if the hardware is really good, completely turning off interrupt moderation while in interrupt mode would be good. The good hardware would keep DMAing and updating the status block to indicate how far it got, and we would process as many descriptors as possible in a single batch before returning, without caring about missing a few. Then the problems are avoiding races in this and switching back to normal mode and getting another interrupt for descriptors that we missed. With good hardware, there would be no extra i/o for this. You could add knobs for the interrupt mode settings, and code to support them. The main use for the knobs would be to re-verify that any non-default use of these knobs gives a pessimization. Not useful. > applicable to certain controllers. In addition, the allowed value > range for certain parameters vary on controller models. So I think > it's good idea to mention allowed value range for each parameters > as well as a warning that mentions possible connection lost caused > by wrongly programmed value(i.e. no RX interrupt for > bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0) Does anyone know the ranges for all models? I still haven't found any documentation that the range is null (nothing works) on 5705-"plus". bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0 might work accidentally if there are enough tx interrupts. There is also the DEVICE_POLLING mistake. In polling mode, these parameters of course have no effect (Polling mode disables interrupts, and the coal parameters have no effect when interrupts are disabled). Bruce From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 08:31:39 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9724F353 for ; Tue, 16 Apr 2013 08:31:39 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [IPv6:2a00:14b0:4200:32e0::1ea]) by mx1.freebsd.org (Postfix) with ESMTP id 5EBB6812 for ; Tue, 16 Apr 2013 08:31:39 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 8971C192A5C for ; Tue, 16 Apr 2013 08:31:31 +0000 (UTC) From: Stefan Bethke Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: VirtualBox, if_bridge and bridged networking Date: Tue, 16 Apr 2013 10:31:27 +0200 Message-Id: <0BD2971C-918F-423C-8D59-A2A3E3B02F04@lassitu.de> To: FreeBSD Net Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 08:31:39 -0000 Hey, I'm a bit stumped getting a (FreeBSD guest) VM to use bridged networking = to work. The same VM works fine on a Mac OS X and an Ubuntu host, so = I'm certain it's not the VMs setting. I'm running # pkg info -g virtualbox* virtualbox-ose-4.2.6 A general-purpose full virtualizer for = x86 hardware virtualbox-ose-kmod-4.2.6_4 VirtualBox kernel module for FreeBSD on FreeBSD 9.1-STABLE r249476 amd64. My LAN gets to the host via vlan1 (attached to re0); which in turn is = bridged via bridge0. IP configuration is on bridge0. It appears that frames sent from the guest make it to the host and = machines connected to the LAN, but no replies appear to be getting back = to the guest. I've tried bridging the guest to bridge0 as well as = vlan1. If I configure the guest's network manually, I can see arp requests = arriving on the host and the LAN; inside the guest I can't see any = frames arriving. If I add arp entries manually on the guest, I can see = pings going out, but the replies never make it back. I am running pf, but I don't see any rejected packets of pflog0 that = correlate in any way. Is there a magic configuration bit that I'm missing? Or is there some = incompatibility between if_bridge and ng_ether? Thanks, Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 09:13:20 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7AF43E3 for ; Tue, 16 Apr 2013 09:13:20 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 303A5D85 for ; Tue, 16 Apr 2013 09:13:20 +0000 (UTC) Received: (qmail 17057 invoked from network); 16 Apr 2013 10:19:25 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 16 Apr 2013 10:19:25 -0000 Message-ID: <516D161E.9010701@freebsd.org> Date: Tue, 16 Apr 2013 11:13:02 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer References: <201304151748.r3FHmhC3002734@slippy.cwsent.com> In-Reply-To: <201304151748.r3FHmhC3002734@slippy.cwsent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 09:13:20 -0000 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 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 09:33:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 085487D8 for ; Tue, 16 Apr 2013 09:33:59 +0000 (UTC) (envelope-from cochard@gmail.com) Received: from mail-ve0-f175.google.com (mail-ve0-f175.google.com [209.85.128.175]) by mx1.freebsd.org (Postfix) with ESMTP id C351BE65 for ; Tue, 16 Apr 2013 09:33:58 +0000 (UTC) Received: by mail-ve0-f175.google.com with SMTP id m1so222337ves.20 for ; Tue, 16 Apr 2013 02:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=xFIZV6UTg/8eqVzQdBy0izec1ahvJWDI4YsOjmiCzOE=; b=ihzyxaE7hjUHeqk8yQ1WiqyNhIbwlZaRYUlhl3yLrmUdelUqnE/cSvY8f3S79OEWNA a0CMw4hiSr4cr5ZrdFrxjNshBSHALCRFe37+CglDyJDJsc0LHmy24dUm5z2nEN1dMZms tUn1Sd49RmOiMYltaOCtPMWwCD55T5kX45+HtzqOZa4eGwyXZa0peZyyL6CefWv/6+GJ Dw8Zbbud0dCnEbZI1P0bOsCht7R7LA1HfGemQf/Zg2B5A1ok4qURf9cIavO0F9pKo/fa Q7l8BAm2GKDZrU/8obpcxmhkb4c+TVfRMQEwmunt3Cu6NCO/TUCwMuHPDAGWrUVYwnpZ YAIg== X-Received: by 10.221.1.144 with SMTP id nq16mr878008vcb.57.1366104837902; Tue, 16 Apr 2013 02:33:57 -0700 (PDT) MIME-Version: 1.0 Sender: cochard@gmail.com Received: by 10.59.9.103 with HTTP; Tue, 16 Apr 2013 02:33:37 -0700 (PDT) From: =?ISO-8859-1?Q?Olivier_Cochard=2DLabb=E9?= Date: Tue, 16 Apr 2013 11:33:37 +0200 X-Google-Sender-Auth: e343A7A_iKPN1g03I_D23Kv4ABg Message-ID: Subject: panic: ifmedia_set when pluging CardBus LAN card xl(4) on 9.1-release To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 09:33:59 -0000 Hi, When I'm plugging CardBus PC Card (3CXFE575BT) on my old laptop it produces a crash. Full core dump here (30MB): http://gugus69.free.fr/freebsd/crash.cardbus.3CXFE575BT.tgz Here an extract of the core.txt file: xl0: <3Com 3c575B Fast Etherlink XL> port 0x1080-0x10ff mem 0x90010000-0x9001007f,0x90011000-0x9001107f irq 10 at device 0.0 on cardbus1 miibus1: on xl0 tdkphy0: <78Q2120 10/100 media interface> PHY 0 on miibus1 tdkphy0: no media present ifmedia_set: no match for 0x0/0xfffffff panic: ifmedia_set cpuid = 0 KDB: stack backtrace: #0 0xc0af3aff at kdb_backtrace+0x4f #1 0xc0ac052f at panic+0x16f #2 0xc0b7d511 at ifmedia_set+0x41 #3 0xc0793eca at miibus_mediainit+0x8a #4 0xc0796041 at mii_phy_dev_attach+0x251 #5 0xc079aa49 at tdkphy_attach+0x29 #6 0xc0aed7f6 at device_attach+0x376 #7 0xc0aeecec at device_probe_and_attach+0x2c #8 0xc0aeed19 at bus_generic_attach+0x19 #9 0xc0794505 at miibus_attach+0xd5 #10 0xc0aed7f6 at device_attach+0x376 #11 0xc0aeecec at device_probe_and_attach+0x2c #12 0xc0aeed19 at bus_generic_attach+0x19 #13 0xc0794b72 at mii_attach+0x4c2 #14 0xc099ea8b at xl_attach+0xc6b #15 0xc0aed7f6 at device_attach+0x376 #16 0xc0aeecec at device_probe_and_attach+0x2c #17 0xc066c0c4 at cardbus_attach_card+0x584 #0 doadump (textdump=1) at pcpu.h:244 244 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:244 #1 0xc0ac027f in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:448 #2 0xc0ac0572 in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:636 #3 0xc0b7d511 in ifmedia_set (ifm=0xc6bee7c0, target=0) at /usr/src/sys/net/if_media.c:181 #4 0xc0793eca in miibus_mediainit (dev=0xc6f0ab80) at /usr/src/sys/dev/mii/mii.c:352 #5 0xc0796041 in mii_phy_dev_attach (dev=0xc6d8c900, flags=1048576, mpf=0xc0f8e8e4, add_media=1) at miibus_if.h:74 #6 0xc079aa49 in tdkphy_attach (dev=0xc6d8c900) at /usr/src/sys/dev/mii/tdkphy.c:112 #7 0xc0aed7f6 in device_attach (dev=0xc6d8c900) at device_if.h:180 #8 0xc0aeecec in device_probe_and_attach (dev=0xc6d8c900) at /usr/src/sys/kern/subr_bus.c:2699 #9 0xc0aeed19 in bus_generic_attach (dev=0xc6f0ab80) at /usr/src/sys/kern/subr_bus.c:3427 #10 0xc0794505 in miibus_attach (dev=0xc6f0ab80) at /usr/src/sys/dev/mii/mii.c:153 #11 0xc0aed7f6 in device_attach (dev=0xc6f0ab80) at device_if.h:180 #12 0xc0aeecec in device_probe_and_attach (dev=0xc6f0ab80) at /usr/src/sys/kern/subr_bus.c:2699 #13 0xc0aeed19 in bus_generic_attach (dev=0xc6e1b800) at /usr/src/sys/kern/subr_bus.c:3427 #14 0xc0794b72 in mii_attach (dev=0xc6e1b800, miibus=0xc7ffc034, ifp=0xc3fdd000, ifmedia_upd=0xc099d380 , ifmedia_sts=0xc099dad0 , capmask=-1, phyloc=-1, offloc=-1, flags=0) at /usr/src/sys/dev/mii/mii.c:514 #15 0xc099ea8b in xl_attach (dev=0xc6e1b800) at /usr/src/sys/dev/xl/if_xl.c:1395 #16 0xc0aed7f6 in device_attach (dev=0xc6e1b800) at device_if.h:180 #17 0xc0aeecec in device_probe_and_attach (dev=0xc6e1b800) at /usr/src/sys/kern/subr_bus.c:2699 #18 0xc066c0c4 in cardbus_attach_card (cbdev=0xc3f43d00) at /usr/src/sys/dev/cardbus/cardbus.c:199 #19 0xc07e5e5f in cbb_event_thread (arg=0xc3e9e000) at card_if.h:83 #20 0xc0a90526 in fork_exit (callout=0xc07e5ac0 , arg=0xc3e9e000, frame=0xd797ed08) at /usr/src/sys/kern/kern_fork.c:992 #21 0xc0e0f6e4 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:276 (kgdb) Regards, Olivier From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 09:51:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 91EE5C19; Tue, 16 Apr 2013 09:51:43 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by mx1.freebsd.org (Postfix) with ESMTP id 68B02F10; Tue, 16 Apr 2013 09:51:43 +0000 (UTC) Received: by mail-pb0-f42.google.com with SMTP id up7so206756pbc.1 for ; Tue, 16 Apr 2013 02:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=TfwhRHq9TNVMRbrz72Daho/xY3NlITwen6OIGmRVXa4=; b=chcHLfa0mdjGQ8kDwM88bhHbzJrzAOg9cM/09L4PU6tE2YOZQu3DlTT+PC4eLsSaZs YdVOxeTS92CoPq7iBJ57W6juORm/xMtxhZoZ9VQgy9gMcQCKF31b39OXkSCObESk9MoL oUpr29k8XLUJxABAF157ZO4r4e0y8JF7UiEdbUPtG1zVAILES8dVO46n7Z/ArfrbDeMf QsRylfEQ4D4xa6w8J7MBvMPq627lhyvvCleBGGs7yYeAs/y4U8533N1J4mNlRYGnpCAq Y+YNaGs6dzEnrqsobMIAynGlxxa8EbzhDcEcS0TqiIMkSxkjnFUKX6/ho7zLRGxHervX UBTQ== X-Received: by 10.68.252.227 with SMTP id zv3mr2286280pbc.14.1366105896923; Tue, 16 Apr 2013 02:51:36 -0700 (PDT) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id ts3sm1475341pbc.12.2013.04.16.02.51.33 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 16 Apr 2013 02:51:35 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Tue, 16 Apr 2013 18:51:27 +0900 From: YongHyeon PYUN Date: Tue, 16 Apr 2013 18:51:27 +0900 To: Bruce Evans Subject: Re: bge(4) sysctl tuneables -- a blast from the past. Message-ID: <20130416095127.GB1428@michelle.cdnetworks.com> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416052500.GA1428@michelle.cdnetworks.com> <20130416162150.X1106@besplex.bde.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130416162150.X1106@besplex.bde.org> User-Agent: Mutt/1.4.2.3i Cc: Sean Bruno , bde , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 09:51:43 -0000 On Tue, Apr 16, 2013 at 05:14:54PM +1000, Bruce Evans wrote: > On Tue, 16 Apr 2013, YongHyeon PYUN wrote: > > >On Mon, Apr 15, 2013 at 03:35:56PM -0700, Sean Bruno wrote: > >> > >>>FreeBSD has too many knobs, but it would be nice if the bge defaults > >>>weren't > >>>so broken, so that they don't need overriding. > >> > >>So many knobs ... well here's more. :-) > >> > >>http://people.freebsd.org/~sbruno/bge_config_update.txt > >> > >>At least this gets a man page update with references to manuals. > > > >You have to change BGE_STD_RX_RING_CNT to change number of RX > >descriptors. It's hard-coded and it needs much more work to change > >that. And I don't see any reason to modify that though(Max # of RX > >descriptor is 512). > > I thought that at first too, but a simple change along these lines > must be OK since old versions had it. There was a BGE_SSLOTS "option" > that was 256. This was used instead of BGE_STD_RX_RING_CNT in much > the same places that the tunable is now used, since 512 bds used to > be a lot. From FreeBSD-~5.2: I'm afraid that will allocate more DMAable memory than specified with the tunable and the amount of data that bus_dmamap_sync(9) have to handle is the same as before. From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 09:52:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94B8CCDC; Tue, 16 Apr 2013 09:52:43 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id EE49BF26; Tue, 16 Apr 2013 09:52:42 +0000 (UTC) Received: by mail-la0-f42.google.com with SMTP id fn20so286382lab.29 for ; Tue, 16 Apr 2013 02:52:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8fHjysi0a+pQ0KhiGkQlxjkAUmLWXNuDDWg59ugDGd4=; b=moj7blK/w1JhBCqbNhlxN43qWFovkHaZbkuPJdkfjU73tYYL46dhPJOgz5VsIXSzmE ytp/ZmyWHnBtSyvPguJwsIRdsubCSYTIRtfrO+y4gUOEDsuem/lPzU7Younr4OJJZpuI kO8YJ2iFfyvJsh6LM8WszSy0B3R54OS+KJWuw+LlVw5RDEUZPNTG2WeQH8dj8Zp2rYd5 PprxCSy/3/wYCMghwqgY3X9Vo/iej7M3TN07qXUR4QL73erxi5AWV8aSvdzRLL/tW27i uBqifKJQThWH1DjsikQnQZGBv+GdLfiDIsSTiWFaw/qYALfdcSTjb4iyZP5np9HHvfXg xbYA== MIME-Version: 1.0 X-Received: by 10.152.5.134 with SMTP id s6mr828543las.24.1366105961853; Tue, 16 Apr 2013 02:52:41 -0700 (PDT) Received: by 10.114.58.179 with HTTP; Tue, 16 Apr 2013 02:52:41 -0700 (PDT) In-Reply-To: <20130416162150.X1106@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416052500.GA1428@michelle.cdnetworks.com> <20130416162150.X1106@besplex.bde.org> Date: Tue, 16 Apr 2013 17:52:41 +0800 Message-ID: Subject: Re: bge(4) sysctl tuneables -- a blast from the past. From: Sepherosa Ziehau To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: YongHyeon PYUN , Sean Bruno , bde , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 09:52:43 -0000 On Tue, Apr 16, 2013 at 3:14 PM, Bruce Evans wrote: > bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0 might work accidentally > if there are enough tx interrupts. There is also the DEVICE_POLLING > mistake. > In polling mode, these parameters of course have no effect (Polling mode > disables interrupts, and the coal parameters have no effect when interrupts > are disabled). As far as I have tested, coalesce BDs and ticks also control how often status block is updated, so it does affect polling(4) Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 10:20:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8379B2D7 for ; Tue, 16 Apr 2013 10:20:23 +0000 (UTC) (envelope-from nbari@inbox.im) Received: from us3.route.mx (us3.route.mx [107.21.107.127]) by mx1.freebsd.org (Postfix) with ESMTP id 3F763A2 for ; Tue, 16 Apr 2013 10:20:22 +0000 (UTC) Received: (route-mx 19509 invoked from network); 16 Apr 2013 10:13:40 -0000 Received: from unknown (HELO nbari-z200.diz.la) (nbari@inbox.im@route.mx) (envelope-sender ) by us3.route.mx (route-mx) with CAMELLIA256-SHA encrypted SMTP for ; 16 Apr 2013 10:13:40 -0000 Message-ID: <516D2451.80105@inbox.im> Date: Tue, 16 Apr 2013 11:13:37 +0100 From: Nicolas de Bari Embriz Garcia Rojas User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130405 Thunderbird/17.0.5 MIME-Version: 1.0 To: Stefan Bethke Subject: Re: VirtualBox, if_bridge and bridged networking References: <0BD2971C-918F-423C-8D59-A2A3E3B02F04@lassitu.de> In-Reply-To: <0BD2971C-918F-423C-8D59-A2A3E3B02F04@lassitu.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 10:20:23 -0000 Try creating a tap interface and later bridge your VM to that tap. in your host create a bridge containing re0 and tap0. regards. On 04/16/2013 09:31, Stefan Bethke wrote: > Hey, > > I'm a bit stumped getting a (FreeBSD guest) VM to use bridged networking to work. The same VM works fine on a Mac OS X and an Ubuntu host, so I'm certain it's not the VMs setting. > > I'm running > # pkg info -g virtualbox* > virtualbox-ose-4.2.6 A general-purpose full virtualizer for x86 hardware > virtualbox-ose-kmod-4.2.6_4 VirtualBox kernel module for FreeBSD > on FreeBSD 9.1-STABLE r249476 amd64. > > My LAN gets to the host via vlan1 (attached to re0); which in turn is bridged via bridge0. IP configuration is on bridge0. > > It appears that frames sent from the guest make it to the host and machines connected to the LAN, but no replies appear to be getting back to the guest. I've tried bridging the guest to bridge0 as well as vlan1. > > If I configure the guest's network manually, I can see arp requests arriving on the host and the LAN; inside the guest I can't see any frames arriving. If I add arp entries manually on the guest, I can see pings going out, but the replies never make it back. > > I am running pf, but I don't see any rejected packets of pflog0 that correlate in any way. > > Is there a magic configuration bit that I'm missing? Or is there some incompatibility between if_bridge and ng_ether? > > > Thanks, > Stefan > From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 06:43:29 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 09BD5824; Tue, 16 Apr 2013 06:43:29 +0000 (UTC) (envelope-from keramida@ceid.upatras.gr) Received: from tux-cave.hellug.gr (tux-cave.hellug.gr [195.134.99.74]) by mx1.freebsd.org (Postfix) with ESMTP id 687CEFB9; Tue, 16 Apr 2013 06:43:27 +0000 (UTC) X-Spam-Status: No X-Hellug-MailScanner-From: keramida@ceid.upatras.gr X-Hellug-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-2.9, required 5, autolearn=not spam, ALL_TRUSTED -1.00, BAYES_00 -1.90) X-Hellug-MailScanner: Found to be clean X-Hellug-MailScanner-ID: r3G6hCUj022455 Received: from saturn.laptop (217-162-217-29.dynamic.hispeed.ch [217.162.217.29]) (authenticated bits=0) by tux-cave.hellug.gr (8.14.3/8.14.3/Debian-9.4) with ESMTP id r3G6hCUj022455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 09:43:19 +0300 Received: from saturn.laptop (localhost [127.0.0.1]) by saturn.laptop (8.14.4/8.14.4/Debian-2.1ubuntu1) with ESMTP id r3G6h6qr025909 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 16 Apr 2013 08:43:06 +0200 Received: (from keramida@localhost) by saturn.laptop (8.14.4/8.14.4/Submit) id r3G6h3nY025896; Tue, 16 Apr 2013 08:43:03 +0200 X-Authentication-Warning: saturn.laptop: keramida set sender to keramida@ceid.upatras.gr using -f From: keramida@ceid.upatras.gr (Giorgos Keramidas) To: Cy Schubert Subject: Re: ipfilter(4) needs maintainer In-Reply-To: <201304151915.r3FJFnM1002686@slippy.cwsent.com> (Cy Schubert's message of "Mon, 15 Apr 2013 12:15:49 -0700") Date: Tue, 16 Apr 2013 07:58:48 +0200 Message-ID: <87sj2rc8yv.fsf@saturn.laptop> References: <201304151915.r3FJFnM1002686@slippy.cwsent.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Mailman-Approved-At: Tue, 16 Apr 2013 11:21:23 +0000 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , "Sam Fourman Jr." , Rui Paulo , "net@freebsd.org" , darrenr@freebsd.org, "cpet@sdf.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 06:43:29 -0000 On Mon, 15 Apr 2013 12:15:49 -0700, Cy Schubert 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. From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 11:44:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 846307A4; Tue, 16 Apr 2013 11:44:16 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 1C3363EE; Tue, 16 Apr 2013 11:44:15 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3GBi64Q019781 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Apr 2013 21:44:07 +1000 Date: Tue, 16 Apr 2013 21:44:06 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sepherosa Ziehau Subject: Re: bge(4) sysctl tuneables -- a blast from the past. In-Reply-To: Message-ID: <20130416213235.O1783@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416052500.GA1428@michelle.cdnetworks.com> <20130416162150.X1106@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=HfxM1V48 c=1 sm=1 a=vYrNp6gXSs8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=_Js9cBt6JEEA:10 a=pwyla-GJPfxvauISbCgA:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: YongHyeon PYUN , Sean Bruno , bde , Bruce Evans , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 11:44:16 -0000 On Tue, 16 Apr 2013, Sepherosa Ziehau wrote: > On Tue, Apr 16, 2013 at 3:14 PM, Bruce Evans wrote: > >> bge_rx_coal_ticks == 0 && bge_rx_max_coal_bds == 0 might work accidentally >> if there are enough tx interrupts. There is also the DEVICE_POLLING >> mistake. >> In polling mode, these parameters of course have no effect (Polling mode >> disables interrupts, and the coal parameters have no effect when interrupts >> are disabled). > > As far as I have tested, coalesce BDs and ticks also control how often > status block is updated, so it does affect polling(4) This might explain why polling worked even worse than expected for most things. However, I got reduced latency using it (from ~55 usec ping latency to ~30 usec). 30 usec would be impossible with the default parameters (normal is an average of at least half of bge_rx_coal_ticks). Maybe I had the parameters reduced to bge_rx_coal_bds = 1 when I found 30 usec (then bge_rx_coal_ticks doesn't matter). This is probably what polling should use. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 11:54:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5C510B66 for ; Tue, 16 Apr 2013 11:54:31 +0000 (UTC) (envelope-from stb@lassitu.de) Received: from gilb.zs64.net (gilb.zs64.net [212.12.50.234]) by mx1.freebsd.org (Postfix) with ESMTP id 22243641 for ; Tue, 16 Apr 2013 11:54:30 +0000 (UTC) Received: by gilb.zs64.net (Postfix, from stb@lassitu.de) id 2EB52193011; Tue, 16 Apr 2013 11:54:29 +0000 (UTC) Subject: Re: VirtualBox, if_bridge and bridged networking Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: Stefan Bethke In-Reply-To: <516D2451.80105@inbox.im> Date: Tue, 16 Apr 2013 13:54:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <113A294E-FF67-4355-8547-B2453B85A26D@lassitu.de> References: <0BD2971C-918F-423C-8D59-A2A3E3B02F04@lassitu.de> <516D2451.80105@inbox.im> To: Nicolas de Bari Embriz Garcia Rojas X-Mailer: Apple Mail (2.1283) Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 11:54:31 -0000 Am 16.04.2013 um 12:13 schrieb Nicolas de Bari Embriz Garcia Rojas: > On 04/16/2013 09:31, Stefan Bethke wrote: >> Hey, >>=20 >> I'm a bit stumped getting a (FreeBSD guest) VM to use bridged = networking to work. The same VM works fine on a Mac OS X and an Ubuntu = host, so I'm certain it's not the VMs setting. >>=20 >> I'm running >> # pkg info -g virtualbox* >> virtualbox-ose-4.2.6 A general-purpose full virtualizer for = x86 hardware >> virtualbox-ose-kmod-4.2.6_4 VirtualBox kernel module for FreeBSD >> on FreeBSD 9.1-STABLE r249476 amd64. >>=20 >> My LAN gets to the host via vlan1 (attached to re0); which in turn is = bridged via bridge0. IP configuration is on bridge0. ... >=20 > Try creating a tap interface and later bridge your VM to that tap. >=20 > in your host create a bridge containing re0 and tap0. Thanks, that worked! Since I couldn't find documentation online, here's my working setup for = the archives: My primary LAN comes into the host physically via re0; it's on vlan1. = It is bridged via bridge0 to tap0, where it gets connected to a remote = site via OpenVPN. Relevant bits from rc.conf (addresses changed): cloned_interfaces=3D"bridge0 tap0 vlan1 vlan2 vlan3 vlan4 gif0" ifconfig_re0=3D"up" ifconfig_vlan1=3D"vlandev re0 vlan 1" ifconfig_bridge0=3D"ether 02:00:00:00:00:01 addm tap0 addm vlan1" ifconfig_bridge0_alias0=3D"inet 192.0.2.1/26" ifconfig_tap0=3D"up" I've extended this config to include tap1, to be used for VirtualBox = bridging: cloned_interfaces=3D"bridge0 tap0 tap1 vlan1 vlan2 vlan3 vlan4 gif0" ifconfig_bridge0=3D"ether 02:00:00:00:00:01 addm tap0 addm tap1 addm = vlan1" ifconfig_bridge0_alias0=3D"inet 192.0.2.1/26" ifconfig_re0=3D"up" ifconfig_vlan1=3D"vlandev re0 vlan 1" ifconfig_tap0=3D"up" ifconfig_tap1=3D"up" Additionally, VirtualBox needs to be able to open the tap interface. = Two settings are necessary: in /etc/sysctl.conf, add: net.link.tap.user_open=3D1 In /etc/defvs.rules, under the rule section for your host, add: add path tap* group wheel mode 660 Then configure the VM to use tap1 for bridging: VBoxManage modifyvm FreeBSD-9-mini --bridgeadapter1 tap1 That should be it! Stefan --=20 Stefan Bethke Fon +49 151 14070811 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 12:24:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id AA62E3FB; Tue, 16 Apr 2013 12:24:51 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id D6F6C852; Tue, 16 Apr 2013 12:24:50 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id ec20so394403lab.41 for ; Tue, 16 Apr 2013 05:24:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lyI7vLMTrvZUWKWbYf3fVIwchqtYNzCJkNmW50okx28=; b=uiBRfGTOyaSHcJK8adHyiQndJlVRLqw1NTbegnJDRZrEuizadT85p1yIUmIRff1KDW r0YE5BNqaJy0M+uBrASaSI+ypJwoQl03hz+3GqQENYwIzvsP0ZA80LlkCN/rTXgJPsCZ bTv1jvOMtygCvVU+zhiwqOMTgN3+MvaKhyWhuG4h4kEx3RM0diZgGv7tOym7ZagpsUog RmsJkuu5YZrgwmP/4zQAbaT1GQqLvGG20gOzMlpcXxhAwJm3ik+oZCnOWvFYLAoYdqX7 eafyDMGT3u3OQpQx2wnULJFstN8zgr77p+AouhcHb0IDwHha9JcsdkzejxTXQgRt8nwO r/ig== MIME-Version: 1.0 X-Received: by 10.112.76.39 with SMTP id h7mr1235278lbw.118.1366115089806; Tue, 16 Apr 2013 05:24:49 -0700 (PDT) Received: by 10.114.58.179 with HTTP; Tue, 16 Apr 2013 05:24:49 -0700 (PDT) In-Reply-To: <20130416152121.G904@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> Date: Tue, 16 Apr 2013 20:24:49 +0800 Message-ID: Subject: Re: bge(4) sysctl tuneables -- a blast from the past. From: Sepherosa Ziehau To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , David Christensen , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 12:24:51 -0000 On Tue, Apr 16, 2013 at 1:56 PM, Bruce Evans wrote: > > Technical bugs include: > - wrong defaults are claimed for *coal_ticks. The defaults are 150, but > are claimed to be 150 milliseconds. These values are dimensionless, > but since ticks take 1 microsecond each, 150 gives 150 microseconds, > not 150 milliseconds. The real effect of TX coalesce ticks is confusing to me; TX interrupt does not come at the rate you have specified, at least for several PCI-e bge(4) I have tested. However, RX coalesce ticks work as expected. Here is how the tests were conducted: - Send only test, no RX - Each packet consume only one BD; UDP datagram, using hardware checksum offloading - TX coalesce BDs is set to 0, so only TX coalesce ticks have effect The interrupt rate I had got seemed to be related to packet size?! I had tested two TX coalesce ticks settings: (the result I had recorded was using BCM5720) The first setting was 1023us; the first col is UDP data size, the second col is rough interrupt rate 18B 667/s 64B 611/s 128B 538/s 256B 432/s 512B 311/s 1024B 194/s 1472B 146/s Tecond setting was 128us; the first col is UDP data size, the second col is rough interrupt rate 18B 1647/s 64B 1338/s 128B 1030/s 256B 700/s 512B 430/s 1024B 235/s 1472B 169/s Well, to be frank, it does not make too much sense to me. I also twisted the HCC_MODE CLRTICK_TX a bit, but didn't get determined result. (davidch is CC'd) Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 18:36:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 356FEE46; Tue, 16 Apr 2013 18:36:31 +0000 (UTC) (envelope-from davidch@broadcom.com) Received: from mms3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by mx1.freebsd.org (Postfix) with ESMTP id 12AB0E7E; Tue, 16 Apr 2013 18:36:30 +0000 (UTC) Received: from [10.9.208.57] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 16 Apr 2013 11:26:10 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from IRVEXCHMB11.corp.ad.broadcom.com ( [fe80::9cdd:3a57:8694:f610]) by IRVEXCHCAS08.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 16 Apr 2013 11:34:13 -0700 From: "David Christensen" To: "Doug Ambrisko" , "d@delphij.net" Subject: RE: bce(4) on the Dell PE 2950 Thread-Topic: bce(4) on the Dell PE 2950 Thread-Index: AQHON8BEpg4paSs9hk6nnkTwmAnTSpjTicQAgATa9gCAAMNj4A== Date: Tue, 16 Apr 2013 18:34:10 +0000 Message-ID: <3A5015FE9E557D448AF7238AF0ACE20A31A4E5@IRVEXCHMB11.corp.ad.broadcom.com> References: <1365800188.1418.29.camel@localhost> <516877F0.9080301@delphij.net> <20130415231748.GA82230@ambrisko.com> In-Reply-To: <20130415231748.GA82230@ambrisko.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.9.208.64] MIME-Version: 1.0 X-WSS-ID: 7D73484835W2917222-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "freebsd-net@freebsd.org" , "davidch@freebsd.org" , Sean Bruno X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 18:36:31 -0000 > | > Specifically, we've seen that newer (9 and higher) have issues with > | > the doing initial setup and negotiation and that Dell did indeed > | > release newer firmware to fix the issues. This requires a full > | > reboot into Linux (probably centos6) to get the update to execute. > | > | I could be wrong but I *think* that the firmware is loaded on device > | initialization, so there may be a chance that the driver can do it > | when starting? Additionally, maybe one can leverage the kernel > | firmware(9) framework so that the firmware can be more easily updated > | by user? The 5706/5708/5709/5716 devices have a set of RISC processors. One is loaded from NVRAM based firmware (MCP) while the others are loaded by firmware embedded in the driver. The MCP firmware is loaded at device power-on when the system is plugged into a socket in order to provide pre-OS access to the system (think Dell DRAC). There's a chicken and egg problem with your suggestion for firmware(9)=20 support of the MCP firmware. Not only does MCP firmware provide pre-OS=20 services but it also provides FreeBSD driver services. There are shared resources on the device which require synchronization between multiple FreeBSD driver instances and the MCP acts as an arbitrator for them. Additionally, I have some security concerns about making NVRAM write=20 functionality easily accessible through the driver since it would be fairly easy to take down a system and require a motherboard swap to fix the problem. There's always a concern that a power-event could interrupt an NVRAM upgrade and make the system unusable so I think it's=20 important to have the system administrator's blessings before making any NVRAM changes to firmware. Not sure how to accomplish that without making the driver load process interactive. Dave From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 19:07:13 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6B3D4E80; Tue, 16 Apr 2013 19:07:13 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 453D41064; Tue, 16 Apr 2013 19:07:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3GJ7DZk028577; Tue, 16 Apr 2013 19:07:13 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3GJ7Dvg028576; Tue, 16 Apr 2013 19:07:13 GMT (envelope-from linimon) Date: Tue, 16 Apr 2013 19:07:13 GMT Message-Id: <201304161907.r3GJ7Dvg028576@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177888: [netinet] [patch] Missing mutex unlock - deadlock multicast subsystem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 19:07:13 -0000 Old Synopsis: Missing mutex unlock - deadlock multicast subsystem New Synopsis: [netinet] [patch] Missing mutex unlock - deadlock multicast subsystem Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 16 19:06:55 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177888 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 19:23:19 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 478F4616; Tue, 16 Apr 2013 19:23:19 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 22D601153; Tue, 16 Apr 2013 19:23:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3GJNJVp033017; Tue, 16 Apr 2013 19:23:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3GJNInH033016; Tue, 16 Apr 2013 19:23:18 GMT (envelope-from linimon) Date: Tue, 16 Apr 2013 19:23:18 GMT Message-Id: <201304161923.r3GJNInH033016@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177889: [ip] [patch] fix printf to generate coherent message, correct spelling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 19:23:19 -0000 Old Synopsis: fix printf to generate coherent message, correct spelling New Synopsis: [ip] [patch] fix printf to generate coherent message, correct spelling Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Apr 16 19:22:28 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177889 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 19:26:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A44D906; Tue, 16 Apr 2013 19:26:49 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 316BB11AC; Tue, 16 Apr 2013 19:26:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3GJQndC033095; Tue, 16 Apr 2013 19:26:49 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3GJQmRH033094; Tue, 16 Apr 2013 19:26:48 GMT (envelope-from delphij) Date: Tue, 16 Apr 2013 19:26:48 GMT Message-Id: <201304161926.r3GJQmRH033094@freefall.freebsd.org> To: sven@vyatta.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Subject: Re: kern/177888: [netinet] [patch] Missing mutex unlock - deadlock multicast subsystem X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 19:26:49 -0000 Synopsis: [netinet] [patch] Missing mutex unlock - deadlock multicast subsystem State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Tue Apr 16 19:25:53 UTC 2013 State-Changed-Why: Patch applied against -HEAD, MFC reminder. (Note that the patch committed have moved MFC_UNLOCK to before set of apival as this do not need to be protected by the lock). Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Tue Apr 16 19:25:53 UTC 2013 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=177888 From owner-freebsd-net@FreeBSD.ORG Tue Apr 16 19:32:43 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21A22E94; Tue, 16 Apr 2013 19:32:43 +0000 (UTC) (envelope-from delphij@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id EFC18120D; Tue, 16 Apr 2013 19:32:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3GJWgXo034923; Tue, 16 Apr 2013 19:32:42 GMT (envelope-from delphij@freefall.freebsd.org) Received: (from delphij@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3GJWg71034922; Tue, 16 Apr 2013 19:32:42 GMT (envelope-from delphij) Date: Tue, 16 Apr 2013 19:32:42 GMT Message-Id: <201304161932.r3GJWg71034922@freefall.freebsd.org> To: sven@vyatta.com, delphij@FreeBSD.org, freebsd-net@FreeBSD.org, delphij@FreeBSD.org From: delphij@FreeBSD.org Subject: Re: kern/177889: [ip] [patch] fix printf to generate coherent message, correct spelling X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 19:32:43 -0000 Synopsis: [ip] [patch] fix printf to generate coherent message, correct spelling State-Changed-From-To: open->patched State-Changed-By: delphij State-Changed-When: Tue Apr 16 19:32:21 UTC 2013 State-Changed-Why: Patch applied against -HEAD, MFC reminder. Responsible-Changed-From-To: freebsd-net->delphij Responsible-Changed-By: delphij Responsible-Changed-When: Tue Apr 16 19:32:21 UTC 2013 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=177889 From owner-freebsd-net@FreeBSD.ORG Wed Apr 17 01:29:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12F234C3 for ; Wed, 17 Apr 2013 01:29:38 +0000 (UTC) (envelope-from njwilliams@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id A2E6820F for ; Wed, 17 Apr 2013 01:29:37 +0000 (UTC) Received: from [136.186.229.154] (nwilliams-laptop.caia.swin.edu.au [136.186.229.154]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r3H1TF9O012489 for ; Wed, 17 Apr 2013 11:29:31 +1000 Message-ID: <516DFAC6.1060200@swin.edu.au> Date: Wed, 17 Apr 2013 11:28:38 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: Multipath TCP for FreeBSD v0.1 References: <513CB9AF.3090409@swin.edu.au> In-Reply-To: <513CB9AF.3090409@swin.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 01:29:38 -0000 Hi all, An update is now available at [1]. This patch fixes a number of known stability issues (see changelog [2]). The readme [3] has also been updated. As with v0.2, this release code is considered to be of alpha quality. Cheers, Nigel, Lawrence and Grenville http://caia.swin.edu.au [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-changelog-v0.3.txt [3] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.3.txt On 11/03/13 03:49, Lawrence Stewart wrote: > Hi all, > > The CAIA MPTCP team is pleased to announce the initial release of our > multipath TCP implementation for FreeBSD 10-CURRENT which is available > from [1]. This release contains wire-related protocol code and a lot of > core stack infrastructure. It is capable of running regular TCP flows > and single or multi-subflow MPTCP flows (with some caveats as documented > in the readme [2]). > > We consider this code to be of alpha quality and plan to release > frequent updates going forward as we continue to flesh out additional > features and fix the rough edges. > > That being said, we welcome everyone to start playing with the code and > provide feedback, bug reports, fixes, praise and/or abuse ;) > > The "Multipath TCP for FreeBSD" project team consists of: > > Nigel Williams: lead R&D engineer > Lawrence Stewart: supporting R&D engineer > Grenville Armitage: principal investigator & overall project lead > > Many thanks go to the Cisco University Research Program Fund at > Community Foundation Silicon Valley for their support of this work. > > Have fun with it! > > Cheers, > Lawrence, Nigel & Grenville > > http://caia.swin.edu.au > > > > [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html > > [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/mptcp-readme-v0.1.txt > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Apr 17 07:01:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B9A811D5 for ; Wed, 17 Apr 2013 07:01:41 +0000 (UTC) (envelope-from crapsh@monkeybrains.net) Received: from mail.monkeybrains.net (mx1.slack.monkeybrains.net [208.69.40.12]) by mx1.freebsd.org (Postfix) with ESMTP id A77D1F41 for ; Wed, 17 Apr 2013 07:01:41 +0000 (UTC) Received: from Computer-of-Penelope.local (199-116-74-159-v301.PUBLIC.monkeybrains.net [199.116.74.159]) (authenticated bits=0) by mail.monkeybrains.net (8.14.6/8.14.6) with ESMTP id r3H6fmLO019397 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 16 Apr 2013 23:41:48 -0700 (PDT) (envelope-from crapsh@monkeybrains.net) Message-ID: <516E4428.6060201@monkeybrains.net> Date: Tue, 16 Apr 2013 23:41:44 -0700 From: "Rudy (bulk)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Subject: ixgbe -- how can I use unsupported SFPs? Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.6 at mail.monkeybrains.net X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 07:01:41 -0000 I added to my /boot/loader.conf: hw.ixgbe.allow_unsupported_sfp=1 Yet when I reboot, I still get: Apr 16 23:29:04 kiwi kernel: ix3: port 0xdf40-0xdf5f mem 0xf8e80000-0xf8efffff,0xf8f78000-0xf8f7bfff irq 37 at device 0.1 on pci4 Apr 16 23:29:04 kiwi kernel: ix3: Using MSIX interrupts with 9 vectors Apr 16 23:29:04 kiwi kernel: ix3: Unsupported SFP+ Module Apr 16 23:29:04 kiwi kernel: device_attach: ix3 attach returned 5 I was attempting to follow this advice: http://lists.freebsd.org/pipermail/freebsd-net/attachments/20100610/61a9127c/ixgbe-sfp.obj Will setting a value in the loader.conf file 'set' the allow_unsupported_sfp bool to TRUE? Here is the code: # grep allow_unsupported_sfp /usr/src/sys/dev/ixgbe/* /usr/src/sys/dev/ixgbe/ixgbe_phy.c: if (hw->allow_unsupported_sfp == TRUE) { /usr/src/sys/dev/ixgbe/ixgbe_type.h: bool allow_unsupported_sfp; Advice? Rudy From owner-freebsd-net@FreeBSD.ORG Wed Apr 17 07:26:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6DB69F4A for ; Wed, 17 Apr 2013 07:26:34 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by mx1.freebsd.org (Postfix) with ESMTP id 312EEDB for ; Wed, 17 Apr 2013 07:26:33 +0000 (UTC) Received: by mail-vc0-f178.google.com with SMTP id hv10so1074345vcb.23 for ; Wed, 17 Apr 2013 00:26:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GKHscfEVxpobJdiDAGG1t78TUaHVs+cypf8XuGc3hOQ=; b=TOWY9PJV4ZyKm066WnT02tKLgxjMhNumQq+0pTX9zv/AtdoESTVuDm3Pj8Z1SvQs/i hNYodd2MAeMZnb9T32gMnXIb3ZcIwWRwfHYwRxmikzNnn5YV+gpm2Gwxlx8CxJMgLHc5 QQAnuEYdX7+kVoJSVr10JP58EVsWBRo2kUyukkre3QBpXRUHsrsJna/l8J9iSy6I2n9U /BM1D2CKBjO1UouCUIFb4vlGUCB4pwZdb2+PMMWkYmd5dNXQu3PVBgTk620EPXtotsJd SGW2FtBI+R4M2w4TCkQpfpMiiZAWTTICpDrqxC36l/pFLmNFotk2oZCUXOrxETgGKzAb 5ZvQ== MIME-Version: 1.0 X-Received: by 10.220.156.8 with SMTP id u8mr3991868vcw.24.1366183593290; Wed, 17 Apr 2013 00:26:33 -0700 (PDT) Received: by 10.220.191.7 with HTTP; Wed, 17 Apr 2013 00:26:33 -0700 (PDT) In-Reply-To: <516E4428.6060201@monkeybrains.net> References: <516E4428.6060201@monkeybrains.net> Date: Wed, 17 Apr 2013 00:26:33 -0700 Message-ID: Subject: Re: ixgbe -- how can I use unsupported SFPs? From: Jack Vogel To: "Rudy (bulk)" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 07:26:34 -0000 You are confusing an internal driver struct with sysctl, there is no ability to do what you are trying to do in the driver, well, not without your own personal hack. There has been some discussion about the issue but as of right now only validated and approved SFP hardware is supported. Jack On Tue, Apr 16, 2013 at 11:41 PM, Rudy (bulk) wrote: > > > I added to my /boot/loader.conf: > hw.ixgbe.allow_unsupported_**sfp=1 > > Yet when I reboot, I still get: > Apr 16 23:29:04 kiwi kernel: ix3: Driver, Version - 2.5.7 - STABLE/9> port 0xdf40-0xdf5f mem > 0xf8e80000-0xf8efffff,**0xf8f78000-0xf8f7bfff irq 37 at device 0.1 on pci4 > Apr 16 23:29:04 kiwi kernel: ix3: Using MSIX interrupts with 9 vectors > Apr 16 23:29:04 kiwi kernel: ix3: Unsupported SFP+ Module > Apr 16 23:29:04 kiwi kernel: device_attach: ix3 attach returned 5 > > > I was attempting to follow this advice: > http://lists.freebsd.org/**pipermail/freebsd-net/** > attachments/20100610/61a9127c/**ixgbe-sfp.obj > > > Will setting a value in the loader.conf file 'set' the > allow_unsupported_sfp bool to TRUE? Here is the code: > > # grep allow_unsupported_sfp /usr/src/sys/dev/ixgbe/* > /usr/src/sys/dev/ixgbe/ixgbe_**phy.c: if > (hw->allow_unsupported_sfp == TRUE) { > /usr/src/sys/dev/ixgbe/ixgbe_**type.h: bool allow_unsupported_sfp; > > > Advice? > > Rudy > ______________________________**_________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/**mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@**freebsd.org > " > From owner-freebsd-net@FreeBSD.ORG Wed Apr 17 11:54:51 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AC3F03BA; Wed, 17 Apr 2013 11:54:51 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail28.syd.optusnet.com.au (mail28.syd.optusnet.com.au [211.29.133.169]) by mx1.freebsd.org (Postfix) with ESMTP id 2FDCF233; Wed, 17 Apr 2013 11:54:50 +0000 (UTC) Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail28.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3HBndcc032596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Apr 2013 21:49:40 +1000 Date: Wed, 17 Apr 2013 21:49:39 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Sepherosa Ziehau Subject: Re: bge(4) sysctl tuneables -- a blast from the past. In-Reply-To: Message-ID: <20130417203212.K1099@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=S7iBW/QP c=1 sm=1 a=vYrNp6gXSs8A:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=_Js9cBt6JEEA:10 a=OYM9qD30a7WLajOxBi8A:9 a=CjuIK1q_8ugA:10 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "pyunyh@gmail.com" , David Christensen , "freebsd-net@freebsd.org" , bde , Bruce Evans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 11:54:51 -0000 On Tue, 16 Apr 2013, Sepherosa Ziehau wrote: > On Tue, Apr 16, 2013 at 1:56 PM, Bruce Evans wrote: >> >> Technical bugs include: >> - wrong defaults are claimed for *coal_ticks. The defaults are 150, but >> are claimed to be 150 milliseconds. These values are dimensionless, >> but since ticks take 1 microsecond each, 150 gives 150 microseconds, >> not 150 milliseconds. > > The real effect of TX coalesce ticks is confusing to me; TX interrupt > does not come at the rate you have specified, at least for several > PCI-e bge(4) I have tested. However, RX coalesce ticks work as > expected. It works for me on a 5701 (PCI-X) on a PCI-33 bus. Perhaps you are just seeing rx interrupts mixed with tx interrupts. At least the FreeBSD driver doesn't determine the interrupt type, so it always processes tx activity when it gets an rx interrupt. I had to do the following to avoid getting rx interrupts (without this the interrupt rate increased by a factor of 3-4 with tx_coal_ticks = 150, from ~6.7 kHz to 19-24 kHz): - I use ttcp for testing, so on the receiving system use ttcp -u -r so that it doesn't echo anything (otherwise it would "echo" with icmp port-unreachable unless firewalled). - Use an old receiving system that doesn't support flow control. The system can't keep up, and drops about half of the packets, so if it did flow control then there would be a lot of rx interrupts. > Here is how the tests were conducted: > - Send only test, no RX > - Each packet consume only one BD; UDP datagram, using hardware > checksum offloading > - TX coalesce BDs is set to 0, so only TX coalesce ticks have effect > > The interrupt rate I had got seemed to be related to packet size?! I > had tested two TX coalesce ticks settings: > (the result I had recorded was using BCM5720) This might be due to larger packet size causing less rx activity. > The first setting was 1023us; the first col is UDP data size, the > second col is rough interrupt rate > 18B 667/s > 64B 611/s Oops, this doesn't look like rx activity. We expect a rate of 977 Hz, possibly increased significantly by tx activity. I get 996-1004 here (1023us is actually 1000?). > 128B 538/s > 256B 432/s > 512B 311/s > 1024B 194/s > 1472B 146/s I get 996-1004 for all of these. Now I remember another problem that I work around using huge ifqueues (10k or 20k entries) and/or busy-waiting in the send() in ttcp. It is too easy for the tx to stop because there is nothing on the ifqueue to refill it. Then it won't restart until the application starts sending again. It is normal for all the queues to fill up. Then send returns ENOBUFS and there is no good way for the application to handle this, since select() on the queues not being full is broken (never supported). Bad ways include: - sleep for a while in the application. It is hard to know when to wake up, and impossible to wake up soon enough if timeout granularity is large. - use huge ifqueues, so that long delays in the application work - spin trying send(). > Tecond setting was 128us; the first col is UDP data size, the second > col is rough interrupt rate > 18B 1647/s > 64B 1338/s Now you should be getting much higher interrupt rates, unless something can't keep up. I get 7904-7967 and 7906-7971. > 128B 1030/s > 256B 700/s > 512B 430/s > 1024B 235/s > 1472B 169/s I get little dependency on the packet size. At 1472B, the packet rate is ~58900. Eveything on the tx side can keep up with that though not much more, so no drop is expected. > Well, to be frank, it does not make too much sense to me. I found timestamps and counters for bge_*xeof() good for understanding the flow of control. It is easy to generate too much data, so I keep the tx and rx statistics separate and try to understand tx and rx activity separately. Some for tx with tx_coal_ticks = 1023 and packet size 18: @ 976 1366197879.094951 454 25 349 1366197879.094976 105 @ 971 1366197879.095947 455 26 351 1366197879.095973 104 @ 972 1366197879.096945 455 25 355 1366197879.096970 100 @ 975 1366197879.097945 451 24 351 1366197879.097969 100 @ 974 1366197879.098943 443 24 337 1366197879.098967 106 The large numbers are absolute timestamps for bge_txeof() entry and exit. The entries are separated by almost exactly 1000 us (not 1023 us as expected). The first numeric column gives the time in us between the previous exit and this entry. Not very relevant here. The fourth numeric column gives the time in us between this entry and exit. Not very relevant here. The third and final numeric columns give the ring indexes on entry and exit, and the 5th numeric column gives the difference of these. These are relevant here. Ideally the ring would be almost but not quite full whenever we start, and the difference would be almost 512, but ttcp apparently can't generate data fast enough to keep it full, so it has an average of 350+ entries and the packet rate is 350+kpps. We don't want the ring to be completely full when we start, since that means that we are not interrupting enough to keep up with the generator and probably also with the hardware. This system can do 640+kpps when ideally configured, using tx_coal_ticks = 1000000 and tx_coal_bds = 384. With tx_coal_ticks = 1023 (1000) and tx_coal_bds = 0. it couldn't do more than 512kpps. Its current non-ideal configuration includes firwalling, sharing the bge interrupt with rl, and not overclocking. In this configuration, the above 2 tx_coal_* settings are almost equally good (tx_coal_ticks = 1023 reduces latency for reaping descriptors, but latency doesn't matter; tx_coal_ticks = 100000 reduces interrupts when not under load, but when not under load interrupt overhead isn't a problem). Bruce From owner-freebsd-net@FreeBSD.ORG Wed Apr 17 12:46:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C5A57F0 for ; Wed, 17 Apr 2013 12:46:43 +0000 (UTC) (envelope-from jmojica@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 68E666CF for ; Wed, 17 Apr 2013 12:46:43 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id p43so1195434wea.10 for ; Wed, 17 Apr 2013 05:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=uOQkWrDQwGAYqvRbXn40uOLUi6BgAHAnwFSGbYpHUhM=; b=iqHA/MC2p2LDoTEhtOMGpV3z5XXjI6voGQLpBanZ0XB7Xc7j6YKauRDM42NqHtZ/8K 68GreaShEyDk1FviRTAJncyWUskbzT2Q462L9T/uhPHdBIBPUTwo8dRCL3Tr1P6cDl/L UqiXAfj8EVupkq5wTOa4F36ZDTOvs1YgTrAMgrqqy6fSTSQ+aHXz50ujNpl8jUTuYxXu ais7gcue7/9wO/ex5ahdnEfl/g2G1ZmgvDXKB9qhKq8WpNHg8I/xOm0Nkk/+0aptEQK0 kOEk4WyVOveRU22ciQ9FlUVe5kw+zkji8zIykoeMq1um8t609iCAln+7Siab8JDia/nB xwGA== MIME-Version: 1.0 X-Received: by 10.194.23.105 with SMTP id l9mr4343729wjf.41.1366202802566; Wed, 17 Apr 2013 05:46:42 -0700 (PDT) Received: by 10.194.122.73 with HTTP; Wed, 17 Apr 2013 05:46:42 -0700 (PDT) Date: Wed, 17 Apr 2013 08:46:42 -0400 Message-ID: Subject: ARP: Error Message in if_ether.c "arprequest: cannot find matching address" From: Juan Mojica To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 12:46:43 -0000 We manage to hit the following message with some regularity. arprequest: cannot find matching address The code shows a printf: printf("%s: cannot find matching address\n", __func__); Any reason this is a printf and not a log(LOG_ERR, The only things I can come up with are: a) it is a really severe and should be printed out, which if that is the case why isn't there an assert there? b) whoops, that should probably be a log(LOG_ERR, On our end we need to figure out exactly why we're intermittently hitting this patch of code. Thanks, -- Juan Mojica Email: jmojica@gmail.com From owner-freebsd-net@FreeBSD.ORG Thu Apr 18 01:11:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E9C9EDF; Thu, 18 Apr 2013 01:11:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C2EBCFD; Thu, 18 Apr 2013 01:11:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3I1B3TF001641; Thu, 18 Apr 2013 01:11:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3I1B3T1001640; Thu, 18 Apr 2013 01:11:03 GMT (envelope-from linimon) Date: Thu, 18 Apr 2013 01:11:03 GMT Message-Id: <201304180111.r3I1B3T1001640@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/177905: [xl] [panic] ifmedia_set when pluging CardBus LAN card, xl(4) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 01:11:04 -0000 Old Synopsis: panic: ifmedia_set when pluging CardBus LAN card, xl(4) driver New Synopsis: [xl] [panic] ifmedia_set when pluging CardBus LAN card, xl(4) driver Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Apr 18 01:10:47 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=177905 From owner-freebsd-net@FreeBSD.ORG Thu Apr 18 14:47:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B26DE829; Thu, 18 Apr 2013 14:47:22 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by mx1.freebsd.org (Postfix) with ESMTP id DB0AC34D; Thu, 18 Apr 2013 14:47:21 +0000 (UTC) Received: by mail-lb0-f175.google.com with SMTP id o10so2733341lbi.6 for ; Thu, 18 Apr 2013 07:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=WF9v9HsZ+YX72SttwDslrb3uywjTu4LysnEDYVPZdnY=; b=DDBDNqGjDMrmQfE5a5j9d/B/eHXYZcCg+4KcVN3GApBtwl9cHbwd4r5lJhVDqQxj4k vSH4d35Ka+5K0lJmNnP/qI3Ikw2bXx/0GzlnILcYr42NqkhzG23t/1zVxHTcjBfhlKg7 fMtBFBTt38dZYqfi74Hw9iJCiCL7Pu7vEydUjqPDMxRVSTz6ZnUvNv+RxaZWN0duErQe Ovf86vK0sHpoUYqaf4cK+w+swh993jdpZooHRK/HISCJif1Yy/SXR7nvPqaKuIpyTTri 6duns/Skuw25xvC+mD4a91jS6+xJ6dM9BRIBwuE4kxvs9yPUfjZX5nfKrhOGCkBaX9v7 K4HQ== MIME-Version: 1.0 X-Received: by 10.112.132.40 with SMTP id or8mr6015304lbb.119.1366296440615; Thu, 18 Apr 2013 07:47:20 -0700 (PDT) Received: by 10.114.58.179 with HTTP; Thu, 18 Apr 2013 07:47:20 -0700 (PDT) In-Reply-To: <20130417203212.K1099@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> <20130417203212.K1099@besplex.bde.org> Date: Thu, 18 Apr 2013 22:47:20 +0800 Message-ID: Subject: Re: bge(4) sysctl tuneables -- a blast from the past. From: Sepherosa Ziehau To: Bruce Evans Content-Type: text/plain; charset=ISO-8859-1 Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , David Christensen , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 14:47:22 -0000 On Wed, Apr 17, 2013 at 7:49 PM, Bruce Evans wrote: > On Tue, 16 Apr 2013, Sepherosa Ziehau wrote: > >> On Tue, Apr 16, 2013 at 1:56 PM, Bruce Evans wrote: >>> >>> >>> Technical bugs include: >>> - wrong defaults are claimed for *coal_ticks. The defaults are 150, but >>> are claimed to be 150 milliseconds. These values are dimensionless, >>> but since ticks take 1 microsecond each, 150 gives 150 microseconds, >>> not 150 milliseconds. >> >> >> The real effect of TX coalesce ticks is confusing to me; TX interrupt >> does not come at the rate you have specified, at least for several >> PCI-e bge(4) I have tested. However, RX coalesce ticks work as >> expected. > > > It works for me on a 5701 (PCI-X) on a PCI-33 bus. > > Perhaps you are just seeing rx interrupts mixed with tx interrupts. At Nah, the testing switch only has the two tested NICs connected (the receiving side is Intel 82571). The ssh connections are on other NICs. And there are no other data between the tested NICs. If the TX coalesce BDs (e.g. set to 128), the receiving side could sink 1.488Mpps generated by the BCM5720, so the receiving side should be OK too. > least the FreeBSD driver doesn't determine the interrupt type, so it > always processes tx activity when it gets an rx interrupt. > > I had to do the following to avoid getting rx interrupts (without this > the interrupt rate increased by a factor of 3-4 with tx_coal_ticks = 150, > from ~6.7 kHz to 19-24 kHz): > - I use ttcp for testing, so on the receiving system use ttcp -u -r so > that it doesn't echo anything (otherwise it would "echo" with icmp > port-unreachable unless firewalled). > - Use an old receiving system that doesn't support flow control. The > system can't keep up, and drops about half of the packets, so if it > did flow control then there would be a lot of rx interrupts. > > >> Here is how the tests were conducted: >> - Send only test, no RX >> - Each packet consume only one BD; UDP datagram, using hardware >> checksum offloading >> - TX coalesce BDs is set to 0, so only TX coalesce ticks have effect >> >> The interrupt rate I had got seemed to be related to packet size?! I >> had tested two TX coalesce ticks settings: >> (the result I had recorded was using BCM5720) > > > This might be due to larger packet size causing less rx activity. No RX activity :) > > >> The first setting was 1023us; the first col is UDP data size, the >> second col is rough interrupt rate >> 18B 667/s >> 64B 611/s > > > Oops, this doesn't look like rx activity. We expect a rate of 977 Hz, > possibly increased significantly by tx activity. > > I get 996-1004 here (1023us is actually 1000?). > > >> 128B 538/s >> 256B 432/s >> 512B 311/s >> 1024B 194/s >> 1472B 146/s > > > I get 996-1004 for all of these. That's result that I wanted to get from the PCI-e bge(4) NICs that I have tested. > > Now I remember another problem that I work around using huge ifqueues (10k > or 20k entries) and/or busy-waiting in the send() in ttcp. It is too easy > for the tx to stop because there is nothing on the ifqueue to refill it. > Then it won't restart until the application starts sending again. It > is normal for all the queues to fill up. Then send returns ENOBUFS and > there is no good way for the application to handle this, since select() > on the queues not being full is broken (never supported). Bad ways include: > - sleep for a while in the application. It is hard to know when to wake up, > and impossible to wake up soon enough if timeout granularity is large. > - use huge ifqueues, so that long delays in the application work > - spin trying send(). Use user space packet generator (netmap is an exception) does suffer the problem you have described, however, my sending tests are conducted using home-made in kernel packet generator (no ALTQ involved): - Upon test start, the 3/4 of ifqueue is filled; then call if_start. For BCM5720, 384 packets are put on to the hardware queue at once. - In bge_txeof(), for each packet mbuf freed, new packet is added to ifqueue. - if_start is called at the end of bge_txeof. Except the startup, the rest (major) part is TXEOF driven. If TX coalesce BDs is set to 128 (TX coalesce ticks is set to 1023 here) on BCM5720, I get ~11700/s interrupt and sending rate is ~1.488Mpps (18B UDP datagram); obviously the TX coalesce BDs is taking effect here (128 * 11700 ~= 1.488Mpps). So I think the packet generator mechanism works as expected (well, it works w/ other types of NICs too, e.g. em, jme) > > >> Tecond setting was 128us; the first col is UDP data size, the second >> col is rough interrupt rate >> 18B 1647/s >> 64B 1338/s > > > Now you should be getting much higher interrupt rates, unless something > can't keep up. I get 7904-7967 and 7906-7971. > > >> 128B 1030/s >> 256B 700/s >> 512B 430/s >> 1024B 235/s >> 1472B 169/s > > > I get little dependency on the packet size. At 1472B, the packet rate is > ~58900. Eveything on the tx side can keep up with that though not much > more, so no drop is expected. > > >> Well, to be frank, it does not make too much sense to me. > > > I found timestamps and counters for bge_*xeof() good for understanding > the flow of control. It is easy to generate too much data, so I keep > the tx and rx statistics separate and try to understand tx and rx activity > separately. Some for tx with tx_coal_ticks = 1023 and packet size 18: > > @ 976 1366197879.094951 454 25 349 1366197879.094976 105 > @ 971 1366197879.095947 455 26 351 1366197879.095973 104 > @ 972 1366197879.096945 455 25 355 1366197879.096970 100 > @ 975 1366197879.097945 451 24 351 1366197879.097969 100 > @ 974 1366197879.098943 443 24 337 1366197879.098967 106 > > The large numbers are absolute timestamps for bge_txeof() entry and exit. > > The entries are separated by almost exactly 1000 us (not 1023 us as > expected). > > The first numeric column gives the time in us between the previous exit and > this entry. Not very relevant here. > > The fourth numeric column gives the time in us between this entry and exit. > Not very relevant here. > > The third and final numeric columns give the ring indexes on entry and > exit, and the 5th numeric column gives the difference of these. These > are relevant here. Ideally the ring would be almost but not quite > full whenever we start, and the difference would be almost 512, but > ttcp apparently can't generate data fast enough to keep it full, so > it has an average of 350+ entries and the packet rate is 350+kpps. We > don't want the ring to be completely full when we start, since that > means that we are not interrupting enough to keep up with the generator > and probably also with the hardware. This system can do 640+kpps when > ideally configured, using tx_coal_ticks = 1000000 and tx_coal_bds = > 384. With tx_coal_ticks = 1023 (1000) and tx_coal_bds = 0. it couldn't > do more than 512kpps. Its current non-ideal configuration includes > firwalling, sharing the bge interrupt with rl, and not overclocking. > In this configuration, the above 2 tx_coal_* settings are almost equally > good (tx_coal_ticks = 1023 reduces latency for reaping descriptors, > but latency doesn't matter; tx_coal_ticks = 100000 reduces interrupts > when not under load, but when not under load interrupt overhead isn't > a problem). Thank you for the measurement and analysis! I have not yet to make any detailed function call timing and packet count measurement :) Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Thu Apr 18 15:24:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EA38733D for ; Thu, 18 Apr 2013 15:24:34 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id C99667CB for ; Thu, 18 Apr 2013 15:24:34 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2F151B94C; Thu, 18 Apr 2013 11:24:34 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: shm_map questions Date: Thu, 18 Apr 2013 09:50:18 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <1365692294.23098.YahooMailClassic@web125801.mail.ne1.yahoo.com> In-Reply-To: <1365692294.23098.YahooMailClassic@web125801.mail.ne1.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304180950.18349.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Thu, 18 Apr 2013 11:24:34 -0400 (EDT) Cc: Laurie Jennings X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 15:24:35 -0000 On Thursday, April 11, 2013 10:58:14 am Laurie Jennings wrote: > Im working on a simple project that shares a memory segment between a user processand a kernel module. I'm having some problems with shm_map and there doesn't seem to be much info on it. > Im not sure what happened to the memory when the user process that creates it terminates. I have some questions. > 1) Does the kernel mapping keep the segment from being garbage collected when the use process that creates it terminated? I've experienced shm_unmap() panic when tryingto unmap a segment > scenario: > User process Maps SegmentKernel maps it with shm_map()User Process TerminatesKernel tries to shm_unmap() and it panics. The kernel mapping bumps the refcount on the underlying vm object, so it will not go away. OTOH, you should be keeping your own reference count on the associated fd so that you can call shm_unmap(). That is, the model should be something like: struct mydata *foo; foo->fp = fget(fd); shm_map(fp, &foo->p); /* Don't call fdrop */ and then when unmapping: struct mydata *foo; shm_unmap(foo->fp, foo->p); fdrop(foo->fp); > 2) Is there a way for the kernel process to know when the user process has goneaway? A ref count? You can install a process_exit EVENTHANDLER if you want to destroy this when a process goes away. I have used shm_map/unmap for other objects that already had a reference count so I did my shm_unmap when that object was destroyed. > 3) Does a SHM_ANON segment persist as long as the kernel has it mapped, or doesit get garbage collected when the creating user process terminates? It goes away when the backing 'struct file' goes away. If you follow the model above of keeping a reference count on the associated struct file then it won't go away until you fdrop() after the shm_unmap. > 4) When using a named segment, can the kernel "reuse" a mapping for a new userprocess? > Example: > User process creates shm segment with path /fooKernel Maps shm segment with shm_map()User process terminates.User process runs again, opening segment /foo > Does the kernel need to re-map, or is the original mapping valid? The mapping is not per-process, so if you have mapped a shm for /foo and mapped it, it will stay mapped until you call shm_unmap. Multiple processes can shm_open /foo and mmap it and they will all share the same memory. You could even share a SHM_ANON fd among multiple processes by passing it across a UNIX domain socket. Hope this helps. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 07:11:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id F1170748 for ; Fri, 19 Apr 2013 07:11:42 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 8EE53D2B for ; Fri, 19 Apr 2013 07:11:42 +0000 (UTC) Received: by mail-we0-f179.google.com with SMTP id u3so305696wey.10 for ; Fri, 19 Apr 2013 00:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ylKwF1ZQkJCE9jVew2RdIlotxWIXnb62XvzhYjwnSiw=; b=Kq33XP/gwIXK8WlVCLw2a3/G7AToMt/SJpXQ/tXCLpL59emY3a+40jhZW7cyR7FaSp XQHMFwOI9fgfbcon78orHPbkC4OPh2YrBOWLDucT4kNNX86jNagoLHsBzALnSjmicpk9 1skQJ1miXHzrjBzcDUBcCCC480IKCiThc0MQ6Icwj/EI/5geSP10lIq2koIZCA+yTkg5 Wu+1UREg3q7LLKoRpvJONyR0GdIN3HVAAYqB4dLxWQjBBgh8h6ypTM/BeNfwiXkFksm+ oIgOXGVWp5UKwE/4YUQE3GznJPZv87x+N7pbj0W8ORtgAQ2v8a+XkC8fEDJrSyMSOQJz 2dLQ== MIME-Version: 1.0 X-Received: by 10.194.93.231 with SMTP id cx7mr16836877wjb.33.1366355501784; Fri, 19 Apr 2013 00:11:41 -0700 (PDT) Received: by 10.194.20.227 with HTTP; Fri, 19 Apr 2013 00:11:41 -0700 (PDT) Date: Fri, 19 Apr 2013 07:11:41 +0000 Message-ID: Subject: Network connections are lost from time to time From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 07:11:43 -0000 Hi all, I have a strange problem with my FreeBSD 9.1 (fully patched): I loose ssh sessions from time to time frequently. This fbsd box is installed in an ESXi 5.1 server and I have another three fbsd 9.1 in the same ESXi host that do not have this problem, but maybe the problem is with my sysctl.conf and loader.conf settings: sysctl.conf # $FreeBSD: release/9.1.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ # # This file is read when going to multi-user and its contents piped thru # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. # # Uncomment this to prevent users from seeing information about processes that # are being run under another UID. security.bsd.see_other_uids=0 security.bsd.see_other_gids=0 # Refresh arp table entries in 2 minutes net.link.ether.inet.max_age=120 # Drop tcp/udp packets destined for closed ports net.inet.tcp.blackhole=2 net.inet.udp.blackhole=1 # Use the H-TCP congestion control algorithm which is more aggressive ##net.inet.tcp.cc.algorithm=htcp # Host cache is used to cache connection details and metrics ##net.inet.tcp.hostcache.expire=5400 # Maximum segment size (MSS) specifies the largest amount of data in a single TCP segment net.inet.tcp.mssdflt=1440 # Make sure time stamps are enabled for slowstart_flightsize net.inet.tcp.rfc1323=1 # Make sure rfc3390 is DISABLED so the slowstart flightsize values are used. net.inet.tcp.rfc3390=0 # Size of the TCP transmit and receive buffer. net.inet.tcp.sendspace=262144 # Increase auto-tuning TCP step size of the TCP transmit and receive buffers. net.inet.tcp.recvbuf_inc=524288 # Somaxconn is the buffer or backlog queue depth for accepting new TCP connections. kern.ipc.somaxconn=1024 # Reduce the amount of SYN/ACKs we will _retransmit_ to an unresponsive initial connection. net.inet.tcp.syncache.rexmtlimit=1 # Spoofed packet attacks may be used to overload the kernel route cache. net.inet.ip.rtexpire=60 net.inet.ip.rtminexpire=2 net.inet.ip.rtmaxcache=1024 loader.conf: ############################################################## ### Loader settings ######################################## ############################################################## autoboot_delay="5" beastie_disable="YES" ############################################################## ### Kernel tunables ######################################## ############################################################## kern.maxfiles="25000" kern.ipc.nmbclusters="32768" net.inet.tcp.syncache.hashsize="1024" net.inet.tcp.syncache.bucketlimit="100" net.inet.tcp.tcbhashsize="4096" ############################################################## ### Hardware tunables ###################################### ############################################################## hw.pci.enable_msi="0" hw.pci.enable_msix="0" ############################################################## ### Networking modules ##################################### ############################################################## cc_htcp_load="YES" ############################################################## ### Other modules ########################################## ############################################################## aio_load="YES" How can I debug where is the problem?? From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 09:22:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D49C0BBB for ; Fri, 19 Apr 2013 09:22:37 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by mx1.freebsd.org (Postfix) with ESMTP id 6FD176CE for ; Fri, 19 Apr 2013 09:22:37 +0000 (UTC) Received: by mail-wi0-f176.google.com with SMTP id hj19so489014wib.15 for ; Fri, 19 Apr 2013 02:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=E7rrnJN1nDf3Nz8McyGjUHAtRaa8tj2nsv3XY18GOuE=; b=T++vxPBxLOyjcm7C/p/juS/a8LLfanfb2l1Qgx4Kmwymz+k7EWK1NPWbdMYDssmVyN aBA4yjYf5Gqmb2Bm9hTWEgf6Z8tpbXoLVHWuA6pgFIb+9TC8QtZH99NyTISx5vVvTzS1 wawi+hBq65PFQAlQ/SEmMddCTnOEBlPL4SOMmnWctpyaowQOUF2qv29tOhDj5cQ81zOQ GQ4zJe3IvSHNQtpkZI6XRkGk8L5aTtXuGCxM5jxMlhqBnlqcA240XPNEb/EBqCg7HNfR AO8paBdqAWPjXfWUmKKvqYQZKcioRnIW+67TWSxvt3d1JD9Vr52DWT0FwVdhgU77Lgu5 9KeA== MIME-Version: 1.0 X-Received: by 10.180.188.3 with SMTP id fw3mr23528139wic.33.1366363356587; Fri, 19 Apr 2013 02:22:36 -0700 (PDT) Received: by 10.194.20.227 with HTTP; Fri, 19 Apr 2013 02:22:36 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 09:22:36 +0000 Message-ID: Subject: Re: Network connections are lost from time to time From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:22:37 -0000 On Fri, Apr 19, 2013 at 7:11 AM, C. L. Martinez wrote: > Hi all, > > I have a strange problem with my FreeBSD 9.1 (fully patched): I loose ssh > sessions from time to time frequently. > > This fbsd box is installed in an ESXi 5.1 server and I have another three > fbsd 9.1 in the same ESXi host that do not have this problem, but maybe the > problem is with my sysctl.conf and loader.conf settings: > > sysctl.conf > > # $FreeBSD: release/9.1.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux $ > # > # This file is read when going to multi-user and its contents piped thru > # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. > # > > # Uncomment this to prevent users from seeing information about processes > that > # are being run under another UID. > security.bsd.see_other_uids=0 > security.bsd.see_other_gids=0 > > # Refresh arp table entries in 2 minutes > net.link.ether.inet.max_age=120 > > # Drop tcp/udp packets destined for closed ports > net.inet.tcp.blackhole=2 > net.inet.udp.blackhole=1 > > # Use the H-TCP congestion control algorithm which is more aggressive > ##net.inet.tcp.cc.algorithm=htcp > > # Host cache is used to cache connection details and metrics > ##net.inet.tcp.hostcache.expire=5400 > > # Maximum segment size (MSS) specifies the largest amount of data in a > single TCP segment > net.inet.tcp.mssdflt=1440 > > # Make sure time stamps are enabled for slowstart_flightsize > net.inet.tcp.rfc1323=1 > > # Make sure rfc3390 is DISABLED so the slowstart flightsize values are > used. > net.inet.tcp.rfc3390=0 > > # Size of the TCP transmit and receive buffer. > net.inet.tcp.sendspace=262144 > > # Increase auto-tuning TCP step size of the TCP transmit and receive > buffers. > net.inet.tcp.recvbuf_inc=524288 > > # Somaxconn is the buffer or backlog queue depth for accepting new TCP > connections. > kern.ipc.somaxconn=1024 > > # Reduce the amount of SYN/ACKs we will _retransmit_ to an unresponsive > initial connection. > net.inet.tcp.syncache.rexmtlimit=1 > > # Spoofed packet attacks may be used to overload the kernel route cache. > net.inet.ip.rtexpire=60 > net.inet.ip.rtminexpire=2 > net.inet.ip.rtmaxcache=1024 > > loader.conf: > > ############################################################## > ### Loader settings ######################################## > ############################################################## > > autoboot_delay="5" > beastie_disable="YES" > > > ############################################################## > ### Kernel tunables ######################################## > ############################################################## > > kern.maxfiles="25000" > kern.ipc.nmbclusters="32768" > net.inet.tcp.syncache.hashsize="1024" > net.inet.tcp.syncache.bucketlimit="100" > net.inet.tcp.tcbhashsize="4096" > > > ############################################################## > ### Hardware tunables ###################################### > ############################################################## > > hw.pci.enable_msi="0" > hw.pci.enable_msix="0" > > > ############################################################## > ### Networking modules ##################################### > ############################################################## > > cc_htcp_load="YES" > > > ############################################################## > ### Other modules ########################################## > ############################################################## > > aio_load="YES" > > How can I debug where is the problem?? > More info when I try to connect with PuTTY from a windows desktop appears the following error: Network error: Software caused connection abort. ... and pf is disabled (ipfw and ipfilter, too). From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 09:46:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 94EE17E; Fri, 19 Apr 2013 09:46:48 +0000 (UTC) (envelope-from demelier.david@gmail.com) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by mx1.freebsd.org (Postfix) with ESMTP id AC0D78A6; Fri, 19 Apr 2013 09:46:47 +0000 (UTC) Received: by mail-wi0-f175.google.com with SMTP id h11so523852wiv.2 for ; Fri, 19 Apr 2013 02:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=n1uUd+/ZOPA38EiRjsijdbPjr5ajljfVvOcMS9FnZWI=; b=x7JMXfJjG0VaTKv9OOoxpTeiVe3OkKeoxsJLrtk9biY2IfJftWQGbIrvAH5RNbnBlZ Jbzf20LglH+lUHWQvGlqLkBRFpQqlB15LsH0kCW0ur/pXAbRJBh+AK4QcnsEG0JXfo70 n9jJM4PuydRZZoyx77G2ihjxe2s59Ndx44Y2DFDfsOIiSK5p4ipVo5TtUtCIXLiALJ8h 7xQNHHdj4uvuKGtbMN/u6AipVlPkwOHLcDKGT77NaedgAz5PTFQEV3u4Fv0XHkOBmYAL XauzlaRoQx516gaLQ1+/JFjvs+x60mQX6AFsXfiL7N3TkoKasNTHwt5/Ec29fySsM20j ohsw== MIME-Version: 1.0 X-Received: by 10.180.83.199 with SMTP id s7mr347953wiy.19.1366364758021; Fri, 19 Apr 2013 02:45:58 -0700 (PDT) Received: by 10.194.76.147 with HTTP; Fri, 19 Apr 2013 02:45:57 -0700 (PDT) In-Reply-To: <20130414160648.GD96431@in-addr.com> References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Fri, 19 Apr 2013 11:45:57 +0200 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: David Demelier To: Gary Palmer Content-Type: text/plain; charset=UTF-8 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:46:48 -0000 2013/4/14 Gary Palmer : > 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 From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 09:54:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C42BA31C for ; Fri, 19 Apr 2013 09:54:10 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 4C1C4903 for ; Fri, 19 Apr 2013 09:54:10 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z2so3525610wey.1 for ; Fri, 19 Apr 2013 02:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=k98VZfFPlx9w/pd/PuH9WZnpqpR0TXhZkNN4H+DQ1A4=; b=MVLgcuIYotDn+YN2ofodta/zbK9oG4JrYK8T+zNM33j1uiqTdU92Z8CUFBF8HrpeMk /SeSI13Ft082kSXaxB7dfQ3OvNia7uLbCtSutDZ9lz5qp6gGamC/wOg9Vmf/sbRz+F1n UGMWEP1hNYZCOc4QIjb7zHD1AxBerE30Znl6H0Z8xZOOfA6T49qf2aQRUwNIe9gUpBU0 N7jQ5f9xJBJlT2RKaygtCqOavClV6qjsBxCTyk4tpu0rdNl0i9IXjt8XZLZYnJp3Ikpc cjQ5wwnxPOQDKoevMrDElDzdgCINeCHa28XKxnGoLGB74VP21bfH/OlvKudtNKytST8H nbCw== MIME-Version: 1.0 X-Received: by 10.180.91.106 with SMTP id cd10mr23887058wib.6.1366365249438; Fri, 19 Apr 2013 02:54:09 -0700 (PDT) Received: by 10.194.20.227 with HTTP; Fri, 19 Apr 2013 02:54:09 -0700 (PDT) In-Reply-To: References: Date: Fri, 19 Apr 2013 09:54:09 +0000 Message-ID: Subject: Re: Network connections are lost from time to time From: "C. L. Martinez" To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 09:54:10 -0000 On Fri, Apr 19, 2013 at 9:22 AM, C. L. Martinez wrote: > > > > On Fri, Apr 19, 2013 at 7:11 AM, C. L. Martinez wrote: > >> Hi all, >> >> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose >> ssh sessions from time to time frequently. >> >> This fbsd box is installed in an ESXi 5.1 server and I have another >> three fbsd 9.1 in the same ESXi host that do not have this problem, but >> maybe the problem is with my sysctl.conf and loader.conf settings: >> >> sysctl.conf >> >> # $FreeBSD: release/9.1.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux >> $ >> # >> # This file is read when going to multi-user and its contents piped thru >> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. >> # >> >> # Uncomment this to prevent users from seeing information about processes >> that >> # are being run under another UID. >> security.bsd.see_other_uids=0 >> security.bsd.see_other_gids=0 >> >> # Refresh arp table entries in 2 minutes >> net.link.ether.inet.max_age=120 >> >> # Drop tcp/udp packets destined for closed ports >> net.inet.tcp.blackhole=2 >> net.inet.udp.blackhole=1 >> >> # Use the H-TCP congestion control algorithm which is more aggressive >> ##net.inet.tcp.cc.algorithm=htcp >> >> # Host cache is used to cache connection details and metrics >> ##net.inet.tcp.hostcache.expire=5400 >> >> # Maximum segment size (MSS) specifies the largest amount of data in a >> single TCP segment >> net.inet.tcp.mssdflt=1440 >> >> # Make sure time stamps are enabled for slowstart_flightsize >> net.inet.tcp.rfc1323=1 >> >> # Make sure rfc3390 is DISABLED so the slowstart flightsize values are >> used. >> net.inet.tcp.rfc3390=0 >> >> # Size of the TCP transmit and receive buffer. >> net.inet.tcp.sendspace=262144 >> >> # Increase auto-tuning TCP step size of the TCP transmit and receive >> buffers. >> net.inet.tcp.recvbuf_inc=524288 >> >> # Somaxconn is the buffer or backlog queue depth for accepting new TCP >> connections. >> kern.ipc.somaxconn=1024 >> >> # Reduce the amount of SYN/ACKs we will _retransmit_ to an unresponsive >> initial connection. >> net.inet.tcp.syncache.rexmtlimit=1 >> >> # Spoofed packet attacks may be used to overload the kernel route cache. >> net.inet.ip.rtexpire=60 >> net.inet.ip.rtminexpire=2 >> net.inet.ip.rtmaxcache=1024 >> >> loader.conf: >> >> ############################################################## >> ### Loader settings ######################################## >> ############################################################## >> >> autoboot_delay="5" >> beastie_disable="YES" >> >> >> ############################################################## >> ### Kernel tunables ######################################## >> ############################################################## >> >> kern.maxfiles="25000" >> kern.ipc.nmbclusters="32768" >> net.inet.tcp.syncache.hashsize="1024" >> net.inet.tcp.syncache.bucketlimit="100" >> net.inet.tcp.tcbhashsize="4096" >> >> >> ############################################################## >> ### Hardware tunables ###################################### >> ############################################################## >> >> hw.pci.enable_msi="0" >> hw.pci.enable_msix="0" >> >> >> ############################################################## >> ### Networking modules ##################################### >> ############################################################## >> >> cc_htcp_load="YES" >> >> >> ############################################################## >> ### Other modules ########################################## >> ############################################################## >> >> aio_load="YES" >> >> How can I debug where is the problem?? >> > > More info when I try to connect with PuTTY from a windows desktop appears > the following error: > > Network error: Software caused connection abort. > > ... and pf is disabled (ipfw and ipfilter, too). > > More info: I have intermittent failures with sendmail: /var/spool/mqueue (1 request) -----Q-ID----- --Size-- -----Q-Time----- ------------Sender/Recipient----------- r3J9o54G022686 243 Fri Apr 19 09:50 (reply: read error from [10.196.0.100]) susor1@domain.com Total requests: 1 It is really strange ... From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 15:46:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C3AF8B13; Fri, 19 Apr 2013 15:46:06 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 2498CCDF; Fri, 19 Apr 2013 15:46:05 +0000 (UTC) Received: from cicuta.babolo.ru (cicuta.babolo.ru [194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id r3J9uDdu051446; Fri, 19 Apr 2013 13:56:13 +0400 (MSK) (envelope-from .@babolo.ru) Received: (nullmailer pid 94223 invoked by uid 136); Fri, 19 Apr 2013 10:06:20 -0000 Date: Fri, 19 Apr 2013 14:06:20 +0400 From: Aleksandr A Babaylov <.@babolo.ru> To: David Demelier Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130419100620.GA94200@babolo.ru> References: <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:46:06 -0000 On Fri, Apr 19, 2013 at 11:45:57AM +0200, David Demelier wrote: > 2013/4/14 Gary Palmer : > > 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 From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 15:52:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 59167917 for ; Fri, 19 Apr 2013 15:52:59 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm15-vm0.bullet.mail.bf1.yahoo.com (nm15-vm0.bullet.mail.bf1.yahoo.com [98.139.212.254]) by mx1.freebsd.org (Postfix) with SMTP id EF29B2C8 for ; Fri, 19 Apr 2013 15:52:58 +0000 (UTC) Received: from [98.139.215.140] by nm15.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2013 15:52:51 -0000 Received: from [98.139.213.11] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 19 Apr 2013 15:52:51 -0000 Received: from [127.0.0.1] by smtp111.mail.bf1.yahoo.com with NNFMP; 19 Apr 2013 15:52:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366386771; bh=VtJiYj5+usi1Jvs0awy4jbXUbeF+3H02ISbAefQdmyc=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=XWSzGevY9jy9Duxd3Q8SeHX9NEFrett7v5AIw2RNKRmNT0Gs4lCa00tLLrM8jm4uVdfBiDyrtQ5hXSVcgTj5HoAWWH8zxTJcFAq5+n+QkuHpXCk+8WU7/215hrc1ugVgc628CeSHt5KN3LzBmWilIRCrcHQWawJDDBracadFVzg= X-Yahoo-Newman-Id: 900788.14381.bm@smtp111.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: ywYAefgVM1msLVHrPPHPRETd5buHY0A1QmXXOwuLttQQXV8 Uy54s8jWqi9MCT.OQrd0i9S3q2Oki0H8HEyfIGNv0c7qMYeFlhfYdyib1TvB sJVg9qHf0dWEBvi9rv3zD_zoH1Z3B9PYmGheCCLV0OqOS8_gsYrEd6Drhi5D cJxpuxhSrNXJVVpb.o6hDxexQERPFKH.bIAbJdIBEcA5lye.EDNBUbZe9pLV pOh2jlo3CzS.qdKZ6fuVTOKXWR6qe1bZt5e5CV_v7exiEDQUyNuP8iJUPHFX gy5JLd.4OMy3z4DX4DXkU0BbfIn0wNThyGqDL_J4YAu7nq0eaHP5bHEt9F1Q meV.FOlYgl_kbmB1OKg50o1V400vUXLOPYl99n8YH2PLp8uSudrOv87TDVUs b6zhS8gNuJqkGtWuKQ8vx4XcooC2fyZxXoaynmM8fvxeaz1prSenJxfv3DWW r9yIC2fa4lNbzvj1BRGA_b1rdLh4sAu3XXzrmqK3B2KieO4sDDSgXQZic5U4 jroGkTlE8A9eEHo8Ys9f60uSr3fPim9_SBLC.rxlju9ka7j_5caVS_ww0c5m _ X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [192.168.43.121] (sean_bruno@70.211.76.117 with plain) by smtp111.mail.bf1.yahoo.com with SMTP; 19 Apr 2013 08:52:51 -0700 PDT Subject: Re: bge(4) sysctl tuneables -- a blast from the past. more knobs! MORE! From: Sean Bruno To: Bruce Evans In-Reply-To: <20130416152121.G904@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-zayncrzHB4mi1f2QEXBL" Date: Fri, 19 Apr 2013 08:52:46 -0700 Message-ID: <1366386766.1387.0.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:52:59 -0000 --=-zayncrzHB4mi1f2QEXBL Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Version 0.2 of patches to bge(4). I'm not totally happy with it, but comments welcome. I need better explanations of usage for the man page. I've dropped bge_rxd completely here as it was suggested to not even bother adjusting it. http://people.freebsd.org/~sbruno/bge_config_update_1.txt > I didn't notice before that these are tunables and not sysctls. That's > much more broken. Actually tuning using them like I do with sysctls > would take ~10000 reboots. Tunables are bogus for anything that isn't > needed for booting. Optimizations are needed for booting. >=20 Done and changed. Things seem to do the right thing when adjusted. > Technical bugs include: > - wrong defaults are claimed for *coal_ticks. The defaults are 150, but > are claimed to be 150 milliseconds. These values are dimensionless, > but since ticks take 1 microsecond each, 150 gives 150 microseconds, > not 150 milliseconds. man page updated to reflect usec timing. checked the tech docs as well and confirmed microseconds. > - *coal_bds is claimed to be a count of packes (sic). Actually, it is a > count of buffer descriptors. Small packets take 1 bd, but normal > packets take 2, and jumbo packets many (?). The best tuning may be > depend on the average bds/packet. man page updated with wording that attempts to say this. > - the new tunables are in the wrong namespace (hw instead of dev) fixed > - the new tunables are too global (bge instead of bge.N) fixed >=20 > There are only 2 bge tunables now, and they only have half of these bugs: > - hw.bge.allow_asf is in the wrong namespace > - hw.bge.allow_asf is too global Maintainer disagrees with this. > - dev.bge.%d.msi seems to be correct. > Both of the old tunables are needed for boot-time configuration. >=20 > Bruce Sean --=-zayncrzHB4mi1f2QEXBL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRcWhJAAoJEBkJRdwI6BaHFDwH/1GyDPS42EREiT23E5oOu5Bv R03H29KIl6fEz4BmWjYxQ0SYPKp50fAHCeu3P9OrlwPGv0DwsViYh2g9D7T19Gx4 GGRUUEfyEQj0mw6GCjaV5vVfMUZyMo64zpReDjgyaWyQXmratXp3IfcRVnqLq87v iRerFfnNWujqg0TCxenRT0+6/4TwxLJ8FLhhVqAoYx36LT7aWpoTwxBglzQ0hkgx 4wiwtvtvyBYnxOTifig2VfAWeDELTrL37Zq4sZGLpysvlJxvsGZJOQwJCUlXQa4O 9byTTgIBelM8t7c4Yo+H5UuWfxdf4+4Bu24DmYAZmahBT6MWzy6YzJ5wkcjMhL0= =0ge+ -----END PGP SIGNATURE----- --=-zayncrzHB4mi1f2QEXBL-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:48:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4809170D for ; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24874881 for ; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id EA59FB95B; Fri, 19 Apr 2013 12:29:07 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: Network connections are lost from time to time Date: Fri, 19 Apr 2013 11:49:22 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304191149.22998.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 12:29:08 -0400 (EDT) Cc: "C. L. Martinez" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:48:46 -0000 On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote: > Hi all, > > I have a strange problem with my FreeBSD 9.1 (fully patched): I loose ssh > sessions from time to time frequently. > > This fbsd box is installed in an ESXi 5.1 server and I have another three > fbsd 9.1 in the same ESXi host that do not have this problem, but maybe the > problem is with my sysctl.conf and loader.conf settings: Which NIC driver are you using? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:48:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4927070E; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 24820880; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id C90ABB992; Fri, 19 Apr 2013 12:29:08 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST Date: Fri, 19 Apr 2013 12:09:11 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201303141500.r2EF01EQ079753@freefall.freebsd.org> In-Reply-To: <201303141500.r2EF01EQ079753@freefall.freebsd.org> MIME-Version: 1.0 Message-Id: <201304191209.11316.jhb@freebsd.org> Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 12:29:08 -0400 (EDT) Cc: Jack Vogel , bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:48:46 -0000 I want to make some progress on this, so let's break this up into smaller parts. First, I think both calls to rearm_queues() should be removed. In the case of the local timer, this can only re-enable interrupts if the interrupt handler is already scheduled or running or its associated task is running. In the last case this means the ithread can run concurrently with the interrupt handler causing out-of-order processing. The rxeof case has the same issue. Normally the code calling rxeof is going to re-enable the interrupt if rxeof runs to completion, and if not it is going to schedule the taskqueue. The effect of the rxeof change was to always re-enable interrupts before scheduling the taskqueue which can result in those running concurrently. Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision 249553) +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working copy) @@ -1386,23 +1386,6 @@ } } -static inline void -ixgbe_rearm_queues(struct adapter *adapter, u64 queues) -{ - u32 mask; - - if (adapter->hw.mac.type == ixgbe_mac_82598EB) { - mask = (IXGBE_EIMS_RTX_QUEUE & queues); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS, mask); - } else { - mask = (queues & 0xFFFFFFFF); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS_EX(0), mask); - mask = (queues >> 32); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS_EX(1), mask); - } -} - - static void ixgbe_handle_que(void *context, int pending) { @@ -2069,7 +2055,6 @@ goto watchdog; out: - ixgbe_rearm_queues(adapter, adapter->que_mask); callout_reset(&adapter->timer, hz, ixgbe_local_timer, adapter); return; @@ -4596,14 +4577,8 @@ /* ** We still have cleaning to do? - ** Schedule another interrupt if so. */ - if ((staterr & IXGBE_RXD_STAT_DD) != 0) { - ixgbe_rearm_queues(adapter, (u64)(1 << que->msix)); - return (TRUE); - } - - return (FALSE); + return ((staterr & IXGBE_RXD_STAT_DD) != 0); } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:48:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6727D70F; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 25448882; Fri, 19 Apr 2013 17:48:46 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 85A32B995; Fri, 19 Apr 2013 12:29:09 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST Date: Fri, 19 Apr 2013 12:27:09 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201303141500.r2EF01EQ079753@freefall.freebsd.org> In-Reply-To: <201303141500.r2EF01EQ079753@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201304191227.09439.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 12:29:09 -0400 (EDT) Cc: Mike Karels , Jack Vogel , bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:48:46 -0000 A second patch. This is not something I mentioned before, but I had this in my checkout. In the legacy IRQ case this could also result in out-of-order processing. It also fixes a potential OACTIVE-stuck type bug that we used to have in igb. I have no way to test this, so it would be good if some other folks could test this. The patch changes ixgbe_txeof() return void and changes the few places that checked its return value to ignore it. While it is true that ixgbe has a tx processing limit (which I think is dubious.. TX completion processing is very cheap unlike RX processing, so it seems to me like it should always run to completion as in igb), in the common case I think the result will be to do what igb used to do: poll the ring at 100% CPU (either in the interrupt handler or in the task it keeps rescheduling) waiting for pending TX packets to be completed (which is pointless: the host CPU can't make the NIC transmit packets any faster by polling). It also changes the interrupt handlers to restart packet transmission synchronously rather than always deferring that to a task (the former is what (nearly) all other drivers do). It also fixes the interrupt handlers to be consistent (one looped on txeof but not the others). In the case of the legacy interrupt handler it is possible it could fail to restart packet transmission if there were no pending RX packets after rxeof returned and txeof fully cleaned its ring without this change. It also fixes the legacy interrupt handler to not re-enable the interrupt if it schedules the task but to wait until the task completes (this could result in concurrent, out-of-order RX processing). Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision 249553) +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working copy) @@ -149,7 +149,7 @@ static void ixgbe_enable_intr(struct adapter *); static void ixgbe_disable_intr(struct adapter *); static void ixgbe_update_stats_counters(struct adapter *); -static bool ixgbe_txeof(struct tx_ring *); +static void ixgbe_txeof(struct tx_ring *); static bool ixgbe_rxeof(struct ix_queue *); static void ixgbe_rx_checksum(u32, struct mbuf *, u32); static void ixgbe_set_promisc(struct adapter *); @@ -1431,7 +1414,10 @@ } /* Reenable this interrupt */ - ixgbe_enable_queue(adapter, que->msix); + if (que->res != NULL) + ixgbe_enable_queue(adapter, que->msix); + else + ixgbe_enable_intr(adapter); return; } @@ -1449,8 +1435,9 @@ struct adapter *adapter = que->adapter; struct ixgbe_hw *hw = &adapter->hw; struct tx_ring *txr = adapter->tx_rings; - bool more_tx, more_rx; - u32 reg_eicr, loop = MAX_LOOP; + struct ifnet *ifp = adapter->ifp; + bool more; + u32 reg_eicr; reg_eicr = IXGBE_READ_REG(hw, IXGBE_EICR); @@ -1461,17 +1448,19 @@ return; } - more_rx = ixgbe_rxeof(que); + more = ixgbe_rxeof(que); IXGBE_TX_LOCK(txr); - do { - more_tx = ixgbe_txeof(txr); - } while (loop-- && more_tx); + ixgbe_txeof(txr); +#if __FreeBSD_version >= 800000 + if (!drbr_empty(ifp, txr->br)) + ixgbe_mq_start_locked(ifp, txr, NULL); +#else + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + ixgbe_start_locked(txr, ifp); +#endif IXGBE_TX_UNLOCK(txr); - if (more_rx || more_tx) - taskqueue_enqueue(que->tq, &que->que_task); - /* Check for fan failure */ if ((hw->phy.media_type == ixgbe_media_type_copper) && (reg_eicr & IXGBE_EICR_GPI_SDP1)) { @@ -1484,7 +1473,10 @@ if (reg_eicr & IXGBE_EICR_LSC) taskqueue_enqueue(adapter->tq, &adapter->link_task); - ixgbe_enable_intr(adapter); + if (more) + taskqueue_enqueue(que->tq, &que->que_task); + else + ixgbe_enable_intr(adapter); return; } @@ -1501,27 +1493,24 @@ struct adapter *adapter = que->adapter; struct tx_ring *txr = que->txr; struct rx_ring *rxr = que->rxr; - bool more_tx, more_rx; + struct ifnet *ifp = adapter->ifp; + bool more; u32 newitr = 0; ixgbe_disable_queue(adapter, que->msix); ++que->irqs; - more_rx = ixgbe_rxeof(que); + more = ixgbe_rxeof(que); IXGBE_TX_LOCK(txr); - more_tx = ixgbe_txeof(txr); - /* - ** Make certain that if the stack - ** has anything queued the task gets - ** scheduled to handle it. - */ + ixgbe_txeof(txr); #ifdef IXGBE_LEGACY_TX if (!IFQ_DRV_IS_EMPTY(&adapter->ifp->if_snd)) + ixgbe_start_locked(txr, ifp); #else - if (!drbr_empty(adapter->ifp, txr->br)) + if (!drbr_empty(ifp, txr->br)) + ixgbe_mq_start_locked(ifp, txr, NULL); #endif - more_tx = 1; IXGBE_TX_UNLOCK(txr); /* Do AIM now? */ @@ -1575,7 +1564,7 @@ rxr->packets = 0; no_calc: - if (more_tx || more_rx) + if (more) taskqueue_enqueue(que->tq, &que->que_task); else /* Reenable this interrupt */ ixgbe_enable_queue(adapter, que->msix); @@ -3557,7 +3545,7 @@ * tx_buffer is put back on the free queue. * **********************************************************************/ -static bool +static void ixgbe_txeof(struct tx_ring *txr) { struct adapter *adapter = txr->adapter; @@ -3605,13 +3593,13 @@ IXGBE_CORE_UNLOCK(adapter); IXGBE_TX_LOCK(txr); } - return FALSE; + return; } #endif /* DEV_NETMAP */ if (txr->tx_avail == txr->num_desc) { txr->queue_status = IXGBE_QUEUE_IDLE; - return FALSE; + return; } /* Get work starting point */ @@ -3705,12 +3693,8 @@ if ((!processed) && ((ticks - txr->watchdog_time) > IXGBE_WATCHDOG)) txr->queue_status = IXGBE_QUEUE_HUNG; - if (txr->tx_avail == txr->num_desc) { + if (txr->tx_avail == txr->num_desc) txr->queue_status = IXGBE_QUEUE_IDLE; - return (FALSE); - } - - return TRUE; } /********************************************************************* -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:48:52 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3FB0271E; Fri, 19 Apr 2013 17:48:52 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id E5B9D889; Fri, 19 Apr 2013 17:48:51 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id ar20so5015255iec.14 for ; Fri, 19 Apr 2013 10:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=B2PVB8cMSMjH86q4mCsr0c1/Pu6/ba/kyJtm9aD+ScI=; b=SiXpdu7naWvwD6CGtzusMIYQRjmFINV7XLKCDiFbLR4SZQxO6fK0p4HhQ5/UPf0Gfp ukB2R6r8iIgzcXm3bz6PleE1UF2I3K+iaj+Rpupgzf9O1WSBAtqmrViSKxwkyHZ3dK// c9YnJOf7ltaIPKZ5jBzpNwVdZKgssQBNmFTIMaGOWlpMkIIgbBiDUaAzJPAC17/87xou xih6Duidrb+JfY+IIs+O7UwmFdz3jdHMDvtgebw7zHH6bAL52x/rc3T5NjreVrOgHHTF iunFlVTIp0AKBd9nXAt8CE7H8Po9tnz7kFC7WvNa2//qtq+FOmFoO4aZ7b8LuHdwJTpl tpGA== MIME-Version: 1.0 X-Received: by 10.50.42.165 with SMTP id p5mr16329322igl.75.1366392355057; Fri, 19 Apr 2013 10:25:55 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Fri, 19 Apr 2013 10:25:54 -0700 (PDT) Received: by 10.64.58.52 with HTTP; Fri, 19 Apr 2013 10:25:54 -0700 (PDT) In-Reply-To: References: <20130411201805.GD76816@FreeBSD.org> <7D8ACD5C-821D-4505-82E4-02267A7BA4F8@FreeBSD.org> <96D56EAE-E797-429E-AEC9-42B19B048CCC@FreeBSD.org> <6DEDD3EA-45C1-4549-AA13-5E4F6674BE3E@samsco.org> <2D0B66DB-E232-4F34-9D01-57DF226B9BAA@FreeBSD.org> <2DA4A561-3304-432D-B5D1-7053A27E758F@yahoo.com> <20130414160648.GD96431@in-addr.com> Date: Fri, 19 Apr 2013 18:25:54 +0100 Message-ID: Subject: Re: ipfilter(4) needs maintainer From: Chris Rees To: David DEMELIER Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Warren Block , Scott Long , "current@freebsd.org" , Chris Rees , Rui Paulo , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:48:52 -0000 On 19 Apr 2013 10:46, "David Demelier" wrote: > > 2013/4/14 Gary Palmer : > > 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 From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:50:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BF071BBB for ; Fri, 19 Apr 2013 17:50:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id B122B910 for ; Fri, 19 Apr 2013 17:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3JHo2qO083286 for ; Fri, 19 Apr 2013 17:50:02 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3JHo2An083285; Fri, 19 Apr 2013 17:50:02 GMT (envelope-from gnats) Date: Fri, 19 Apr 2013 17:50:02 GMT Message-Id: <201304191750.r3JHo2An083285@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:50:02 -0000 The following reply was made to PR kern/176446; it has been noted by GNATS. From: John Baldwin To: freebsd-net@freebsd.org Cc: Jack Vogel , bug-followup@freebsd.org, Mike Karels Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST Date: Fri, 19 Apr 2013 12:27:09 -0400 A second patch. This is not something I mentioned before, but I had this in my checkout. In the legacy IRQ case this could also result in out-of-order processing. It also fixes a potential OACTIVE-stuck type bug that we used to have in igb. I have no way to test this, so it would be good if some other folks could test this. The patch changes ixgbe_txeof() return void and changes the few places that checked its return value to ignore it. While it is true that ixgbe has a tx processing limit (which I think is dubious.. TX completion processing is very cheap unlike RX processing, so it seems to me like it should always run to completion as in igb), in the common case I think the result will be to do what igb used to do: poll the ring at 100% CPU (either in the interrupt handler or in the task it keeps rescheduling) waiting for pending TX packets to be completed (which is pointless: the host CPU can't make the NIC transmit packets any faster by polling). It also changes the interrupt handlers to restart packet transmission synchronously rather than always deferring that to a task (the former is what (nearly) all other drivers do). It also fixes the interrupt handlers to be consistent (one looped on txeof but not the others). In the case of the legacy interrupt handler it is possible it could fail to restart packet transmission if there were no pending RX packets after rxeof returned and txeof fully cleaned its ring without this change. It also fixes the legacy interrupt handler to not re-enable the interrupt if it schedules the task but to wait until the task completes (this could result in concurrent, out-of-order RX processing). Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision 249553) +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working copy) @@ -149,7 +149,7 @@ static void ixgbe_enable_intr(struct adapter *); static void ixgbe_disable_intr(struct adapter *); static void ixgbe_update_stats_counters(struct adapter *); -static bool ixgbe_txeof(struct tx_ring *); +static void ixgbe_txeof(struct tx_ring *); static bool ixgbe_rxeof(struct ix_queue *); static void ixgbe_rx_checksum(u32, struct mbuf *, u32); static void ixgbe_set_promisc(struct adapter *); @@ -1431,7 +1414,10 @@ } /* Reenable this interrupt */ - ixgbe_enable_queue(adapter, que->msix); + if (que->res != NULL) + ixgbe_enable_queue(adapter, que->msix); + else + ixgbe_enable_intr(adapter); return; } @@ -1449,8 +1435,9 @@ struct adapter *adapter = que->adapter; struct ixgbe_hw *hw = &adapter->hw; struct tx_ring *txr = adapter->tx_rings; - bool more_tx, more_rx; - u32 reg_eicr, loop = MAX_LOOP; + struct ifnet *ifp = adapter->ifp; + bool more; + u32 reg_eicr; reg_eicr = IXGBE_READ_REG(hw, IXGBE_EICR); @@ -1461,17 +1448,19 @@ return; } - more_rx = ixgbe_rxeof(que); + more = ixgbe_rxeof(que); IXGBE_TX_LOCK(txr); - do { - more_tx = ixgbe_txeof(txr); - } while (loop-- && more_tx); + ixgbe_txeof(txr); +#if __FreeBSD_version >= 800000 + if (!drbr_empty(ifp, txr->br)) + ixgbe_mq_start_locked(ifp, txr, NULL); +#else + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) + ixgbe_start_locked(txr, ifp); +#endif IXGBE_TX_UNLOCK(txr); - if (more_rx || more_tx) - taskqueue_enqueue(que->tq, &que->que_task); - /* Check for fan failure */ if ((hw->phy.media_type == ixgbe_media_type_copper) && (reg_eicr & IXGBE_EICR_GPI_SDP1)) { @@ -1484,7 +1473,10 @@ if (reg_eicr & IXGBE_EICR_LSC) taskqueue_enqueue(adapter->tq, &adapter->link_task); - ixgbe_enable_intr(adapter); + if (more) + taskqueue_enqueue(que->tq, &que->que_task); + else + ixgbe_enable_intr(adapter); return; } @@ -1501,27 +1493,24 @@ struct adapter *adapter = que->adapter; struct tx_ring *txr = que->txr; struct rx_ring *rxr = que->rxr; - bool more_tx, more_rx; + struct ifnet *ifp = adapter->ifp; + bool more; u32 newitr = 0; ixgbe_disable_queue(adapter, que->msix); ++que->irqs; - more_rx = ixgbe_rxeof(que); + more = ixgbe_rxeof(que); IXGBE_TX_LOCK(txr); - more_tx = ixgbe_txeof(txr); - /* - ** Make certain that if the stack - ** has anything queued the task gets - ** scheduled to handle it. - */ + ixgbe_txeof(txr); #ifdef IXGBE_LEGACY_TX if (!IFQ_DRV_IS_EMPTY(&adapter->ifp->if_snd)) + ixgbe_start_locked(txr, ifp); #else - if (!drbr_empty(adapter->ifp, txr->br)) + if (!drbr_empty(ifp, txr->br)) + ixgbe_mq_start_locked(ifp, txr, NULL); #endif - more_tx = 1; IXGBE_TX_UNLOCK(txr); /* Do AIM now? */ @@ -1575,7 +1564,7 @@ rxr->packets = 0; no_calc: - if (more_tx || more_rx) + if (more) taskqueue_enqueue(que->tq, &que->que_task); else /* Reenable this interrupt */ ixgbe_enable_queue(adapter, que->msix); @@ -3557,7 +3545,7 @@ * tx_buffer is put back on the free queue. * **********************************************************************/ -static bool +static void ixgbe_txeof(struct tx_ring *txr) { struct adapter *adapter = txr->adapter; @@ -3605,13 +3593,13 @@ IXGBE_CORE_UNLOCK(adapter); IXGBE_TX_LOCK(txr); } - return FALSE; + return; } #endif /* DEV_NETMAP */ if (txr->tx_avail == txr->num_desc) { txr->queue_status = IXGBE_QUEUE_IDLE; - return FALSE; + return; } /* Get work starting point */ @@ -3705,12 +3693,8 @@ if ((!processed) && ((ticks - txr->watchdog_time) > IXGBE_WATCHDOG)) txr->queue_status = IXGBE_QUEUE_HUNG; - if (txr->tx_avail == txr->num_desc) { + if (txr->tx_avail == txr->num_desc) txr->queue_status = IXGBE_QUEUE_IDLE; - return (FALSE); - } - - return TRUE; } /********************************************************************* -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:50:04 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 279E1BC6 for ; Fri, 19 Apr 2013 17:50:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id F267F918 for ; Fri, 19 Apr 2013 17:50:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3JHo3aP083304 for ; Fri, 19 Apr 2013 17:50:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3JHo3Ur083303; Fri, 19 Apr 2013 17:50:03 GMT (envelope-from gnats) Date: Fri, 19 Apr 2013 17:50:03 GMT Message-Id: <201304191750.r3JHo3Ur083303@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:50:04 -0000 The following reply was made to PR kern/176446; it has been noted by GNATS. From: John Baldwin To: freebsd-net@freebsd.org Cc: Jack Vogel , bug-followup@freebsd.org Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST Date: Fri, 19 Apr 2013 12:09:11 -0400 I want to make some progress on this, so let's break this up into smaller parts. First, I think both calls to rearm_queues() should be removed. In the case of the local timer, this can only re-enable interrupts if the interrupt handler is already scheduled or running or its associated task is running. In the last case this means the ithread can run concurrently with the interrupt handler causing out-of-order processing. The rxeof case has the same issue. Normally the code calling rxeof is going to re-enable the interrupt if rxeof runs to completion, and if not it is going to schedule the taskqueue. The effect of the rxeof change was to always re-enable interrupts before scheduling the taskqueue which can result in those running concurrently. Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =================================================================== --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision 249553) +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working copy) @@ -1386,23 +1386,6 @@ } } -static inline void -ixgbe_rearm_queues(struct adapter *adapter, u64 queues) -{ - u32 mask; - - if (adapter->hw.mac.type == ixgbe_mac_82598EB) { - mask = (IXGBE_EIMS_RTX_QUEUE & queues); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS, mask); - } else { - mask = (queues & 0xFFFFFFFF); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS_EX(0), mask); - mask = (queues >> 32); - IXGBE_WRITE_REG(&adapter->hw, IXGBE_EICS_EX(1), mask); - } -} - - static void ixgbe_handle_que(void *context, int pending) { @@ -2069,7 +2055,6 @@ goto watchdog; out: - ixgbe_rearm_queues(adapter, adapter->que_mask); callout_reset(&adapter->timer, hz, ixgbe_local_timer, adapter); return; @@ -4596,14 +4577,8 @@ /* ** We still have cleaning to do? - ** Schedule another interrupt if so. */ - if ((staterr & IXGBE_RXD_STAT_DD) != 0) { - ixgbe_rearm_queues(adapter, (u64)(1 << que->msix)); - return (TRUE); - } - - return (FALSE); + return ((staterr & IXGBE_RXD_STAT_DD) != 0); } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 17:52:30 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C0D7C343; Fri, 19 Apr 2013 17:52:30 +0000 (UTC) (envelope-from adrian@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2359FB; Fri, 19 Apr 2013 17:52:30 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3JHqUxa084963; Fri, 19 Apr 2013 17:52:30 GMT (envelope-from adrian@freefall.freebsd.org) Received: (from adrian@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3JHqUBf084962; Fri, 19 Apr 2013 17:52:30 GMT (envelope-from adrian) Date: Fri, 19 Apr 2013 17:52:30 GMT Message-Id: <201304191752.r3JHqUBf084962@freefall.freebsd.org> To: adrian@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-embedded@FreeBSD.org From: adrian@FreeBSD.org Subject: Re: kern/177878: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes on kern/177873 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 17:52:30 -0000 Synopsis: [rtl8366rb] [patch] Update rtl8366rb switch driver to match changes on kern/177873 Responsible-Changed-From-To: freebsd-net->freebsd-embedded Responsible-Changed-By: adrian Responsible-Changed-When: Fri Apr 19 17:52:19 UTC 2013 Responsible-Changed-Why: snarf. http://www.freebsd.org/cgi/query-pr.cgi?pr=177878 From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 18:25:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6675D45E for ; Fri, 19 Apr 2013 18:25:54 +0000 (UTC) (envelope-from sean_bruno@yahoo.com) Received: from nm33-vm6.bullet.mail.gq1.yahoo.com (nm33-vm6.bullet.mail.gq1.yahoo.com [98.136.216.245]) by mx1.freebsd.org (Postfix) with ESMTP id 2ADB2119F for ; Fri, 19 Apr 2013 18:25:54 +0000 (UTC) Received: from [98.137.12.191] by nm33.bullet.mail.gq1.yahoo.com with NNFMP; 19 Apr 2013 05:13:09 -0000 Received: from [208.71.42.203] by tm12.bullet.mail.gq1.yahoo.com with NNFMP; 19 Apr 2013 05:13:09 -0000 Received: from [127.0.0.1] by smtp214.mail.gq1.yahoo.com with NNFMP; 19 Apr 2013 05:13:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1366348389; bh=6Gt7lPc1luhDCz+bRhUCDghtGCqBHZxBiaHfiMXQN1s=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Subject:From:Reply-To:To:Cc:In-Reply-To:References:Content-Type:Date:Message-ID:Mime-Version:X-Mailer; b=uS8IzL89X2rXiC5lkEzGJqFCOljasM4UPWnIWN9uJOc/S4NoTW/aNkcHs1EFgVg6jq62g+jNEpFqwkbr2DB1aK5vLaYXRx6uWPh8XaVPu4aRGFRZzi72GrO4U77Y2YAErMMJH2CYkVySz0g4nZv+OY0WB8P8oOKjhN8p2R5OXFE= X-Yahoo-Newman-Id: 439863.16558.bm@smtp214.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: pZbDVfsVM1lCA.Le5GSsjb53OC5s24nw9LaM3dneThg9h3u WNTBlzICt4D3YzQXePwRHBlmx.FhvgfPqF3O_cXWHnBviKT0xe6XUMiS9dwT qkIcJdwRjgS8kpJkQIb1R3_TcxHRAOw0Ra2bxGJFyeEQQh1tGLlnEY8iHSf8 .jUozjMAk4_NmRWuxqum9VMLQ_.ftfMa7TbRfJSOBBgSSFeAx.kpmcmH.x3M M0ck0C3BMxcXFf77VJYe6eqN5cMl0RMUr_PuNjXbh3DymTfBn_R7NUK80mLx LnzEGIHSXVThQEVoVM2poiR3K7emQswilUJEVL7gl8dWAdJuscgqPHGOMRjH W_jlbgPqIRQYV1Smoxo8ymP_uVAnhYqj3Vy26zWCLRDY497vO2LZ.gABEUyw pQNyxCP5Se7NFG_ykNW8Bf8CNORsEisIuuu_gwcj3t0Nr.0JhIH.iWlP2HHa IElghg_jtF6WblWpB_fvZTeXTBQS1MJyQXQDIQrhfcgVjqO0awcAgHGEb.GW 0rvlUmY1CLeDUjTT8XvxHdKOrzfi5496O4YXgqVkZY7TBU5goeUflqoWIY8M oJyNowGPcN5J2CIJ1dgk1 X-Yahoo-SMTP: u5BKR6OswBC_iZJVfGRoMkTIpc8pEA4- X-Rocket-Received: from [10.73.210.63] (sean_bruno@209.131.62.145 with plain) by smtp214.mail.gq1.yahoo.com with SMTP; 18 Apr 2013 22:13:09 -0700 PDT Subject: Re: bge(4) sysctl tuneables -- a blast from the past. more knobs! MORE! From: Sean Bruno To: Bruce Evans In-Reply-To: <20130416152121.G904@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="=-0Pjypm7Wx2XM1dPF/zws" Date: Thu, 18 Apr 2013 22:13:08 -0700 Message-ID: <1366348388.1389.11.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , bde X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:25:54 -0000 --=-0Pjypm7Wx2XM1dPF/zws Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Version 0.2 of patches to bge(4). I'm not totally happy with it, but comments welcome. I need better explanations of usage for the man page. I've dropped bge_rxd completely here as it was suggested to not even bother adjusting it. http://people.freebsd.org/~sbruno/bge_config_update_1.txt > I didn't notice before that these are tunables and not sysctls. That's > much more broken. Actually tuning using them like I do with sysctls > would take ~10000 reboots. Tunables are bogus for anything that isn't > needed for booting. Optimizations are needed for booting. >=20 Done and changed. Things seem to do the right thing when adjusted. > Technical bugs include: > - wrong defaults are claimed for *coal_ticks. The defaults are 150, but > are claimed to be 150 milliseconds. These values are dimensionless, > but since ticks take 1 microsecond each, 150 gives 150 microseconds, > not 150 milliseconds. man page updated to reflect usec timing. checked the tech docs as well and confirmed microseconds. > - *coal_bds is claimed to be a count of packes (sic). Actually, it is a > count of buffer descriptors. Small packets take 1 bd, but normal > packets take 2, and jumbo packets many (?). The best tuning may be > depend on the average bds/packet. man page updated with wording that attempts to say this. > - the new tunables are in the wrong namespace (hw instead of dev) fixed > - the new tunables are too global (bge instead of bge.N) fixed >=20 > There are only 2 bge tunables now, and they only have half of these bugs: > - hw.bge.allow_asf is in the wrong namespace > - hw.bge.allow_asf is too global Maintainer disagrees with this. > - dev.bge.%d.msi seems to be correct. > Both of the old tunables are needed for boot-time configuration. >=20 > Bruce Sean --=-0Pjypm7Wx2XM1dPF/zws Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRcNJkAAoJEBkJRdwI6BaH9CgH/ijLqMCY6kZz86aoKIc5LINs SQok2VVpx3Fmrg+ecXsslHCzEfrsFXOiW6iCZBv4gB79FcWQtwEmmU7TubaoiehS sQgxvkkaCpt3dVYwF1CR9DqfKWjYp4nljQMR3shOgGjPRyM7vLUdottLFMHZZzKY yXaEg4U1O5mxdq5BK76Fg0OOc/3liGqSoKcX4OYPES0jSV9PmZLGVo6/3ivAtD/q QmlTqSp05YyaVVPe4Yrn77M3XsMtwfi8WiJwT3tcRQAj16Za3FgIGqcsmPaLC4LT +i7tjZ8IrEJV/QTp0P1BsDtDD5qOAP2V07rW9Z0ZmD1onpf08LUrDCWY4o3EX40= =vAll -----END PGP SIGNATURE----- --=-0Pjypm7Wx2XM1dPF/zws-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 18:27:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CFF3255F; Fri, 19 Apr 2013 18:27:15 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 4452711C4; Fri, 19 Apr 2013 18:27:15 +0000 (UTC) Received: by mail-wi0-f170.google.com with SMTP id l13so1410816wie.3 for ; Fri, 19 Apr 2013 11:27:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lRVJBehmx25FkyKXgPmoBWs4aHZqxg7/12ZxI1EmR+0=; b=Air2RSy6ImZBsHZ0HM+Xscb/UfzFL0oEYGYFPCK0DzBfkj0b9I0nTtJ2je5FV9H0k+ L1nrmD6KtY5f6TGhKHZXdxahFASK5cqIp1cNWQJChd9jabFdCWMy2Y9SGu9YXtWJzkYe 8oNwQUBPM8FntArofwnJhX8WEAAPkRr6rOJZXgC3FsNVHIRctCJ+3bvouGzUKutMsiz0 kaaTph5nb3qEOWpBEdvALGftsGE3kISLuOiHdt96II+ZYu2MBueQBmuXDggCJqae5tPA kwNNLraF0pH/WvJutH1rNvJ/2pK5ISCPGa3TamXuIIjNgk6D7rFhVVf2zzHS/j1WdfIm ruOA== MIME-Version: 1.0 X-Received: by 10.180.77.226 with SMTP id v2mr41167581wiw.33.1366389138312; Fri, 19 Apr 2013 09:32:18 -0700 (PDT) Received: by 10.194.20.227 with HTTP; Fri, 19 Apr 2013 09:32:18 -0700 (PDT) In-Reply-To: <201304191149.22998.jhb@freebsd.org> References: <201304191149.22998.jhb@freebsd.org> Date: Fri, 19 Apr 2013 16:32:18 +0000 Message-ID: Subject: Re: Network connections are lost from time to time From: "C. L. Martinez" To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:27:15 -0000 On Friday, April 19, 2013, John Baldwin wrote: > On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote: >> Hi all, >> >> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose ssh >> sessions from time to time frequently. >> >> This fbsd box is installed in an ESXi 5.1 server and I have another three >> fbsd 9.1 in the same ESXi host that do not have this problem, but maybe the >> problem is with my sysctl.conf and loader.conf settings: > > Which NIC driver are you using? > > -- > John Baldwin e1000. > From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 18:44:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 37CE73E4 for ; Fri, 19 Apr 2013 18:44:56 +0000 (UTC) (envelope-from jzhang2000@gmail.com) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id B9B1D15C3 for ; Fri, 19 Apr 2013 18:44:55 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id es20so2517lab.41 for ; Fri, 19 Apr 2013 11:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=ybZQQBiUTvpQiIrIM/ly//Qf5X9GBvSLtZghwMd9cpg=; b=tQCFd1jiKqC3DTgyd67v8Ggiw0G48dsvkJh3BS3hGGNzF2Yt40tqT5sP6QCthhgRsH HSuQX0TeDbpUsJWS0dtNi0psI9dBf+rgf0OhHin9QcU+nxCg9/QZ6aVDklva4J9PkYgb WYGPeA/d3aUJtSe+fp0IqkjmuJ4gBiMw0AzsubmKA1hMMM/fgLZTrqwci5hryGLZI8KM XJUmXkE4TS9zIB85fdVP4Mnm7ZYK0D9tN8YSLhUEvPFOWJWWS2zF4V0E6AbUeeUjWUWz Ff3r6wzb45DPnGpLhY3PhQVLBdihMS3reFwNeFSdygXN1SmOKPM8jwK8ZVLtXMKVV9/J 1qww== MIME-Version: 1.0 X-Received: by 10.112.162.100 with SMTP id xz4mr3035415lbb.91.1366397094585; Fri, 19 Apr 2013 11:44:54 -0700 (PDT) Received: by 10.114.173.161 with HTTP; Fri, 19 Apr 2013 11:44:54 -0700 (PDT) Date: Fri, 19 Apr 2013 14:44:54 -0400 Message-ID: Subject: Any existing work for routing socket to pick event notifications like IPv6 prefix add/delete/expiring From: Jimmy Zhang To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 18:44:56 -0000 Hi, Our user space program would like to be notified upon these IPv6 events brought by Router Advertisement messages. Any existing work or any plan in this area? Thanks, Jimmy From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 19:03:32 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 95E18ABD; Fri, 19 Apr 2013 19:03:32 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 02FFB173E; Fri, 19 Apr 2013 19:03:31 +0000 (UTC) Received: from mail17.syd.optusnet.com.au (mail17.syd.optusnet.com.au [211.29.132.198]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3JBWnBd030164; Fri, 19 Apr 2013 21:32:49 +1000 Received: from c211-30-173-106.carlnfd1.nsw.optusnet.com.au (c211-30-173-106.carlnfd1.nsw.optusnet.com.au [211.30.173.106]) by mail17.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id r3JBWcE4012696 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 21:32:40 +1000 Date: Fri, 19 Apr 2013 21:32:38 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: sbruno@FreeBSD.org Subject: Re: bge(4) sysctl tuneables -- a blast from the past. more knobs! MORE! In-Reply-To: <1366348388.1389.11.camel@localhost> Message-ID: <20130419203629.N1028@besplex.bde.org> References: <1365781568.1418.1.camel@localhost> <20130413200512.G1165@besplex.bde.org> <1366065356.1350.7.camel@localhost> <20130416152121.G904@besplex.bde.org> <1366348388.1389.11.camel@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=Ov0XUFDt c=1 sm=1 a=mFpRME-EEqMA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=gmUmqqDpSwAA:10 a=6I5d2MoRAAAA:8 a=xB1JHitMHlILzK4byPMA:9 a=CjuIK1q_8ugA:10 a=02v0E20eI2-Xn35J:21 a=zPCK-PPU6FJlAUc6:21 a=TEtd8y5WR3g2ypngnwZWYw==:117 Cc: "pyunyh@gmail.com" , "freebsd-net@freebsd.org" , bde , Bruce Evans X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:03:32 -0000 On Thu, 18 Apr 2013, Sean Bruno wrote: > Version 0.2 of patches to bge(4). I'm not totally happy with it, but > comments welcome. I need better explanations of usage for the man page. > > I've dropped bge_rxd completely here as it was suggested to not even > bother adjusting it. > > http://people.freebsd.org/~sbruno/bge_config_update_1.txt I dislike this. It is very bloated to have a SYSCTL_PROC() for every setting. Yet the SYSCTL_PROC()'s aren't even correct. They write directly to the device registers with no locking. Further bloat is given by a tunable backing every sysctl. Style bugs include verbose descriptions and obfuscation the strings for these. I prefer my version of course. It allows setting all the values using SYSCTL_INT()s. It is a feature that these settings are to memory variables only. This allows building up a complicated set of changes without having to ensure that all intermediate steps give a valid and/ or usable hardware setting at every stage. Then there is a SYSCTL_PROC() for the operation of transferring the values to the hardware. This sysctl isn't missing locking, and doesn't just write to the device registers, but reprograms the coal hardware like a device reset would. Direct writing to the registers would probably work except possibly for transient problems, and but the hardware doesn't seem to guarantee this and there are no benefits from current corners here. The little SYSCTL_PROC()s could be used to do range checks, but range checks would not be very useful and none are done now. Range checks of individual values as they are set would defeat building up complicated sets of changes in another way. Many combinations of values are invalid, but it is hard to say which, and it would be wrong to disallow intermediate invalid combinations that won't ever be used. All that can be done easily is to range check each parameter from its min to its max. This is not very useful, since combinations with everything min or everything max are probably just as dysfunctional as some slightly out of bounds values. >> There are only 2 bge tunables now, and they only have half of these bugs: >> - hw.bge.allow_asf is in the wrong namespace >> - hw.bge.allow_asf is too global > Maintainer disagrees with this. I think he agreed that this were wrong too. It is at least missing the verboseness (5 lines for this; 26 lines for each of 4 new sysctls). Anyway, the old bugs should be fixed separately. Here are my old coal patches for bge. They have been edited from a larger patch and may have editing errors. @ diff -c2 ./dev/bge/if_bge.c~ ./dev/bge/if_bge.c @ *** ./dev/bge/if_bge.c~ Fri May 16 16:39:01 2008 @ --- ./dev/bge/if_bge.c Thu Sep 30 19:51:38 2010 @ *************** @ *** 1,2 **** @ --- 1,10 ---- @ + int bge_careful_coal = 1; @ + int bge_qlen = 1; @ + int bge_errsrc = 0x17; @ + int bge_rx_repl = 64; @ + int bge_coal_writes; @ + int bge_coal_write_fails; @ + int bge_polling_trust_statusword = 0; @ + @ /*- @ * Copyright (c) 2001 Wind River Systems Debugging variables. bge_careful_coal selects a way of directly writing rx_max_coal_bds that is not completely sloppy though it doesn't busy-wait to synchronize. @ *************** @ *** 1661,1664 **** @ --- 1665,1675 ---- @ @ /* Set up host coalescing defaults */ @ + if (sc->bge_dyncoal_max_intr_freq != 0) { @ + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / @ + sc->bge_dyncoal_max_intr_freq; @ + sc->bge_rx_coal_ticks = BGE_TICKS_PER_SEC / @ + sc->bge_dyncoal_max_intr_freq; @ + } else @ + sc->bge_rx_coal_ticks = 150; @ CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); @ CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); @ *************** @ *** 2351,2354 **** @ --- 2362,2414 ---- @ @ static int @ + bge_sysctl_program_coal(SYSCTL_HANDLER_ARGS) @ + { @ + struct bge_softc *sc; @ + int error, i, val; @ + @ + val = 0; @ + error = sysctl_handle_int(oidp, &val, 0, req); @ + if (error != 0 || req->newptr == NULL) @ + return (error); @ + sc = arg1; @ + BGE_LOCK(sc); @ + @ + /* XXX cut from bge_blockinit(): */ @ + @ + /* Disable host coalescing until we get it set up */ @ + CSR_WRITE_4(sc, BGE_HCC_MODE, 0x00000000); @ + @ + /* Poll to make sure it's shut down. */ @ + for (i = 0; i < BGE_TIMEOUT; i++) { @ + if (!(CSR_READ_4(sc, BGE_HCC_MODE) & BGE_HCCMODE_ENABLE)) @ + break; @ + DELAY(10); @ + } @ + @ + if (i == BGE_TIMEOUT) { @ + device_printf(sc->bge_dev, @ + "host coalescing engine failed to idle\n"); @ + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); @ + BGE_UNLOCK(sc); @ + return (ENXIO); @ + } @ + @ + /* Set up host coalescing defaults */ @ + if (sc->bge_dyncoal_max_intr_freq != 0) @ + sc->bge_dyncoal_scale = ((uint64_t)1 << 24) / @ + sc->bge_dyncoal_max_intr_freq; @ + CSR_WRITE_4(sc, BGE_HCC_RX_COAL_TICKS, sc->bge_rx_coal_ticks); @ + CSR_WRITE_4(sc, BGE_HCC_TX_COAL_TICKS, sc->bge_tx_coal_ticks); @ + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, sc->bge_rx_max_coal_bds); @ + CSR_WRITE_4(sc, BGE_HCC_TX_MAX_COAL_BDS, sc->bge_tx_max_coal_bds); @ + @ + /* Turn on host coalescing state machine */ @ + CSR_WRITE_4(sc, BGE_HCC_MODE, BGE_HCCMODE_ENABLE); @ + @ + BGE_UNLOCK(sc); @ + return (0); @ + } @ + @ + static int @ bge_attach(device_t dev) @ { @ *************** @ *** 2584,2591 **** @ /* Set default tuneable values. */ @ sc->bge_stat_ticks = BGE_TICKS_PER_SEC; @ ! sc->bge_rx_coal_ticks = 150; @ ! sc->bge_tx_coal_ticks = 150; @ ! sc->bge_rx_max_coal_bds = 10; @ ! sc->bge_tx_max_coal_bds = 10; @ @ /* Set up ifnet structure */ @ --- 2645,2652 ---- @ /* Set default tuneable values. */ @ sc->bge_stat_ticks = BGE_TICKS_PER_SEC; @ ! sc->bge_dyncoal_max_intr_freq = 10000; @ ! sc->bge_tx_coal_ticks = 1000000; @ ! sc->bge_rx_max_coal_bds = 128; @ ! sc->bge_tx_max_coal_bds = BGE_TX_RING_CNT * 3 / 4; @ @ /* Set up ifnet structure */ @ *************** @ *** 3331,3343 **** @ if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && @ sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || @ ! statusword || sc->bge_link_evt) @ bge_link_upd(sc); @ @ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { @ - /* Check RX return ring producer/consumer. */ @ bge_rxeof(sc); @ - @ - /* Check TX ring producer/consumer. */ @ bge_txeof(sc); @ } @ @ --- 3583,3638 ---- @ if ((sc->bge_asicrev == BGE_ASICREV_BCM5700 && @ sc->bge_chipid != BGE_CHIPID_BCM5700_B2) || @ ! (macstatus & BGE_MACSTAT_LINK_CHANGED) || sc->bge_link_evt) @ bge_link_upd(sc); @ @ if (ifp->if_drv_flags & IFF_DRV_RUNNING) { @ bge_rxeof(sc); @ bge_txeof(sc); @ + if (sc->bge_dyncoal_max_intr_freq != 0 && @ + ++sc->bge_dyncoal_intrcnt == 16) { @ + struct bintime bt; @ + uint32_t dpi, pfrac, tfrac, xtime; @ + @ + binuptime(&bt); @ + xtime = (bt.sec << 24) | (bt.frac >> 40); @ + pfrac = (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * @ + sc->bge_dyncoal_scale; @ + tfrac = xtime - sc->bge_dyncoal_xtime; @ + sc->bge_dyncoal_rx_pps = @ + (ifp->if_ipackets - sc->bge_dyncoal_ipackets) * @ + ((uint64_t)1 << 24) / tfrac; @ + dpi = pfrac / (tfrac | 2) + 1; @ + if (dpi > sc->bge_rx_max_coal_bds) @ + dpi = sc->bge_rx_max_coal_bds; @ + if (dpi != sc->bge_dyncoal_rx_max_coal_bds) { @ + if (bge_careful_coal) { @ + CSR_WRITE_4(sc, BGE_HCC_MODE, 0); @ + CSR_READ_4(sc, BGE_HCC_MODE); @ + if ((CSR_READ_4(sc, BGE_HCC_MODE) & @ + BGE_HCCMODE_ENABLE) == 0) { @ + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, @ + dpi); @ + sc->bge_dyncoal_rx_max_coal_bds = dpi; @ + bge_coal_writes++; @ + } else @ + bge_coal_write_fails++; @ + CSR_WRITE_4(sc, BGE_HCC_MODE, @ + BGE_HCCMODE_ENABLE); @ + } else { @ + /* @ + * XXX not waiting for the engine is needed @ + * for efficiency since we reprogram it a @ + * lot so as to react fast, and this seems @ + * to work. However, similar reprogramming @ + * of RX_COAL_TICKS doesn't work. @ + */ @ + CSR_WRITE_4(sc, BGE_HCC_RX_MAX_COAL_BDS, dpi); @ + sc->bge_dyncoal_rx_max_coal_bds = dpi; @ + } @ + } @ + sc->bge_dyncoal_xtime = xtime; @ + sc->bge_dyncoal_intrcnt = 0; @ + sc->bge_dyncoal_ipackets = ifp->if_ipackets; @ + } @ } @ @ *************** @ *** 4450,4453 **** @ --- 4756,4782 ---- @ children = SYSCTL_CHILDREN(device_get_sysctl_tree(sc->bge_dev)); @ @ + SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "program_coal", @ + CTLTYPE_INT | CTLFLAG_RW, @ + sc, 0, bge_sysctl_program_coal, "I", @ + "program bge coalescence values"); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_coal_ticks", CTLFLAG_RW, @ + &sc->bge_rx_coal_ticks, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_coal_ticks", CTLFLAG_RW, @ + &sc->bge_tx_coal_ticks, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "rx_max_coal_bds", CTLFLAG_RW, @ + &sc->bge_rx_max_coal_bds, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "tx_max_coal_bds", CTLFLAG_RW, @ + &sc->bge_tx_max_coal_bds, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_max_intr_freq", @ + CTLFLAG_RW, @ + &sc->bge_dyncoal_max_intr_freq, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_max_coal_bds", @ + CTLFLAG_RD, @ + &sc->bge_dyncoal_rx_max_coal_bds, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_rx_pps", CTLFLAG_RD, @ + &sc->bge_dyncoal_rx_pps, 0, ""); @ + SYSCTL_ADD_UINT(ctx, children, OID_AUTO, "dyncoal_scale", CTLFLAG_RD, @ + &sc->bge_dyncoal_scale, 0, ""); @ + @ #ifdef BGE_REGISTER_DEBUG @ SYSCTL_ADD_PROC(ctx, children, OID_AUTO, "debug_info", @ diff -c2 ./dev/bge/if_bgereg.h~ ./dev/bge/if_bgereg.h @ *** ./dev/bge/if_bgereg.h~ Fri May 16 16:39:21 2008 @ --- ./dev/bge/if_bgereg.h Fri May 16 16:39:23 2008 @ *************** @ *** 2579,2582 **** @ --- 2573,2583 ---- @ uint32_t bge_tx_discards; @ uint32_t bge_tx_collisions; @ + int bge_dyncoal_intrcnt; @ + u_long bge_dyncoal_ipackets; @ + uint32_t bge_dyncoal_max_intr_freq; @ + uint32_t bge_dyncoal_rx_max_coal_bds; @ + uint32_t bge_dyncoal_rx_pps; @ + uint32_t bge_dyncoal_scale; @ + uint32_t bge_dyncoal_xtime; @ #ifdef DEVICE_POLLING @ int rxcycles; The dynamical coal programming hasn't been mentioned recently, but really, it is the only useful thing in the above. Once the system does correct dynamic coal programming, there is no need for static sysctls except to reprove that they can't do such a good job as dynamic programming. I don't bother with dynamic coal program for tx. It would be possible to switch to more conservative tx settings under heavy rx load, and if you know too much about the device internals then balance all the resource uses so that they compete with each other as little as possible, but the possible gains from that are small. Bruce From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 19:26:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 16D65E5 for ; Fri, 19 Apr 2013 19:26:05 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id E704E1889 for ; Fri, 19 Apr 2013 19:26:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 62BE6B943; Fri, 19 Apr 2013 15:26:04 -0400 (EDT) From: John Baldwin To: "C. L. Martinez" Subject: Re: Network connections are lost from time to time Date: Fri, 19 Apr 2013 15:11:14 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201304191149.22998.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304191511.14940.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 15:26:04 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:26:05 -0000 On Friday, April 19, 2013 12:32:18 pm C. L. Martinez wrote: > On Friday, April 19, 2013, John Baldwin wrote: > > On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote: > >> Hi all, > >> > >> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose > ssh > >> sessions from time to time frequently. > >> > >> This fbsd box is installed in an ESXi 5.1 server and I have another > three > >> fbsd 9.1 in the same ESXi host that do not have this problem, but maybe > the > >> problem is with my sysctl.conf and loader.conf settings: > > > > Which NIC driver are you using? > > > > -- > > John Baldwin > > > e1000. igb? There are some fixes to handle out of order packets on transmit that could break new connections in some cases. That is probably worth testing. I think you can just grab the sys/dev/e1000 from 9-stable and drop it into a 9.1 tree to test. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 19:33:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 82A0D3A2; Fri, 19 Apr 2013 19:33:00 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-x233.google.com (mail-vb0-x233.google.com [IPv6:2607:f8b0:400c:c02::233]) by mx1.freebsd.org (Postfix) with ESMTP id 20D8A191D; Fri, 19 Apr 2013 19:33:00 +0000 (UTC) Received: by mail-vb0-f51.google.com with SMTP id x19so4098757vbf.10 for ; Fri, 19 Apr 2013 12:32:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ULWFLv9gLTHEMv8GZV+rgS7Lp7JEWxZgFYCTfptzaBQ=; b=BpMREHRi7EnE1vC2h+YBchZUI5OfSKL3nW2iYIpGBIeZ7WMeUX1f+s/53QsEVSAHmY bIMgbMOiUEJ6gDw6xNu7e45P3rOBdzCN7y2kroJJqo1nV+bkL5JV0gjz7ZK+Wte+4nfr gPb8LYis69irs4z1QJwuEHhfmClbT4RCDMnEvWgfFcnL4e+7ehGEeKd65dPyXBx2/MYW KqWsQTZR0lW7VXt07x9vRH8tuZLgSOfyJCnV9MTSWeSldDdEdaM+4PgOWwqYIhjCXokH oRaH5+y0Q0xBnz1qeIyEyNxheMpbSD8h+Z+DIBzt9289UJhdTGG0xi3nU7iXfbDKWEVC IXoQ== MIME-Version: 1.0 X-Received: by 10.220.223.202 with SMTP id il10mr12801497vcb.4.1366399979606; Fri, 19 Apr 2013 12:32:59 -0700 (PDT) Received: by 10.220.77.65 with HTTP; Fri, 19 Apr 2013 12:32:59 -0700 (PDT) In-Reply-To: <201304191227.09439.jhb@freebsd.org> References: <201303141500.r2EF01EQ079753@freefall.freebsd.org> <201304191227.09439.jhb@freebsd.org> Date: Fri, 19 Apr 2013 12:32:59 -0700 Message-ID: Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST From: Jack Vogel To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Net , Mike Karels , bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:33:00 -0000 Thanks John, I'm incorporating your changes into my source tree. I also plan on changing the "glue" between mq_start and mq_start_locked on igb after some UDP testing that was done, and believe ixgbe should follow suit. Results there have shown the latency is just too high if I only use the task_enqueue... What works best is to always queue to the buf ring, but then also always to do the TRY_LOCK. I will update HEAD as soon as I handle an internal firedrill I have today :) Jack On Fri, Apr 19, 2013 at 9:27 AM, John Baldwin wrote: > A second patch. This is not something I mentioned before, but I had this > in > my checkout. In the legacy IRQ case this could also result in out-of-order > processing. It also fixes a potential OACTIVE-stuck type bug that we used > to > have in igb. I have no way to test this, so it would be good if some other > folks could test this. > > The patch changes ixgbe_txeof() return void and changes the few places that > checked its return value to ignore it. While it is true that ixgbe has a > tx > processing limit (which I think is dubious.. TX completion processing is > very > cheap unlike RX processing, so it seems to me like it should always run to > completion as in igb), in the common case I think the result will be to do > what igb used to do: poll the ring at 100% CPU (either in the interrupt > handler or in the task it keeps rescheduling) waiting for pending TX > packets > to be completed (which is pointless: the host CPU can't make the NIC > transmit > packets any faster by polling). > > It also changes the interrupt handlers to restart packet transmission > synchronously rather than always deferring that to a task (the former is > what > (nearly) all other drivers do). It also fixes the interrupt handlers to be > consistent (one looped on txeof but not the others). In the case of the > legacy interrupt handler it is possible it could fail to restart packet > transmission if there were no pending RX packets after rxeof returned and > txeof fully cleaned its ring without this change. > > It also fixes the legacy interrupt handler to not re-enable the interrupt > if > it schedules the task but to wait until the task completes (this could > result > in concurrent, out-of-order RX processing). > > Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c > =================================================================== > --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision > 249553) > +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working > copy) > @@ -149,7 +149,7 @@ > static void ixgbe_enable_intr(struct adapter *); > static void ixgbe_disable_intr(struct adapter *); > static void ixgbe_update_stats_counters(struct adapter *); > -static bool ixgbe_txeof(struct tx_ring *); > +static void ixgbe_txeof(struct tx_ring *); > static bool ixgbe_rxeof(struct ix_queue *); > static void ixgbe_rx_checksum(u32, struct mbuf *, u32); > static void ixgbe_set_promisc(struct adapter *); > @@ -1431,7 +1414,10 @@ > } > > /* Reenable this interrupt */ > - ixgbe_enable_queue(adapter, que->msix); > + if (que->res != NULL) > + ixgbe_enable_queue(adapter, que->msix); > + else > + ixgbe_enable_intr(adapter); > return; > } > > @@ -1449,8 +1435,9 @@ > struct adapter *adapter = que->adapter; > struct ixgbe_hw *hw = &adapter->hw; > struct tx_ring *txr = adapter->tx_rings; > - bool more_tx, more_rx; > - u32 reg_eicr, loop = MAX_LOOP; > + struct ifnet *ifp = adapter->ifp; > + bool more; > + u32 reg_eicr; > > > reg_eicr = IXGBE_READ_REG(hw, IXGBE_EICR); > @@ -1461,17 +1448,19 @@ > return; > } > > - more_rx = ixgbe_rxeof(que); > + more = ixgbe_rxeof(que); > > IXGBE_TX_LOCK(txr); > - do { > - more_tx = ixgbe_txeof(txr); > - } while (loop-- && more_tx); > + ixgbe_txeof(txr); > +#if __FreeBSD_version >= 800000 > + if (!drbr_empty(ifp, txr->br)) > + ixgbe_mq_start_locked(ifp, txr, NULL); > +#else > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > + ixgbe_start_locked(txr, ifp); > +#endif > IXGBE_TX_UNLOCK(txr); > > - if (more_rx || more_tx) > - taskqueue_enqueue(que->tq, &que->que_task); > - > /* Check for fan failure */ > if ((hw->phy.media_type == ixgbe_media_type_copper) && > (reg_eicr & IXGBE_EICR_GPI_SDP1)) { > @@ -1484,7 +1473,10 @@ > if (reg_eicr & IXGBE_EICR_LSC) > taskqueue_enqueue(adapter->tq, &adapter->link_task); > > - ixgbe_enable_intr(adapter); > + if (more) > + taskqueue_enqueue(que->tq, &que->que_task); > + else > + ixgbe_enable_intr(adapter); > return; > } > > @@ -1501,27 +1493,24 @@ > struct adapter *adapter = que->adapter; > struct tx_ring *txr = que->txr; > struct rx_ring *rxr = que->rxr; > - bool more_tx, more_rx; > + struct ifnet *ifp = adapter->ifp; > + bool more; > u32 newitr = 0; > > ixgbe_disable_queue(adapter, que->msix); > ++que->irqs; > > - more_rx = ixgbe_rxeof(que); > + more = ixgbe_rxeof(que); > > IXGBE_TX_LOCK(txr); > - more_tx = ixgbe_txeof(txr); > - /* > - ** Make certain that if the stack > - ** has anything queued the task gets > - ** scheduled to handle it. > - */ > + ixgbe_txeof(txr); > #ifdef IXGBE_LEGACY_TX > if (!IFQ_DRV_IS_EMPTY(&adapter->ifp->if_snd)) > + ixgbe_start_locked(txr, ifp); > #else > - if (!drbr_empty(adapter->ifp, txr->br)) > + if (!drbr_empty(ifp, txr->br)) > + ixgbe_mq_start_locked(ifp, txr, NULL); > #endif > - more_tx = 1; > IXGBE_TX_UNLOCK(txr); > > /* Do AIM now? */ > @@ -1575,7 +1564,7 @@ > rxr->packets = 0; > > no_calc: > - if (more_tx || more_rx) > + if (more) > taskqueue_enqueue(que->tq, &que->que_task); > else /* Reenable this interrupt */ > ixgbe_enable_queue(adapter, que->msix); > @@ -3557,7 +3545,7 @@ > * tx_buffer is put back on the free queue. > * > **********************************************************************/ > -static bool > +static void > ixgbe_txeof(struct tx_ring *txr) > { > struct adapter *adapter = txr->adapter; > @@ -3605,13 +3593,13 @@ > IXGBE_CORE_UNLOCK(adapter); > IXGBE_TX_LOCK(txr); > } > - return FALSE; > + return; > } > #endif /* DEV_NETMAP */ > > if (txr->tx_avail == txr->num_desc) { > txr->queue_status = IXGBE_QUEUE_IDLE; > - return FALSE; > + return; > } > > /* Get work starting point */ > @@ -3705,12 +3693,8 @@ > if ((!processed) && ((ticks - txr->watchdog_time) > > IXGBE_WATCHDOG)) > txr->queue_status = IXGBE_QUEUE_HUNG; > > - if (txr->tx_avail == txr->num_desc) { > + if (txr->tx_avail == txr->num_desc) > txr->queue_status = IXGBE_QUEUE_IDLE; > - return (FALSE); > - } > - > - return TRUE; > } > > /********************************************************************* > > > -- > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 19:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 63389639 for ; Fri, 19 Apr 2013 19:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 531FD1A7F for ; Fri, 19 Apr 2013 19:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r3JJe1dI005502 for ; Fri, 19 Apr 2013 19:40:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r3JJe1uH005501; Fri, 19 Apr 2013 19:40:01 GMT (envelope-from gnats) Date: Fri, 19 Apr 2013 19:40:01 GMT Message-Id: <201304191940.r3JJe1uH005501@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Jack Vogel Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jack Vogel List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 19:40:01 -0000 The following reply was made to PR kern/176446; it has been noted by GNATS. From: Jack Vogel To: John Baldwin Cc: FreeBSD Net , bug-followup@freebsd.org, Mike Karels Subject: Re: kern/176446: [netinet] [patch] Concurrency in ixgbe driving out-of-order packet process and spurious RST Date: Fri, 19 Apr 2013 12:32:59 -0700 --14dae9cdc48767db0904dabbc98d Content-Type: text/plain; charset=ISO-8859-1 Thanks John, I'm incorporating your changes into my source tree. I also plan on changing the "glue" between mq_start and mq_start_locked on igb after some UDP testing that was done, and believe ixgbe should follow suit. Results there have shown the latency is just too high if I only use the task_enqueue... What works best is to always queue to the buf ring, but then also always to do the TRY_LOCK. I will update HEAD as soon as I handle an internal firedrill I have today :) Jack On Fri, Apr 19, 2013 at 9:27 AM, John Baldwin wrote: > A second patch. This is not something I mentioned before, but I had this > in > my checkout. In the legacy IRQ case this could also result in out-of-order > processing. It also fixes a potential OACTIVE-stuck type bug that we used > to > have in igb. I have no way to test this, so it would be good if some other > folks could test this. > > The patch changes ixgbe_txeof() return void and changes the few places that > checked its return value to ignore it. While it is true that ixgbe has a > tx > processing limit (which I think is dubious.. TX completion processing is > very > cheap unlike RX processing, so it seems to me like it should always run to > completion as in igb), in the common case I think the result will be to do > what igb used to do: poll the ring at 100% CPU (either in the interrupt > handler or in the task it keeps rescheduling) waiting for pending TX > packets > to be completed (which is pointless: the host CPU can't make the NIC > transmit > packets any faster by polling). > > It also changes the interrupt handlers to restart packet transmission > synchronously rather than always deferring that to a task (the former is > what > (nearly) all other drivers do). It also fixes the interrupt handlers to be > consistent (one looped on txeof but not the others). In the case of the > legacy interrupt handler it is possible it could fail to restart packet > transmission if there were no pending RX packets after rxeof returned and > txeof fully cleaned its ring without this change. > > It also fixes the legacy interrupt handler to not re-enable the interrupt > if > it schedules the task but to wait until the task completes (this could > result > in concurrent, out-of-order RX processing). > > Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c > =================================================================== > --- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (revision > 249553) > +++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c (working > copy) > @@ -149,7 +149,7 @@ > static void ixgbe_enable_intr(struct adapter *); > static void ixgbe_disable_intr(struct adapter *); > static void ixgbe_update_stats_counters(struct adapter *); > -static bool ixgbe_txeof(struct tx_ring *); > +static void ixgbe_txeof(struct tx_ring *); > static bool ixgbe_rxeof(struct ix_queue *); > static void ixgbe_rx_checksum(u32, struct mbuf *, u32); > static void ixgbe_set_promisc(struct adapter *); > @@ -1431,7 +1414,10 @@ > } > > /* Reenable this interrupt */ > - ixgbe_enable_queue(adapter, que->msix); > + if (que->res != NULL) > + ixgbe_enable_queue(adapter, que->msix); > + else > + ixgbe_enable_intr(adapter); > return; > } > > @@ -1449,8 +1435,9 @@ > struct adapter *adapter = que->adapter; > struct ixgbe_hw *hw = &adapter->hw; > struct tx_ring *txr = adapter->tx_rings; > - bool more_tx, more_rx; > - u32 reg_eicr, loop = MAX_LOOP; > + struct ifnet *ifp = adapter->ifp; > + bool more; > + u32 reg_eicr; > > > reg_eicr = IXGBE_READ_REG(hw, IXGBE_EICR); > @@ -1461,17 +1448,19 @@ > return; > } > > - more_rx = ixgbe_rxeof(que); > + more = ixgbe_rxeof(que); > > IXGBE_TX_LOCK(txr); > - do { > - more_tx = ixgbe_txeof(txr); > - } while (loop-- && more_tx); > + ixgbe_txeof(txr); > +#if __FreeBSD_version >= 800000 > + if (!drbr_empty(ifp, txr->br)) > + ixgbe_mq_start_locked(ifp, txr, NULL); > +#else > + if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd)) > + ixgbe_start_locked(txr, ifp); > +#endif > IXGBE_TX_UNLOCK(txr); > > - if (more_rx || more_tx) > - taskqueue_enqueue(que->tq, &que->que_task); > - > /* Check for fan failure */ > if ((hw->phy.media_type == ixgbe_media_type_copper) && > (reg_eicr & IXGBE_EICR_GPI_SDP1)) { > @@ -1484,7 +1473,10 @@ > if (reg_eicr & IXGBE_EICR_LSC) > taskqueue_enqueue(adapter->tq, &adapter->link_task); > > - ixgbe_enable_intr(adapter); > + if (more) > + taskqueue_enqueue(que->tq, &que->que_task); > + else > + ixgbe_enable_intr(adapter); > return; > } > > @@ -1501,27 +1493,24 @@ > struct adapter *adapter = que->adapter; > struct tx_ring *txr = que->txr; > struct rx_ring *rxr = que->rxr; > - bool more_tx, more_rx; > + struct ifnet *ifp = adapter->ifp; > + bool more; > u32 newitr = 0; > > ixgbe_disable_queue(adapter, que->msix); > ++que->irqs; > > - more_rx = ixgbe_rxeof(que); > + more = ixgbe_rxeof(que); > > IXGBE_TX_LOCK(txr); > - more_tx = ixgbe_txeof(txr); > - /* > - ** Make certain that if the stack > - ** has anything queued the task gets > - ** scheduled to handle it. > - */ > + ixgbe_txeof(txr); > #ifdef IXGBE_LEGACY_TX > if (!IFQ_DRV_IS_EMPTY(&adapter->ifp->if_snd)) > + ixgbe_start_locked(txr, ifp); > #else > - if (!drbr_empty(adapter->ifp, txr->br)) > + if (!drbr_empty(ifp, txr->br)) > + ixgbe_mq_start_locked(ifp, txr, NULL); > #endif > - more_tx = 1; > IXGBE_TX_UNLOCK(txr); > > /* Do AIM now? */ > @@ -1575,7 +1564,7 @@ > rxr->packets = 0; > > no_calc: > - if (more_tx || more_rx) > + if (more) > taskqueue_enqueue(que->tq, &que->que_task); > else /* Reenable this interrupt */ > ixgbe_enable_queue(adapter, que->msix); > @@ -3557,7 +3545,7 @@ > * tx_buffer is put back on the free queue. > * > **********************************************************************/ > -static bool > +static void > ixgbe_txeof(struct tx_ring *txr) > { > struct adapter *adapter = txr->adapter; > @@ -3605,13 +3593,13 @@ > IXGBE_CORE_UNLOCK(adapter); > IXGBE_TX_LOCK(txr); > } > - return FALSE; > + return; > } > #endif /* DEV_NETMAP */ > > if (txr->tx_avail == txr->num_desc) { > txr->queue_status = IXGBE_QUEUE_IDLE; > - return FALSE; > + return; > } > > /* Get work starting point */ > @@ -3705,12 +3693,8 @@ > if ((!processed) && ((ticks - txr->watchdog_time) > > IXGBE_WATCHDOG)) > txr->queue_status = IXGBE_QUEUE_HUNG; > > - if (txr->tx_avail == txr->num_desc) { > + if (txr->tx_avail == txr->num_desc) > txr->queue_status = IXGBE_QUEUE_IDLE; > - return (FALSE); > - } > - > - return TRUE; > } > > /********************************************************************* > > > -- > John Baldwin > --14dae9cdc48767db0904dabbc98d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks John, I'm incorporating you= r changes into my source tree. I also plan on changing the
"g= lue" between mq_start and mq_start_locked on igb after some UDP testin= g that was done, and
believe ixgbe should follow suit. Results there have shown the latenc= y is just too high if I only use
the task_enqueue... What works best is = to always queue to the buf ring, but then also always to
do the TR= Y_LOCK. I will update HEAD as soon as I handle an internal firedrill I have= today :)

Jack



On Fri, Apr 19, 2013 at 9:27 AM, John Baldwin <jhb@freebsd.= org> wrote:
A second patch. =A0This is not something I m= entioned before, but I had this in
my checkout. =A0In the legacy IRQ case this could also result in out-of-ord= er
processing. =A0It also fixes a potential OACTIVE-stuck type bug that we use= d to
have in igb. =A0I have no way to test this, so it would be good if some oth= er
folks could test this.

The patch changes ixgbe_txeof() return void and changes the few places that=
checked its return value to ignore it. =A0While it is true that ixgbe has a= tx
processing limit (which I think is dubious.. TX completion processing is ve= ry
cheap unlike RX processing, so it seems to me like it should always run to<= br> completion as in igb), in the common case I think the result will be to do<= br> what igb used to do: poll the ring at 100% CPU (either in the interrupt
handler or in the task it keeps rescheduling) waiting for pending TX packet= s
to be completed (which is pointless: the host CPU can't make the NIC tr= ansmit
packets any faster by polling).

It also changes the interrupt handlers to restart packet transmission
synchronously rather than always deferring that to a task (the former is wh= at
(nearly) all other drivers do). =A0It also fixes the interrupt handlers to = be
consistent (one looped on txeof but not the others). =A0In the case of the<= br> legacy interrupt handler it is possible it could fail to restart packet
transmission if there were no pending RX packets after rxeof returned and txeof fully cleaned its ring without this change.

It also fixes the legacy interrupt handler to not re-enable the interrupt i= f
it schedules the task but to wait until the task completes (this could resu= lt
in concurrent, out-of-order RX processing).

Index: /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =A0 =A0 =A0 (revi= sion 249553)
+++ /home/jhb/work/freebsd/svn/head/sys/dev/ixgbe/ixgbe.c =A0 =A0 =A0 (work= ing copy)
@@ -149,7 +149,7 @@
=A0static void =A0 =A0 ixgbe_enable_intr(struct adapter *);
=A0static void =A0 =A0 ixgbe_disable_intr(struct adapter *);
=A0static void =A0 =A0 ixgbe_update_stats_counters(struct adapter *);
-static bool =A0 =A0ixgbe_txeof(struct tx_ring *);
+static void =A0 =A0ixgbe_txeof(struct tx_ring *);
=A0static bool =A0 =A0ixgbe_rxeof(struct ix_queue *);
=A0static void =A0 =A0ixgbe_rx_checksum(u32, struct mbuf *, u32);
=A0static void =A0 =A0 ixgbe_set_promisc(struct adapter *);
@@ -1431,7 +1414,10 @@
=A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 /* Reenable this interrupt */
- =A0 =A0 =A0 ixgbe_enable_queue(adapter, que->msix);
+ =A0 =A0 =A0 if (que->res !=3D NULL)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_enable_queue(adapter, que->msix); + =A0 =A0 =A0 else
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_enable_intr(adapter);
=A0 =A0 =A0 =A0 return;
=A0}

@@ -1449,8 +1435,9 @@
=A0 =A0 =A0 =A0 struct adapter =A0*adapter =3D que->adapter;
=A0 =A0 =A0 =A0 struct ixgbe_hw *hw =3D &adapter->hw;
=A0 =A0 =A0 =A0 struct =A0 =A0 =A0 =A0 =A0tx_ring *txr =3D adapter->tx_r= ings;
- =A0 =A0 =A0 bool =A0 =A0 =A0 =A0 =A0 =A0more_tx, more_rx;
- =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 reg_eicr, loop =3D MAX_LOOP;
+ =A0 =A0 =A0 struct ifnet =A0 =A0*ifp =3D adapter->ifp;
+ =A0 =A0 =A0 bool =A0 =A0 =A0 =A0 =A0 =A0more;
+ =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 reg_eicr;


=A0 =A0 =A0 =A0 reg_eicr =3D IXGBE_READ_REG(hw, IXGBE_EICR);
@@ -1461,17 +1448,19 @@
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
=A0 =A0 =A0 =A0 }

- =A0 =A0 =A0 more_rx =3D ixgbe_rxeof(que);
+ =A0 =A0 =A0 more =3D ixgbe_rxeof(que);

=A0 =A0 =A0 =A0 IXGBE_TX_LOCK(txr);
- =A0 =A0 =A0 do {
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 more_tx =3D ixgbe_txeof(txr);
- =A0 =A0 =A0 } while (loop-- && more_tx);
+ =A0 =A0 =A0 ixgbe_txeof(txr);
+#if __FreeBSD_version >=3D 800000
+ =A0 =A0 =A0 if (!drbr_empty(ifp, txr->br))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_mq_start_locked(ifp, txr, NULL);
+#else
+ =A0 =A0 =A0 if (!IFQ_DRV_IS_EMPTY(&ifp->if_snd))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_start_locked(txr, ifp);
+#endif
=A0 =A0 =A0 =A0 IXGBE_TX_UNLOCK(txr);

- =A0 =A0 =A0 if (more_rx || more_tx)
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 taskqueue_enqueue(que->tq, &que->qu= e_task);
-
=A0 =A0 =A0 =A0 /* Check for fan failure */
=A0 =A0 =A0 =A0 if ((hw->phy.media_type =3D=3D ixgbe_media_type_copper) = &&
=A0 =A0 =A0 =A0 =A0 =A0 (reg_eicr & IXGBE_EICR_GPI_SDP1)) {
@@ -1484,7 +1473,10 @@
=A0 =A0 =A0 =A0 if (reg_eicr & IXGBE_EICR_LSC)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 taskqueue_enqueue(adapter->tq, &adap= ter->link_task);

- =A0 =A0 =A0 ixgbe_enable_intr(adapter);
+ =A0 =A0 =A0 if (more)
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 taskqueue_enqueue(que->tq, &que->qu= e_task);
+ =A0 =A0 =A0 else
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_enable_intr(adapter);
=A0 =A0 =A0 =A0 return;
=A0}

@@ -1501,27 +1493,24 @@
=A0 =A0 =A0 =A0 struct adapter =A0*adapter =3D que->adapter;
=A0 =A0 =A0 =A0 struct tx_ring =A0*txr =3D que->txr;
=A0 =A0 =A0 =A0 struct rx_ring =A0*rxr =3D que->rxr;
- =A0 =A0 =A0 bool =A0 =A0 =A0 =A0 =A0 =A0more_tx, more_rx;
+ =A0 =A0 =A0 struct ifnet =A0 =A0*ifp =3D adapter->ifp;
+ =A0 =A0 =A0 bool =A0 =A0 =A0 =A0 =A0 =A0more;
=A0 =A0 =A0 =A0 u32 =A0 =A0 =A0 =A0 =A0 =A0 newitr =3D 0;

=A0 =A0 =A0 =A0 ixgbe_disable_queue(adapter, que->msix);
=A0 =A0 =A0 =A0 ++que->irqs;

- =A0 =A0 =A0 more_rx =3D ixgbe_rxeof(que);
+ =A0 =A0 =A0 more =3D ixgbe_rxeof(que);

=A0 =A0 =A0 =A0 IXGBE_TX_LOCK(txr);
- =A0 =A0 =A0 more_tx =3D ixgbe_txeof(txr);
- =A0 =A0 =A0 /*
- =A0 =A0 =A0 ** Make certain that if the stack
- =A0 =A0 =A0 ** has anything queued the task gets
- =A0 =A0 =A0 ** scheduled to handle it.
- =A0 =A0 =A0 */
+ =A0 =A0 =A0 ixgbe_txeof(txr);
=A0#ifdef IXGBE_LEGACY_TX
=A0 =A0 =A0 =A0 if (!IFQ_DRV_IS_EMPTY(&adapter->ifp->if_snd))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_start_locked(txr, ifp);
=A0#else
- =A0 =A0 =A0 if (!drbr_empty(adapter->ifp, txr->br))
+ =A0 =A0 =A0 if (!drbr_empty(ifp, txr->br))
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_mq_start_locked(ifp, txr, NULL);
=A0#endif
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 more_tx =3D 1;
=A0 =A0 =A0 =A0 IXGBE_TX_UNLOCK(txr);

=A0 =A0 =A0 =A0 /* Do AIM now? */
@@ -1575,7 +1564,7 @@
=A0 =A0 =A0 =A0 =A0rxr->packets =3D 0;

=A0no_calc:
- =A0 =A0 =A0 if (more_tx || more_rx)
+ =A0 =A0 =A0 if (more)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 taskqueue_enqueue(que->tq, &que->= que_task);
=A0 =A0 =A0 =A0 else /* Reenable this interrupt */
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ixgbe_enable_queue(adapter, que->msix);<= br> @@ -3557,7 +3545,7 @@
=A0 * =A0tx_buffer is put back on the free queue.
=A0 *
=A0 **********************************************************************/=
-static bool
+static void
=A0ixgbe_txeof(struct tx_ring *txr)
=A0{
=A0 =A0 =A0 =A0 struct adapter =A0 =A0 =A0 =A0 =A0*adapter =3D txr->adap= ter;
@@ -3605,13 +3593,13 @@
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IXGBE_CORE_UNLOCK(adapter);=
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IXGBE_TX_LOCK(txr);
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
- =A0 =A0 =A0 =A0 =A0 =A0 =A0 return FALSE;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
=A0 =A0 =A0 =A0 }
=A0#endif /* DEV_NETMAP */

=A0 =A0 =A0 =A0 if (txr->tx_avail =3D=3D txr->num_desc) {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 txr->queue_status =3D IXGBE_QUEUE_IDLE;<= br> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return FALSE;
+ =A0 =A0 =A0 =A0 =A0 =A0 =A0 return;
=A0 =A0 =A0 =A0 }

=A0 =A0 =A0 =A0 /* Get work starting point */
@@ -3705,12 +3693,8 @@
=A0 =A0 =A0 =A0 if ((!processed) && ((ticks - txr->watchdog_time= ) > IXGBE_WATCHDOG))
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 txr->queue_status =3D IXGBE_QUEUE_HUNG;<= br>
- =A0 =A0 =A0 if (txr->tx_avail =3D=3D txr->num_desc) {
+ =A0 =A0 =A0 if (txr->tx_avail =3D=3D txr->num_desc)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 txr->queue_status =3D IXGBE_QUEUE_IDLE;<= br> - =A0 =A0 =A0 =A0 =A0 =A0 =A0 return (FALSE);
- =A0 =A0 =A0 }
-
- =A0 =A0 =A0 return TRUE;
=A0}

=A0/*********************************************************************

--
John Baldwin

--14dae9cdc48767db0904dabbc98d-- From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 20:14:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 738A11CD; Fri, 19 Apr 2013 20:14:45 +0000 (UTC) (envelope-from carlopmart@gmail.com) Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by mx1.freebsd.org (Postfix) with ESMTP id DB0701C30; Fri, 19 Apr 2013 20:14:44 +0000 (UTC) Received: by mail-we0-f180.google.com with SMTP id r5so3846508wey.25 for ; Fri, 19 Apr 2013 13:14:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=W8WvvbG+0LXsgTneIy4KwoIW6z85yuq2Z6t/Pe1e3vg=; b=KVJOpnJVcWnY6fiLfgXVCB+QwSfRl4CWs2Ch8/91gN3pwXAPbFPwibYc5GLrzeNHiB WZmgPdCPgL5zTYxz+dbudTS13yrqZ+v55b6pDyNYtAE4J21a0G7InyW1zFuXfFfpHy9M kfvj9Oo9XaKR+984fZTHZKcAQkQOC98tJ4Bh90gpo3OyHEwc8eXo1EastPxsu8chUWVs le1K6aLFR/mqca+bn0OcE9JGofhN/SSz/dtKwwmBd+BDO8DwFPb9fih2RTXAaHdSfG0h fLg73AzxknrkNm4MW0FDEpZDnm5soIdytrKn/cHJnElUCRTa6sWap2oWUzbNZkJ5r8St VtcQ== MIME-Version: 1.0 X-Received: by 10.194.103.72 with SMTP id fu8mr28565499wjb.42.1366402483366; Fri, 19 Apr 2013 13:14:43 -0700 (PDT) Received: by 10.194.20.227 with HTTP; Fri, 19 Apr 2013 13:14:43 -0700 (PDT) In-Reply-To: <201304191511.14940.jhb@freebsd.org> References: <201304191149.22998.jhb@freebsd.org> <201304191511.14940.jhb@freebsd.org> Date: Fri, 19 Apr 2013 20:14:43 +0000 Message-ID: Subject: Re: Network connections are lost from time to time From: "C. L. Martinez" To: John Baldwin Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:14:45 -0000 On Friday, April 19, 2013, John Baldwin wrote: > On Friday, April 19, 2013 12:32:18 pm C. L. Martinez wrote: >> On Friday, April 19, 2013, John Baldwin wrote: >> > On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote: >> >> Hi all, >> >> >> >> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose >> ssh >> >> sessions from time to time frequently. >> >> >> >> This fbsd box is installed in an ESXi 5.1 server and I have another >> three >> >> fbsd 9.1 in the same ESXi host that do not have this problem, but maybe >> the >> >> problem is with my sysctl.conf and loader.conf settings: >> > >> > Which NIC driver are you using? >> > >> > -- >> > John Baldwin >> >> >> e1000. > > igb? There are some fixes to handle out of order packets on transmit that > could break new connections in some cases. That is probably worth testing. I > think you can just grab the sys/dev/e1000 from 9-stable and drop it into a > 9.1 tree to test. > > -- Nop, I am using em driver ... > John Baldwin > From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 20:35:29 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA04C4EC; Fri, 19 Apr 2013 20:35:29 +0000 (UTC) (envelope-from prvs=182147b016=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 49CDF1D31; Fri, 19 Apr 2013 20:35:28 +0000 (UTC) Received: from r2d2 ([46.65.172.4]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50003360046.msg; Fri, 19 Apr 2013 21:34:59 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Fri, 19 Apr 2013 21:34:59 +0100 (not processed: message from valid local sender) X-MDDKIM-Result: neutral (mail1.multiplay.co.uk) X-MDRemoteIP: 46.65.172.4 X-Return-Path: prvs=182147b016=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk Message-ID: <5493AADA4F0D424B8B304A248B552EAB@multiplay.co.uk> From: "Steven Hartland" To: "C. L. Martinez" , "John Baldwin" References: <201304191149.22998.jhb@freebsd.org> <201304191511.14940.jhb@freebsd.org> Subject: Re: Network connections are lost from time to time Date: Fri, 19 Apr 2013 21:35:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Cc: freebsd-net@freebsd.org, Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 20:35:29 -0000 ----- Original Message ----- From: "C. L. Martinez" >>> e1000. >> >> igb? There are some fixes to handle out of order packets on transmit that >> could break new connections in some cases. That is probably worth > testing. I >> think you can just grab the sys/dev/e1000 from 9-stable and drop it into a >> 9.1 tree to test. >> >> -- > Nop, I am using em driver ... e1000 also provides emX so likely still worth a shot to see if it solves your issue. Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 21:11:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5AB81F4D for ; Fri, 19 Apr 2013 21:11:54 +0000 (UTC) (envelope-from bredehorn@gmx.de) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by mx1.freebsd.org (Postfix) with ESMTP id D5D0B1EFF for ; Fri, 19 Apr 2013 21:11:53 +0000 (UTC) Received: from 3capp-gmx-bs49.server.lan ([172.19.170.102]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MeNF3-1UB8mx3JHD-00QC5Y for ; Fri, 19 Apr 2013 09:41:48 +0200 Received: from [91.61.117.188] by 3capp-gmx-bs49.server.lan with HTTP; Fri Apr 19 09:41:48 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Rainer Bredehorn" To: "net FreeBSD" Subject: PF IPv6 fragment support Content-Type: text/plain; charset=UTF-8 Date: Fri, 19 Apr 2013 09:41:48 +0200 (CEST) Importance: normal Sensitivity: Normal X-Priority: 3 X-Provags-ID: V03:K0:dBNo/BEpzvjkNnl3wtA5QZ7HUt5Y0jumi63bNO0Tp78 BzhyduTOCYBKIwvEYNTJ5GCWIE2izy6rUGZWhVKUKw44ITIEwp +2xVE+bYiu/RHV8KmUW4tMwAu++6Sj0v+R31ew3YNBATsp8U8d ONyFoULRHJ8ggCNl2paXHHXlyc3CBC8e7bF309EuVqncdVx3XO 7FuFUasoktU032huiCYnKQtDNl413iXyAiTuYvxJjt4hJPVYsf Mji6BRmhJWTvKv0udLFsJSVQg7fivJ2n1xQw4QC6Lu44bv/ECd t4HkmM= X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 21:11:54 -0000 Hi! I'm using FreeBSD 8.3 which doesn't support IPv6 fragments in PF. Does FreeBSD 9.x PF support IPv6 fragments? I can't find it in the 9.0 or 9.1 manpages. For pf.conf they are the same as in FreeBSD 8.3. Rainer. From owner-freebsd-net@FreeBSD.ORG Fri Apr 19 21:28:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BDF3A1E7 for ; Fri, 19 Apr 2013 21:28:04 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9ADCF1FAC for ; Fri, 19 Apr 2013 21:28:04 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 91459B962; Fri, 19 Apr 2013 17:28:02 -0400 (EDT) From: John Baldwin To: "C. L. Martinez" Subject: Re: Network connections are lost from time to time Date: Fri, 19 Apr 2013 16:27:59 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201304191511.14940.jhb@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201304191627.59402.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 19 Apr 2013 17:28:02 -0400 (EDT) Cc: "freebsd-net@freebsd.org" , Jack Vogel X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 21:28:04 -0000 On Friday, April 19, 2013 4:14:43 pm C. L. Martinez wrote: > On Friday, April 19, 2013, John Baldwin wrote: > > On Friday, April 19, 2013 12:32:18 pm C. L. Martinez wrote: > >> On Friday, April 19, 2013, John Baldwin wrote: > >> > On Friday, April 19, 2013 3:11:41 am C. L. Martinez wrote: > >> >> Hi all, > >> >> > >> >> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose > >> ssh > >> >> sessions from time to time frequently. > >> >> > >> >> This fbsd box is installed in an ESXi 5.1 server and I have another > >> three > >> >> fbsd 9.1 in the same ESXi host that do not have this problem, but > maybe > >> the > >> >> problem is with my sysctl.conf and loader.conf settings: > >> > > >> > Which NIC driver are you using? > >> > > >> > -- > >> > John Baldwin > >> > >> > >> e1000. > > > > igb? There are some fixes to handle out of order packets on transmit that > > could break new connections in some cases. That is probably worth > testing. I > > think you can just grab the sys/dev/e1000 from 9-stable and drop it into a > > 9.1 tree to test. > > > > -- > Nop, I am using em driver ... Ok, have you thought about running a tcpdump and then examining the dump around the time that a drop occurs? (Specifically, if you know the connection that drops you can get wireshark to only display the packets for that dump). Also, have you compared netstat -s before and after drops? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Sat Apr 20 10:07:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 823AD1A7 for ; Sat, 20 Apr 2013 10:07:47 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 5396115C8 for ; Sat, 20 Apr 2013 10:07:47 +0000 (UTC) Received: from jre-mbp.elischer.org (ppp121-45-237-17.lns20.per1.internode.on.net [121.45.237.17]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r3JD08WW035666 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 19 Apr 2013 06:00:11 -0700 (PDT) (envelope-from julian@freebsd.org) Message-ID: <51713FD3.20300@freebsd.org> Date: Fri, 19 Apr 2013 21:00:03 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "C. L. Martinez" Subject: Re: Network connections are lost from time to time References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2013 10:07:47 -0000 On 4/19/13 5:54 PM, C. L. Martinez wrote: > On Fri, Apr 19, 2013 at 9:22 AM, C. L. Martinez wrote: > >> >> >> On Fri, Apr 19, 2013 at 7:11 AM, C. L. Martinez wrote: >> >>> Hi all, >>> >>> I have a strange problem with my FreeBSD 9.1 (fully patched): I loose >>> ssh sessions from time to time frequently. >>> >>> This fbsd box is installed in an ESXi 5.1 server and I have another >>> three fbsd 9.1 in the same ESXi host that do not have this problem, but >>> maybe the problem is with my sysctl.conf and loader.conf settings: >>> >>> sysctl.conf >>> >>> # $FreeBSD: release/9.1.0/etc/sysctl.conf 112200 2003-03-13 18:43:50Z mux >>> $ >>> # >>> # This file is read when going to multi-user and its contents piped thru >>> # ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details. >>> # >>> >>> # Uncomment this to prevent users from seeing information about processes >>> that >>> # are being run under another UID. >>> security.bsd.see_other_uids=0 >>> security.bsd.see_other_gids=0 >>> >>> # Refresh arp table entries in 2 minutes >>> net.link.ether.inet.max_age=120 >>> >>> # Drop tcp/udp packets destined for closed ports >>> net.inet.tcp.blackhole=2 >>> net.inet.udp.blackhole=1 >>> >>> # Use the H-TCP congestion control algorithm which is more aggressive >>> ##net.inet.tcp.cc.algorithm=htcp >>> >>> # Host cache is used to cache connection details and metrics >>> ##net.inet.tcp.hostcache.expire=5400 >>> >>> # Maximum segment size (MSS) specifies the largest amount of data in a >>> single TCP segment >>> net.inet.tcp.mssdflt=1440 >>> >>> # Make sure time stamps are enabled for slowstart_flightsize >>> net.inet.tcp.rfc1323=1 >>> >>> # Make sure rfc3390 is DISABLED so the slowstart flightsize values are >>> used. >>> net.inet.tcp.rfc3390=0 >>> >>> # Size of the TCP transmit and receive buffer. >>> net.inet.tcp.sendspace=262144 >>> >>> # Increase auto-tuning TCP step size of the TCP transmit and receive >>> buffers. >>> net.inet.tcp.recvbuf_inc=524288 >>> >>> # Somaxconn is the buffer or backlog queue depth for accepting new TCP >>> connections. >>> kern.ipc.somaxconn=1024 >>> >>> # Reduce the amount of SYN/ACKs we will _retransmit_ to an unresponsive >>> initial connection. >>> net.inet.tcp.syncache.rexmtlimit=1 >>> >>> # Spoofed packet attacks may be used to overload the kernel route cache. >>> net.inet.ip.rtexpire=60 >>> net.inet.ip.rtminexpire=2 >>> net.inet.ip.rtmaxcache=1024 >>> >>> loader.conf: >>> >>> ############################################################## >>> ### Loader settings ######################################## >>> ############################################################## >>> >>> autoboot_delay="5" >>> beastie_disable="YES" >>> >>> >>> ############################################################## >>> ### Kernel tunables ######################################## >>> ############################################################## >>> >>> kern.maxfiles="25000" >>> kern.ipc.nmbclusters="32768" >>> net.inet.tcp.syncache.hashsize="1024" >>> net.inet.tcp.syncache.bucketlimit="100" >>> net.inet.tcp.tcbhashsize="4096" >>> >>> >>> ############################################################## >>> ### Hardware tunables ###################################### >>> ############################################################## >>> >>> hw.pci.enable_msi="0" >>> hw.pci.enable_msix="0" >>> >>> >>> ############################################################## >>> ### Networking modules ##################################### >>> ############################################################## >>> >>> cc_htcp_load="YES" >>> >>> >>> ############################################################## >>> ### Other modules ########################################## >>> ############################################################## >>> >>> aio_load="YES" >>> >>> How can I debug where is the problem?? >>> >> More info when I try to connect with PuTTY from a windows desktop appears >> the following error: >> >> Network error: Software caused connection abort. >> >> ... and pf is disabled (ipfw and ipfilter, too). >> >> > More info: I have intermittent failures with sendmail: > > /var/spool/mqueue (1 request) > -----Q-ID----- --Size-- -----Q-Time----- > ------------Sender/Recipient----------- > r3J9o54G022686 243 Fri Apr 19 09:50 > (reply: read error from [10.196.0.100]) > susor1@domain.com > Total requests: 1 > > It is really strange ... are you sure you do not have another virtual machine with the same address? (LL or IP) > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >