From owner-freebsd-net@FreeBSD.ORG Sun Dec 29 00:16:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2E0DBC01 for ; Sun, 29 Dec 2013 00:16:15 +0000 (UTC) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A830B1640 for ; Sun, 29 Dec 2013 00:16:14 +0000 (UTC) Received: by mail-la0-f44.google.com with SMTP id ep20so4995484lab.31 for ; Sat, 28 Dec 2013 16:16:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=vsDIDwaL2ctYdY/7jZLWnn5DitB4kXEvILobShCX4SU=; b=GqRR/0LXRdW8bo0/xWasUYtvWH7UKrFYVEu8RhKameN/7iryWZKNCDoYPyuWVWLzR9 rEx2bTqsE4kkVmkBcPvD6B628Kf3RFWiKDWpSXXSLVYl0KGWFtt7cay8wtr0rCx/rxRB 4gbOkWBfjYp/68qzWHIOcNMmW2XgMS2Uxq2hA4Pi7+Ccl7gGyS1mTX7h9CqNXnSK8CE3 w/BgLMj+D0zGlSx/cG67Qs06wXpUbRErsUa8/gAahIvm4nEU/aHvKoof15aCevudcB4V 79bpoUvIEWiv15Dx9eaf05+uXa+JDNV4RRddUIPTdtztoKO4PTO5RQJ/mRC44RiCGXoZ zlpQ== MIME-Version: 1.0 X-Received: by 10.112.135.102 with SMTP id pr6mr8375081lbb.43.1388276172569; Sat, 28 Dec 2013 16:16:12 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Sat, 28 Dec 2013 16:16:12 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Dec 2013 00:16:12 +0000 X-Google-Sender-Auth: Hmik8uDD_-krY4JMcXfvrrnJ-D8 Message-ID: Subject: Re: Issues putting jails on their own subnet From: Nikolay Denev To: Andrew Klaus Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 00:16:15 -0000 Hi Andrew, Actually you should be able to override this routing entry by just deleting it, or you can also check if "net.add_addr_allfibs" sysctl can help you. --Nikolay On Sat, Dec 28, 2013 at 10:05 PM, Andrew Klaus wrote: > Hello, > > I'm trying to segregate some of my jails onto their own (DMZ) subnet. > > Internal subnet: 10.0.3.0/24 > DMZ subnet: 10.0.4.0/24 > > Both of these subnets are on my FreeBSD host, but I'm using a second > routing table for my DMZ jails as seen here: > > --------------- > setfib 1 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.0.4.1 UGS 0 2393945 vlan4 > 10.0.3.0/24 link#12 U 0 0 vlan3 > ---------------- > > The problem I'm facing, is when I try to connect to the DMZ'd jail from the > 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but > replies back through on the vlan3 interface. I guess this makes sense, > because of that second route entry (that I can't override). > > I've tried using PF to force the packets back through to 10.0.4.1, but it > doesn't seem to want to work. Is the only other way to use the > experimental vnet/vimage? > > Any ideas would be helpful. > > Thanks, > > Andrew > _______________________________________________ > 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 Sun Dec 29 00:31:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C7C23DD3 for ; Sun, 29 Dec 2013 00:31:09 +0000 (UTC) Received: from mail-vc0-x22d.google.com (mail-vc0-x22d.google.com [IPv6:2607:f8b0:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8182A1741 for ; Sun, 29 Dec 2013 00:31:09 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id ht17so5410921vcb.32 for ; Sat, 28 Dec 2013 16:31:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=YNt99FAUS/KpPHj5UFrQFYRxQXmPxOCIbASbNwnompk=; b=vaPuID7xBwcfE+9dJlu/wuT4wDl9m+6WVChShRUEda6EenF2G+Vt75CRGJnT+dzjVH Y/w0C5X//hFhDbAZnoRQnIOR2xyruDduMj7IGIQuiWx9j1QlUSirudaMonnYat2PQVDf cillB7UHt1uQTvjZ52kceiWHtkjY/h5PVm8jOaHs7dVH9f1P4m1ZqNfAuehWcxjsiofI mzDHQQzrznsB15Qxal49lM9HNj21QWngJRMVlRIOvRWcL87122Dw2lKDE0v+Uy4FSVuW FwJRJRAdCvyfQfDI38Ya6WU4TqVWKXLmVHgpg02TVmTac8PRxshxnLgzDNHvRJBWWqoq pBcQ== X-Received: by 10.220.189.2 with SMTP id dc2mr12326vcb.60.1388277068614; Sat, 28 Dec 2013 16:31:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.180.9 with HTTP; Sat, 28 Dec 2013 16:30:48 -0800 (PST) In-Reply-To: References: From: Andrew Klaus Date: Sat, 28 Dec 2013 17:30:48 -0700 Message-ID: Subject: Re: Issues putting jails on their own subnet To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 00:31:09 -0000 It doesn't seem to let me delete it (first thing I tried).. Gives me this error: # route delete 10.0.3.0/24 route: writing to routing socket: Address already in use delete net 10.0.3.0 fib 0: gateway uses the same route However, using the tunable, then works perfectly. Thanks! On Sat, Dec 28, 2013 at 5:16 PM, Nikolay Denev wrote: > Hi Andrew, > > Actually you should be able to override this routing entry by just > deleting it, or you can also check if "net.add_addr_allfibs" sysctl can > help you. > > > --Nikolay > > > > On Sat, Dec 28, 2013 at 10:05 PM, Andrew Klaus wrote: > >> Hello, >> >> I'm trying to segregate some of my jails onto their own (DMZ) subnet. >> >> Internal subnet: 10.0.3.0/24 >> DMZ subnet: 10.0.4.0/24 >> >> Both of these subnets are on my FreeBSD host, but I'm using a second >> routing table for my DMZ jails as seen here: >> >> --------------- >> setfib 1 netstat -rn >> Routing tables >> >> Internet: >> Destination Gateway Flags Refs Use Netif Expire >> default 10.0.4.1 UGS 0 2393945 vlan4 >> 10.0.3.0/24 link#12 U 0 0 vlan3 >> ---------------- >> >> The problem I'm facing, is when I try to connect to the DMZ'd jail from >> the >> 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but >> replies back through on the vlan3 interface. I guess this makes sense, >> because of that second route entry (that I can't override). >> >> I've tried using PF to force the packets back through to 10.0.4.1, but it >> doesn't seem to want to work. Is the only other way to use the >> experimental vnet/vimage? >> >> Any ideas would be helpful. >> >> Thanks, >> >> Andrew >> _______________________________________________ >> 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 Sun Dec 29 01:28:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AC8A560D for ; Sun, 29 Dec 2013 01:28:51 +0000 (UTC) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1DB9719F8 for ; Sun, 29 Dec 2013 01:28:50 +0000 (UTC) Received: by mail-lb0-f178.google.com with SMTP id c11so4830210lbj.23 for ; Sat, 28 Dec 2013 17:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HADX6410Fyg2+bPPUOavMskJUI6H/b7pTrsj/2UxBJk=; b=hnfrhdxXojWJ8I3enhbWg4MxfVpZz0bFkPITy672DnC1K5Se4BsdzJMtM9ehMKnUIR 9XlIF1zOrLveI42raY9Dg5ZCzphdqQ4XOuhZDur6Gxd9rzatK6jMtdBX7JcoLXOzUR0J 83+Gct4+c/QgNjwS4Ril0v8wlmADSE6y8A0c4WXy8/hkFaMRj4k8wAyvcZtXn6MIrcJr uww8n+CmmtkIP3injeKUcuOOo650PVK4Yjc6FLhEH0xDeiaMQF8qoO8aDztkSAF1Lw68 E9BSc3wyYp6DK/xHMq4PO/DnQtnSco36s9pYRSV1eCGvDt6EitbFEY3i9WBIfp8VPyMN MvXQ== MIME-Version: 1.0 X-Received: by 10.152.116.46 with SMTP id jt14mr11628720lab.31.1388280529100; Sat, 28 Dec 2013 17:28:49 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Sat, 28 Dec 2013 17:28:49 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Dec 2013 01:28:49 +0000 X-Google-Sender-Auth: 32UQK6OOT2_lb5YEF42WLv5KaAI Message-ID: Subject: Re: Issues putting jails on their own subnet From: Nikolay Denev To: Andrew Klaus Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 01:28:51 -0000 Hi, I meant to delete the route from FIB 1, not from the main FIB, like "setfib 1 route delete 10.0.3.0/24" Anyways, good that you made it work using the tunable. Cheers, --Nikolay On Sun, Dec 29, 2013 at 12:30 AM, Andrew Klaus wrote: > It doesn't seem to let me delete it (first thing I tried).. Gives me this > error: > > # route delete 10.0.3.0/24 > route: writing to routing socket: Address already in use > delete net 10.0.3.0 fib 0: gateway uses the same route > > However, using the tunable, then works perfectly. > > Thanks! > > > On Sat, Dec 28, 2013 at 5:16 PM, Nikolay Denev wrote: > > > Hi Andrew, > > > > Actually you should be able to override this routing entry by just > > deleting it, or you can also check if "net.add_addr_allfibs" sysctl can > > help you. > > > > > > --Nikolay > > > > > > > > On Sat, Dec 28, 2013 at 10:05 PM, Andrew Klaus >wrote: > > > >> Hello, > >> > >> I'm trying to segregate some of my jails onto their own (DMZ) subnet. > >> > >> Internal subnet: 10.0.3.0/24 > >> DMZ subnet: 10.0.4.0/24 > >> > >> Both of these subnets are on my FreeBSD host, but I'm using a second > >> routing table for my DMZ jails as seen here: > >> > >> --------------- > >> setfib 1 netstat -rn > >> Routing tables > >> > >> Internet: > >> Destination Gateway Flags Refs Use Netif > Expire > >> default 10.0.4.1 UGS 0 2393945 vlan4 > >> 10.0.3.0/24 link#12 U 0 0 vlan3 > >> ---------------- > >> > >> The problem I'm facing, is when I try to connect to the DMZ'd jail from > >> the > >> 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but > >> replies back through on the vlan3 interface. I guess this makes sense, > >> because of that second route entry (that I can't override). > >> > >> I've tried using PF to force the packets back through to 10.0.4.1, but > it > >> doesn't seem to want to work. Is the only other way to use the > >> experimental vnet/vimage? > >> > >> Any ideas would be helpful. > >> > >> Thanks, > >> > >> Andrew > >> _______________________________________________ > >> 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" > >> > > > > > _______________________________________________ > 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 Sun Dec 29 04:24:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 98EA8CE4; Sun, 29 Dec 2013 04:24:15 +0000 (UTC) Received: from mx1.fisglobal.com (mx1.fisglobal.com [199.200.24.190]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5ADE1160A; Sun, 29 Dec 2013 04:24:15 +0000 (UTC) Received: from smtp.fisglobal.com ([10.132.206.31]) by ltcfislmsgpa03.fnfis.com (8.14.5/8.14.5) with ESMTP id rBT4O4g0010079 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sat, 28 Dec 2013 22:24:04 -0600 Received: from LTCFISWMSGMB21.FNFIS.com ([169.254.1.7]) by LTCFISWMSGHT03.FNFIS.com ([10.132.206.31]) with mapi id 14.03.0158.001; Sat, 28 Dec 2013 22:24:03 -0600 From: "Teske, Devin" To: "" Subject: Re: network.subr _aliasN handling Thread-Topic: network.subr _aliasN handling Thread-Index: AQHPBE3NCNy+IhmEZ0eModIwDB4CDw== Date: Sun, 29 Dec 2013 04:24:02 +0000 Message-ID: References: <20131228055324.GA72764@aim7400.DataIX.local> In-Reply-To: <20131228055324.GA72764@aim7400.DataIX.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.132.253.120] Content-Type: multipart/mixed; boundary="_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2013-12-28_02:2013-12-27,2013-12-28,1970-01-01 signatures=0 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Devin Teske List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Dec 2013 04:24:15 -0000 --_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_ Content-Type: text/plain; charset="us-ascii" Content-ID: <167BE959779B3C469BB3E67480BDED94@fisglobal.com> Content-Transfer-Encoding: quoted-printable On Dec 27, 2013, at 9:53 PM, wrote: > Curious what everyone's opinion would be on modifying the handling of _al= iasN functions or providing a wrapper around it to handle non-sequential or= dering. >=20 > My goal on this is simple and based around groupings similiar to that of = the way user id(1)'s in passwd and group are handled or denoted for use on = modern systems. >=20 > I.e.: I would like to achieve this... >=20 > *_alias[1-99] =3D System type addresses "Importand addresses or internal" > *_alias[100-199] =3D Aliases for interface 1 > *_alias[200-299] =3D Aliases for interface 2 > etc... >=20 > NOt looking to achieve some sort of prefered naming convention for the in= terface aliases, but loosen them so they may be defined by the user in what= ever means neccesary to their benefit. >=20 > In a scheme similiar to above I attempted to set an address on every othe= r 4th alias leaving 3 space rule room for insertion of further addresses bu= t was surprised when the processing of the aliases ceased at the first non-= sequential space. >=20 > So why not just grab every _aliasN no matter of what it is for the interf= ace and shove them into an arrary to be processed by a "for" statement ? th= e order would still be kept without having to inspect every defintion of al= ias and incrementing prehistorically. >=20 > As well this could provide early loading of the addresses into their resp= ective arrays so they may be processed and provided to any other functions = that may need to access them earlier on in script fallthrough. >=20 > Looking at _alias'N' sequentialy feels like a neucense. You mean something like the attached? --=20 Devin _____________ The information contained in this message is proprietary and/or confidentia= l. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any ma= nner; and (iii) notify the sender immediately. In addition, please be aware= that any message addressed to our domain is subject to archiving and revie= w by persons other than the intended recipient. Thank you. --_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_ Content-Type: text/plain; name="patch.txt" Content-Description: patch.txt Content-Disposition: attachment; filename="patch.txt"; size=1783; creation-date="Sun, 29 Dec 2013 04:24:02 GMT"; modification-date="Sun, 29 Dec 2013 04:24:02 GMT" Content-ID: Content-Transfer-Encoding: base64 SW5kZXg6IGV0Yy9uZXR3b3JrLnN1YnINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBldGMvbmV0d29yay5zdWJy CShyZXZpc2lvbiAyNTU3MTIpDQorKysgZXRjL25ldHdvcmsuc3Vicgkod29ya2luZyBjb3B5KQ0K QEAgLTEwMjcsOSArMTAyNyw4IEBAIGlmYWxpYXNfYWZfY29tbW9uKCkNCiAJX2FjdGlvbj0kMw0K IA0KIAkjIGlmY29uZmlnX0lGX2FsaWFzTiB3aGljaCBzdGFydHMgd2l0aCAkX2FmDQotCWFsaWFz PTANCi0Jd2hpbGUgOiA7IGRvDQotCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZfdmFyICRfaWYgaWZj b25maWdfSUZfYWxpYXMke2FsaWFzfWANCisJZm9yIGFsaWFzIGluIGBsaXN0X3ZhcnMgaWZjb25m aWdfJHtfaWZ9X2FsaWFzWzAtOV1cKmA7IGRvDQorCQlldmFsIGlmY29uZmlnX2FyZ3M9XCJcJCRh bGlhc1wiDQogCQlfaWFmPQ0KIAkJY2FzZSAkaWZjb25maWdfYXJncyBpbg0KIAkJaW5ldFwgKikJ X2lhZj1pbmV0IDs7DQpAQCAtMTA1MSwxNSArMTA1MCwxMyBAQCBpZmFsaWFzX2FmX2NvbW1vbigp DQogCQkJd2FybiAiXCRpZmNvbmZpZ18ke19pZn1fYWxpYXMke2FsaWFzfSBuZWVkcyAiIFwNCiAJ CQkgICAgIlwiaW5ldFwiIGtleXdvcmQgZm9yIGFuIElQdjQgYWRkcmVzcy4iDQogCQllc2FjDQot CQlhbGlhcz0kKCgkYWxpYXMgKyAxKSkNCiAJZG9uZQ0KIA0KIAkjIGJhY2t3YXJkIGNvbXBhdGli aWxpdHk6IGlwdjZfaWZjb25maWdfSUZfYWxpYXNOLg0KIAljYXNlICRfYWYgaW4NCiAJaW5ldDYp DQotCQlhbGlhcz0wDQotCQl3aGlsZSA6IDsgZG8NCi0JCQlpZmNvbmZpZ19hcmdzPWBnZXRfaWZf dmFyICRfaWYgaXB2Nl9pZmNvbmZpZ19JRl9hbGlhcyR7YWxpYXN9YA0KKwkJZm9yIGFsaWFzIGlu IGBsaXN0X3ZhcnMgaXB2Nl9pZmNvbmZpZ18ke19pZn1fYWxpYXNbMC05XVwqYDsgZG8NCisJCQll dmFsIGlmY29uZmlnX2FyZ3M9XCJcJCRhbGlhc1wiDQogCQkJY2FzZSAke19hY3Rpb259OiIke2lm Y29uZmlnX2FyZ3N9IiBpbg0KIAkJCSo6IiIpDQogCQkJCWJyZWFrDQpAQCAtMTA3MSw3ICsxMDY4 LDYgQEAgaWZhbGlhc19hZl9jb21tb24oKQ0KIAkJCQkgICAgImluc3RlYWQuIg0KIAkJCTs7DQog CQkJZXNhYw0KLQkJCWFsaWFzPSQoKCRhbGlhcyArIDEpKQ0KIAkJZG9uZQ0KIAllc2FjDQogDQpJ bmRleDogZXRjL3JjLnN1YnINCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCi0tLSBldGMvcmMuc3VicgkocmV2aXNpb24g MjU1NzEyKQ0KKysrIGV0Yy9yYy5zdWJyCSh3b3JraW5nIGNvcHkpDQpAQCAtNTQsNiArNTQsMjAg QEAgSklEPWAkUFMgLXAgJCQgLW8gamlkPWANCiAjCWZ1bmN0aW9ucw0KICMJLS0tLS0tLS0tDQog DQorIyBsaXN0X3ZhcnMgcGF0dGVybg0KKyMJTGlzdCB2YXJzIG1hdGNoaW5nIHBhdHRlcm4uDQor IyANCitsaXN0X3ZhcnMoKQ0KK3sNCisJc2V0IHwgeyB3aGlsZSByZWFkIExJTkU7IGRvDQorCQl2 YXI9IiR7TElORSUlPSp9Ig0KKwkJY2FzZSAiJHZhciIgaW4NCisJCSIkTElORSJ8KlshYS16QS1a MC05X10qKSBjb250aW51ZSA7Ow0KKwkJJDEpIGVjaG8gJHZhcg0KKwkJZXNhYw0KKwlkb25lOyB9 DQorfQ0KKw0KICMgc2V0X3JjdmFyX29ic29sZXRlIG9sZHZhciBbbmV3dmFyXSBbbXNnXQ0KICMJ RGVmaW5lIG9ic29sZXRlIHZhcmlhYmxlLg0KICMJR2xvYmFsIHZhcmlhYmxlICRyY3ZhcnNfb2Jz b2xldGUgaXMgdXNlZC4NCg== --_002_A7699871A1704AD5B740ED8BE17C7107fisglobalcom_-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 29 04:48:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9BFB1E3D for ; Sun, 29 Dec 2013 04:48:48 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 42A381701 for ; Sun, 29 Dec 2013 04:48:48 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id x13so10601684ief.6 for ; Sat, 28 Dec 2013 20:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MiFsxhS35lAWjs+zt0xliPfzrEEgjNO56rbsLgWpw2A=; b=KAr4zsE2aZv8U23OGJ43u8X2VbmbmDF/bCMh8bpOSGsYNsVRK4GsvgZm7RbaJPthX9 jmrT8UYsej0A6uOYUEVnq4GWFIRm1Muw/6mUF3Ms20bdMpDxaM87yfM1CWlD+y+vgBLh 07YfCzJty9qVx25ZbI94ogfSFnhKgKrObS5WE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=MiFsxhS35lAWjs+zt0xliPfzrEEgjNO56rbsLgWpw2A=; b=klZDFMAQ31ztBF3tjMzwlnCI0tfI5P5qwmBd+WMdTjMmbCSxKlfdqn66NgR4p6+bfP cD/Yy12o0nzAYpgxAAB2XP6eKeJOp1cd4S2sXfJj0VVEouST5z9p0Jm2ol2JBU9/jgI8 LiPTGVb8w2JJPcg3j09bEMhGDeQaRLXIC+cTj49qHvWnxv2Fmj/hc3188ZnhCksprllX 9/Nb5AgNwcTteUmcbLjgth9HzlySgq2mXuitfCyiUnxnHC9AxKyOooNCOIgWvBqcbgcX ylMgSuAVF4pEeqtEcZqT+UXIBKhWy9LQ+oK4ckAF7parkzyFhiQbRrzgGK5GC1/nqZUW rM3w== X-Gm-Message-State: ALoCoQlGm84GtlKBuR1BjCrYPdG7xKF1ULNv7wkdmwrZxdZPxHGPChngAWlkvjdxD9Tsl8/etrRU X-Received: by 10.50.50.203 with SMTP id e11mr28106070igo.42.1388292527756; Sat, 28 Dec 2013 20:48:47 -0800 (PST) Received: from [172.31.35.2] (75-128-101-59.dhcp.sgnw.mi.charter.com. [75.128.101.59]) by mx.google.com with ESMTPSA id kt2sm53142742igb.1.2013.12.28.20.48.45 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 28 Dec 2013 20:48:46 -0800 (PST) References: <20131228055324.GA72764@aim7400.DataIX.local> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-E0EDC189-5055-46F8-8EB1-27CE29789255; protocol="application/pkcs7-signature" Content-Transfer-Encoding: 7bit Message-Id: <91BDCC2B-D1CD-44E6-8135-515099C4ECA8@dataix.net> X-Mailer: iPhone Mail (11B554a) From: Jason Hellenthal Subject: Re: network.subr _aliasN handling Date: Sat, 28 Dec 2013 23:48:44 -0500 To: Devin Teske X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "rc@freebsd.org" , Devin Teske , "Teske, Devin" , "net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 04:48:48 -0000 --Apple-Mail-E0EDC189-5055-46F8-8EB1-27CE29789255 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable I'll have to test it out but yes I'm pretty sure. --=20 Jason Hellenthal Voice: 95.30.17.6/616 JJH48-ARIN > On Dec 28, 2013, at 23:24, "Teske, Devin" wrot= e: >=20 >=20 >> On Dec 27, 2013, at 9:53 PM, wrote: >>=20 >> Curious what everyone's opinion would be on modifying the handling of _al= iasN functions or providing a wrapper around it to handle non-sequential ord= ering. >>=20 >> My goal on this is simple and based around groupings similiar to that of t= he way user id(1)'s in passwd and group are handled or denoted for use on mo= dern systems. >>=20 >> I.e.: I would like to achieve this... >>=20 >> *_alias[1-99] =3D System type addresses "Importand addresses or internal"= >> *_alias[100-199] =3D Aliases for interface 1 >> *_alias[200-299] =3D Aliases for interface 2 >> etc... >>=20 >> NOt looking to achieve some sort of prefered naming convention for the in= terface aliases, but loosen them so they may be defined by the user in whate= ver means neccesary to their benefit. >>=20 >> In a scheme similiar to above I attempted to set an address on every othe= r 4th alias leaving 3 space rule room for insertion of further addresses but= was surprised when the processing of the aliases ceased at the first non-se= quential space. >>=20 >> So why not just grab every _aliasN no matter of what it is for the interf= ace and shove them into an arrary to be processed by a "for" statement ? the= order would still be kept without having to inspect every defintion of alia= s and incrementing prehistorically. >>=20 >> As well this could provide early loading of the addresses into their resp= ective arrays so they may be processed and provided to any other functions t= hat may need to access them earlier on in script fallthrough. >>=20 >> Looking at _alias'N' sequentialy feels like a neucense. >=20 > You mean something like the attached? > --=20 > Devin >=20 > _____________ > The information contained in this message is proprietary and/or confidenti= al. If you are not the intended recipient, please: (i) delete the message an= d all copies; (ii) do not disclose, distribute or use the message in any man= ner; and (iii) notify the sender immediately. In addition, please be aware t= hat any message addressed to our domain is subject to archiving and review b= y persons other than the intended recipient. Thank you. > --Apple-Mail-E0EDC189-5055-46F8-8EB1-27CE29789255 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Disposition: attachment; filename=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIUOTCCBjAw ggUYoAMCAQICAwaijjANBgkqhkiG9w0BAQsFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENB MB4XDTEzMDUxODA4NTA0OFoXDTE0MDUxOTIyMDk0N1owSDEfMB0GA1UEAwwWamhlbGxlbnRoYWxA ZGF0YWl4Lm5ldDElMCMGCSqGSIb3DQEJARYWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnYFS1bWZr3KhKBzWAdRwrY+En+RRV8nCaYubqrMG+ YJbuenaIKSbIuFiDWipW4RHYTpE28pKaSnaVTG9WtAZvsWj0gYN9g2fYCnCOUceES2Yvi3RavxpB hsuzKIfsHb8iNNSEuczLu6gn4mQyaHwE4x6xSUKmbK8njR+YoF522F60wjsnq5dlOJdTrhDfObE5 5P23279WbRp8azgZX1VRB66wdKRDuSI1vBts4Nsha2paXd6HUUduHrPACBQREJTGXN8XtEKVwo63 aKUhRgtUwHNEuSWck/xwVl7PBUWH2dORAWTCqHjNuCKNOQ1/0LMiyMj7FdsBjN4dgL4YZpsCAwEA AaOCAtwwggLYMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggr BgEFBQcDBDAdBgNVHQ4EFgQU29qUrmZtgQ7ZVoDKogfpJOSfk+YwHwYDVR0jBBgwFoAUU3Ltkpzg 2ssBXHx+ljVO8tS4UYIwIQYDVR0RBBowGIEWamhlbGxlbnRoYWxAZGF0YWl4Lm5ldDCCAUwGA1Ud IASCAUMwggE/MIIBOwYLKwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9wb2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29y ZGluZyB0byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRD b20gQ0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAtMCug KaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEFBQcBAQSB gTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMS9jbGll bnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFz czEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJ KoZIhvcNAQELBQADggEBAHsw8/Hw07gsNTKYnld74NBFtHnQOPkXYuccWx3j0PGQe9nqNxeingBf 2yvx+xBQzBoi4J1u84Jbrbe8Ii3+LLD/QMW9cN0SBIgRStPQLVee4STdjeabGmpXQa7omC02wYYO 83qh6CgJEIbmrsBSZH8ZSVrjkC4UmZS8wAQMS3qTWAPF0ZQGWx2+Gks2fXuacyt2LpNR+p9ogjAZ 1/rmUKjNhQZLswytaLRUdwAwSfQ3+TNs68h6Kv1LC3bNGBT3NEtr2q/nzzb5MzuFcDE6f9exroAC 4BHmokAprhna/vZdb6BrPjpXgRAlWAh3wEMxw75M9S/Nbzj/jNp+I+lvUJYwggY0MIIEHKADAgEC AgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQy MTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMi U2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xh c3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IB DwAwggEKAoIBAQDHCYPMzi3YGrEppC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6E RKKnu8zPf1Jwuk0tsvVCk6U9b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1 PKHG/FaR/wpbfuIqu54qzHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvur yGaC/o2/ceD2uYDX9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSM TGKkDiXm6/3/4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNV HRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4 UYIwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2Nh LmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3 LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3Ns LmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4ICAQAKgwh9eKssBly4Y4xerhy5 I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8pyTUnFsukDFUI22zF5bVHzuJ+GxhnS qN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMmCeUTyMyikfbUFvIBivtvkR8ZFAk22BZy +pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIzuQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4Yj Cl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVmz/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586 YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3 a0LwZrp8MQ+Z77U1uL7TelWO5lApsbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0q ZW2Niy/QvVNKbb43A43ny076khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjx kJh8BYtv9ePsXklAxtm8J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV 27ioRKbj/cIq7JRXun0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCB8kwggWxoAMCAQICAQEw DQYJKoZIhvcNAQEFBQAwfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzAp BgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA2MDkxNzE5NDYzNloXDTM2MDkxNzE5NDYz NlowfTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3Vy ZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAwYjbCbxsRnx4 n5V7tTOQ8nJi1sE2ICIkXs7pd/JDCqIGZKTMjjb4OOYj8G5tsTzdcqOFHKHTPbQzK9Mvr/7qsEFZ Z7bEBn0KnnSF1nlMgDd63zkFUln39BtGQ6TShYXSw3HzdWI0uiyKfx6P7u000BHHls1SPboz1t1N 3gs7SkufwiYv+rUWHHI1d8o8XebK4SaLGjZ2XAHbdBQl/u21oIgP3XjKLR8HlzABLXJ5+kbWEyqo uaarg0kd5fLv3eQBjhgKj2NTFoViqQ4ZOsy1ZqbCa3QH5Cvhdj60bdj2ROFzYh87xL6gU1YlbFEJ 96qryr92/W2b853bvz1mvAxWqq+YSJU6S9+nWFDZOHWpW+pDDAL/mevobE1wWyllnN2qXcyvATHs DOvSjejqnHvmbvcnZgwaSNduQuM/3iE+e+ENcPtjqqhsGlS0XCV6yaLJixamuyx+F14FTVhuEh0B 7hIQDcYyfxj//PT6zW6R6DZJvhpIaYvClk0aErJpF8EKkNb6eSJIv7p7afhwx/p6N9jYDdJ2T1f/ kLfjkdLd78Jgt2c63f6qnPDUi39yIs7Gn5e2+K+KoBCo2fsYxra1XFI8ibYZKnMBCg8DsxJg8nov gdujbv8mMJf1i92JV7atPbOvK8W3dgLwpdYrmoYUKnL24zOMXQlLE9+7jHQTUksCAwEAAaOCAlIw ggJOMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgGuMB0GA1UdDgQWBBROC+8apEBbpRdphzDKNGhD 0EGu8jBkBgNVHR8EXTBbMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2EtY3Js LmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydGNvbS5vcmcvc2ZzY2EtY3JsLmNybDCCAV0GA1Ud IASCAVQwggFQMIIBTAYLKwYBBAGBtTcBAQEwggE7MC8GCCsGAQUFBwIBFiNodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvcG9saWN5LnBkZjA1BggrBgEFBQcCARYpaHR0cDovL2NlcnQuc3RhcnRjb20u b3JnL2ludGVybWVkaWF0ZS5wZGYwgdAGCCsGAQUFBwICMIHDMCcWIFN0YXJ0IENvbW1lcmNpYWwg KFN0YXJ0Q29tKSBMdGQuMAMCAQEagZdMaW1pdGVkIExpYWJpbGl0eSwgcmVhZCB0aGUgc2VjdGlv biAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3ku cGRmMBEGCWCGSAGG+EIBAQQEAwIABzA4BglghkgBhvhCAQ0EKxYpU3RhcnRDb20gRnJlZSBTU0wg Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkwDQYJKoZIhvcNAQEFBQADggIBABZsmfRmDDT10IVefQrs 2hBOOBxe36YlBUuRMsHoO/E93UQJWwdJiinLZgK3sZr3JZgJPI4b4d02hytLu2jTOWY9oCbH8jmR HVGrgnt+1c5a5OIDV3Bplwj5XlimCt+MBppFFhY4Cl5X9mLHegIF5rwetfKe9Kkpg/iyFONuKIdE w5Aa3jipPKxDTWRFzt0oqVzyc3sE+Bfoq7HzLlxkbnMxOhK4vLMR5H2PgVGaO42J9E2TZns8A+3T mh2a82VQ9aDQdZ8vr/DqgkOY+GmciXnEQ45GcuNkNhKv9yUeOImQd37Da2q5w8tES6x4kIvnxywe SxFEyDRSJ80KXZ+FwYnVGnjylRBTMt2AhGZ12bVoKPthLr6EqDjAmRKGpR5nZK0GLi+pcIXHlg98 iWX1jkNUDqvdpYA5lGDANMmWcCyjEvUfSHu9HH5rt52Q9CI7rvj8Ksr6glKg769LVZPrwbXwIous NE4mIgShhyx1SrflfRPXuAxkwDbSyS+GEowjCcEbgjtzSaNqV4eU5dZ4xZlDY+NN4Hct4WWZcmkE GkcJ5g8BViT7H78OealYLrnECQF+lbptAAY+supKEDnY0Cv1v+x1v5cCxQkbCNxVN+KB+zeEQ2Ig yudWS2Xq/mzBJJMkoTTrBf+aIq6bfT/xZVEKpjBqs/SIHIAN/HKK6INeMYIDbzCCA2sCAQEwgZQw gYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFBy aW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMAkGBSsOAwIaBQCgggGvMBgGCSqGSIb3 DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEzMTIyOTA0NDg0NlowIwYJKoZIhvcN AQkEMRYEFJCVlWoBokm+uUWgNoI5428syF5cMIGlBgkrBgEEAYI3EAQxgZcwgZQwgYwxCzAJBgNV BAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBD ZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50 ZXJtZWRpYXRlIENsaWVudCBDQQIDBqKOMIGnBgsqhkiG9w0BCRACCzGBl6CBlDCBjDELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENl cnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRl cm1lZGlhdGUgQ2xpZW50IENBAgMGoo4wDQYJKoZIhvcNAQEBBQAEggEAgKLvIceMVEzfizxepOmL MOj3vb09ZeExkgRI7mnjcSinDaRkqNua0qclHJh4hJjoQOlh3JrIU4alc9vfFK2El/gdlM3AjO34 vOoOHori5Kf3B0Q1fEq3VoA0ItjDx9K6H53q9e/PJYNhtDmvgXHI/vTImB1aZce0bniVEK/OD6Sl v02VoEOBbEoAEBfHse3xa4pKzpc6pz6t/lksh9mpf1C5LrwNFJ/Pv6MswLqDKskszfL+r6UcQUQY egzBNiRCTofCjIgz3ICQxvi1R3PUvPN97nqpzKtaBm/dH47YQZwk/P8A//OELfWNReHSrykeSLz5 trRryPDr/RVEkGGOEgAAAAAAAA== --Apple-Mail-E0EDC189-5055-46F8-8EB1-27CE29789255-- From owner-freebsd-net@FreeBSD.ORG Sun Dec 29 04:48: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E1EAE44 for ; Sun, 29 Dec 2013 04:48:56 +0000 (UTC) Received: from mail-vc0-x22a.google.com (mail-vc0-x22a.google.com [IPv6:2607:f8b0:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF7801705 for ; Sun, 29 Dec 2013 04:48:55 +0000 (UTC) Received: by mail-vc0-f170.google.com with SMTP id la4so5449304vcb.29 for ; Sat, 28 Dec 2013 20:48:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QwBKV2OtWqjomFc4G8IO5xVmWgQ7eWsBVAi6fbZOcMA=; b=hJbu365jRD6aOl62K0zZmYrOcStbutXc+ttOImYR1/ZNJ66bIYlrW5BRSd46XvHL5Z t8TKw/8g8RDZ/rJ6D5nv1GrA27AT/4T4xac0JAU79N1+5uFMCn+wXBb+0IqXYgBCM49S 5Y43Rq5m/T8MDaklNyd8Drd9W1Pps16ZmMDzB2H3T3G0ypuTgLXTYoYAg0MEZd/ipdlU LZFZMNb7xzBdaZ9dRrc17o9e6CI8U6I/5h+hHDIJ4FJ7zXsjWDfpMm5FaEhnCIhx5N2r 4X4Gj1LPmtVfROZAFy5NWcD2k7zwpmq4PUnXytOHy+48FOgC0yKuthHdPvhO5OqXoKbb DlDw== X-Received: by 10.53.11.198 with SMTP id ek6mr4371699vdd.24.1388292535030; Sat, 28 Dec 2013 20:48:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.180.9 with HTTP; Sat, 28 Dec 2013 20:48:34 -0800 (PST) In-Reply-To: References: From: Andrew Klaus Date: Sat, 28 Dec 2013 21:48:34 -0700 Message-ID: Subject: Re: Issues putting jails on their own subnet To: Nikolay Denev Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 04:48:56 -0000 Hmm.. I did try it that way earlier, but I'm getting the same issue: # setfib 2 netstat -rn Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.0.3.1 UGS 0 0 vlan3 10.0.4.0/24 link#13 U 0 0 vlan4 10.0.4.13/32 link#13 U 0 0 vlan4 10.0.4.16/32 link#13 U 0 0 vlan4 127.0.0.1 link#10 UH 0 0 lo0 # setfib 2 route delete 10.0.4.0/24 route: writing to routing socket: Address already in use delete net 10.0.4.0 fib 2: gateway uses the same route Is there a way to delete it without deleting the IP from the interface? Thanks, Andrew On Sat, Dec 28, 2013 at 6:28 PM, Nikolay Denev wrote: > Hi, > > I meant to delete the route from FIB 1, not from the main FIB, like > "setfib 1 route delete 10.0.3.0/24" > > Anyways, good that you made it work using the tunable. > > Cheers, > > --Nikolay > > > On Sun, Dec 29, 2013 at 12:30 AM, Andrew Klaus wrote: > >> It doesn't seem to let me delete it (first thing I tried).. Gives me this >> error: >> >> # route delete 10.0.3.0/24 >> route: writing to routing socket: Address already in use >> delete net 10.0.3.0 fib 0: gateway uses the same route >> >> However, using the tunable, then works perfectly. >> >> Thanks! >> >> >> On Sat, Dec 28, 2013 at 5:16 PM, Nikolay Denev >> wrote: >> >> > Hi Andrew, >> > >> > Actually you should be able to override this routing entry by just >> > deleting it, or you can also check if "net.add_addr_allfibs" sysctl can >> > help you. >> > >> > >> > --Nikolay >> > >> > >> > >> > On Sat, Dec 28, 2013 at 10:05 PM, Andrew Klaus > >wrote: >> > >> >> Hello, >> >> >> >> I'm trying to segregate some of my jails onto their own (DMZ) subnet. >> >> >> >> Internal subnet: 10.0.3.0/24 >> >> DMZ subnet: 10.0.4.0/24 >> >> >> >> Both of these subnets are on my FreeBSD host, but I'm using a second >> >> routing table for my DMZ jails as seen here: >> >> >> >> --------------- >> >> setfib 1 netstat -rn >> >> Routing tables >> >> >> >> Internet: >> >> Destination Gateway Flags Refs Use Netif >> Expire >> >> default 10.0.4.1 UGS 0 2393945 vlan4 >> >> 10.0.3.0/24 link#12 U 0 0 vlan3 >> >> ---------------- >> >> >> >> The problem I'm facing, is when I try to connect to the DMZ'd jail from >> >> the >> >> 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but >> >> replies back through on the vlan3 interface. I guess this makes sense, >> >> because of that second route entry (that I can't override). >> >> >> >> I've tried using PF to force the packets back through to 10.0.4.1, but >> it >> >> doesn't seem to want to work. Is the only other way to use the >> >> experimental vnet/vimage? >> >> >> >> Any ideas would be helpful. >> >> >> >> Thanks, >> >> >> >> Andrew >> >> _______________________________________________ >> >> 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" >> >> >> > >> > >> _______________________________________________ >> 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 Sun Dec 29 11:53:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9F5C2319 for ; Sun, 29 Dec 2013 11:53:03 +0000 (UTC) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 10DEE1F01 for ; Sun, 29 Dec 2013 11:53:02 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id eh20so5065969lab.33 for ; Sun, 29 Dec 2013 03:53:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=cqr+edfLN9sZgLfM9yogi6MfDbrlq8hjuVDt2inG+rI=; b=K8czitWxYKxo3hKzCR6itYiVPiie/nWpyi9OX3EzjUltv5iLr/Zq2PPh1uPAxzoLbo UrsGJ5WWZd5AUB7BT8ucz2+3rMj+MCybmffDPeyYNFGWZozXZHLhmLaSLhgSE0KSaoaK IU6Ggx5R9l79fViUfvEg9rdXPszpvgl80yO9nNzFnhvS8FblfjoZ6CK0KxSAbyn8c6oG xOYgoiVyS1d0RJVY6W0z6nCcWr4ur5W39g0DYcMDIDxmxyoFQBIZ8FulpbUYalyLmGJ/ /eLAHdtS5i9dUYbP4a59dYASciB7gysRWWyNyaBd3i+RvzAlQJI9gkfly8HAKsIMEN0q phkA== MIME-Version: 1.0 X-Received: by 10.112.13.169 with SMTP id i9mr518253lbc.73.1388317980912; Sun, 29 Dec 2013 03:53:00 -0800 (PST) Sender: ndenev@gmail.com Received: by 10.114.242.33 with HTTP; Sun, 29 Dec 2013 03:53:00 -0800 (PST) In-Reply-To: References: Date: Sun, 29 Dec 2013 11:53:00 +0000 X-Google-Sender-Auth: pWEP6HXGssoEP_f3Gqgkf70YLCI Message-ID: Subject: Re: Issues putting jails on their own subnet From: Nikolay Denev To: Andrew Klaus Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 29 Dec 2013 11:53:03 -0000 Hmm, you are right. I'm pretty sure I was able to do this before running 9.1 however I've tried now on 10 and it fails. Quick search suggests some changes that might prevent the route to be deleted : http://lists.freebsd.org/pipermail/svn-src-head/2013-March/045550.html --Nikolay On Sun, Dec 29, 2013 at 4:48 AM, Andrew Klaus wrote: > Hmm.. I did try it that way earlier, but I'm getting the same issue: > > # setfib 2 netstat -rn > Routing tables > > Internet: > Destination Gateway Flags Refs Use Netif Expire > default 10.0.3.1 UGS 0 0 vlan3 > 10.0.4.0/24 link#13 U 0 0 vlan4 > 10.0.4.13/32 link#13 U 0 0 vlan4 > 10.0.4.16/32 link#13 U 0 0 vlan4 > 127.0.0.1 link#10 UH 0 0 lo0 > > > # setfib 2 route delete 10.0.4.0/24 > route: writing to routing socket: Address already in use > delete net 10.0.4.0 fib 2: gateway uses the same route > > > Is there a way to delete it without deleting the IP from the interface? > > Thanks, > > Andrew > > > On Sat, Dec 28, 2013 at 6:28 PM, Nikolay Denev wrote: > >> Hi, >> >> I meant to delete the route from FIB 1, not from the main FIB, like >> "setfib 1 route delete 10.0.3.0/24" >> >> Anyways, good that you made it work using the tunable. >> >> Cheers, >> >> --Nikolay >> >> >> On Sun, Dec 29, 2013 at 12:30 AM, Andrew Klaus wrote: >> >>> It doesn't seem to let me delete it (first thing I tried).. Gives me this >>> error: >>> >>> # route delete 10.0.3.0/24 >>> route: writing to routing socket: Address already in use >>> delete net 10.0.3.0 fib 0: gateway uses the same route >>> >>> However, using the tunable, then works perfectly. >>> >>> Thanks! >>> >>> >>> On Sat, Dec 28, 2013 at 5:16 PM, Nikolay Denev >>> wrote: >>> >>> > Hi Andrew, >>> > >>> > Actually you should be able to override this routing entry by just >>> > deleting it, or you can also check if "net.add_addr_allfibs" sysctl can >>> > help you. >>> > >>> > >>> > --Nikolay >>> > >>> > >>> > >>> > On Sat, Dec 28, 2013 at 10:05 PM, Andrew Klaus >> >wrote: >>> > >>> >> Hello, >>> >> >>> >> I'm trying to segregate some of my jails onto their own (DMZ) subnet. >>> >> >>> >> Internal subnet: 10.0.3.0/24 >>> >> DMZ subnet: 10.0.4.0/24 >>> >> >>> >> Both of these subnets are on my FreeBSD host, but I'm using a second >>> >> routing table for my DMZ jails as seen here: >>> >> >>> >> --------------- >>> >> setfib 1 netstat -rn >>> >> Routing tables >>> >> >>> >> Internet: >>> >> Destination Gateway Flags Refs Use Netif >>> Expire >>> >> default 10.0.4.1 UGS 0 2393945 vlan4 >>> >> 10.0.3.0/24 link#12 U 0 0 vlan3 >>> >> ---------------- >>> >> >>> >> The problem I'm facing, is when I try to connect to the DMZ'd jail >>> from >>> >> the >>> >> 10.0.3.0 network, traffic comes in on vlan4 like it's supposed to, but >>> >> replies back through on the vlan3 interface. I guess this makes sense, >>> >> because of that second route entry (that I can't override). >>> >> >>> >> I've tried using PF to force the packets back through to 10.0.4.1, >>> but it >>> >> doesn't seem to want to work. Is the only other way to use the >>> >> experimental vnet/vimage? >>> >> >>> >> Any ideas would be helpful. >>> >> >>> >> Thanks, >>> >> >>> >> Andrew >>> >> _______________________________________________ >>> >> 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 >>> " >>> >> >>> > >>> > >>> _______________________________________________ >>> 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 Dec 30 11:06:50 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 372A1F61 for ; Mon, 30 Dec 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 216CF10FF for ; Mon, 30 Dec 2013 11:06:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.7/8.14.7) with ESMTP id rBUB6o2B058171 for ; Mon, 30 Dec 2013 11:06:50 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.7/8.14.7/Submit) id rBUB6nbi058169 for freebsd-net@FreeBSD.org; Mon, 30 Dec 2013 11:06:49 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 30 Dec 2013 11:06:49 GMT Message-Id: <201312301106.rBUB6nbi058169@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.17 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, 30 Dec 2013 11:06:50 -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/185148 net [ip6] [patch] Cleanup ip6_mroute.c o kern/184311 net [bge] [panic] kernel panic with bge(4) on SunFire X210 o kern/184084 net [ral] kernel crash by ral (RT3090) o bin/183687 net [patch] route(8): route add -net 172.20 add wrong host o kern/183659 net [tcp] ]TCP stack lock contention with short-lived conn o conf/183407 net [rc.d] [patch] Routing restart returns non-zero exitco o kern/183391 net [oce] 10gigabit networking problems with Emulex OCE 11 o kern/183390 net [ixgbe] 10gigabit networking problems o kern/182917 net [igb] strange out traffic with igb interfaces o kern/182847 net [netinet6] [patch] Remove dead code o kern/182665 net [wlan] Kernel panic when creating second wlandev. o kern/182382 net [tcp] sysctl to set TCP CC method on BIG ENDIAN system o kern/182297 net [cm] ArcNet driver fails to detect the link address - o kern/182212 net [patch] [ng_mppc] ng_mppc(4) blocks on network errors o kern/181970 net [re] LAN RealtekŪ 8111G is not supported by re driver o kern/181931 net [vlan] [lagg] vlan over lagg over mlxen crashes the ke o kern/181823 net [ip6] [patch] make ipv6 mroute return same errror code o kern/181741 net [kernel] [patch] Packet loss when 'control' messages a o kern/181703 net [re] [patch] Fix Realtek 8111G Ethernet controller not o kern/181657 net [bpf] [patch] BPF_COP/BPF_COPX instruction reservation o kern/181257 net [bge] bge link status change o kern/181236 net [igb] igb driver unstable work o kern/181135 net [netmap] [patch] sys/dev/netmap patch for Linux compat o kern/181131 net [netmap] [patch] sys/dev/netmap memory allocation impr o kern/181006 net [run] [patch] mbuf leak in run(4) driver o kern/180893 net [if_ethersubr] [patch] Packets received with own LLADD o kern/180844 net [panic] [re] Intermittent panic (re driver?) o kern/180775 net [bxe] if_bxe driver broken with Broadcom BCM57711 card o kern/180722 net [bluetooth] bluetooth takes 30-50 attempts to pair to s kern/180468 net [request] LOCAL_PEERCRED support for PF_INET o kern/180065 net [netinet6] [patch] Multicast loopback to own host brok o kern/179926 net [lacp] [patch] active aggregator selection bug o kern/179824 net [ixgbe] System (9.1-p4) hangs on heavy ixgbe network t o kern/179733 net [lagg] [patch] interface loses capabilities when proto o kern/179429 net [tap] STP enabled tap bridge o kern/179299 net [igb] Intel X540-T2 - unstable driver a kern/179264 net [vimage] [pf] Core dump with Packet filter and VIMAGE o kern/178947 net [arp] arp rejecting not working o kern/178782 net [ixgbe] 82599EB SFP does not work with passthrough und o kern/178612 net [run] kernel panic due the problems with run driver o kern/178472 net [ip6] [patch] make return code consistent with IPv4 co o kern/178079 net [tcp] Switching TCP CC algorithm panics on sparc64 wit s kern/178071 net FreeBSD unable to recongize Kontron (Industrial Comput o kern/177905 net [xl] [panic] ifmedia_set when pluging CardBus LAN card o kern/177618 net [bridge] Problem with bridge firewall with trunk ports 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 f 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/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/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 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/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 p 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/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/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/166462 net [gre] gre(4) when using a tunnel source address from c 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 p kern/165903 net mbuf leak 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/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/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/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 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 p 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/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 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/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/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 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 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/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 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 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/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/121534 net [ipl] [nat] FreeBSD Release 6.3 Kernel Trap 12: 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] f kern/108197 net [panic] [gif] [ip6] if_delmulti reference counting pan 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/104738 net [inet] [patch] Reentrant problem with inet_ntoa in the 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/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling 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 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging 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/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 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/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/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 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 473 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Dec 31 03:38:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0F95E526 for ; Tue, 31 Dec 2013 03:38:59 +0000 (UTC) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8DB251B1C for ; Tue, 31 Dec 2013 03:38:58 +0000 (UTC) Received: by mail-lb0-f171.google.com with SMTP id w7so6086417lbi.30 for ; Mon, 30 Dec 2013 19:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Q1c4/frshThABSqm4FchDlKswk51skkiL3/7fn+K5PE=; b=I4beU6haw3vkksZ83RxjV3nkNpcJsIRxEwo3TnEOEH7vFomN+kCiYEp1HvoHscmP1T Lg/2kVCbtWnqUkyVg/86zK9dw2K1qD0betClfzs0aYVCaT+OeXOQdd9YE9HbUjgdhIU3 myBxOicGqeC5Omo+cdJGB7vacASjJ/EznNfW/v0FwpyEoXEx8H9Rzoa/3c5k7j2C0/Lv e393tndtbyWPnFnTUxyvLCYiasjYpu6abwLrtH54E4dgwFgcwpAmZnxeqaI8ZHFwmtbf QqowDaIZW5u2iZqV7Fo5rY/NIyQFytatTff/n+cy3R9OX2FMjrG0MZhTIVg8xQLZet8E XbHw== MIME-Version: 1.0 X-Received: by 10.112.130.35 with SMTP id ob3mr27490004lbb.2.1388461136478; Mon, 30 Dec 2013 19:38:56 -0800 (PST) Received: by 10.114.199.102 with HTTP; Mon, 30 Dec 2013 19:38:56 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Dec 2013 11:38:56 +0800 Message-ID: Subject: Re: Question about the "connected" UDP sockets From: Sepherosa Ziehau To: Oleg Moskalenko Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 31 Dec 2013 03:38:59 -0000 On Fri, Dec 27, 2013 at 1:49 AM, Oleg Moskalenko wrote: > Hi > > I cannot find the information about the implementation details of the > "connected" UDP sockets in FreeBSD. I know that in older Linux kernels all You could start from sys/netinet/udp_usrreq.c:udp_connect(). > UDP sockets are stored in a hash table - and the remote IP:port are not > used for the hash calculation, so the performance is awful when you have > thousands "connected" UDP sockets on the same local IP:port address. So a > UDP packet incoming to the local address has to go through the long list of > sockets to find the proper destination. > > How it is done in the FreeBSD ? Are the UDP "connected" sockets using a > hash table with key based upon 5-tuple (protocol, remote-ip, remote-port, > local-ip, local-port} ? UDP uses its own hash table for "connected" sockets (inpcb actually). The "connected" inpcbs are hashed using lport/fport/laddr/faddr (4-tuple). Best Regards, sephe From owner-freebsd-net@FreeBSD.ORG Tue Dec 31 04:03:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E2DB1A21 for ; Tue, 31 Dec 2013 04:03:13 +0000 (UTC) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id A14F91DAB for ; Tue, 31 Dec 2013 04:03:13 +0000 (UTC) Received: by mail-yh0-f46.google.com with SMTP id l109so2512846yhq.5 for ; Mon, 30 Dec 2013 20:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:from:subject:date:to; bh=HiJwDr5tBb98oog11mFBpF5sLwfnlik4DbywvXk/ZCU=; b=T4RjtVBtCNAc4/byhNlze40fZRlgL5Vtob7s9O6fZmfgM7ah24r9L5mrbP2qmNVIIi /Px1lHCXhMeZTZ4TvY47E3QEmemlbfUFKMPHG6EfJqqphAtUE3g5N1Hf17kHGQPWMVkN YBnYUPN+sRtBX4L8fwTUtvEtgqyTZ9xZke4Y4ggO3gR997pK+d88QnMir4B4iYgmdZem uUjONiNpqZN2pqyGqPPAF9gFK2MVCpEl8VJyjO8vGssinQSN5LVb9agKd5zK88c2AAeG BNUAsLvbchU09caVD2CxGSoWhtIdaurtdQYqNQnKlK/qGYPa+3tV29NTnk5uQqSktUro IjVg== X-Received: by 10.236.44.102 with SMTP id m66mr5437150yhb.89.1388462592317; Mon, 30 Dec 2013 20:03:12 -0800 (PST) Received: from ?IPv6:2600:1013:b01b:979b:b848:f680:19c2:b4ce? ([2600:1013:b01b:979b:b848:f680:19c2:b4ce]) by mx.google.com with ESMTPSA id h66sm64555321yhb.7.2013.12.30.20.03.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 30 Dec 2013 20:03:11 -0800 (PST) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B350) From: Oleg Moskalenko Subject: Re: Question about the "connected" UDP sockets Date: Mon, 30 Dec 2013 20:03:08 -0800 To: Sepherosa Ziehau Cc: FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 31 Dec 2013 04:03:13 -0000 Thanks a lot ! Oleg Sent from my iPhone On Dec 30, 2013, at 7:38 PM, Sepherosa Ziehau wrote: > On Fri, Dec 27, 2013 at 1:49 AM, Oleg Moskalenko wro= te: >> Hi >>=20 >> I cannot find the information about the implementation details of the >> "connected" UDP sockets in FreeBSD. I know that in older Linux kernels al= l >=20 >=20 > You could start from sys/netinet/udp_usrreq.c:udp_connect(). >=20 >=20 >> UDP sockets are stored in a hash table - and the remote IP:port are not >> used for the hash calculation, so the performance is awful when you have >> thousands "connected" UDP sockets on the same local IP:port address. So a= >> UDP packet incoming to the local address has to go through the long list o= f >> sockets to find the proper destination. >>=20 >> How it is done in the FreeBSD ? Are the UDP "connected" sockets using a >> hash table with key based upon 5-tuple (protocol, remote-ip, remote-port,= >> local-ip, local-port} ? >=20 >=20 > UDP uses its own hash table for "connected" sockets (inpcb actually). > The "connected" inpcbs are hashed using lport/fport/laddr/faddr > (4-tuple). >=20 > Best Regards, > sephe From owner-freebsd-net@FreeBSD.ORG Tue Dec 31 05:34: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]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7028E32F for ; Tue, 31 Dec 2013 05:34:41 +0000 (UTC) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 348FD12E3 for ; Tue, 31 Dec 2013 05:34:41 +0000 (UTC) Received: by mail-qc0-f179.google.com with SMTP id i8so11490645qcq.38 for ; Mon, 30 Dec 2013 21:34:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=DwiVTL4FEBjETbl+sODqesk7U/wLqNp62wIzBgPbqJQ=; b=DGHBbiA/qRZepvBsg/iRACBsSRpr+CfdjhA8Mrobx6H6NBagjx4TMfy3dq6l+OKBOw Qf+tE5dwPtqqoIIDUjxx9a3akEASTZi8hv5H/ZkChDNuD46hWAYZS7S5d/LE8OySMj7E R8mjmUuyrrDaUnA21X5VO8DoK2YVTAcDUntmJDzo4YVXytqGgs2fkyforNAi+9xxDUcH VRZ10gFVHRleZeBtj/uQBuukTWP/mr5ZV53JqSS9xuZtCpN3V4M7sJ8tpai/aTk1zU2V 7dwMoSH7VCcXUuZID+jsSsY6RAPwta9SW+4kh02wjSuUroEhauQEqZZLSLFxtN8OXRzi HNCw== MIME-Version: 1.0 X-Received: by 10.229.13.133 with SMTP id c5mr114074865qca.22.1388468080354; Mon, 30 Dec 2013 21:34:40 -0800 (PST) Received: by 10.96.143.226 with HTTP; Mon, 30 Dec 2013 21:34:40 -0800 (PST) Date: Tue, 31 Dec 2013 13:34:40 +0800 Message-ID: Subject: Does pfflowd come up in freeBSD10 From: Ge Jin To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 31 Dec 2013 05:34:41 -0000 Hi, all! I saw pfflowd-0.8 can compile in pfsense. But after my test on freeBSD10, the program seemed not work.Does someone use it under the freeBSD10 ? How could make the pfflowd work ? Thank you! There is the pfflowd-0.8 links: https://github.com/pfsense/pfsense-tools/tree/master/pfPorts/pfflowd-0.8 From owner-freebsd-net@FreeBSD.ORG Tue Dec 31 07:35:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7E5B0CD6 for ; Tue, 31 Dec 2013 07:35:38 +0000 (UTC) Received: from mail-qa0-x230.google.com (mail-qa0-x230.google.com [IPv6:2607:f8b0:400d:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 401811A32 for ; Tue, 31 Dec 2013 07:35:38 +0000 (UTC) Received: by mail-qa0-f48.google.com with SMTP id w5so11493390qac.14 for ; Mon, 30 Dec 2013 23:35:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=1c5dJAbDe1r9gnMm2/fZvbSvu/N3QR4Ry4SbwKlneIA=; b=oEk+izeuGP6E44wKd3NjstQf8hZDpOQkYTq98RtOz9cKI8xoWUxaaam2mV2mBXqZoz s3wKdcJ93tIOA+9SR57I265kGRRYZa8DOnY7UXBkQTHP2jb9WIhkrWYIfCl+NGVVqx1d SFha9TXbn4eCj25fan0euVwIp0qhnBiLD1Z7Tz6Ob0MoKgmplRQOFxQKiPmZREAc7eST lKNBBQuhuVvjmLbapGKnvdmS66nCk3M2lUl3VcjeyOei5mYRk1X1XFhTamGlq6if45EC ZRvhJRVMRcUN/t94q5aeeQNJL1OLp536bqiR/LsUbsrk/AAEZ64fDvG861rEItSpmKhK 33hQ== MIME-Version: 1.0 X-Received: by 10.224.14.132 with SMTP id g4mr10476226qaa.26.1388475337244; Mon, 30 Dec 2013 23:35:37 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Mon, 30 Dec 2013 23:35:37 -0800 (PST) Date: Mon, 30 Dec 2013 23:35:37 -0800 X-Google-Sender-Auth: 9i4BXUDaZMCSQdV-m7zYdC9zUVE Message-ID: Subject: ipv6 lock contention with parallel socket io From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 31 Dec 2013 07:35:38 -0000 Hi, I've noticed a bunch of lock contention occurs when doing highly parallel (> 4096 sockets) TCP IPv6 traffic. The contention is here: root@c001-freebsd11:/home/adrian/git/github/erikarn/libiapp # sysctl debug.lock.prof.stats | head -2 ; sysctl debug.lock.prof.stats | sort -nk4 | tail -10 debug.lock.prof.stats: max wait_max total wait_total count avg wait_avg cnt_hold cnt_lock name 507 1349 116285 233979 617482 0 0 0 11927 /usr/home/adrian/work/freebsd/head/src/sys/netinet/tcp_hostcache.c:291 (sleep mutex:tcp_hc_entry) 499 995 122943 479346 617480 0 0 0 104210 /usr/home/adrian/work/freebsd/head/src/sys/netinet6/in6_src.c:885 (sleep mutex:rtentry) 515 202 493751 581039 617481 0 0 0 12779 /usr/home/adrian/work/freebsd/head/src/sys/netinet6/in6.c:2376 (rw:lle) 1872 2020 1542355 1529313 617481 2 2 0 97308 /usr/home/adrian/work/freebsd/head/src/sys/netinet6/nd6.c:2229 (rw:if_afdata) 494 1066 141964 1892922 617481 0 3 0 503429 /usr/home/adrian/work/freebsd/head/src/sys/net/flowtable.c:1251 (sleep mutex:rtentry) 388 1121 161966 2152377 617482 0 3 0 397770 /usr/home/adrian/work/freebsd/head/src/sys/netinet/tcp_output.c:1198 (sleep mutex:rtentry) 7 849 603349 2431982 499778 1 4 0 279708 /usr/home/adrian/work/freebsd/head/src/sys/kern/subr_turnstile.c:551 (spin mutex:turnstile chain) 539 1171 844350 5776354 1852441 0 3 0 1254017 /usr/home/adrian/work/freebsd/head/src/sys/net/route.c:380 (sleep mutex:rtentry) 203 2849 851312 7862530 617481 1 12 0 139389 /usr/home/adrian/work/freebsd/head/src/sys/netinet6/nd6.c:1894 (rw:if_afdata) 36 2401 363853 18179236 508578 0 35 0 125063 /usr/home/adrian/work/freebsd/head/src/sys/netinet6/ip6_input.c:701 (rw:if_afdata) root@c001-freebsd11:/home/adrian/git/github/erikarn/libiapp # .. it's the IF_ADATA lock surrounding the lla_lookup() calls. Now: * is there any reason this isn't an rmlock? * the instance early on in nd6_output_lle() isn't taking the read lock, it's taking the full lock. Is there any reason for this? I don't have much experience or time to spend on optimising the ipv6 code to scale better but this seems like one of those things that'll bite us in the ass as the amount of ipv6 deployed increases. Does anyone have any ideas/suggestions on how we could improve things? Thanks, -a From owner-freebsd-net@FreeBSD.ORG Tue Dec 31 17:53:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6449292 for ; Tue, 31 Dec 2013 17:53:26 +0000 (UTC) Received: from mail-qc0-x230.google.com (mail-qc0-x230.google.com [IPv6:2607:f8b0:400d:c01::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 95B9213AB for ; Tue, 31 Dec 2013 17:53:26 +0000 (UTC) Received: by mail-qc0-f176.google.com with SMTP id i8so12123119qcq.7 for ; Tue, 31 Dec 2013 09:53:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=EW5T+EWu3en0CMwcHaCMHlRZvsGLM70RvbOxHDvvsYE=; b=yGKKbjVdE9GWqrpvmyi6opESJWIMJg8kSpQn8cQD44pJ4jO/jMf/C/Vg5lGp5N4cFk ImixALfEDUwUdGVpM3gbnTo20G2ELgiwQ2mT3y+EalW+yiYms3YcUJv8DlfiRzQi6NuQ cmJct7TtaX+BiCNpgjlriicRpArj3Cz/vPWqNWoDTV5VadO0sedSJpsSV6hKPbNhWQ+I t8n6qb9udSAb2tiR8hr966kuXLApxVHya3mtDJ7nFiE3p1276sMJTiwGepgaiobDtGcA Q2056jISXUFcyBwgD98F05fStZv+WjCV10WaN048DOmtIcMiaucYbJd4IiHHXRNW5mEf nfNQ== MIME-Version: 1.0 X-Received: by 10.224.14.132 with SMTP id g4mr14868094qaa.26.1388512405703; Tue, 31 Dec 2013 09:53:25 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.224.52.8 with HTTP; Tue, 31 Dec 2013 09:53:25 -0800 (PST) In-Reply-To: References: Date: Tue, 31 Dec 2013 09:53:25 -0800 X-Google-Sender-Auth: Tn-ta3GzaBj91UsxaO7yFoKtUFc Message-ID: Subject: Re: ipv6 lock contention with parallel socket io From: Adrian Chadd To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.17 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, 31 Dec 2013 17:53:26 -0000 On 30 December 2013 23:35, Adrian Chadd wrote: > Hi, > > I've noticed a bunch of lock contention occurs when doing highly > parallel (> 4096 sockets) TCP IPv6 traffic. > > The contention is here: > [snip] > > .. it's the IF_ADATA lock surrounding the lla_lookup() calls. > > Now: > > * is there any reason this isn't an rmlock? > * the instance early on in nd6_output_lle() isn't taking the read > lock, it's taking the full lock. Is there any reason for this? > > I don't have much experience or time to spend on optimising the ipv6 > code to scale better but this seems like one of those things that'll > bite us in the ass as the amount of ipv6 deployed increases. > > Does anyone have any ideas/suggestions on how we could improve things? This improves things quite a bit - from 1.9gbyte/sec @ 100% cpu usage to 2.7gbyte/sec @ 85% CPU usage. It's not perfect - the lock contention is still there - but it's much less of an issue now. Are there any issues with it? Index: sys/netinet6/nd6.c =================================================================== --- sys/netinet6/nd6.c (revision 259475) +++ sys/netinet6/nd6.c (working copy) @@ -1891,9 +1891,9 @@ flags = ((m != NULL) || (lle != NULL)) ? LLE_EXCLUSIVE : 0; if (ln == NULL) { retry: - IF_AFDATA_LOCK(ifp); + IF_AFDATA_RLOCK(ifp); ln = lla_lookup(LLTABLE6(ifp), flags, (struct sockaddr *)dst); - IF_AFDATA_UNLOCK(ifp); + IF_AFDATA_RUNLOCK(ifp); if ((ln == NULL) && nd6_is_addr_neighbor(dst, ifp)) { /* * Since nd6_is_addr_neighbor() internally calls nd6_lookup(), Thanks, -a