From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 10:32:00 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90683202 for ; Tue, 1 Jan 2013 10:32:00 +0000 (UTC) (envelope-from oleg.moskalenko@citrix.com) Received: from SMTP02.CITRIX.COM (smtp02.citrix.com [66.165.176.63]) by mx1.freebsd.org (Postfix) with ESMTP id 4561A8FC0A for ; Tue, 1 Jan 2013 10:31:59 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,391,1355097600"; d="scan'208,217";a="2212458" Received: from sjcpmailmx02.citrite.net ([10.216.14.75]) by FTLPIPO02.CITRIX.COM with ESMTP/TLS/RC4-MD5; 01 Jan 2013 10:31:58 +0000 Received: from SJCPMAILBOX01.citrite.net ([10.216.4.72]) by SJCPMAILMX02.citrite.net ([10.216.14.75]) with mapi; Tue, 1 Jan 2013 02:31:57 -0800 From: Oleg Moskalenko To: "'freebsd-net@freebsd.org'" Date: Tue, 1 Jan 2013 02:31:56 -0800 Subject: Announcement: RFC5766 TURN Server / Media traffic gateway is available Thread-Topic: Announcement: RFC5766 TURN Server / Media traffic gateway is available Thread-Index: Ac3oCfrZfy5QtWWsQpGBudK96SbGKw== Message-ID: <031222CBCF33214AB2EB4ABA279428A3012CA8FA98ED@SJCPMAILBOX01.citrite.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 10:32:00 -0000 Hi All I created a public networking project that implements RFC 5766 (and RFC 538= 9 and RFC 6156). This is a NAT traversal solution for (mostly) UDP traffic.= It can be used also as a Media traffic gateway. Initially the code was developed for a corporate project. I obtained a lega= l permission to convert it to the public project. It has BSD license, and I= use FreeBSD as the primary development platform. But the project compiles = and runs well on Linux and Solaris, too. I have not tested it on MacOS, yet= . The project reached its initial goals (full implementation of aforementione= d RFCs) and it is well tested: http://code.google.com/p/rfc5766-turn-server/ I am working on FreeBSD port to include it into the net/ ports, if that wil= l be useful for FreeBSD community. Thanks Oleg Moskalenko From owner-freebsd-net@FreeBSD.ORG Tue Jan 1 21:24:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A869FC14 for ; Tue, 1 Jan 2013 21:24:58 +0000 (UTC) (envelope-from os@bossbox.com) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by mx1.freebsd.org (Postfix) with ESMTP id 3161E8FC08 for ; Tue, 1 Jan 2013 21:24:57 +0000 (UTC) Received: by mail-wg0-f41.google.com with SMTP id ds1so5676387wgb.2 for ; Tue, 01 Jan 2013 13:24:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=lXt9c+hr5w39WtTWx9fBRQDxQseb/g0Rv8OUUbMNfu8=; b=JPGfQSXlr28L3RC3gXtHpkKpJbTanYdL/X2hmQkq5KP4iBoeCy4W2JxFquqvmo7+of 9bRh1K8vcWtj9UXLSEoJQTexRuv2kBGyPcdukRu0bvu1+f2PuTt2kmUUILlmMtKvSYzP hoKwVSu30bKmse1NcmmRmruZvHK5vjSas2JFZdlJ0Eu1w+VSr2/hOW497ELO+MB2JMst k2WSoUU3L4gtN5h+KWUn1EwjSryKBUrXdkGPHasLe1lfAIKpAXHXYozoZHIEf30Ohsqk 4dZY5ynXgUDwARZQzZgDU0HH/CAi+xHlrWVyUy+CQKCgQEtJCJ6llKy0oY3wMhGdlEyn nHrw== MIME-Version: 1.0 Received: by 10.194.177.199 with SMTP id cs7mr70013596wjc.41.1357075497043; Tue, 01 Jan 2013 13:24:57 -0800 (PST) Received: by 10.216.114.67 with HTTP; Tue, 1 Jan 2013 13:24:56 -0800 (PST) Date: Tue, 1 Jan 2013 21:24:56 +0000 Message-ID: Subject: Slow uplink speeds across WAN/VPN link From: "Brian O'Regan" To: freebsd-net@freebsd.org X-Gm-Message-State: ALoCoQnOTvav0SfavKO7JN/9xZOmTe0IcGW2uP1H+GjgxEkiamlvUfM34P5fWD95tHKLNLqJ+zo/ Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jan 2013 21:24:58 -0000 Hopefully I've chosen the correct mailing list. I have users who are uploading over WAN/VPN link to FreeBSD file servers and speed averages 1.9Mbits. To non FreeBSD servers we would see speeds of aprox 5-6Mbits. Previously in a similar situation over a WAN link with no VPN I have used net.inet.tcp.inflight.enable to greatly increase the speed. I was wondering if there is something similar to the above sysctl that's more specific to WAN where the traffic is crossing a VPN? Or if anyone has any other suggestions to tweak? Currently FreeBSD 7.4 is been used and we're not currently in a position to upgrade. Kind Regards, Brian Hughes From owner-freebsd-net@FreeBSD.ORG Wed Jan 2 02:07:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F9E390D; Wed, 2 Jan 2013 02:07:10 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f43.google.com (mail-pb0-f43.google.com [209.85.160.43]) by mx1.freebsd.org (Postfix) with ESMTP id BFC818FC08; Wed, 2 Jan 2013 02:07:09 +0000 (UTC) Received: by mail-pb0-f43.google.com with SMTP id um15so7604407pbc.16 for ; Tue, 01 Jan 2013 18:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=PuCDbh8Rhcc40EzjAk1OwmuZ8rrB5MUiC2+mIyK1rFc=; b=fQQrzYv+kdx1C9fgWxVOPzu1k5HABMzXrThoPDBDWWenIOc9QKTiGxB9Z/ETyWkcLN Tuu+MyYGWI0nYt/quIGMvl8QJTxqYsB9B0xzwHoN8ty4CjOVS+ohWDXr5q0qnsoSgn88 GS4r/sWaUDX7+BxugKvtx8hZoxHVdA0jZ7Tbzc2Rlohc+FBBP2zvqa+PG8gzbOfn6ar+ mKhTjeYozffG18eqplvP2ruvWfDepN5RjvsKXIttJf9gwZzPC3VG2fq4kwSCQ7aJFJGc 75L6OQJNd/Foyg2SWumumWZfnarf/NuZ3asxXzmRk4EipUPyygMU30qwHY7byokdycNO 5bLw== X-Received: by 10.66.88.129 with SMTP id bg1mr132951318pab.71.1357092423775; Tue, 01 Jan 2013 18:07:03 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id vk5sm27496379pbc.34.2013.01.01.18.07.00 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 01 Jan 2013 18:07:02 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Wed, 02 Jan 2013 11:06:55 +0900 From: YongHyeon PYUN Date: Wed, 2 Jan 2013 11:06:55 +0900 To: Barney Cordoba Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver Message-ID: <20130102020655.GB6382@michelle.cdnetworks.com> References: <1356995087.59212.YahooMailClassic@web121604.mail.ne1.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1356995087.59212.YahooMailClassic@web121604.mail.ne1.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: Garrett Cooper , freebsd-net@freebsd.org, Adrian Chadd , David Christensen , linimon@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 02:07:10 -0000 On Mon, Dec 31, 2012 at 03:04:47PM -0800, Barney Cordoba wrote: > > > --- On Mon, 12/31/12, Adrian Chadd wrote: > > > From: Adrian Chadd > > Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver > > To: "Garrett Cooper" > > Cc: "Barney Cordoba" , "David Christensen" , linimon@freebsd.org, freebsd-net@freebsd.org > > Date: Monday, December 31, 2012, 2:00 PM > > On 31 December 2012 07:58, Garrett > > Cooper > > wrote: > > > > > I would ask David about whether or not there was a > > performance > > > difference because they might have some numbers for > > if_bxe. > > > > > > Not sure about the concept in general, but it seems > > like a reasonable > > > application protocol specific request. But by and > > large, I agree that > > > UDP checksumming doesn't make logical sense because it > > adds > > > unnecessary overhead on a L3 protocol that's assumed to > > be unreliable. > > > > People are terminating millions of VoIP calls on FreeBSD > > devices. All using UDP. > > > > I can imagine large scale VoIP gateways wanting to try and > > benefit from this. > > > > The statement above "assumes" that there is a benefit. voIP packets > are short, so the benefit of offloading is reduced. There is some > delay added by the hardware, and there are cpu cycles used in managing > the offload code. So those operations not only muddy the code, > but they may not be faster than simply doing the checksum on a much, much > faster cpu. I'm under the impression that recent Intel controllers tend to add more burden for driver to setup checksum offloading context. In addition, some controllers have DMA restrictions to make checksum offloading works such that it may add additional overhead unless its DMA engine supports multiple outstanding reads. As you said, checksum offloading may not make it faster but saved CPU cycles for checksum offloading could be used for other system activities. You can disable checksum offloading any time when you find it's not good for specific load. From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 03:27:03 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B848DB31; Thu, 3 Jan 2013 03:27:03 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id 8D7051A8; Thu, 3 Jan 2013 03:27:00 +0000 (UTC) Received: from glorfindel.gritton.org (c-174-52-130-157.hsd1.ut.comcast.net [174.52.130.157]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r033Epe3091804; Wed, 2 Jan 2013 20:14:51 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <50E4F7A9.4070900@FreeBSD.org> Date: Wed, 02 Jan 2013 20:14:49 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.24) Gecko/20120129 Thunderbird/3.1.16 MIME-Version: 1.0 To: FreeBSD-Jail , freebsd-net@FreeBSD.org Subject: kern/68189 and kern/169751: what jails are allowed to see in a routing socket Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Thiel , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 03:27:03 -0000 I've been looking at PR kern/169751, which was noting that routing sockets don't work inside a jail. It made the point that setting security.jail.socket_unixiproute_only or security.jail.allow_raw_sockets didn't help things. It would seem kind of a given from the "unixiproute" name that a route socket ought to work. And indeed, such a socket is permitted to be created in such a jail. It's just using it that doesn't work. I narrowed this failure down to line 816 of sys/net/rtsock.c, which explicitly denies jails from reading routes, regardless of the setting of the above two sysctls (or the jail allow.* bits they work with). And that bit of code came about in response to PR kern/68189, which noted that jails could see interfaces that aren't theirs (i.e. their address doesn't live on it). So we have two PRs that are kind of at cross purposes. It would be nice to keep hiding non-jail interfaces from a jail, but it would also be nice to let a jailed process know the route to somewhere - at least sometimes. One solution would be to add a much finer layer of control to the jail test in rtsock.c, looking at interfaces and seeing if they're somehow connected with one of the jail's IP addresses. But that just seems like a lot of messy corner-case code. Another way around this, and what I'd like to go with if there are no objections, is to allow the route sockets to be used by jails that have raw_sockets permission. I know that's kind of a semantic leap, but it seems that a jail that has the power of using raw sockets would be able to do pretty much as it pleases with routes anyway if it tried hard enough. Also, it would be consistent to allow such operations on jails that aren't IP-restricted, or in VIMAGE jails. - Jamie From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 09:36:09 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E6AC72BF; Thu, 3 Jan 2013 09:36:09 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 790F3A03; Thu, 3 Jan 2013 09:36:09 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id CCF8C25D39FD; Thu, 3 Jan 2013 09:36:07 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id E28D9BE849B; Thu, 3 Jan 2013 09:36:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id UyQXKKm90s5O; Thu, 3 Jan 2013 09:36:05 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id E67B2BE846B; Thu, 3 Jan 2013 09:36:01 +0000 (UTC) Date: Thu, 3 Jan 2013 09:36:01 +0000 (UTC) From: "Bjoern A. Zeeb" To: Jamie Gritton Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket In-Reply-To: <50E4F7A9.4070900@FreeBSD.org> Message-ID: References: <50E4F7A9.4070900@FreeBSD.org> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: David Thiel , freebsd-net@FreeBSD.org, FreeBSD-Jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 09:36:10 -0000 On Wed, 2 Jan 2013, Jamie Gritton wrote: > I've been looking at PR kern/169751, which was noting that routing sockets > don't work inside a jail. It made the point that setting > security.jail.socket_unixiproute_only or security.jail.allow_raw_sockets > didn't help things. It would seem kind of a given from the "unixiproute" > name that a route socket ought to work. And indeed, such a socket is > permitted to be created in such a jail. It's just using it that doesn't > work. > > I narrowed this failure down to line 816 of sys/net/rtsock.c, which > explicitly denies jails from reading routes, regardless of the setting of the > above two sysctls (or the jail allow.* bits they work with). And that bit of > code came about in response to PR kern/68189, which noted that jails could > see interfaces that aren't theirs (i.e. their address doesn't live on it). > > So we have two PRs that are kind of at cross purposes. It would be nice to > keep hiding non-jail interfaces from a jail, but it would also be nice to let jails have no notion of interfaces, only addresses, so by defintiion there cannot be "non-jail interfaces". > a jailed process know the route to somewhere - at least sometimes. One > solution would be to add a much finer layer of control to the jail test in > rtsock.c, looking at interfaces and seeing if they're somehow connected with > one of the jail's IP addresses. But that just seems like a lot of messy > corner-case code. > > Another way around this, and what I'd like to go with if there are no > objections, is to allow the route sockets to be used by jails that have > raw_sockets permission. I know that's kind of a semantic leap, but it seems > that a jail that has the power of using raw sockets would be able to do > pretty much as it pleases with routes anyway if it tried hard enough. Also, > it would be consistent to allow such operations on jails that aren't > IP-restricted, or in VIMAGE jails. I have not further looked at the code but the answer is that we should not further complicate jails after 14 years when we have a perfect good solution for the problem; vnets are there for exactly this. Someone with enough interest and time should just finish things (tm) ;-) Meanwhile your suggestion might be ok given simple enough, but I wonder if a different flag would be helpful still. I would not be able to "trust" (the little that is possible anyway) raw_sockets anymore if they suddently could fiddle with the routing table - even read-only, should that really be enough. I would explicitly advertise it as 'do not use - will go away again' feature and it should the moment vnets are declared non-experimental. Just my 2cts. /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 17:48:32 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E984E905; Thu, 3 Jan 2013 17:48:31 +0000 (UTC) (envelope-from jamie@FreeBSD.org) Received: from m2.gritton.org (gritton.org [199.192.164.235]) by mx1.freebsd.org (Postfix) with ESMTP id BAEE37BE; Thu, 3 Jan 2013 17:48:31 +0000 (UTC) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by m2.gritton.org (8.14.5/8.14.5) with ESMTP id r03HmTrH003893; Thu, 3 Jan 2013 10:48:29 -0700 (MST) (envelope-from jamie@FreeBSD.org) Message-ID: <50E5C468.7080700@FreeBSD.org> Date: Thu, 03 Jan 2013 10:48:24 -0700 From: Jamie Gritton User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120126 Thunderbird/9.0 MIME-Version: 1.0 To: FreeBSD-Jail , freebsd-net@FreeBSD.org Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket References: <50E4F7A9.4070900@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Thiel , "Bjoern A. Zeeb" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:48:32 -0000 On 01/03/13 02:36, Bjoern A. Zeeb wrote: > On Wed, 2 Jan 2013, Jamie Gritton wrote: > >> I've been looking at PR kern/169751, which was noting that routing >> sockets don't work inside a jail. It made the point that setting >> security.jail.socket_unixiproute_only or >> security.jail.allow_raw_sockets didn't help things. It would seem kind >> of a given from the "unixiproute" name that a route socket ought to >> work. And indeed, such a socket is permitted to be created in such a >> jail. It's just using it that doesn't work. >> >> I narrowed this failure down to line 816 of sys/net/rtsock.c, which >> explicitly denies jails from reading routes, regardless of the setting >> of the above two sysctls (or the jail allow.* bits they work with). >> And that bit of code came about in response to PR kern/68189, which >> noted that jails could see interfaces that aren't theirs (i.e. their >> address doesn't live on it). >> >> So we have two PRs that are kind of at cross purposes. It would be >> nice to keep hiding non-jail interfaces from a jail, but it would also >> be nice to let > > jails have no notion of interfaces, only addresses, so by defintiion > there cannot be "non-jail interfaces". Technically yes. But jails do have IP addresses that are tied to interfaces. Still, there's too much of a morass that direction. >> a jailed process know the route to somewhere - at least sometimes. One >> solution would be to add a much finer layer of control to the jail >> test in rtsock.c, looking at interfaces and seeing if they're somehow >> connected with one of the jail's IP addresses. But that just seems >> like a lot of messy corner-case code. >> >> Another way around this, and what I'd like to go with if there are no >> objections, is to allow the route sockets to be used by jails that >> have raw_sockets permission. I know that's kind of a semantic leap, >> but it seems that a jail that has the power of using raw sockets would >> be able to do pretty much as it pleases with routes anyway if it tried >> hard enough. Also, it would be consistent to allow such operations on >> jails that aren't IP-restricted, or in VIMAGE jails. > > I have not further looked at the code but the answer is that we should > not further complicate jails after 14 years when we have a perfect > good solution for the problem; vnets are there for exactly this. > Someone with enough interest and time should just finish things (tm) ;-) I would at least want to open all network things up to jails that have no network restrictions, because they aren't really "jails in the network sense." > Meanwhile your suggestion might be ok given simple enough, but I wonder > if a different flag would be helpful still. I would not be able to > "trust" (the little that is possible anyway) raw_sockets anymore if they > suddently could fiddle with the routing table - even read-only, should > that really be enough. > I would explicitly advertise it as 'do not use - will go away again' > feature and it should the moment vnets are declared non-experimental. > > Just my 2cts. > > /bz Well I'd rather not introduce something as a stopgap. Either this is worth doing or it isn't. It does make sense to at least make sure it works with VNET. - Jamie From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 17:52:08 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2408FC16; Thu, 3 Jan 2013 17:52:08 +0000 (UTC) (envelope-from ike@blackskyresearch.net) Received: from rs139.luxsci.com (rs139.luxsci.com [72.32.23.91]) by mx1.freebsd.org (Postfix) with ESMTP id DFEC8801; Thu, 3 Jan 2013 17:52:07 +0000 (UTC) Received: from rs139.luxsci.com (localhost.localdomain [127.0.0.1]) by rs139.luxsci.com (8.13.8/8.13.8) with ESMTP id r03Hk6fR030241; Thu, 3 Jan 2013 11:46:07 -0600 Received: (from root@localhost) by rs139.luxsci.com (8.13.8/8.13.8/Submit) id r03Hk5RB030164; Thu, 3 Jan 2013 17:46:05 GMT Received: (from sender 74627) (rs139.luxsci.com [127.0.0.1]) by LuxSci SP; Thu, 03 Jan 2013 17:46:02 +0000 Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket Content-Type: text/plain; charset=us-ascii From: "Isaac (.ike) Levy" In-Reply-To: Date: Thu, 3 Jan 2013 12:45:41 -0500 Content-Transfer-Encoding: quoted-printable References: <50E4F7A9.4070900@FreeBSD.org> To: "Bjoern A. Zeeb" , Jamie Gritton X-Lux-Comment: Message r03HjfLa029309 sent by user #74627 Message-Id: <1357235165-2012934.06566733.fr03HjfLa029309@rs139.luxsci.com> X-Comment: LuxSci SP Message ID - 1357235165-2012934.06566733 Cc: David Thiel , freebsd-net@freebsd.org, FreeBSD-Jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 17:52:08 -0000 Hi Jamie, All, On Jan 3, 2013, at 4:36 AM, Bjoern A. Zeeb wrote: > On Wed, 2 Jan 2013, Jamie Gritton wrote: >=20 >> I've been looking at PR kern/169751, which was noting that routing = sockets don't work inside a jail. It made the point that setting = security.jail.socket_unixiproute_only or security.jail.allow_raw_sockets = didn't help things. It would seem kind of a given from the = "unixiproute" name that a route socket ought to work. And indeed, such = a socket is permitted to be created in such a jail. It's just using it = that doesn't work. >>=20 >> I narrowed this failure down to line 816 of sys/net/rtsock.c, which = explicitly denies jails from reading routes, regardless of the setting = of the above two sysctls (or the jail allow.* bits they work with). And = that bit of code came about in response to PR kern/68189, which noted = that jails could see interfaces that aren't theirs (i.e. their address = doesn't live on it). >>=20 >> So we have two PRs that are kind of at cross purposes. It would be = nice to keep hiding non-jail interfaces from a jail, but it would also = be nice to let >=20 > jails have no notion of interfaces, only addresses, so by defintiion > there cannot be "non-jail interfaces". >=20 >=20 >> a jailed process know the route to somewhere - at least sometimes. = One solution would be to add a much finer layer of control to the jail = test in rtsock.c, looking at interfaces and seeing if they're somehow = connected with one of the jail's IP addresses. But that just seems like = a lot of messy corner-case code. >>=20 >> Another way around this, and what I'd like to go with if there are no = objections, I humbly object. >> is to allow the route sockets to be used by jails that have = raw_sockets permission. I know that's kind of a semantic leap, but it = seems that a jail that has the power of using raw sockets would be able = to do pretty much as it pleases with routes anyway if it tried hard = enough. Also, it would be consistent to allow such operations on jails = that aren't IP-restricted, or in VIMAGE jails. >=20 > I have not further looked at the code but the answer is that we should > not further complicate jails after 14 years when we have a perfect > good solution for the problem; vnets are there for exactly this. > Someone with enough interest and time should just finish things (tm) = ;-) >=20 > Meanwhile your suggestion might be ok given simple enough, but I = wonder > if a different flag would be helpful still. I would not be able to > "trust" (the little that is possible anyway) raw_sockets anymore if = they > suddently could fiddle with the routing table - even read-only, should > that really be enough. > I would explicitly advertise it as 'do not use - will go away again' > feature and it should the moment vnets are declared non-experimental. >=20 > Just my 2cts. >=20 > /bz I'm going to enthusiastically agree with Bjoern here, especially when = vnets exist. I see your point, and your need, but this kind of virtual server centric = approach is better applied, full-bore, to other server virtualization = models, where interfaces actually exist, (in the form of abstracted = hardware). I believe allowing this sort of abstraction is precisely the kind of = fundamentals-bending which has led other virtual server implementations = to the bone pile- jail(2) is securable and useful explicitly because it = is fundamentally designed to contain resources, not emulate them. Best, .ike From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 20:00:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12A7AF3E for ; Thu, 3 Jan 2013 20:00:33 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by mx1.freebsd.org (Postfix) with ESMTP id A8845F3E for ; Thu, 3 Jan 2013 20:00:32 +0000 (UTC) Received: by mail-ee0-f46.google.com with SMTP id e53so7850301eek.33 for ; Thu, 03 Jan 2013 12:00:31 -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=DrNd9EgSd4BNP8RWobaICo1zRdDOFQFf/93SBmd79b8=; b=l6elHVO1alN2n70/aoB0Y/OJmv3vUUThu/jYkMfSzgWsrKVvexBx/ZZAAkhix8G45f rXUfFB92RNXiBwILpodeJG9JMB00U8Nnq6KTwd3GR/2Iega2MZAyrHISmAvwJiXYzSdS Fz4BsJ5h0a7vIorW86hXcWDG5vKHNEKrRYUkb9sAF6tBQVI2UVhL6EACeR1/HtCpIB2Y TK4GhTt4w5oIbGXE8sr4DlSBV6CJMLEIcOwyfN5Iy9YPutM2y9yEtgoVu9HKt3pmOUNM A8JlwFTWh9GiHNkeFJTaLoV3T9E+chwCVm7LYjb3Xfxufik8Y4K6lzP5wpDPk7tGdMgl HtCw== MIME-Version: 1.0 Received: by 10.14.2.196 with SMTP id 44mr136659613eef.25.1357243231559; Thu, 03 Jan 2013 12:00:31 -0800 (PST) Received: by 10.14.221.135 with HTTP; Thu, 3 Jan 2013 12:00:31 -0800 (PST) Date: Thu, 3 Jan 2013 12:00:31 -0800 Message-ID: Subject: arpwatch questions appropriate here? From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 20:00:33 -0000 All, It's been a while since I tried arpwatch on FreeBSD, and it looks as if it still has some important limitations. Most important to me, it doesn't seem to like to run on an unnumbered interface - I'd like to use it to listen on a mirror port on my switch(es), and can't see how to do that. Also, I don't see a facility for something like an arpwatch.conf file (in particular, I'd like to specify known networks, so I can watch for bogons), though I am able to specify arpwatch_enable and arpwatch_interfaces in rc.conf, which is nice. Has anyone here been able to work through these problems? If there's a better place I should be asking, please let me know. Thanks, Kurt From owner-freebsd-net@FreeBSD.ORG Thu Jan 3 21:23:56 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7B3092BD; Thu, 3 Jan 2013 21:23:56 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [IPv6:2607:f2f8:a9c4::2]) by mx1.freebsd.org (Postfix) with ESMTP id 654BB7AF; Thu, 3 Jan 2013 21:23:56 +0000 (UTC) Received: by redundancy.redundancy.org (Postfix, from userid 1001) id 76BD42FC36E; Thu, 3 Jan 2013 13:23:55 -0800 (PST) Date: Thu, 3 Jan 2013 13:23:55 -0800 From: David Thiel To: Jamie Gritton Subject: Re: kern/68189 and kern/169751: what jails are allowed to see in a routing socket Message-ID: <20130103212355.GA37196@redundancy.redundancy.org> References: <50E4F7A9.4070900@FreeBSD.org> <50E5C468.7080700@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50E5C468.7080700@FreeBSD.org> X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg X-Face: %H~{$1~NOw1y#%mM6{|4:/, FreeBSD-Jail X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2013 21:23:56 -0000 On Thu, Jan 03, 2013 at 10:48:24AM -0700, Jamie Gritton wrote: > On 01/03/13 02:36, Bjoern A. Zeeb wrote: > > Meanwhile your suggestion might be ok given simple enough, but I wonder > > if a different flag would be helpful still. I would not be able to > > "trust" (the little that is possible anyway) raw_sockets anymore if they > > suddently could fiddle with the routing table - even read-only, should > > that really be enough. > > I would explicitly advertise it as 'do not use - will go away again' > > feature and it should the moment vnets are declared non-experimental. > > Well I'd rather not introduce something as a stopgap. Either this is > worth doing or it isn't. It does make sense to at least make sure it > works with VNET. Hello all, Thanks for your consideration of the issue. I don't think it would necessarily have to be a stopgap - I think something like jail.socket_allow_readroute, default 0, wouldn't hurt anything and would definitely help some folks, as this issue has arisen for multiple people over the years. While I agree that vnets will be a great future solution, I think that the very existence of unixiproute_only is kind of problematic, as it implies that jails should be able to use routing sockets by default (read-only, presumably). If we don't want to allow that, should it at least be slated to rename/redocument this sysctl at some point in the future? Or is it intended that VNET totally replace old jail infrastructure, obviating the need for that sysctl at all? -David From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 05:13:31 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 82678FD3; Fri, 4 Jan 2013 05:13:31 +0000 (UTC) (envelope-from frank@exit.com) Received: from tinker.exit.com (unknown [IPv6:2001:470:f0fd:0:2e0:81ff:fe2b:acbc]) by mx1.freebsd.org (Postfix) with ESMTP id 3F4289E2; Fri, 4 Jan 2013 05:13:31 +0000 (UTC) Received: from jill.exit.com (jill.exit.com [IPv6:2001:470:f0fd:0:2e0:81ff:febc:fdcc]) by tinker.exit.com (8.14.5/8.14.5) with ESMTP id r045DS7g092181; Thu, 3 Jan 2013 21:13:29 -0800 (PST) (envelope-from frank@exit.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=exit.com; s=tinker; t=1357276409; bh=D690w6LcLw3Hptcz3jNfp5ZXUdcGa5Pmiuimtb3KRxc=; h=Subject:From:Reply-To:To:Cc:Date; b=K6dnTyOkEaygQb8fejsyqAkeRRnjKqu7ZTjqP9LIlgQwguM1vKF6jJtG0BIqn5dbf z4BtCXN/JfsILtSA8qGwsVLF9Iv+0d8vQY7lIDnwsooV6k3PUQMsAy8JnhI5vkSQuv FosYc/uBUTYCj3bwTEXmjx4ob/iyNpEv5bpc+87Q= Received: from jill.exit.com (localhost [127.0.0.1]) by jill.exit.com (8.14.5/8.14.5) with ESMTP id r045D6Ar050838; Thu, 3 Jan 2013 21:13:06 -0800 (PST) (envelope-from frank@exit.com) Received: (from frank@localhost) by jill.exit.com (8.14.5/8.14.5/Submit) id r045D67n050837; Thu, 3 Jan 2013 21:13:06 -0800 (PST) (envelope-from frank@exit.com) X-Authentication-Warning: jill.exit.com: frank set sender to frank@exit.com using -f Subject: [Fwd: Re: Firmware error with iwn on 9-stable.] From: Frank Mayhar To: bschmidt@freebsd.org Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Organization: Exit Consulting Date: Thu, 03 Jan 2013 21:13:06 -0800 Message-ID: <1357276386.13744.28.camel@jill.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Cc: FreeBSD-net , freebsd-wireless X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: frank@exit.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 05:13:31 -0000 Hi, Bernhard. I'm close to throwing in the towel on this card and getting an Atheros-based one or perhaps an older Intel. Before I do that, though, I wanted to run this by you. If you're interested in tracking this down and fixing it, I can certainly do testing for you. I've added details below; if there's anything else I can provide, please let me know. Thanks. -------- Forwarded Message -------- > From: Frank Mayhar > Reply-to: frank@exit.com > To: freebsd-mobile > Cc: freebsd-wireless@freebsd.org > Subject: Re: Firmware error with iwn on 9-stable. > Date: Tue, 01 Jan 2013 21:41:26 -0800 >=20 > On Tue, 2013-01-01 at 21:36 -0800, Frank Mayhar wrote: > > On Mon, 2012-12-31 at 23:49 -0800, Frank Mayhar wrote: > > > I'm trying to set up a new laptop, which has an Intel Centrino > > > Ultimate-N 6300 wireless card. I was under the impression that the > > > 9-stable iwn driver fully supported this card but I've run into a > > > problem. Specifically, I'm seeing this firmware crash: > > >=20 > > > iwn0: iwn_intr: fatal firmware error > >=20 > > For the record, this appears to be the problem referred to by > > "kern/163154: [iwn] fatal firmware error on 9.0-RC3." Apparently this > > still happens in 9-stable, with the same symptoms, fails with 802.11a > > but not with 11g. >=20 > Oops, spoke too soon. It fails the same way with 11g in my case. Here are the relevant bits from a verbose dmesg: iwn0: mem 0xf7600000-0xf7601fff irq 17 at device 0.0 on pci3 iwn0: attempting to allocate 1 MSI vectors (1 supported) iwn0: using IRQ 266 for MSI iwn0: MIMO 3T3R, MoW, address 24:77:03:dc:b3:4c iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 3T3R iwn0: 11na MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: MCS 8-15: 13Mbps - 130Mbps iwn0: MCS 16-23: 19.5Mbps - 195Mbps iwn0: 11na MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps iwn0: MCS 16-23: 21.5Mbps - 216.5Mbps iwn0: 11na MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: MCS 8-15: 27Mbps - 270Mbps iwn0: MCS 16-23: 40.5Mbps - 405Mbps iwn0: 11na MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: MCS 8-15: 30Mbps - 300Mbps iwn0: MCS 16-23: 45Mbps - 450Mbps iwn0: 11ng MCS 20MHz iwn0: MCS 0-7: 6.5Mbps - 65Mbps iwn0: MCS 8-15: 13Mbps - 130Mbps iwn0: MCS 16-23: 19.5Mbps - 195Mbps iwn0: 11ng MCS 20MHz SGI iwn0: MCS 0-7: 7Mbps - 72Mbps iwn0: MCS 8-15: 14.5Mbps - 144.5Mbps iwn0: MCS 16-23: 21.5Mbps - 216.5Mbps iwn0: 11ng MCS 40MHz: iwn0: MCS 0-7: 13.5Mbps - 135Mbps iwn0: MCS 8-15: 27Mbps - 270Mbps iwn0: MCS 16-23: 40.5Mbps - 405Mbps iwn0: 11ng MCS 40MHz SGI: iwn0: MCS 0-7: 15Mbps - 150Mbps iwn0: MCS 8-15: 30Mbps - 300Mbps iwn0: MCS 16-23: 45Mbps - 450Mbps And here's the firmware error: iwn0: iwn_intr: fatal firmware error firmware error log: error type =3D "SYSASSERT" (0x00000005) program counter =3D 0x00003C2C source line =3D 0x00000580 error data =3D 0x0000000100000000 branch link =3D 0x00003C2800003C28 interrupt link =3D 0x0000153200000000 time =3D 3781260668 driver status: tx ring 0: qid=3D0 cur=3D0 queued=3D0 =20 tx ring 1: qid=3D1 cur=3D0 queued=3D0 =20 tx ring 2: qid=3D2 cur=3D0 queued=3D0 =20 tx ring 3: qid=3D3 cur=3D2 queued=3D0 =20 tx ring 4: qid=3D4 cur=3D40 queued=3D0 =20 tx ring 5: qid=3D5 cur=3D0 queued=3D0 =20 tx ring 6: qid=3D6 cur=3D0 queued=3D0 =20 tx ring 7: qid=3D7 cur=3D0 queued=3D0 =20 tx ring 8: qid=3D8 cur=3D0 queued=3D0 =20 tx ring 9: qid=3D9 cur=3D0 queued=3D0 =20 tx ring 10: qid=3D10 cur=3D0 queued=3D0 =20 tx ring 11: qid=3D11 cur=3D0 queued=3D0 =20 tx ring 12: qid=3D12 cur=3D0 queued=3D0 =20 tx ring 13: qid=3D13 cur=3D0 queued=3D0 =20 tx ring 14: qid=3D14 cur=3D0 queued=3D0 =20 tx ring 15: qid=3D15 cur=3D0 queued=3D0 =20 tx ring 16: qid=3D16 cur=3D0 queued=3D0 =20 tx ring 17: qid=3D17 cur=3D0 queued=3D0 =20 tx ring 18: qid=3D18 cur=3D0 queued=3D0 =20 tx ring 19: qid=3D19 cur=3D0 queued=3D0 =20 rx ring: cur=3D63 --=20 Frank Mayhar frank@exit.com From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 10:15:41 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 79571409 for ; Fri, 4 Jan 2013 10:15:41 +0000 (UTC) (envelope-from ndenev@gmail.com) Received: from mail-ea0-f181.google.com (mail-ea0-f181.google.com [209.85.215.181]) by mx1.freebsd.org (Postfix) with ESMTP id 0D14DA0D for ; Fri, 4 Jan 2013 10:15:40 +0000 (UTC) Received: by mail-ea0-f181.google.com with SMTP id k14so6464216eaa.26 for ; Fri, 04 Jan 2013 02:15:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=oQaBCoXyN+QPMrgXsDH/1TfHnAaapU27Yz4bg6pEqng=; b=rIxUPEUG/DNKyDgX7THK/Jeb3G/Es/Pl0HqQ61UYPJy9ETevxeUCLSOeW3zJLevVbQ 1lD86XLEkdg5qjg3ZLn8hhsCcKTwHWfgY9xx4Ltil+h5NidbSaLE2ZgRKZEfPIEpUqT5 ykyMt+2C8eQlpAZYtgmCRlgGpmhl2OXLuOPJ1JdJhAK3SFeVWXhdqWNPHYGev/y61vQO Rltz69M/DhWpAwAWD7AsXxzBIaBoCEBTmt7pZ2VCRTNSAqMMYI56xVcuEYK9+roAHZFa JA0N46Ocs/EDtenrPjST2yOPWTwamUWaFDko4y60tBLu3Kp9+3gXyZ2rdyjvrRCOHAGT w2eQ== X-Received: by 10.14.225.4 with SMTP id y4mr140452945eep.6.1357294533694; Fri, 04 Jan 2013 02:15:33 -0800 (PST) Received: from ndenevsa.sf.moneybookers.net (g1.moneybookers.com. [217.18.249.148]) by mx.google.com with ESMTPS id w3sm109951003eel.17.2013.01.04.02.15.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 02:15:32 -0800 (PST) Subject: Re: kern/167947: [setfib] [patch] arpresolve checks only the default FIB for the interface route Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=us-ascii From: Nikolay Denev In-Reply-To: <201206120800.q5C80Shi056679@freefall.freebsd.org> Date: Fri, 4 Jan 2013 12:15:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3ABDDB0F-D982-44B1-B7F5-CE836FA0F760@gmail.com> References: <201206120800.q5C80Shi056679@freefall.freebsd.org> To: freebsd-net@FreeBSD.org X-Mailer: Apple Mail (2.1499) Cc: Rudolf Polzer X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 10:15:41 -0000 On Jun 12, 2012, at 11:00 AM, Rudolf Polzer wrote: > The following reply was made to PR kern/167947; it has been noted by = GNATS. >=20 > From: Rudolf Polzer > To: "bug-followup@FreeBSD.org" , = "ndenev@gmail.com" > > Cc: "christoph.weber-fahr@vodafone.com" = > Subject: Re: kern/167947: [setfib] [patch] arpresolve checks only the > default FIB for the interface route > Date: Tue, 12 Jun 2012 09:34:23 +0200 >=20 > Hi, >=20 > I had the problem too, and could confirm the fix. >=20 > FreeBSD ********.arcor.net 8.3-RELEASE-p2 FreeBSD 8.3-RELEASE-p2 #1: = Tue > Jun 12 09:06:31 CEST 2012 =3D20 > root@********.arcor.net:/usr/src/sys/amd64/compile/GENERICfib amd64 >=20 > However, the fix ONLY works if using ifconfig ... fib N to set the fib > for an interface, and not the FreeBSD 7.x method to assign the FIB via > ipfw rules. Just thought I should mention this - in our case, the > ifconfig way is the better choice anyway. >=20 > Best regards, >=20 > Rudolf Polzer=3D > _______________________________________________ > 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" Just a ping to see if someone from the network guys can take a look at = this :) P.S.: Yeah, the ipfw way should not work as it doesn't change the fib of = the interface. From owner-freebsd-net@FreeBSD.ORG Fri Jan 4 14:41:09 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 83D2B789; Fri, 4 Jan 2013 14:41:09 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from mail.digiware.nl (unknown [IPv6:2001:4cb8:90:ffff::3]) by mx1.freebsd.org (Postfix) with ESMTP id 47DCA702; Fri, 4 Jan 2013 14:41:08 +0000 (UTC) Received: from rack1.digiware.nl (localhost.digiware.nl [127.0.0.1]) by mail.digiware.nl (Postfix) with ESMTP id E75F3153434; Fri, 4 Jan 2013 15:41:07 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.nl Received: from mail.digiware.nl ([127.0.0.1]) by rack1.digiware.nl (rack1.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4-0uoQcfj9U; Fri, 4 Jan 2013 15:41:07 +0100 (CET) Received: from [127.0.0.1] (opteron [192.168.10.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.digiware.nl (Postfix) with ESMTPS id 591FF153433; Fri, 4 Jan 2013 15:41:07 +0100 (CET) Message-ID: <50E6EA0C.5080005@digiware.nl> Date: Fri, 04 Jan 2013 15:41:16 +0100 From: Willem Jan Withagen Organization: Digiware Management b.v. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Barney Cordoba Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver References: <1356995087.59212.YahooMailClassic@web121604.mail.ne1.yahoo.com> In-Reply-To: <1356995087.59212.YahooMailClassic@web121604.mail.ne1.yahoo.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 130103-1, 01/03/2013), Outbound message X-Antivirus-Status: Clean Cc: Garrett Cooper , freebsd-net@freebsd.org, Adrian Chadd , David Christensen , linimon@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 14:41:09 -0000 On 2013-01-01 0:04, Barney Cordoba wrote: > The statement above "assumes" that there is a benefit. voIP packets > are short, so the benefit of offloading is reduced. There is some > delay added by the hardware, and there are cpu cycles used in managing > the offload code. So those operations not only muddy the code, > but they may not be faster than simply doing the checksum on a much, much > faster cpu. Forgoing all the discussions on performance and possible penalties in drivers..... I think there is a large set of UDP streams (and growing) that do use larger packets. The video streaming we did used a size of header(14)+7*188, which is the max number of MPEG packet to fit into anything with an MTU < 1500. Receiving those on small embedded devices which can do HW check-summing is very beneficial there. On the large servers we would generate up to 5Gbit of outgoing streams. I'm sure that offloading UDP checks would be an advantage as well. (They did run mainly Linux, but FreeBSD would also work) Unfortunately most of the infrastructure has been taken down, so it is no longer possible to verify any of the assumptions. --WjW From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 15:17:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09E73A0 for ; Sat, 5 Jan 2013 15:17:18 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm13-vm1.bullet.mail.ne1.yahoo.com (nm13-vm1.bullet.mail.ne1.yahoo.com [98.138.91.62]) by mx1.freebsd.org (Postfix) with ESMTP id B3B43132 for ; Sat, 5 Jan 2013 15:17:17 +0000 (UTC) Received: from [98.138.90.53] by nm13.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2013 15:17:11 -0000 Received: from [98.138.89.171] by tm6.bullet.mail.ne1.yahoo.com with NNFMP; 05 Jan 2013 15:17:11 -0000 Received: from [127.0.0.1] by omp1027.mail.ne1.yahoo.com with NNFMP; 05 Jan 2013 15:17:10 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 994806.88279.bm@omp1027.mail.ne1.yahoo.com Received: (qmail 17569 invoked by uid 60001); 5 Jan 2013 15:17:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1357399030; bh=7mYSPBZoYdieWyEQ011sw0NRhi6z1gf9No2NXLisiaY=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=pBb1mIdNHhbDy7zWPpC28sEicjDTYk/K3UKdhvdoJuzUvFr2UejM+beO+akWFlklctYn2xUOQEMKLXcy1CLO+C7DAVyzSDY36ty9LEVFP3LWHzxRAO56RYXdmxYU0n/1BvfcZTMK5R+im6pzPEEF9IYSE8qXMVtHIs8EYElxSfM= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=tUQPzEKtOC1KF+3v4gvgLLNf40tb2CSAYVeUjD5JcFIV1Pmb9xl8Q0KPDdzMHwz4Sjx8pDHrs8X6peOFWDoz0InGSwI/a880AJZvkTXmYKF59NwgypqmXS5KACDrVwtbeviq91OzYamqA5ZrSetROJpvJtOWyvO6fLd60zCq9rc=; X-YMail-OSG: XMtunNoVM1l8TCF96Js_IYI.zVilmll4O1JY3y1xT.D.km7 N.919JH.tiSGbuF2WDJ2nPke0etAJR00208l0a8pamNaPSXos3_1oAJOw2go .b.7C6VeCD2PHG1hyqXu8pPvhi7YsfE95r5SC5XQarQndaTckcIX2azZD_TU X6nT4IjsgLRtORioK77gQz8qrk61rcxMMDnj1dVYM4F6trdAnvHP_EgAFI7b sbiG5WzbpZJVkFoXWwmEhDJ6Smqtdsf.YnQ1FTw.Gk35IYd6wgKCLTk1v4Vi gDVrmYaPSgJnM1gG11YjTzkvvYyNf8OyiSsJ6keLcNxtjZgcogdTyn7ZhVhO 8IggATiUlApDEbKDADN3c5CdLgNxElYafuC19WuOR9s_6B8cryYUakAUbgAZ X7YMA3OdlG7VMPwN1osgH600xXd8VUtbtMtiwl_sNzTj6pGn5.8kZ_UMYgqz YeoZBFqGZXI0hWaDteqatyGlUTDVgxeQrAA_LWw4rW7PXEuPMxhjrCB3mA1m F8cDTsPUqLhHYN6v.YrHSVKn_rUcqsg-- Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Sat, 05 Jan 2013 07:17:10 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gRnJpLCAxLzQvMTMsIFdpbGxlbSBKYW4gV2l0aGFnZW4gPHdqd0BkaWdpd2FyZS5ubD4gd3JvdGU6Cgo.IEZyb206IFdpbGxlbSBKYW4gV2l0aGFnZW4gPHdqd0BkaWdpd2FyZS5ubD4KPiBTdWJqZWN0OiBSZToga2Vybi8xNzQ4NTE6IFtieGVdIFtwYXRjaF0gVURQIGNoZWNrc3VtIG9mZmxvYWQgaXMgd3JvbmcgaW4gYnhlIGRyaXZlcgo.IFRvOiAiQmFybmV5IENvcmRvYmEiIDxiYXJuZXlfY29yZG9iYUB5YWhvby5jb20.Cj4gQ2M6ICJHYXJyZXR0IENvb3BlciIgPHlhbmVnb21pQGdtYWlsLmMBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.129.483 Message-ID: <1357399030.5935.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Sat, 5 Jan 2013 07:17:10 -0800 (PST) From: Barney Cordoba Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver To: Willem Jan Withagen In-Reply-To: <50E6EA0C.5080005@digiware.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Garrett Cooper , freebsd-net@freebsd.org, Adrian Chadd , David Christensen , linimon@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 15:17:18 -0000 --- On Fri, 1/4/13, Willem Jan Withagen wrote: > From: Willem Jan Withagen > Subject: Re: kern/174851: [bxe] [patch] UDP checksum offload is wrong in bxe driver > To: "Barney Cordoba" > Cc: "Garrett Cooper" , freebsd-net@freebsd.org, "Adrian Chadd" , "David Christensen" , linimon@freebsd.org > Date: Friday, January 4, 2013, 9:41 AM > On 2013-01-01 0:04, Barney Cordoba > wrote: > > > The statement above "assumes" that there is a benefit. > voIP packets > > are short, so the benefit of offloading is reduced. > There is some > > delay added by the hardware, and there are cpu cycles > used in managing > > the offload code. So those operations not only muddy > the code, > > but they may not be faster than simply doing the > checksum on a much, much > > faster cpu. > > Forgoing all the discussions on performance and possible > penalties in > drivers..... > > I think there is a large set of UDP streams (and growing) > that do use > larger packets. > > The video streaming we did used a size of header(14)+7*188, > which is the > max number of MPEG packet to fit into anything with an MTU > < 1500. > > Receiving those on small embedded devices which can do HW > check-summing > is very beneficial there. > On the large servers we would generate up to 5Gbit of > outgoing streams. > I'm sure that offloading UDP checks would be an advantage as > well. > (They did run mainly Linux, but FreeBSD would also work) > > Unfortunately most of the infrastructure has been taken > down, so it is > no longer possible to verify any of the assumptions. > > --WjW If you haven't benchmarked it, then you're just guessing. That's my point. Its like SMP in freeBSD 4. People bought big, honking machines and the big expensive machines were slower than a single core system at less than half the price. Just because something sounds better doesn't mean that it is better. BC From owner-freebsd-net@FreeBSD.ORG Sat Jan 5 22:23:05 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 76029BAD; Sat, 5 Jan 2013 22:23:05 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 44FAC8C5; Sat, 5 Jan 2013 22:23:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id r05MN5wA048996; Sat, 5 Jan 2013 22:23:05 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id r05MN5ap048992; Sat, 5 Jan 2013 22:23:05 GMT (envelope-from ae) Date: Sat, 5 Jan 2013 22:23:05 GMT Message-Id: <201301052223.r05MN5ap048992@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, ae@FreeBSD.org From: ae@FreeBSD.org Subject: Re: kern/171697: [ip6] [ndp] panic when changing routes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jan 2013 22:23:05 -0000 Synopsis: [ip6] [ndp] panic when changing routes Responsible-Changed-From-To: freebsd-net->ae Responsible-Changed-By: ae Responsible-Changed-When: Sat Jan 5 22:22:46 UTC 2013 Responsible-Changed-Why: Take it. http://www.freebsd.org/cgi/query-pr.cgi?pr=171697