From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 06:09:01 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 502BB1065673 for ; Sun, 12 Jun 2011 06:09:01 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id CA92E8FC14 for ; Sun, 12 Jun 2011 06:09:00 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5C68hqM048598 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2011 15:08:54 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5C68ffR049110; Sun, 12 Jun 2011 15:08:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 12 Jun 2011 15:00:14 +0900 (JST) Message-Id: <20110612.150014.583045369315129695.hrs@allbsd.org> To: net@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jun_12_15_00_14_2011_795)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Sun, 12 Jun 2011 15:08:54 +0900 (JST) X-Spam-Status: No, score=6.1 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: bplank@gta.com Subject: [CFT] RFC 6106 support patch for RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 06:09:01 -0000 ----Security_Multipart(Sun_Jun_12_15_00_14_2011_795)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, A patch to add RFC 6106 support to rtadvd(8) and rtsold(8) on RELENG_8 can be found at the following URL: http://people.freebsd.org/~hrs/rfc6106_stable8_20110611.diff Can anyone test it? 8.X uses net.inet6.ip6.accept_rtadv and net.inet6.ip6.forwarding to determine if accepting RAs or not (i.e. ACCEPT_RTADV flag is ignored), so the patch follows the same logic. Note that an -R option must manually be specified in rtsold(8) to use the received RDNSS/DNSSL information since RELENG_8 does not have resolvconf(8) (MFC of resolvconf(8) needs printf() support in sh(1) first, IIRC). I am not sure at this moment whether MFC of supporting per-IF ACCEPT_RTADV flag and acceptance of RAs even when net.inet6.ip6.forwarding=1 happens. This is because it needs relatively large rc.d script changes. Any comments are welcome. -- Hiroki ----Security_Multipart(Sun_Jun_12_15_00_14_2011_795)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk30Ve4ACgkQTyzT2CeTzy2QhACgqwiTN11qL1BuC0HsgRDt0oFO kRUAnjbfUTbeOjGmwJ2VCN8V1Hju3utR =bdSq -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_12_15_00_14_2011_795)---- From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 06:48:47 2011 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 60CBC106564A; Sun, 12 Jun 2011 06:48:47 +0000 (UTC) (envelope-from nparhar@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 22BF58FC16; Sun, 12 Jun 2011 06:48:46 +0000 (UTC) Received: by pzk5 with SMTP id 5so2606352pzk.17 for ; Sat, 11 Jun 2011 23:48:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=GwFqc/34PkgCbb96j5VF2kBem3VrdTepkpJlVvM3a+o=; b=cAgA6fn58ZkShBR4HHx2TYK3PE+ag/XCP0EdQ4bsz5+A23kuZqHPSsKKGL1acMpa6s lnSRWIjhl1KXuJOxtsOis+D8NTryWT0wWCSTe2drcKHlpIFt55NX/B1FhhEMycoSIzn9 HDFgzBi9w7xJkrOLn+qdsohHIn0gVo8bprJ+k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; b=f+fS1jfQ7pYgaT9zpyEz/7AjIRcZC/MZ6uSqpWoz6jduStb3ibRAXaiEVJ464G+HSW 6cjhqljrGqRmlonnxkl9tXlEP4Al38P7gz9zWktCJVuZ2RctvFyoxFj6K5vAOFbMHnma 7s3lHDlrx6SEKhaeo8fEVf2wLg5+rFlZ5bxOc= Received: by 10.142.231.7 with SMTP id d7mr609005wfh.216.1307859740278; Sat, 11 Jun 2011 23:22:20 -0700 (PDT) Received: from itx (c-107-3-142-221.hsd1.ca.comcast.net [107.3.142.221]) by mx.google.com with ESMTPS id l10sm4638001wfk.9.2011.06.11.23.22.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 11 Jun 2011 23:22:18 -0700 (PDT) Date: Sat, 11 Jun 2011 23:22:11 -0700 From: Navdeep Parhar To: "K. Macy" Message-ID: <20110612062211.GA31301@itx> Mail-Followup-To: "K. Macy" , freebsd-net@freebsd.org References: <20110611181352.GA67777@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD I/OAT (QuickData now?) driver X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 06:48:47 -0000 On Sat, Jun 11, 2011 at 08:07:18PM +0200, K. Macy wrote: > > I'd really encourage people to look at the code (e.g. the pkt-gen.c > > program, which is part of the archive) so you can see how easy it > > is to use. > > Provided one has a dedicated interface. Not necessarily. The T4 ASIC has more than 1K rx queues and ~64K tx queues, which can be created (and destroyed) on the fly and combined under a "virtual interface." You could have scores of such virtual interfaces, each of which would represent an ifnet to the kernel. If there's interest, cxgbe(4) can grow support for virtual interfaces and netmap tx/rx queues that come and go as required. Untrusted rx queues are allowed too - privileged code associates memory regions with an rx queue, untrusted code is allowed direct access to the hardware ring but can only specify offsets within the allowed memory region. Regards, Navdeep From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 11:35:05 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0A3B106566B; Sun, 12 Jun 2011 11:35:05 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 55DE48FC08; Sun, 12 Jun 2011 11:35:05 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p5CBYpeE010478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2011 20:34:58 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 12 Jun 2011 20:34:51 +0900 Message-ID: From: Hajimu UMEMOTO To: Hiroki Sato In-Reply-To: <20110612.150014.583045369315129695.hrs@allbsd.org> References: <20110612.150014.583045369315129695.hrs@allbsd.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 12 Jun 2011 20:34:58 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: bplank@gta.com, net@FreeBSD.org Subject: Re: [CFT] RFC 6106 support patch for RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 11:35:05 -0000 Hi, >>>>> On Sun, 12 Jun 2011 15:00:14 +0900 (JST) >>>>> Hiroki Sato said: hrs> A patch to add RFC 6106 support to rtadvd(8) and rtsold(8) on hrs> RELENG_8 can be found at the following URL: hrs> http://people.freebsd.org/~hrs/rfc6106_stable8_20110611.diff hrs> Can anyone test it? 8.X uses net.inet6.ip6.accept_rtadv and hrs> net.inet6.ip6.forwarding to determine if accepting RAs or not hrs> (i.e. ACCEPT_RTADV flag is ignored), so the patch follows the same hrs> logic. hrs> Note that an -R option must manually be specified in rtsold(8) to use hrs> the received RDNSS/DNSSL information since RELENG_8 does not have hrs> resolvconf(8) (MFC of resolvconf(8) needs printf() support in sh(1) hrs> first, IIRC). I've put the patch to add resolvconf(8) to RELENG_8: http://people.freebsd.org/~ume/resolvconf-releng_8.diff Note that it doesn't contain printf() support in sh(1). Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 11:41:05 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EF188106566C; Sun, 12 Jun 2011 11:41:05 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id 96CC88FC12; Sun, 12 Jun 2011 11:41:05 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga.mahoroba.org [IPv6:2001:2f0:104:8010:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p5CBYpeE010478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2011 20:34:58 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sun, 12 Jun 2011 20:34:51 +0900 Message-ID: From: Hajimu UMEMOTO To: Hiroki Sato In-Reply-To: <20110612.150014.583045369315129695.hrs@allbsd.org> References: <20110612.150014.583045369315129695.hrs@allbsd.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Sun, 12 Jun 2011 20:34:58 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: bplank@gta.com, net@FreeBSD.org Subject: Re: [CFT] RFC 6106 support patch for RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 11:41:06 -0000 Hi, >>>>> On Sun, 12 Jun 2011 15:00:14 +0900 (JST) >>>>> Hiroki Sato said: hrs> A patch to add RFC 6106 support to rtadvd(8) and rtsold(8) on hrs> RELENG_8 can be found at the following URL: hrs> http://people.freebsd.org/~hrs/rfc6106_stable8_20110611.diff hrs> Can anyone test it? 8.X uses net.inet6.ip6.accept_rtadv and hrs> net.inet6.ip6.forwarding to determine if accepting RAs or not hrs> (i.e. ACCEPT_RTADV flag is ignored), so the patch follows the same hrs> logic. hrs> Note that an -R option must manually be specified in rtsold(8) to use hrs> the received RDNSS/DNSSL information since RELENG_8 does not have hrs> resolvconf(8) (MFC of resolvconf(8) needs printf() support in sh(1) hrs> first, IIRC). I've put the patch to add resolvconf(8) to RELENG_8: http://people.freebsd.org/~ume/resolvconf-releng_8.diff Note that it doesn't contain printf() support in sh(1). Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 12:37:40 2011 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 A3750106564A for ; Sun, 12 Jun 2011 12:37:40 +0000 (UTC) (envelope-from rmh.aybabtu@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 747FD8FC08 for ; Sun, 12 Jun 2011 12:37:40 +0000 (UTC) Received: by pwj8 with SMTP id 8so2305843pwj.13 for ; Sun, 12 Jun 2011 05:37:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=d7b6qJb8KrOxyOuYW1WSmaMM8xoHYqBQP7lP/VWPIvo=; b=DtPCemw8m5bB8W8pnIMIrzid9NB/XAhHq8PbfPMSGTU8eYQT/OzfmpMkeRr2FRi0rv CpzUFl3I+3W+RA7b3leK2qa2BFqQghDKPRhJjnxGJyTZhv8/BydWZCi/2C99bt6x+xAZ iD6KLywhGwTN/pMx/2JAOnNYyzHhGsTmwhpYc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; b=MgqHw9nzKRyVinZjthzh+9zliDNxYb6G/N7Gr/xhOercQDbnrsdqXypSh5fnxcpGCn fQpK7T8ap/fFeCnx8uu+C8vnquxlD2YxGXk4ddg+CE3jUMy6MHRkm/AHD50sc2wGKbjs o+/1nq47Q7+RdwcxGBNbhjizaD+IoSpmOg9Ro= MIME-Version: 1.0 Received: by 10.68.48.129 with SMTP id l1mr1709752pbn.112.1307880930884; Sun, 12 Jun 2011 05:15:30 -0700 (PDT) Sender: rmh.aybabtu@gmail.com Received: by 10.68.46.100 with HTTP; Sun, 12 Jun 2011 05:15:30 -0700 (PDT) In-Reply-To: <201106021642.p52Gg36i028702@freefall.freebsd.org> References: <201106021642.p52Gg36i028702@freefall.freebsd.org> Date: Sun, 12 Jun 2011 14:15:30 +0200 X-Google-Sender-Auth: KyriqWCxmb3li4iP9alFYIH-D-w Message-ID: From: Robert Millan To: yongari@freebsd.org, bug-followup@freebsd.org, freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: Subject: Re: kern/154591: [msk] [panic] if_msk driver causes kernel panic (fatal trap while in kernel mode) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 12:37:40 -0000 Btw will this be MFC'ed? 2011/6/2 : > Synopsis: [msk] [panic] if_msk driver causes kernel panic (fatal trap while in kernel mode) > > State-Changed-From-To: feedback->patched > State-Changed-By: yongari > State-Changed-When: Thu Jun 2 16:41:41 UTC 2011 > State-Changed-Why: > Fixed in HEAD. > Thanks for testing! > > http://www.freebsd.org/cgi/query-pr.cgi?pr=154591 > -- Robert Millan From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 12:43:15 2011 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 CBB12106564A for ; Sun, 12 Jun 2011 12:43:15 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 913B78FC16 for ; Sun, 12 Jun 2011 12:43:15 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 0505B7300A; Sun, 12 Jun 2011 14:59:30 +0200 (CEST) Date: Sun, 12 Jun 2011 14:59:29 +0200 From: Luigi Rizzo To: freebsd-net@freebsd.org Message-ID: <20110612125929.GA76345@onelab2.iet.unipi.it> References: <20110611181352.GA67777@onelab2.iet.unipi.it> <20110612062211.GA31301@itx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110612062211.GA31301@itx> User-Agent: Mutt/1.4.2.3i Subject: virtual NIC rings (Re: FreeBSD I/OAT (QuickData now?) driver) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 12:43:15 -0000 Two previous discussions on direct NIC access evolved on how to share one interface among multiple clients (including the host stack) some of which can be less trusted than others. I have not addressed these problems yet in netmap, because i see them as orthogonal to the API for accessing data, nor i think that the number of virtual queues supported by the hardware is fundamental in solving the problem. As i see it, the important thing is understand who does: - replication (needed for multicast, broadcast, sniffing) The main reason to put the NIC in charge of replication is that it saves contention on locks. Other than that, there are only disadvantages, because the PCI-e bus has a lot less capacity than the memory bus, and (perhaps) a CPU-assisted replication could be based on shared readonly copies. - packet filtering (which packet goes where); some nics already support routing of packets to queues according to various fields. This is nice to have, but not essential. I'd argue that it mostly saves lock contention, but otherwise, with the table sizes available in the NIC, even filtering in software is not prohibitively expensive. - "access control" (is client X allowed to send/receive certain traffic). Do we want an untrusted client to be able to send packets with someone else's source MAC or IP ? Perhaps the right answer is "who cares, it can happen anyways on the PC next to you", and this saves a per-packet decision. On the incoming side the problem is easier, as programming the packet filter/replicator is done once in a while and not on a per-packet basis. - memory protection. Right now netmap uses a single buffer area for all rings on all cards. While this is extremely efficient at runtime (you can move packets around by just shuffling buffer indexes; validity checks require a single comparison and perhaps a lookup; you can do zero-copy forwarding, or modify buffers if needed), it is clearly vulnerable to data corruption from misbehaving processes. It will be interesting to see how we can insert some protection without killing the option of zero-copy operation. Once we have addresses these issues, of course any hardware support will be welcome. Just to refer to the one implementation i know, netmap creates one virtual ring for each hardware ring, plus one ring pair for the host stack. I think the next step would be to put some additional field (e.g. a MAC address) to drive the filtering and replication engines (either on-nic, or done in software). Then one could e.g. say "give me all traffic for MAC X," and have the kernel decide whether this needs partial or full traffic replication, etc. cheers luigi http://info.iet.unipi.it/~luigi/netmap/ From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 12:59:37 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9D5FD1065670 for ; Sun, 12 Jun 2011 12:59:37 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 254E08FC0A for ; Sun, 12 Jun 2011 12:59:36 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5CCxOtZ051285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2011 21:59:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5CCxNTx053619; Sun, 12 Jun 2011 21:59:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 12 Jun 2011 21:58:59 +0900 (JST) Message-Id: <20110612.215859.521968037530590019.hrs@allbsd.org> To: net@FreeBSD.org From: Hiroki Sato In-Reply-To: <20110612.150014.583045369315129695.hrs@allbsd.org> References: <20110612.150014.583045369315129695.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sun_Jun_12_21_58_59_2011_109)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Sun, 12 Jun 2011 21:59:35 +0900 (JST) X-Spam-Status: No, score=5.6 required=14.0 tests=BAYES_40, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: bplank@gta.com Subject: Re: [CFT] RFC 6106 support patch for RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 12:59:37 -0000 ----Security_Multipart(Sun_Jun_12_21_58_59_2011_109)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20110612.150014.583045369315129695.hrs@allbsd.org>: hr> Hi, hr> hr> A patch to add RFC 6106 support to rtadvd(8) and rtsold(8) on hr> RELENG_8 can be found at the following URL: hr> hr> http://people.freebsd.org/~hrs/rfc6106_stable8_20110611.diff A patch for sbin/rtsol was missing in the above. Please use the following instead: http://people.freebsd.org/~hrs/rfc6106_stable8_20110612-1.diff -- Hiroki ----Security_Multipart(Sun_Jun_12_21_58_59_2011_109)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk30uBMACgkQTyzT2CeTzy2QngCfTjUuk/1ozwfJZ9MaQHimfHFr S9sAnAyTSZMR0MfuFkyNjxdfRbKphkNF =/ROQ -----END PGP SIGNATURE----- ----Security_Multipart(Sun_Jun_12_21_58_59_2011_109)---- From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 21:53:53 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AF026106566C; Sun, 12 Jun 2011 21:53:53 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 893878FC13; Sun, 12 Jun 2011 21:53:53 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5CLrrwR032282; Sun, 12 Jun 2011 21:53:53 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5CLrrw5032278; Sun, 12 Jun 2011 21:53:53 GMT (envelope-from linimon) Date: Sun, 12 Jun 2011 21:53:53 GMT Message-Id: <201106122153.p5CLrrw5032278@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-amd64@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/157802: [dummynet] [panic] kernel panic in dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 21:53:53 -0000 Old Synopsis: kernel panic in dummynet New Synopsis: [dummynet] [panic] kernel panic in dummynet Responsible-Changed-From-To: freebsd-amd64->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Jun 12 21:53:36 UTC 2011 Responsible-Changed-Why: reclassify. http://www.freebsd.org/cgi/query-pr.cgi?pr=157802 From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 22:30:47 2011 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 4A848106564A for ; Sun, 12 Jun 2011 22:30:47 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 172558FC08 for ; Sun, 12 Jun 2011 22:30:46 +0000 (UTC) Received: (qmail 28023 invoked by uid 0); 12 Jun 2011 22:30:44 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jun 2011 22:30:44 -0000 Received: (qmail 28019 invoked by uid 90); 12 Jun 2011 22:30:44 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 12 Jun 2011 22:30:44 -0000 Date: Sun, 12 Jun 2011 18:30:44 -0400 (EDT) From: Charles Sprickman X-X-Sender: spork@hotlap.nat.fasttrackmonkey.com To: freebsd-net@freebsd.org Message-ID: User-Agent: Alpine 2.00 (OSX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 22:30:47 -0000 Hello, I've been trying to wrap my head around the differences between address resolution in IPv6 and IPv4 and I'm a bit confused by a real-world issue I'm seeing in a colo facility where we have dual-stack connectivity. Basically, what I see is summed up in this recent post: http://freebsd.1045724.n5.nabble.com/Proper-way-to-setup-IPv6-gateway-on-running-node-without-reboot-td4313847.html If I manually configure a static IPv6 IP and then set a default route for a router on the same subnet, ie: ifconfig em0 inet6 2001:xxx:xxxx::2/48 route add -inet6 default 2001:xxx:xxxx::1 I have no issues pinging other hosts on the subnet (which also have static IPs and manually configured gateways), but I find that address resolution for the router is spotty at best. If I start and maintain a ping from the host to the router, the first few packets are lost, then traffic flows. If I'm pinging from an outside host, once I stop the ping from the host to the gateway, the external ping fails shortly thereafter. I can also get traffic to flow to the gateway briefly by running "rtsol em0", but after a few minutes it stops. Now following the steps in the thread linked above works, and what that basically has you do is enable link-local addresses, down/up the interface, and then all is well. Can anyone help me understand what the relationship is between address resolution for the router and link-local? Why is this required? Why can I ping other hosts on the subnet without enabling link-local? I understand link-local is needed for *automatic* router discovery, but in my case I'm explicity setting a default route. I'm having a hard time finding good docs on this, most tutorials seem to center around a tunneling setup or simple autoconfigured LAN stuff - no one's really addressing typical colo/datacenter configs. I've got my workaround, but I'd like to understand what's going on. Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Sun Jun 12 22:44:08 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id F2C18106564A for ; Sun, 12 Jun 2011 22:44:08 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from [127.0.0.1] (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 637BB1544ED; Sun, 12 Jun 2011 22:44:08 +0000 (UTC) Message-ID: <4DF54139.1050004@FreeBSD.org> Date: Sun, 12 Jun 2011 15:44:09 -0700 From: Doug Barton Organization: http://www.FreeBSD.org/ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Charles Sprickman References: In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 12 Jun 2011 22:44:09 -0000 On 6/12/2011 3:30 PM, Charles Sprickman wrote: > Can anyone help me understand what the relationship is between address > resolution for the router I don't know what you mean by "address resolution for the router." > and link-local? Why is this required? Why > can I ping other hosts on the subnet without enabling link-local? link-local is required for IPv6. The gateway address should be the link-local address, not the GUA. -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 02:29:50 2011 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 9225A1065672 for ; Mon, 13 Jun 2011 02:29:50 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id 3199A8FC18 for ; Mon, 13 Jun 2011 02:29:50 +0000 (UTC) Received: (qmail 14492 invoked by uid 0); 13 Jun 2011 02:29:49 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 13 Jun 2011 02:29:49 -0000 Received: (qmail 14489 invoked by uid 90); 13 Jun 2011 02:29:49 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (AES256-SHA encrypted) SMTP; 13 Jun 2011 02:29:49 -0000 Message-ID: <4DF5761C.9040509@bway.net> Date: Sun, 12 Jun 2011 22:29:48 -0400 From: Charles Sprickman User-Agent: Postbox 2.1.4 (Macintosh/20110310) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4DF54139.1050004@FreeBSD.org> <4DF56879.30204@bway.net> In-Reply-To: <4DF56879.30204@bway.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 02:29:50 -0000 (sending to list, accidentally missed "reply to all" when I replied to Doug) Doug Barton wrote: > On 6/12/2011 3:30 PM, Charles Sprickman wrote: >> Can anyone help me understand what the relationship is between address >> resolution for the router > > I don't know what you mean by "address resolution for the router." Layer-2 to Layer-3 mapping and discovery. >> and link-local? Why is this required? Why >> can I ping other hosts on the subnet without enabling link-local? > > link-local is required for IPv6. The gateway address should be the > link-local address, not the GUA. What is the purpose then of the default route statement for IPv6 in rc.conf and why have my providers offered up a non-link-local gateway address? Thanks, Charles From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 11:07:08 2011 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 9E82D1065674 for ; Mon, 13 Jun 2011 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8729D8FC12 for ; Mon, 13 Jun 2011 11:07:08 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5DB78RI092138 for ; Mon, 13 Jun 2011 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5DB77cQ092136 for freebsd-net@FreeBSD.org; Mon, 13 Jun 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 13 Jun 2011 11:07:07 GMT Message-Id: <201106131107.p5DB77cQ092136@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 Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 11:07:08 -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/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156978 net [lagg][patch] Take lagg rlock before checking flags o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155498 net [ral] ral(4) needs to be resynced with OpenBSD's to ga o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154831 net [arp] [patch] arp sysctl setting log_arp_permanent_mod o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152360 net [dummynet] [panic] Crash related to dummynet. 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/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 bin/150642 net netstat(1) doesn't print anything for SCTP sockets o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u 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 bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. 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 o kern/144572 net [carp] CARP preemption mode traffic partially goes to 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/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed 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/141023 net [carp] CARP arp replays with wrong src mac 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 o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134931 net [route] Route messages sent to all socket listeners re 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 o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a 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 o 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 conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation 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/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro 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/126714 net [carp] CARP interface renaming makes system no longer 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/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125442 net [carp] [lagg] CARP combined with LAGG causes system pa o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node 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/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120130 net [carp] [panic] carp causes kernel panics in any conste 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/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap 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 kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip 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/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph 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/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support 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 o kern/54383 net [nfs] [patch] NFS root configurations without dynamic s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c 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 376 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 14:58:46 2011 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 83D2B106564A; Mon, 13 Jun 2011 14:58:46 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id E424B8FC08; Mon, 13 Jun 2011 14:58:45 +0000 (UTC) Received: by fxm11 with SMTP id 11so4143640fxm.13 for ; Mon, 13 Jun 2011 07:58:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:sender:date:message-id :user-agent:mime-version:content-type; bh=zo3r5HUQmow14CMwuaO6cEoQRzZ3x3MoilaMGQBoODc=; b=WKkHhcIoGKzKMxijXpy3w/aZ03q02W3lLeE6qWP8qACFMOg2iXSK+R5LYnkI7CAl2c /jyGXZkn7NNkxAtCGsMoMIkUREA89V/AWTrwEN/8o5VLnfJv0+3uEFDcYo/Clc3/qlFT TEV5SPI694cukyP3Z5OkUmK4N179LwikJKJfI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:sender:date:message-id:user-agent:mime-version :content-type; b=Qvt2W5ZpG1dBsZiSLkahOZAkSCoEEe1RMAz4xv0+lEWF+4ZpFvICIatzuWxFIOOa7X 8RsEnPla2Nde0qdzEWrR0ulLyLrBownqqU4+XdQb+eBnqxW5Upzw7I08WpwuiQNZaTVg hOErcxW6IRYwQvbvnJ257uUiLtr5sxg7It7TA= Received: by 10.223.6.198 with SMTP id a6mr3082476faa.126.1307977124764; Mon, 13 Jun 2011 07:58:44 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id q21sm2101094fan.16.2011.06.13.07.58.42 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 07:58:43 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@freebsd.org Sender: Mikolaj Golub Date: Mon, 13 Jun 2011 17:58:41 +0300 Message-ID: <86mxhleq1q.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Pawel Jakub Dawidek Subject: Automatic receive buffer sizing works only for connections in ESTABLISHED state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 14:58:46 -0000 Hi, Automatic receive buffer sizing works only for connections in ESTABLISHED state. In tcp_input() auto resizing code is under "if (tp->t_state == TCPS_ESTABLISHED && ...)" branch. This is unfortunate for HAST, which uses one direction connections and shutdown another direction, so the receiving socket is in FIN_WAIT_2 and auto resizing does not work here. Is there some reason why it should be only for connections in ESTABLISHED state or this should be considered as a bug? -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 15:39:22 2011 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 A689E1065676 for ; Mon, 13 Jun 2011 15:39:22 +0000 (UTC) (envelope-from ray@freebsd.org) Received: from dlink.ua (smtp.dlink.ua [193.138.187.146]) by mx1.freebsd.org (Postfix) with ESMTP id 65F618FC14 for ; Mon, 13 Jun 2011 15:39:22 +0000 (UTC) Received: from 73-19-133-95.pool.ukrtel.net ([95.133.19.73] helo=rnote.ddteam.net) by dlink.ua with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1QW8c9-0002sg-Bj for freebsd-net@FreeBSD.org; Mon, 13 Jun 2011 17:59:41 +0300 Date: Mon, 13 Jun 2011 17:58:25 +0300 From: Aleksandr Rybalko To: freebsd-net@FreeBSD.org Message-Id: <20110613175825.181e6803.ray@freebsd.org> Organization: FreeBSD.ORG X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) X-Operating-System: FreeBSD Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: H/W offload VLAN/PPPoE/NAT X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 15:39:22 -0000 Hi folks, I work with System-on-Chip(SoC) Ralink RT3052F and I have a questions which I think preferred to discuss here. SoC have Ethernet MAC and Ethernet switch, they connected together with two ports at MAC side called as GMAC1 and GMAC2. MAC internally have so called Frame-Engine, bus that deliver packets between GMAC1, GMAC2, CPU port, Discard port and PPE (Packet Processing Engine) Packet Processing Engine can insert/remove VLAN tag and PPPoE headers and do NAT/PAT translations. VLAN offload I will implement w/ IFCAP_VLAN_HWTAGGING and will use EVENTHANDLER_REGISTER(vlan_[un]config, ...) to limit max vlan subifaces to max 16 items supported by MAC. Right? Problem with PPPoE offload, since chip support only insert/remove PPPoE session header, so we need something like vlan clones, but for PPPoE. And session setup still should be done at parent interface. Any ideas? Another big question is a PPE, which seems just return packets to driver after processing, so I don't have any idea how to correct implement it. May someone help me with ideas, samples or something else what may help me? I would be thankful for any ideas. WBW -- Aleksandr Rybalko -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 16:19:46 2011 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 1B9761065670; Mon, 13 Jun 2011 16:19:46 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4903D8FC08; Mon, 13 Jun 2011 16:19:44 +0000 (UTC) Received: by fxm11 with SMTP id 11so4214848fxm.13 for ; Mon, 13 Jun 2011 09:19:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:sender:date:message-id :user-agent:mime-version:content-type; bh=fcvuK4pQB0uwAI1jGyBJI1L4cFh3hDkYJOvvUL6k304=; b=Yn49INjCAKib1Doe3iuh16WTW+R5feP8/oWuH7kd4o9BRoG4WLVQEXerRkanuVmKiQ EEiWRXWomypOZLwVkdALtuw3tFRa26FHYYxr0Tgf92/KbULk7UEdXGOoCSEQVSLgjy2c NLnDG1EtF3F4a2YfwYn0N6AcOFG6xhuXzImow= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:sender:date:message-id:user-agent:mime-version :content-type; b=aFnfka0I4Qt+/xxx42M2NNJjW3JUavO1+WhvRpeWKxXjBVzVoIIjUxp+qgKPL8ijFS 18s6XTM3LTIex9M+Snx8qcynwlPg6qKu6kU4eJjS9TSDNXk4+wXsXd4wUgAUZewgcI3R DrcikNlayri44dbUXHFMFOX0ohQaZcqHLi/vQ= Received: by 10.223.5.28 with SMTP id 28mr5277310fat.103.1307981983913; Mon, 13 Jun 2011 09:19:43 -0700 (PDT) Received: from localhost ([95.69.172.154]) by mx.google.com with ESMTPS id a18sm2122905fak.29.2011.06.13.09.19.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 13 Jun 2011 09:19:42 -0700 (PDT) From: Mikolaj Golub To: freebsd-net@freebsd.org Sender: Mikolaj Golub Date: Mon, 13 Jun 2011 19:19:40 +0300 Message-ID: <86pqmhn1pf.fsf@kopusha.home.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kostik Belousov , Pawel Jakub Dawidek Subject: Scenario to make recv(MSG_WAITALL) stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 16:19:46 -0000 Hi, Below is a scenario how to make recv(2) with MSG_WAITALL flag get stuck. (See http://people.freebsd.org/~trociny/test_MSG_WAITALL.4.c for the test code). Let's the size of the receive buffer is SOBUF_SIZE (e.g. 10000 bytes). On sender side do 2 send() requests: 1) data of size much smaller than SOBUF_SIZE (e.g. SOBUF_SIZE / 10); 2) data of size equal to SOBUF_SIZE. After this on receiver side do 2 recv() requests with MSG_WAITALL flag set: 1) recv() data of SOBUF_SIZE / 10 size; 2) recv() data of SOBUF_SIZE size; The second recv() will last for very long time. In tcpdump one can observe that the window is permanently stuck at 0 and pending data is only sent via TCP window probes (so one byte every few seconds). 18:09:14.784698 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [S], seq 1907676797, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 22207 ecr 0], length 0 18:09:14.784729 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [S.], seq 2298857585, ack 1907676798, win 10000, options [mss 16344,nop,wscale 3,sackOK,TS val 2718467987 ecr 22207], length 0 18:09:14.784749 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], ack 1, win 8960, options [nop,nop,TS val 22207 ecr 2718467987], length 0 18:09:14.785168 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [P.], seq 1:1001, ack 1, win 8960, options [nop,nop,TS val 22207 ecr 2718467987], length 1000 18:09:14.785264 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1001:10001, ack 1, win 8960, options [nop,nop,TS val 22207 ecr 2718467987], length 9000 18:09:14.785280 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10001, win 0, options [nop,nop,TS val 2718467987 ecr 22207], length 0 18:09:19.784440 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10001:10002, ack 1, win 8960, options [nop,nop,TS val 22707 ecr 2718467987], length 1 18:09:19.784480 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10001, win 0, options [nop,nop,TS val 2718468487 ecr 22707], length 0 18:09:24.784439 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10001:10002, ack 1, win 8960, options [nop,nop,TS val 23207 ecr 2718468487], length 1 18:09:24.784472 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10002, win 0, options [nop,nop,TS val 2718468987 ecr 23207], length 0 18:09:29.784437 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10002:10003, ack 1, win 8960, options [nop,nop,TS val 23707 ecr 2718468987], length 1 18:09:29.784478 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10003, win 0, options [nop,nop,TS val 2718469487 ecr 23707], length 0 18:09:34.784444 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10003:10004, ack 1, win 8960, options [nop,nop,TS val 24207 ecr 2718469487], length 1 18:09:34.784486 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10004, win 0, options [nop,nop,TS val 2718469987 ecr 24207], length 0 18:09:39.784443 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10004:10005, ack 1, win 8960, options [nop,nop,TS val 24707 ecr 2718469987], length 1 18:09:39.784478 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10005, win 0, options [nop,nop,TS val 2718470487 ecr 24707], length 0 18:09:44.784442 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 10005:10006, ack 1, win 8960, options [nop,nop,TS val 25207 ecr 2718470487], length 1 18:09:44.784477 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 10006, win 0, options [nop,nop,TS val 2718470987 ecr 25207], length 0 ... I first noticed this issue with HAST and suspect other people observed it with HAST too. Below is explanation what is going on. We totaly filled the receiver buffer with one SOBUF_SIZE/10 size request and partial SOBUF_SIZE request. When the first request was processed we got SOBUF_SIZE/10 free space. It was just enogh to recive the rest of bytes for the second request, and the reciving thread went in soreceive_generic->sbwait here: /* * If we have less data than requested, block awaiting more (subject * to any timeout) if: * 1. the current count is less than the low water mark, or * 2. MSG_WAITALL is set, and it is possible to do the entire * receive operation at once if we block (resid <= hiwat). * 3. MSG_DONTWAIT is not set * If MSG_WAITALL is set but resid is larger than the receive buffer, * we have to do the receive in sections, and thus risk returning a * short count if a timeout or signal occurs after we start. */ if (m == NULL || (((flags & MSG_DONTWAIT) == 0 && so->so_rcv.sb_cc < uio->uio_resid) && (so->so_rcv.sb_cc < so->so_rcv.sb_lowat || ((flags & MSG_WAITALL) && uio->uio_resid <= so->so_rcv.sb_hiwat)) && m->m_nextpkt == NULL && (pr->pr_flags & PR_ATOMIC) == 0)) { ... error = sbwait(&so->so_rcv); recvbuf is almost full but has enough space to satisfy MSG_WAITALL request without draining data to user buffer, and soreceive waits for data. But the window was closed when the buffer was filled and to avoid silly window syndrome it opens only when available space is larger than sb_hiwat/4 or maxseg: tcp_output(): /* * Calculate receive window. Don't shrink window, * but avoid silly window syndrome. */ if (recwin < (long)(so->so_rcv.sb_hiwat / 4) && recwin < (long)tp->t_maxseg) recwin = 0; so it is stuck and pending data is only sent via TCP window probes. It looks like the fix could be to remove this condition to block if MSG_WAITALL is set and it is possible to do the entire receive operation at once, like in the patch: http://people.freebsd.org/~trociny/uipc_socket.c.soreceive_generic.MSG_DONTWAIT.patch This works for me but I am not sure this is a correct solution. Note, the issue is not reproduced with soreceive_stream. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Mon Jun 13 16:47:20 2011 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 34D7D1065670; Mon, 13 Jun 2011 16:47:20 +0000 (UTC) (envelope-from kip.macy@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id C6F438FC08; Mon, 13 Jun 2011 16:47:19 +0000 (UTC) Received: by vws18 with SMTP id 18so5451291vws.13 for ; Mon, 13 Jun 2011 09:47:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NEXLBnGo+sRZtC9zk8UfILwgu79ev2Kb7mSySpwvKdc=; b=rbh/JtxMghTpvjYvnDouG5HbJ+89zMEOCVq2rd3NZLBNeIj+od64x9J9zcevJmfOwH MsjhPwrRJ1dz6ADZKrkmFfwiBfujfytd7e9LEM4xii4TBxlGTh3lrWMaRQgtkWEIT7eh qFoe9EcbeTkUICak2LTWVGNObFGfKbaStUclI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=gwrxxNfpKTS9sn/jO3ByriTOyJA9CwRjr396t4Ka8tu/ijsbCDmlh8qKS6PoHD3tHC j9t3bbpn1nTsCCvzvVYmA46ISHypgPxBES6Se3NvRRnbjnUi9tA1igbzDzWPhWnm5pJm FA2t6big2eE1eL7yZ/aPuLHqnOXbQBIZ+yXu8= MIME-Version: 1.0 Received: by 10.52.179.202 with SMTP id di10mr7920343vdc.225.1307983638415; Mon, 13 Jun 2011 09:47:18 -0700 (PDT) Received: by 10.52.181.225 with HTTP; Mon, 13 Jun 2011 09:47:18 -0700 (PDT) In-Reply-To: <86mxhleq1q.fsf@kopusha.home.net> References: <86mxhleq1q.fsf@kopusha.home.net> Date: Mon, 13 Jun 2011 18:47:18 +0200 Message-ID: From: Kip Macy To: Mikolaj Golub Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, andre@freebsd.org Subject: Re: Automatic receive buffer sizing works only for connections in ESTABLISHED state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 13 Jun 2011 16:47:20 -0000 On Mon, Jun 13, 2011 at 4:58 PM, Mikolaj Golub wrote: > Hi, > > Automatic receive buffer sizing works only for connections in ESTABLISHED > state. In tcp_input() auto resizing code is under "if (tp->t_state == > TCPS_ESTABLISHED && ...)" branch. > > This is unfortunate for HAST, which uses one direction connections and > shutdown another direction, so the receiving socket is in FIN_WAIT_2 and auto > resizing does not work here. > > Is there some reason why it should be only for connections in ESTABLISHED > state or this should be considered as a bug? Andre wrote the socket buffer auto-sizing, so I am CC'ing him. -Kip From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 05:57:48 2011 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 068D1106564A for ; Tue, 14 Jun 2011 05:57:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 673E48FC17 for ; Tue, 14 Jun 2011 05:57:46 +0000 (UTC) Received: (qmail 46406 invoked from network); 14 Jun 2011 04:34:56 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 14 Jun 2011 04:34:56 -0000 Message-ID: <4DF6F21B.2040609@freebsd.org> Date: Tue, 14 Jun 2011 07:31:07 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Kip Macy References: <86mxhleq1q.fsf@kopusha.home.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mikolaj Golub , freebsd-net@freebsd.org Subject: Re: Automatic receive buffer sizing works only for connections in ESTABLISHED state X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 05:57:48 -0000 On 13.06.2011 18:47, Kip Macy wrote: > On Mon, Jun 13, 2011 at 4:58 PM, Mikolaj Golub wrote: >> Hi, >> >> Automatic receive buffer sizing works only for connections in ESTABLISHED >> state. In tcp_input() auto resizing code is under "if (tp->t_state == >> TCPS_ESTABLISHED&& ...)" branch. >> >> This is unfortunate for HAST, which uses one direction connections and >> shutdown another direction, so the receiving socket is in FIN_WAIT_2 and auto >> resizing does not work here. >> >> Is there some reason why it should be only for connections in ESTABLISHED >> state or this should be considered as a bug? > > Andre wrote the socket buffer auto-sizing, so I am CC'ing him. It certainly could be extended from == to >= ESTABLISHED for the mentioned reason. At the moment I'm still quite busy with other stuff. However from July on I've got plenty of time again for FreeBSD works. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 06:57:20 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79B90106566C; Tue, 14 Jun 2011 06:57:20 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 528BB8FC15; Tue, 14 Jun 2011 06:57:20 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5E6vKZh006883; Tue, 14 Jun 2011 06:57:20 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5E6vKkW006879; Tue, 14 Jun 2011 06:57:20 GMT (envelope-from ae) Date: Tue, 14 Jun 2011 06:57:20 GMT Message-Id: <201106140657.p5E6vKkW006879@freefall.freebsd.org> To: ae@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/152360: [dummynet] [panic] Crash related to dummynet. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 06:57:20 -0000 Synopsis: [dummynet] [panic] Crash related to dummynet. Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: ae Responsible-Changed-When: Tue Jun 14 06:56:18 UTC 2011 Responsible-Changed-Why: Reassign. It's ipfw related. http://www.freebsd.org/cgi/query-pr.cgi?pr=152360 From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 09:55:07 2011 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 F12F2106566B for ; Tue, 14 Jun 2011 09:55:07 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 4B9B48FC13 for ; Tue, 14 Jun 2011 09:55:06 +0000 (UTC) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id p5E9N3X9057649 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2011 12:23:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4) with ESMTP id p5E9N3SK061635; Tue, 14 Jun 2011 12:23:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p5E9N3bK061634; Tue, 14 Jun 2011 12:23:03 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 14 Jun 2011 12:23:03 +0300 From: Kostik Belousov To: Mikolaj Golub Message-ID: <20110614092303.GG48734@deviant.kiev.zoral.com.ua> References: <86pqmhn1pf.fsf@kopusha.home.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3lc1OntGIaWzUKJL" Content-Disposition: inline In-Reply-To: <86pqmhn1pf.fsf@kopusha.home.net> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: Scenario to make recv(MSG_WAITALL) stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 09:55:08 -0000 --3lc1OntGIaWzUKJL Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 13, 2011 at 07:19:40PM +0300, Mikolaj Golub wrote: > Hi, >=20 > Below is a scenario how to make recv(2) with MSG_WAITALL flag get stuck. >=20 > (See http://people.freebsd.org/~trociny/test_MSG_WAITALL.4.c for the test= code). >=20 > Let's the size of the receive buffer is SOBUF_SIZE (e.g. 10000 bytes). >=20 > On sender side do 2 send() requests: >=20 > 1) data of size much smaller than SOBUF_SIZE (e.g. SOBUF_SIZE / 10); >=20 > 2) data of size equal to SOBUF_SIZE. >=20 > After this on receiver side do 2 recv() requests with MSG_WAITALL flag se= t: >=20 > 1) recv() data of SOBUF_SIZE / 10 size; >=20 > 2) recv() data of SOBUF_SIZE size; >=20 > The second recv() will last for very long time. In tcpdump one can observe > that the window is permanently stuck at 0 and pending data is only sent v= ia > TCP window probes (so one byte every few seconds). >=20 > 18:09:14.784698 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [S], seq 1907= 676797, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 22207 ecr = 0], length 0 > 18:09:14.784729 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [S.], seq 229= 8857585, ack 1907676798, win 10000, options [mss 16344,nop,wscale 3,sackOK,= TS val 2718467987 ecr 22207], length 0 > 18:09:14.784749 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], ack 1, w= in 8960, options [nop,nop,TS val 22207 ecr 2718467987], length 0 > 18:09:14.785168 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [P.], seq 1:1= 001, ack 1, win 8960, options [nop,nop,TS val 22207 ecr 2718467987], length= 1000 > 18:09:14.785264 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1001= :10001, ack 1, win 8960, options [nop,nop,TS val 22207 ecr 2718467987], len= gth 9000 > 18:09:14.785280 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 1, win 0, options [nop,nop,TS val 2718467987 ecr 22207], length 0 > 18:09:19.784440 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 1:10002, ack 1, win 8960, options [nop,nop,TS val 22707 ecr 2718467987], le= ngth 1 > 18:09:19.784480 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 1, win 0, options [nop,nop,TS val 2718468487 ecr 22707], length 0 > 18:09:24.784439 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 1:10002, ack 1, win 8960, options [nop,nop,TS val 23207 ecr 2718468487], le= ngth 1 > 18:09:24.784472 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 2, win 0, options [nop,nop,TS val 2718468987 ecr 23207], length 0 > 18:09:29.784437 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 2:10003, ack 1, win 8960, options [nop,nop,TS val 23707 ecr 2718468987], le= ngth 1 > 18:09:29.784478 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 3, win 0, options [nop,nop,TS val 2718469487 ecr 23707], length 0 > 18:09:34.784444 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 3:10004, ack 1, win 8960, options [nop,nop,TS val 24207 ecr 2718469487], le= ngth 1 > 18:09:34.784486 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 4, win 0, options [nop,nop,TS val 2718469987 ecr 24207], length 0 > 18:09:39.784443 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 4:10005, ack 1, win 8960, options [nop,nop,TS val 24707 ecr 2718469987], le= ngth 1 > 18:09:39.784478 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 5, win 0, options [nop,nop,TS val 2718470487 ecr 24707], length 0 > 18:09:44.784442 IP 127.0.0.1.53378 > 127.0.0.1.23481: Flags [.], seq 1000= 5:10006, ack 1, win 8960, options [nop,nop,TS val 25207 ecr 2718470487], le= ngth 1 > 18:09:44.784477 IP 127.0.0.1.23481 > 127.0.0.1.53378: Flags [.], ack 1000= 6, win 0, options [nop,nop,TS val 2718470987 ecr 25207], length 0 > ... >=20 > I first noticed this issue with HAST and suspect other people observed it= with > HAST too. >=20 > Below is explanation what is going on. >=20 > We totaly filled the receiver buffer with one SOBUF_SIZE/10 size request = and > partial SOBUF_SIZE request. When the first request was processed we got > SOBUF_SIZE/10 free space. It was just enogh to recive the rest of bytes f= or > the second request, and the reciving thread went in soreceive_generic->sb= wait > here: >=20 > /* > * If we have less data than requested, block awaiting more (subj= ect > * to any timeout) if: > * 1. the current count is less than the low water mark, or > * 2. MSG_WAITALL is set, and it is possible to do the entire > * receive operation at once if we block (resid <=3D hiwat). > * 3. MSG_DONTWAIT is not set > * If MSG_WAITALL is set but resid is larger than the receive buf= fer, > * we have to do the receive in sections, and thus risk returning= a > * short count if a timeout or signal occurs after we start. > */ > if (m =3D=3D NULL || (((flags & MSG_DONTWAIT) =3D=3D 0 && > so->so_rcv.sb_cc < uio->uio_resid) && > (so->so_rcv.sb_cc < so->so_rcv.sb_lowat || > ((flags & MSG_WAITALL) && uio->uio_resid <=3D so->so_rcv.sb_h= iwat)) && > m->m_nextpkt =3D=3D NULL && (pr->pr_flags & PR_ATOMIC) =3D=3D= 0)) { > ... > error =3D sbwait(&so->so_rcv); >=20 > recvbuf is almost full but has enough space to satisfy MSG_WAITALL request > without draining data to user buffer, and soreceive waits for data. But t= he > window was closed when the buffer was filled and to avoid silly window > syndrome it opens only when available space is larger than sb_hiwat/4 or > maxseg: >=20 > tcp_output(): >=20 > /* > * Calculate receive window. Don't shrink window, > * but avoid silly window syndrome. > */ > if (recwin < (long)(so->so_rcv.sb_hiwat / 4) && > recwin < (long)tp->t_maxseg) > recwin =3D 0; >=20 > so it is stuck and pending data is only sent via TCP window probes. >=20 > It looks like the fix could be to remove this condition to block if > MSG_WAITALL is set and it is possible to do the entire receive operation = at > once, like in the patch: >=20 > http://people.freebsd.org/~trociny/uipc_socket.c.soreceive_generic.MSG_DO= NTWAIT.patch >=20 > This works for me but I am not sure this is a correct solution. >=20 > Note, the issue is not reproduced with soreceive_stream. >=20 I do not understand what then happens for the recvfrom(2) call ? Would it get some error, or 0 as return and no data, or something else ? Also, what is the MT_CONTROL chunk about ? --3lc1OntGIaWzUKJL Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk33KHcACgkQC3+MBN1Mb4iprACg1vS2OwYrzEl3p9lkyzEg0GuH 3PQAoIO+Pj62IonkyB2UzamxDS3TGX2Z =KRFM -----END PGP SIGNATURE----- --3lc1OntGIaWzUKJL-- From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 14:39:33 2011 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 4E26A1065672 for ; Tue, 14 Jun 2011 14:39:33 +0000 (UTC) (envelope-from spinthiras.mario@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id F37978FC0A for ; Tue, 14 Jun 2011 14:39:32 +0000 (UTC) Received: by vxc34 with SMTP id 34so6494822vxc.13 for ; Tue, 14 Jun 2011 07:39:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=ABS+6DY+mcCUijjg9tKZhRIZ1YoXcPPdLSPWNwwkhbU=; b=aAtbFpHFT5X4y0ubVM01/hcemFIf8Hq92ch332oXmnmNwkqKKoT7u0pAG8WVn0N8PM bprovl7SZPuE7RN/2GcZvGILd/7teQ2Go7R8w9+XqCLV6t9tYy2i7Vkf1zexJXRkHfjJ NyIwUWsYuJL4YQgjwY8qoMlZZBdJQixkfcbFQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=HSZy+05PvFgvhs9ygKi0msiJ7yAAbNPmLlZAnx49rDxQG6FNaLmECoEU3yNbCqICzc J3HnsaP/SKuLpgkkC+6B3VsC7pmkzXMVyb5qfPN2iWNZ0+ZGsXUJsjHTPaCNRwVEdOqW PERAzQ5tz0s39AIOMy0NeRBovAQp7Ls/Z4590= Received: by 10.52.177.104 with SMTP id cp8mr5743009vdc.132.1308062372184; Tue, 14 Jun 2011 07:39:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.4 with HTTP; Tue, 14 Jun 2011 07:38:52 -0700 (PDT) In-Reply-To: References: From: Mario Spinthiras Date: Tue, 14 Jun 2011 15:38:52 +0100 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 14:39:33 -0000 Hello everyone, I'm back with more updates on the issue. Forgive my lack of elaboration on the topic in my previous post; over the frustration of this problem I couldn't see this topic through so I let it go for a few days to revisit with a clear head perhaps. As I mentioned in a previous post, the problem is between 2 nodes running PfSense 2.0 RC1 over a point to point link. The uname from the machines: Endpoint A: [2.0-RC1][root@pfSense.localdomain]/root(3): uname -a FreeBSD pfSense.localdomain 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Sat Feb 26 18:05:58 EST 2011 root@FreeBSD_8.0_pfSense_2.0-AMD64.snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 amd64 [2.0-RC1][root@pfSense.localdomain]/root(4): Enpoint B: [2.0-RC1][root@pfsense.localdomain]/root(1): uname -a FreeBSD pfsense.localdomain 8.1-RELEASE-p3 FreeBSD 8.1-RELEASE-p3 #1: Tue Apr 26 20:56:16 EDT 2011 sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 i386 [2.0-RC1][root@pfsense.localdomain]/root(2): The link has a RTT of 130ms. The link's traffic is for the most part TCP with UDP not being used much. The performance of the link in one direction is fine (expected 160 odd Mbps). In the other direction it seems the link struggles to climb even with a 3 MB window size and all sorts of tuning on the stack. An output of the iperf test running for 20 seconds produces the following results: Node A: [2.0-RC1][root@pfSense.localdomain]/root(24): iperf -c b.b.b.b -w 3M -t 20 -i 5 ------------------------------------------------------------ Client connecting to b.b.b.b, TCP port 5001 TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) ------------------------------------------------------------ [ 3] local a.a.a.a port 22995 connected with b.b.b.b port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0- 5.0 sec 75.3 MBytes 126 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 5.0-10.0 sec 107 MBytes 180 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 10.0-15.0 sec 107 MBytes 180 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 15.0-20.0 sec 108 MBytes 181 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-20.2 sec 404 MBytes 167 Mbits/sec [2.0-RC1][root@pfSense.localdomain]/root(25): Node B: [2.0-RC1][root@pfsense.localdomain]/root(2): iperf -c a.a.a.a -t 20 -i 10 -w 3M ------------------------------------------------------------ Client connecting to a.a.a.a, TCP port 5001 TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) ------------------------------------------------------------ [ 3] local b.b.b.b port 44160 connected with a.a.a.a port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 7.73 MBytes 6.49 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 10.0-20.0 sec 9.95 MBytes 8.34 Mbits/sec [ ID] Interval Transfer Bandwidth [ 3] 0.0-20.3 sec 18.1 MBytes 7.47 Mbits/sec [2.0-RC1][root@pfsense.localdomain]/root(3): The performance is terrible in Node B. Their corresponding interfaces look like this: Node A: [2.0-RC1][root@pfSense.localdomain]/root(26): ifconfig igb1 igb1: flags=28943 metric 0 mtu 1500 options=100bb ether 00:1b:21:9b:6e:ab inet6 fe80::21b:21ff:fe9b:6eab%igb1 prefixlen 64 scopeid 0x4 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active [2.0-RC1][root@pfSense.localdomain]/root(27): [2.0-RC1][root@pfSense.localdomain]/root(28): ifconfig igb1_593 igb1_593: flags=8843 metric 0 mtu 1500 options=3 ether 00:1b:21:9b:6e:ab inet6 fe80::225:90ff:fe20:5510%igb1_593 prefixlen 64 scopeid 0xa inet a.a.a.a netmask 0xfffffff8 broadcast x.x.x.x nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active vlan: 593 parent interface: igb1 [2.0-RC1][root@pfSense.localdomain]/root(29): Node B: [2.0-RC1][root@pfsense.localdomain]/root(48): ifconfig igb3 igb3: flags=8843 metric 0 mtu 1500 options=101bb ether 00:1b:21:8e:2b:5f inet6 fe80::21b:21ff:fe8e:2b5f%igb3 prefixlen 64 scopeid 0x4 nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active [2.0-RC1][root@pfsense.localdomain]/root(49): ifconfig igb3_vlan593 igb3_vlan593: flags=8843 metric 0 mtu 1500 options=3 ether 00:1b:21:8e:2b:5f inet6 fe80::21b:21ff:fe8e:2b5c%igb3_vlan593 prefixlen 64 scopeid 0xb inet b.b.b.b netmask 0xfffffff8 broadcast x.x.x.x nd6 options=3 media: Ethernet autoselect (1000baseT ) status: active vlan: 593 parent interface: igb3 [2.0-RC1][root@pfsense.localdomain]/root(50): As you can see from the ifconfig output, the link runs dot1q with a VID of 593. The netstat -m counters: Node A: [2.0-RC1][root@pfSense.localdomain]/root(29): netstat -m 10261/10606/20867 mbufs in use (current/cache/total) 10241/5957/16198/25600 mbuf clusters in use (current/cache/total/max) 10240/5120 mbuf+clusters out of packet secondary zone in use (current/cache) 0/3989/3989/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 25612K/33173K/58785K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/0/0 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines [2.0-RC1][root@pfSense.localdomain]/root(30): Node B: [2.0-RC1][root@pfsense.localdomain]/root(50): netstat -m 9691/4274/13965 mbufs in use (current/cache/total) 6355/1891/8246/25600 mbuf clusters in use (current/cache/total/max) 6354/1070 mbuf+clusters out of packet secondary zone in use (current/cache) 1216/1271/2487/12800 4k (page size) jumbo clusters in use (current/cache/total/max) 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) 20091K/9934K/30026K bytes allocated to network (current/cache/total) 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) 0/0/0 requests for jumbo clusters denied (4k/9k/16k) 0/8/6656 sfbufs in use (current/peak/max) 0 requests for sfbufs denied 0 requests for sfbufs delayed 0 requests for I/O initiated by sendfile 0 calls to protocol drain routines [2.0-RC1][root@pfsense.localdomain]/root(51): dmesg output on both nodes. Node A: igb1: port 0xe880-0xe89f mem 0xf97e0000-0xf97fffff,0xf9c00000-0xf9ffffff,0xf97dc000-0xf97dffff irq 17 at device 0.1 on pci3 igb1: Using MSIX interrupts with 5 vectors igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] igb1: [ITHREAD] Node B: igb3: port 0xc880-0xc89f mem 0xf9fe0000-0xf9ffffff,0xfa000000-0xfa3fffff,0xf9fdc000-0xf9fdffff irq 37 at device 0.1 on pci6 igb3: Using MSIX interrupts with 5 vectors igb3: [ITHREAD] igb3: [ITHREAD] igb3: [ITHREAD] igb3: [ITHREAD] igb3: [ITHREAD] igb3: link state changed to UP igb3_vlan593: link state changed to UP pciconf output: Node A: igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 rev=0x01hdr=0x00 class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf97e0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xf9c00000, size 4194304, enabled bar [18] = type I/O Port, range 32, base 0xe880, size 32, enabled bar [1c] = type Memory, range 32, base 0xf97dc000, size 16384, enabled Node B: igb3@pci0:6:0:1: class=0x020000 card=0xa02b8086 chip=0x10e88086 rev=0x01 hdr=0x00 class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xf9fe0000, size 131072, enabled bar [14] = type Memory, range 32, base 0xfa000000, size 4194304, enabled bar [18] = type I/O Port, range 32, base 0xc880, size 32, enabled bar [1c] = type Memory, range 32, base 0xf9fdc000, size 16384, enabled I've been looking at issues regarding performance with the igb issue from a few years back at this thread : http://lists.freebsd.org/pipermail/freebsd-doc/2009-June/015983.html. These are very similar problems to what I'm having however disabling LRO and TSO does not work for me. I'm quite frustrated with this because I'm not getting an error or not looking in the right place. Can someone out there point me in the right direction? Any help will be much appreciated. Warm Regards, Mario Spinthiras From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 16:33:49 2011 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 45F74106567B for ; Tue, 14 Jun 2011 16:33:49 +0000 (UTC) (envelope-from prvs=1146ddc565=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id C215C8FC13 for ; Tue, 14 Jun 2011 16:33:48 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Tue, 14 Jun 2011 17:21:41 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Tue, 14 Jun 2011 17:21:41 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013586266.msg for ; Tue, 14 Jun 2011 17:21:39 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1146ddc565=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <1922F0D311E24052A6F2C728D504E924@multiplay.co.uk> From: "Steven Hartland" To: "Mario Spinthiras" , References: Date: Tue, 14 Jun 2011 17:22:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 16:33:49 -0000 ----- Original Message ----- From: "Mario Spinthiras" > > I've been looking at issues regarding performance with the igb issue from a > few years back at this thread : > http://lists.freebsd.org/pipermail/freebsd-doc/2009-June/015983.html. These > are very similar problems to what I'm having however disabling LRO and TSO > does not work for me. When you said you have disabled them, how did you do this as its key to if it will fix your issue or not? Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Tue Jun 14 17:15:10 2011 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 348F7106567A for ; Tue, 14 Jun 2011 17:15:10 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id A3A108FC1C for ; Tue, 14 Jun 2011 17:15:08 +0000 (UTC) Received: by vxc34 with SMTP id 34so6689110vxc.13 for ; Tue, 14 Jun 2011 10:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Muz4IERSe2ZiNw/ojbqrWjsYr+XLoZY9V5Dam1eU+cA=; b=VJ3E3AVoQaM7dl/acnDxWo8F34gcFd75eszFNNs/WOeTRSMuLmEtLGK7I6Z6Ho9jVl gJYpV5XvKmFAR+pbaJX4MwZL15qtOlxsdWPET45haFY3aiZiaBSzyxUZ2aYFFPVlt+c6 vlzyFSY0N+aY4YRAVgpzhoJ1dXukoP45scS+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RZTnptd7lc0++TU6MoRti56gsTzxBQeV0PbXpCZxXlG6gpbwjsuAKuTjoT5tG+IQsq /Oa8GMTFpPbdaZaXpU5WL030YzLOO2whHGh6W+lbWcuzHwIsg9VPeliMHMMj5MAElLrB tHF6ryrNKE3HL/E1wh3RwGP+N5Tb7Niadat6I= MIME-Version: 1.0 Received: by 10.52.115.163 with SMTP id jp3mr5147089vdb.187.1308071707214; Tue, 14 Jun 2011 10:15:07 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 14 Jun 2011 10:15:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 10:15:07 -0700 Message-ID: From: Jack Vogel To: Mario Spinthiras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 17:15:10 -0000 Why do you have TSO off. If you run the same connection without the vlan what do you see? Jack On Tue, Jun 14, 2011 at 7:38 AM, Mario Spinthiras < spinthiras.mario@gmail.com> wrote: > Hello everyone, > > I'm back with more updates on the issue. Forgive my lack of elaboration on > the topic in my previous post; over the frustration of this problem I > couldn't see this topic through so I let it go for a few days to revisit > with a clear head perhaps. > > As I mentioned in a previous post, the problem is between 2 nodes running > PfSense 2.0 RC1 over a point to point link. The uname from the machines: > > Endpoint A: > > [2.0-RC1][root@pfSense.localdomain]/root(3): uname -a > FreeBSD pfSense.localdomain 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Sat > Feb 26 18:05:58 EST 2011 > root@FreeBSD_8.0_pfSense_2.0-AMD64.snaps.pfsense.org: > /usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 > amd64 > [2.0-RC1][root@pfSense.localdomain]/root(4): > > Enpoint B: > > [2.0-RC1][root@pfsense.localdomain]/root(1): uname -a > FreeBSD pfsense.localdomain 8.1-RELEASE-p3 FreeBSD 8.1-RELEASE-p3 #1: Tue > Apr 26 20:56:16 EDT 2011 > sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org: > /usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 > i386 > [2.0-RC1][root@pfsense.localdomain]/root(2): > > > The link has a RTT of 130ms. The link's traffic is for the most part TCP > with UDP not being used much. The performance of the link in one direction > is fine (expected 160 odd Mbps). In the other direction it seems the link > struggles to climb even with a 3 MB window size and all sorts of tuning on > the stack. An output of the iperf test running for 20 seconds produces the > following results: > > Node A: > > [2.0-RC1][root@pfSense.localdomain]/root(24): iperf -c b.b.b.b -w 3M -t 20 > -i 5 > ------------------------------------------------------------ > Client connecting to b.b.b.b, TCP port 5001 > TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) > ------------------------------------------------------------ > [ 3] local a.a.a.a port 22995 connected with b.b.b.b port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0- 5.0 sec 75.3 MBytes 126 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 5.0-10.0 sec 107 MBytes 180 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 10.0-15.0 sec 107 MBytes 180 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 15.0-20.0 sec 108 MBytes 181 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-20.2 sec 404 MBytes 167 Mbits/sec > [2.0-RC1][root@pfSense.localdomain]/root(25): > > > Node B: > > [2.0-RC1][root@pfsense.localdomain]/root(2): iperf -c a.a.a.a -t 20 -i 10 > -w > 3M > ------------------------------------------------------------ > Client connecting to a.a.a.a, TCP port 5001 > TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) > ------------------------------------------------------------ > [ 3] local b.b.b.b port 44160 connected with a.a.a.a port 5001 > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 7.73 MBytes 6.49 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 10.0-20.0 sec 9.95 MBytes 8.34 Mbits/sec > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-20.3 sec 18.1 MBytes 7.47 Mbits/sec > [2.0-RC1][root@pfsense.localdomain]/root(3): > > The performance is terrible in Node B. > > Their corresponding interfaces look like this: > > Node A: > > [2.0-RC1][root@pfSense.localdomain]/root(26): ifconfig igb1 > igb1: flags=28943 > metric 0 mtu 1500 > > > options=100bb > ether 00:1b:21:9b:6e:ab > inet6 fe80::21b:21ff:fe9b:6eab%igb1 prefixlen 64 scopeid 0x4 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > [2.0-RC1][root@pfSense.localdomain]/root(27): > > [2.0-RC1][root@pfSense.localdomain]/root(28): ifconfig igb1_593 > igb1_593: flags=8843 metric 0 mtu > 1500 > options=3 > ether 00:1b:21:9b:6e:ab > inet6 fe80::225:90ff:fe20:5510%igb1_593 prefixlen 64 scopeid 0xa > inet a.a.a.a netmask 0xfffffff8 broadcast x.x.x.x > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 593 parent interface: igb1 > [2.0-RC1][root@pfSense.localdomain]/root(29): > > Node B: > > [2.0-RC1][root@pfsense.localdomain]/root(48): ifconfig igb3 > igb3: flags=8843 metric 0 mtu 1500 > > > options=101bb > ether 00:1b:21:8e:2b:5f > inet6 fe80::21b:21ff:fe8e:2b5f%igb3 prefixlen 64 scopeid 0x4 > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > [2.0-RC1][root@pfsense.localdomain]/root(49): ifconfig igb3_vlan593 > igb3_vlan593: flags=8843 metric 0 > mtu 1500 > options=3 > ether 00:1b:21:8e:2b:5f > inet6 fe80::21b:21ff:fe8e:2b5c%igb3_vlan593 prefixlen 64 scopeid 0xb > inet b.b.b.b netmask 0xfffffff8 broadcast x.x.x.x > nd6 options=3 > media: Ethernet autoselect (1000baseT ) > status: active > vlan: 593 parent interface: igb3 > [2.0-RC1][root@pfsense.localdomain]/root(50): > > > As you can see from the ifconfig output, the link runs dot1q with a VID of > 593. > > The netstat -m counters: > > Node A: > > [2.0-RC1][root@pfSense.localdomain]/root(29): netstat -m > 10261/10606/20867 mbufs in use (current/cache/total) > 10241/5957/16198/25600 mbuf clusters in use (current/cache/total/max) > 10240/5120 mbuf+clusters out of packet secondary zone in use > (current/cache) > 0/3989/3989/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 25612K/33173K/58785K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/0/0 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > [2.0-RC1][root@pfSense.localdomain]/root(30): > > Node B: > > [2.0-RC1][root@pfsense.localdomain]/root(50): netstat -m > 9691/4274/13965 mbufs in use (current/cache/total) > 6355/1891/8246/25600 mbuf clusters in use (current/cache/total/max) > 6354/1070 mbuf+clusters out of packet secondary zone in use (current/cache) > 1216/1271/2487/12800 4k (page size) jumbo clusters in use > (current/cache/total/max) > 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) > 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) > 20091K/9934K/30026K bytes allocated to network (current/cache/total) > 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) > 0/0/0 requests for jumbo clusters denied (4k/9k/16k) > 0/8/6656 sfbufs in use (current/peak/max) > 0 requests for sfbufs denied > 0 requests for sfbufs delayed > 0 requests for I/O initiated by sendfile > 0 calls to protocol drain routines > [2.0-RC1][root@pfsense.localdomain]/root(51): > > > dmesg output on both nodes. > > Node A: > > igb1: port > 0xe880-0xe89f mem > 0xf97e0000-0xf97fffff,0xf9c00000-0xf9ffffff,0xf97dc000-0xf97dffff irq 17 at > device 0.1 on pci3 > igb1: Using MSIX interrupts with 5 vectors > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > igb1: [ITHREAD] > > > Node B: > > igb3: port > 0xc880-0xc89f mem > 0xf9fe0000-0xf9ffffff,0xfa000000-0xfa3fffff,0xf9fdc000-0xf9fdffff irq 37 at > device 0.1 on pci6 > igb3: Using MSIX interrupts with 5 vectors > igb3: [ITHREAD] > igb3: [ITHREAD] > igb3: [ITHREAD] > igb3: [ITHREAD] > igb3: [ITHREAD] > igb3: link state changed to UP > igb3_vlan593: link state changed to UP > > > pciconf output: > > Node A: > > igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 > rev=0x01hdr=0x00 > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xf97e0000, size 131072, > enabled > bar [14] = type Memory, range 32, base 0xf9c00000, size 4194304, > enabled > bar [18] = type I/O Port, range 32, base 0xe880, size 32, enabled > bar [1c] = type Memory, range 32, base 0xf97dc000, size 16384, enabled > > > Node B: > > igb3@pci0:6:0:1: class=0x020000 card=0xa02b8086 chip=0x10e88086 > rev=0x01 hdr=0x00 > class = network > subclass = ethernet > bar [10] = type Memory, range 32, base 0xf9fe0000, size 131072, > enabled > bar [14] = type Memory, range 32, base 0xfa000000, size 4194304, > enabled > bar [18] = type I/O Port, range 32, base 0xc880, size 32, enabled > bar [1c] = type Memory, range 32, base 0xf9fdc000, size 16384, enabled > > > I've been looking at issues regarding performance with the igb issue from a > few years back at this thread : > http://lists.freebsd.org/pipermail/freebsd-doc/2009-June/015983.html. > These > are very similar problems to what I'm having however disabling LRO and TSO > does not work for me. > > I'm quite frustrated with this because I'm not getting an error or not > looking in the right place. Can someone out there point me in the right > direction? Any help will be much appreciated. > > Warm Regards, > Mario Spinthiras > _______________________________________________ > 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 Tue Jun 14 17:17:26 2011 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 9BB10106564A for ; Tue, 14 Jun 2011 17:17:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B71F8FC14 for ; Tue, 14 Jun 2011 17:17:25 +0000 (UTC) Received: by vws18 with SMTP id 18so6676661vws.13 for ; Tue, 14 Jun 2011 10:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=MB1ZPJklTV4M/uFzgjNMMV+7BD8h5uifrJSViGXmzbQ=; b=sz0l8Xw4AvyAKeU2srtUAw01SqhlF54xs4rKlQ+ZsZUu5A5wJ8V7VKYym1a0qF3vmS 5Du4ugsTmMbQ8zWwig31hWzlhbV8Qv5fmp/WAnsaBJ6J7Pq49CzWXJnwrr83ZQjZ5Afh 7XucWth0W9Ha/9sYUyEnt2mFb/swPOz7QZ34g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=nf3YtrXJH3Mlb29pTMsaqsavIu7hOyNKnE7Mxws9sCLpgbkl/pRII8GaqDdjRgYUqd 06mz4fF2gwjwNFEybEHeKcWhjbaMRIciTLQfMUUwHieBKI0Zu/i+vIb23ouWxjFzG3E3 A1e4hnzC7OGuv5CVJamJ8HtStkjXHfJ2aPZjA= MIME-Version: 1.0 Received: by 10.52.96.134 with SMTP id ds6mr7951544vdb.27.1308071845224; Tue, 14 Jun 2011 10:17:25 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Tue, 14 Jun 2011 10:17:25 -0700 (PDT) In-Reply-To: References: Date: Tue, 14 Jun 2011 10:17:25 -0700 Message-ID: From: Jack Vogel To: Mario Spinthiras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 17:17:26 -0000 PS. My driver does not smell :), however if you want the 'freshest' smell possible maybe you should update to the version in STABLE/8 :) Jack On Tue, Jun 14, 2011 at 10:15 AM, Jack Vogel wrote: > Why do you have TSO off. If you run the same connection without the vlan > what do you see? > > Jack > > > > On Tue, Jun 14, 2011 at 7:38 AM, Mario Spinthiras < > spinthiras.mario@gmail.com> wrote: > >> Hello everyone, >> >> I'm back with more updates on the issue. Forgive my lack of elaboration >> on >> the topic in my previous post; over the frustration of this problem I >> couldn't see this topic through so I let it go for a few days to revisit >> with a clear head perhaps. >> >> As I mentioned in a previous post, the problem is between 2 nodes running >> PfSense 2.0 RC1 over a point to point link. The uname from the machines: >> >> Endpoint A: >> >> [2.0-RC1][root@pfSense.localdomain]/root(3): uname -a >> FreeBSD pfSense.localdomain 8.1-RELEASE-p2 FreeBSD 8.1-RELEASE-p2 #0: Sat >> Feb 26 18:05:58 EST 2011 >> root@FreeBSD_8.0_pfSense_2.0-AMD64.snaps.pfsense.org: >> /usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 >> amd64 >> [2.0-RC1][root@pfSense.localdomain]/root(4): >> >> Enpoint B: >> >> [2.0-RC1][root@pfsense.localdomain]/root(1): uname -a >> FreeBSD pfsense.localdomain 8.1-RELEASE-p3 FreeBSD 8.1-RELEASE-p3 #1: Tue >> Apr 26 20:56:16 EDT 2011 >> sullrich@FreeBSD_8.0_pfSense_2.0-snaps.pfsense.org: >> /usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 >> i386 >> [2.0-RC1][root@pfsense.localdomain]/root(2): >> >> >> The link has a RTT of 130ms. The link's traffic is for the most part TCP >> with UDP not being used much. The performance of the link in one direction >> is fine (expected 160 odd Mbps). In the other direction it seems the link >> struggles to climb even with a 3 MB window size and all sorts of tuning on >> the stack. An output of the iperf test running for 20 seconds produces the >> following results: >> >> Node A: >> >> [2.0-RC1][root@pfSense.localdomain]/root(24): iperf -c b.b.b.b -w 3M -t >> 20 >> -i 5 >> ------------------------------------------------------------ >> Client connecting to b.b.b.b, TCP port 5001 >> TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) >> ------------------------------------------------------------ >> [ 3] local a.a.a.a port 22995 connected with b.b.b.b port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0- 5.0 sec 75.3 MBytes 126 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 5.0-10.0 sec 107 MBytes 180 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 10.0-15.0 sec 107 MBytes 180 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 15.0-20.0 sec 108 MBytes 181 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-20.2 sec 404 MBytes 167 Mbits/sec >> [2.0-RC1][root@pfSense.localdomain]/root(25): >> >> >> Node B: >> >> [2.0-RC1][root@pfsense.localdomain]/root(2): iperf -c a.a.a.a -t 20 -i 10 >> -w >> 3M >> ------------------------------------------------------------ >> Client connecting to a.a.a.a, TCP port 5001 >> TCP window size: 3.00 MByte (WARNING: requested 3.00 MByte) >> ------------------------------------------------------------ >> [ 3] local b.b.b.b port 44160 connected with a.a.a.a port 5001 >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-10.0 sec 7.73 MBytes 6.49 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 10.0-20.0 sec 9.95 MBytes 8.34 Mbits/sec >> [ ID] Interval Transfer Bandwidth >> [ 3] 0.0-20.3 sec 18.1 MBytes 7.47 Mbits/sec >> [2.0-RC1][root@pfsense.localdomain]/root(3): >> >> The performance is terrible in Node B. >> >> Their corresponding interfaces look like this: >> >> Node A: >> >> [2.0-RC1][root@pfSense.localdomain]/root(26): ifconfig igb1 >> igb1: flags=28943 >> metric 0 mtu 1500 >> >> >> options=100bb >> ether 00:1b:21:9b:6e:ab >> inet6 fe80::21b:21ff:fe9b:6eab%igb1 prefixlen 64 scopeid 0x4 >> nd6 options=3 >> media: Ethernet autoselect (1000baseT ) >> status: active >> [2.0-RC1][root@pfSense.localdomain]/root(27): >> >> [2.0-RC1][root@pfSense.localdomain]/root(28): ifconfig igb1_593 >> igb1_593: flags=8843 metric 0 mtu >> 1500 >> options=3 >> ether 00:1b:21:9b:6e:ab >> inet6 fe80::225:90ff:fe20:5510%igb1_593 prefixlen 64 scopeid 0xa >> inet a.a.a.a netmask 0xfffffff8 broadcast x.x.x.x >> nd6 options=3 >> media: Ethernet autoselect (1000baseT ) >> status: active >> vlan: 593 parent interface: igb1 >> [2.0-RC1][root@pfSense.localdomain]/root(29): >> >> Node B: >> >> [2.0-RC1][root@pfsense.localdomain]/root(48): ifconfig igb3 >> igb3: flags=8843 metric 0 mtu 1500 >> >> >> options=101bb >> ether 00:1b:21:8e:2b:5f >> inet6 fe80::21b:21ff:fe8e:2b5f%igb3 prefixlen 64 scopeid 0x4 >> nd6 options=3 >> media: Ethernet autoselect (1000baseT ) >> status: active >> [2.0-RC1][root@pfsense.localdomain]/root(49): ifconfig igb3_vlan593 >> igb3_vlan593: flags=8843 metric 0 >> mtu 1500 >> options=3 >> ether 00:1b:21:8e:2b:5f >> inet6 fe80::21b:21ff:fe8e:2b5c%igb3_vlan593 prefixlen 64 scopeid >> 0xb >> inet b.b.b.b netmask 0xfffffff8 broadcast x.x.x.x >> nd6 options=3 >> media: Ethernet autoselect (1000baseT ) >> status: active >> vlan: 593 parent interface: igb3 >> [2.0-RC1][root@pfsense.localdomain]/root(50): >> >> >> As you can see from the ifconfig output, the link runs dot1q with a VID of >> 593. >> >> The netstat -m counters: >> >> Node A: >> >> [2.0-RC1][root@pfSense.localdomain]/root(29): netstat -m >> 10261/10606/20867 mbufs in use (current/cache/total) >> 10241/5957/16198/25600 mbuf clusters in use (current/cache/total/max) >> 10240/5120 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 0/3989/3989/12800 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) >> 25612K/33173K/58785K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/0/0 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> [2.0-RC1][root@pfSense.localdomain]/root(30): >> >> Node B: >> >> [2.0-RC1][root@pfsense.localdomain]/root(50): netstat -m >> 9691/4274/13965 mbufs in use (current/cache/total) >> 6355/1891/8246/25600 mbuf clusters in use (current/cache/total/max) >> 6354/1070 mbuf+clusters out of packet secondary zone in use >> (current/cache) >> 1216/1271/2487/12800 4k (page size) jumbo clusters in use >> (current/cache/total/max) >> 0/0/0/6400 9k jumbo clusters in use (current/cache/total/max) >> 0/0/0/3200 16k jumbo clusters in use (current/cache/total/max) >> 20091K/9934K/30026K bytes allocated to network (current/cache/total) >> 0/0/0 requests for mbufs denied (mbufs/clusters/mbuf+clusters) >> 0/0/0 requests for jumbo clusters denied (4k/9k/16k) >> 0/8/6656 sfbufs in use (current/peak/max) >> 0 requests for sfbufs denied >> 0 requests for sfbufs delayed >> 0 requests for I/O initiated by sendfile >> 0 calls to protocol drain routines >> [2.0-RC1][root@pfsense.localdomain]/root(51): >> >> >> dmesg output on both nodes. >> >> Node A: >> >> igb1: port >> 0xe880-0xe89f mem >> 0xf97e0000-0xf97fffff,0xf9c00000-0xf9ffffff,0xf97dc000-0xf97dffff irq 17 >> at >> device 0.1 on pci3 >> igb1: Using MSIX interrupts with 5 vectors >> igb1: [ITHREAD] >> igb1: [ITHREAD] >> igb1: [ITHREAD] >> igb1: [ITHREAD] >> igb1: [ITHREAD] >> >> >> Node B: >> >> igb3: port >> 0xc880-0xc89f mem >> 0xf9fe0000-0xf9ffffff,0xfa000000-0xfa3fffff,0xf9fdc000-0xf9fdffff irq 37 >> at >> device 0.1 on pci6 >> igb3: Using MSIX interrupts with 5 vectors >> igb3: [ITHREAD] >> igb3: [ITHREAD] >> igb3: [ITHREAD] >> igb3: [ITHREAD] >> igb3: [ITHREAD] >> igb3: link state changed to UP >> igb3_vlan593: link state changed to UP >> >> >> pciconf output: >> >> Node A: >> >> igb1@pci0:3:0:1: class=0x020000 card=0xa03c8086 chip=0x10c98086 >> rev=0x01hdr=0x00 >> class = network >> subclass = ethernet >> bar [10] = type Memory, range 32, base 0xf97e0000, size 131072, >> enabled >> bar [14] = type Memory, range 32, base 0xf9c00000, size 4194304, >> enabled >> bar [18] = type I/O Port, range 32, base 0xe880, size 32, enabled >> bar [1c] = type Memory, range 32, base 0xf97dc000, size 16384, >> enabled >> >> >> Node B: >> >> igb3@pci0:6:0:1: class=0x020000 card=0xa02b8086 chip=0x10e88086 >> rev=0x01 hdr=0x00 >> class = network >> subclass = ethernet >> bar [10] = type Memory, range 32, base 0xf9fe0000, size 131072, >> enabled >> bar [14] = type Memory, range 32, base 0xfa000000, size 4194304, >> enabled >> bar [18] = type I/O Port, range 32, base 0xc880, size 32, enabled >> bar [1c] = type Memory, range 32, base 0xf9fdc000, size 16384, >> enabled >> >> >> I've been looking at issues regarding performance with the igb issue from >> a >> few years back at this thread : >> http://lists.freebsd.org/pipermail/freebsd-doc/2009-June/015983.html. >> These >> are very similar problems to what I'm having however disabling LRO and TSO >> does not work for me. >> >> I'm quite frustrated with this because I'm not getting an error or not >> looking in the right place. Can someone out there point me in the right >> direction? Any help will be much appreciated. >> >> Warm Regards, >> Mario Spinthiras >> _______________________________________________ >> 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 Tue Jun 14 22:51:13 2011 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 DC8E5106566B; Tue, 14 Jun 2011 22:51:12 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yi0-f54.google.com (mail-yi0-f54.google.com [209.85.218.54]) by mx1.freebsd.org (Postfix) with ESMTP id 880A68FC14; Tue, 14 Jun 2011 22:51:12 +0000 (UTC) Received: by yic13 with SMTP id 13so2152142yic.13 for ; Tue, 14 Jun 2011 15:51:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:date:x-google-sender-auth :message-id:subject:from:to:cc:content-type; bh=DGk3iY5W4pOeBwMutcHYG6qfjhJ1A8hNlVb2Qr/2X5s=; b=ZoIdeD+rBWjwTkuoL3YKs2aGkwrSB8zstohzDCF9kJg9a7mzp4k3P/V2n/p1qxB6Wz U1NNpA1CeOgV4ZA5mRHs8L9cxg8++zuHYMjhDykmM/FUIJluPm4MrAZUdXVNtkrNv478 4s5dhwT8LeulelvlRq2W8EPUKYu34gC8eNVus= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; b=bpospt+sMT+8ODyOLZ041A01Q3G+egWMT30beElV3vgGLwg9RfmY1Y2i8tS7sgscPl K5nYYdOljHjBXxqNglPlTmcpKSW9oNOVy52wIO0bVJyoI8A9ntThT/qpJtXeNmVLwEYb GMn8BMjmdcSovrtkUI2fXoPxO4aatOaMB0YE4= MIME-Version: 1.0 Received: by 10.236.186.65 with SMTP id v41mr10935634yhm.1.1308090142297; Tue, 14 Jun 2011 15:22:22 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.61.73 with HTTP; Tue, 14 Jun 2011 15:22:22 -0700 (PDT) Date: Tue, 14 Jun 2011 15:22:22 -0700 X-Google-Sender-Auth: QfrUYqe8tJz_a23dbAhyXwAdlwc Message-ID: From: Artem Belevich To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1 Cc: Rick Macklem Subject: amd + NFS reconnect = ICMP storm + unkillable process. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 14 Jun 2011 22:51:13 -0000 Hi, I wonder if someone else ran into this issue before and, maybe, have a solution. I've been running into a problem where access to filesystems mouted with amd wedges processes in an unkillable state and produces ICMP storm on loopback interface.I've managed to narrow down to NFS reconnect, but that's when I ran out of ideas. Usually the problem happens when I abort a parallel build job in an i386 jail on FreeBSD-8/amd64 (r223055). When the build job is killed now and then I end up with one process consuming 100% of CPU time on one of the cores. At the same time I get a lot of messages on the console saying "Limiting icmp unreach response from 49837 to 200 packets/sec" and the loopback traffic goes way up. As far as I can tell here's what's happening: * My setup uses a lot of filesystems mounted by amd. * amd itself pretends to be an NFS server running on the localhost and serving requests for amd mounts. * Now and then amd seems to change the ports it uses. Beats me why. * the problem seems to happen when some process is about to access amd mountpoint when amd instance disappears from the port it used to listen on. In my case it does correlate with interrupted builds, but I have no clue why. * NFS client detects disconnect and tries to reconnect using the same destination port. * That generates ICMP response as port is unreachable and it reconnect call returns almost immediatelly. * We try to reconnect again, and again, and again.... * the process in this state is unkillable Here's what the stack of the 'stuck' process looks like in those rare moments when it gets to sleep: 18779 100511 collect2 - mi_switch+0x176 turnstile_wait+0x1cb _mtx_lock_sleep+0xe1 sleepq_catch_signals+0x386 sleepq_timedwait_sig+0x19 _sleep+0x1b1 clnt_dg_call+0x7e6 clnt_reconnect_call+0x12e nfs_request+0x212 nfs_getattr+0x2e4 VOP_GETATTR_APV+0x44 nfs_bioread+0x42a VOP_READLINK_APV+0x4a namei+0x4f9 kern_statat_vnhook+0x92 kern_statat+0x15 freebsd32_stat+0x2e syscallenter+0x23d * Usually some timeout expires in few minutes, the process dies, ICMP storm stops and the system is usable again. * On occasion the process is stuck forever and I have to reboot the box. I'm not sure who's to blame here. Is the automounter at fault for disappearing from the port it was supposed to listen to? If NFS guilty of trying blindly to reconnect on the same port and not giving up sooner? Should I flog the operator (ALA myself) for misconfiguring something (what?) in amd or NFS? More importantly -- how do I fix it? Any suggestions on fixing/debugging this issue? --Artem From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 06:44:42 2011 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 45C02106564A; Wed, 15 Jun 2011 06:44:42 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 93DEF8FC14; Wed, 15 Jun 2011 06:44:40 +0000 (UTC) Received: by bwz12 with SMTP id 12so329640bwz.13 for ; Tue, 14 Jun 2011 23:44:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:cc:subject:organization:references :sender:date:in-reply-to:message-id:user-agent:mime-version :content-type; bh=Q4r669Fo9k1aQeZ1/ssZG8q3BS0lUl1GL/snik7m670=; b=hveHCq/wmJLceZwzLZtfuo86zd0+TJsuVw+nu/aobfU7Qb/I4ynfD9MS1WT+vjZanA yVSNblvbyYHey9YQWs68gYVvQKsqJ3MeRdJiRUVvAE/zjP3E5zAbGnIvAiruAbi1xu/t NyWtoiw0duoyO4NoSCH/JxtLD3nOFUQh4voZM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:sender:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=KSc1kwSxJRfInA9/VUIOw5lSjVDuCIZzeGYubr84lIw3IQpf623Ecp/EpgXCZYgO0U adLBgU6UDyhwxafnBA2mwqSKNhNY+TyLI9Xgsxf9jYvPIk1DiUiRAJ1WU/qsHh9VonvA g9iHNICtBVcjzrs17xV0xKorVCrQ+mpBsjL64= Received: by 10.204.42.11 with SMTP id q11mr126349bke.131.1308120279590; Tue, 14 Jun 2011 23:44:39 -0700 (PDT) Received: from localhost ([94.27.39.186]) by mx.google.com with ESMTPS id j7sm94766bka.20.2011.06.14.23.44.35 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 14 Jun 2011 23:44:36 -0700 (PDT) From: Mikolaj Golub To: Kostik Belousov Organization: TOA Ukraine References: <86pqmhn1pf.fsf@kopusha.home.net> <20110614092303.GG48734@deviant.kiev.zoral.com.ua> Sender: Mikolaj Golub Date: Wed, 15 Jun 2011 09:44:33 +0300 In-Reply-To: <20110614092303.GG48734@deviant.kiev.zoral.com.ua> (Kostik Belousov's message of "Tue, 14 Jun 2011 12:23:03 +0300") Message-ID: <86k4cntwz2.fsf@in138.ua3> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Pawel Jakub Dawidek Subject: Re: Scenario to make recv(MSG_WAITALL) stuck X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 06:44:42 -0000 On Tue, 14 Jun 2011 12:23:03 +0300 Kostik Belousov wrote: KB> I do not understand what then happens for the recvfrom(2) call ? KB> Would it get some error, or 0 as return and no data, or something else ? It will wait for data below in another loop ("Now continue to read any data mbufs off of the head..."). Elaborating, I would split soreceive_generic on three logical parts. In the first (restart) part we block until some data are received and also (without the patch) in the case of MSG_WAITALL if the buffer is big enough we block until all MSG_WAITALL request is received (actually it will spin in "goto restart" loop until some condition becomes invalid). The second part is some processing of received data and the third part is a "while" loop where data is copied to userspace and in the case of MSG_WAITALL request if not all data is received to satisfy the request it also waits for this data. My patch removes the condition in the first part in the case of MSG_WAITALL to wait for all data if buffer is big enough. We always will wait for the rest of data in the third part. It might be not so effective, and this is my first concern about the patch (although not big :-). KB> Also, what is the MT_CONTROL chunk about ? When I removed the condition to skip blocking in the first part I started to observe panic on KASSERT(m->m_type == MT_DATA) for the following scenario (produced by HAST): sender: send(4 bytes); /* send protocol name */ sendmsg(); /* send descriptor (normal data is empty, descriptor in control data) */ receiver: recv(127 bytes, MSG_WAITALL); /* recive protocol name */ recvmsg(); /* recive descriptor */ Although the recv() has MSG_WAITALL, it exits after receiving 4 bytes because the next received data is of different (MT_CONTROL) type. An it panicked when got control data. It is unclear for me why it is not expected to have MT_CONTROL data in that part. We do have processing of MT_CONTROL above (in the second part) in the code but I still a have feeling that it is possible to create some scenario to break this assert without my patch too, but I have failed so far. And this is my second concern about my patch, big enough, because for now I am not sure that this is correct. Although I have not observed issues with it so far... Also, I am not sure if there is sense to bother with soreceive_generic() at all. May be it is more perspective to spend time on "maturing" soreceive_stream(). As I see it is going to be a replacement for soreceive_generic() for stream sockets. -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 08:57:07 2011 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 2BEAD106564A for ; Wed, 15 Jun 2011 08:57:07 +0000 (UTC) (envelope-from spinthiras.mario@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id D8EF68FC0C for ; Wed, 15 Jun 2011 08:57:06 +0000 (UTC) Received: by vxc34 with SMTP id 34so193695vxc.13 for ; Wed, 15 Jun 2011 01:57:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=VeB+1lyserePYLZdHAiZp8UtVpUc+tw1BCTTU9fT44k=; b=rXpiWutdeQ4iSkPEPfZr9nVrymSCJRHxrN3wI8MMOSQdVaKmkb43dCSJmJFJjM08BD r6FfTtLWBlvfvZifhF9QUeZkvqFF5C+6j39Yw5wYFgno8XNcR4Vh3A/LWl5nDRr4bobe KmJfQxEi6EA3l/UlKdFiXiWacVVpsuF0/bBaQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=mXRtuIZtN70rIrBhQiBRTy51iy67NMmRVJAsiRuh4JTrYxLz6uJf+KecWtR+lPpm5r KjQAV9bZLbN7f6WeRg2G2GDSIMxbc3yNxRM96IDWV3LZYihxeU60q+41XgQTKhtwcinI PiOfDupdFalS4A570RzR4dSPL9w6LHE7iF4E0= Received: by 10.52.177.104 with SMTP id cp8mr345434vdc.132.1308128226094; Wed, 15 Jun 2011 01:57:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.186.4 with HTTP; Wed, 15 Jun 2011 01:56:26 -0700 (PDT) In-Reply-To: References: From: Mario Spinthiras Date: Wed, 15 Jun 2011 09:56:26 +0100 Message-ID: To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Jack Vogel Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 08:57:07 -0000 Hi, To disable LRO I tried ifconfig igb1 -lro and I also tried adding the sysctl params in loader.conf. Both did not result in any change. I'm going to have to find a way to use the new igb driver I guess, hoping that would fix it maybe. Regards, Mario From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 12:20:10 2011 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 0D73D106566C for ; Wed, 15 Jun 2011 12:20:10 +0000 (UTC) (envelope-from prvs=11471d9592=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 893828FC0C for ; Wed, 15 Jun 2011 12:20:09 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Wed, 15 Jun 2011 13:08:53 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Wed, 15 Jun 2011 13:08:52 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50013689427.msg for ; Wed, 15 Jun 2011 13:08:51 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=11471d9592=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <7258F7D2BBCD4D2A987F8A6B17479166@multiplay.co.uk> From: "Steven Hartland" To: "Mario Spinthiras" , References: Date: Wed, 15 Jun 2011 13:09:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6090 Cc: Jack Vogel Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 12:20:10 -0000 IIRC it needs to be in sysctl.conf, so try that. ----- Original Message ----- From: "Mario Spinthiras" To: Cc: "Jack Vogel" Sent: Wednesday, June 15, 2011 9:56 AM Subject: Re: strange igb interface performance problems > Hi, > > To disable LRO I tried ifconfig igb1 -lro and I also tried adding the > sysctl params in loader.conf. Both did not result in any change. > > I'm going to have to find a way to use the new igb driver I guess, hoping > that would fix it maybe. > > > Regards, > Mario > _______________________________________________ > 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" > ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 16:54:09 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 94F3D106566C for ; Wed, 15 Jun 2011 16:54:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 4F1E18FC12 for ; Wed, 15 Jun 2011 16:54:08 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5FGrq5k087236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 16 Jun 2011 01:54:03 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5FGrogv098146 for ; Thu, 16 Jun 2011 01:53:52 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 01:53:17 +0900 (JST) Message-Id: <20110616.015317.781291617533474654.hrs@allbsd.org> To: net@FreeBSD.org From: Hiroki Sato X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_01_53_17_2011_553)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 01:54:03 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: Subject: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:54:09 -0000 ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I would like your comments about the following issue and proposal. The background is as follows. The resolvconf(8) utility has been imported some time before to handle update of /etc/resolv.conf by using multiple RDNSS (recursive DNS server) information sources. The possible sources are ppp, rtsold, dhclient, mpd, etc. The resolvconf(8) prevents /etc/resolv.conf from being overwritten by multiple information sources disorderly. The RDNSS information is handled by resolvconf(8) in a per-interface basis. When a new RDNSS entry is provided on an interface, it will be registered to resolvconf(8)'s internal database with the interface id, and then resolvconf(8) will update /etc/resolv.conf. The resultant resolv.conf contains aggregate entries from all interfaces. For example, let's consider em0 received RDNSS information via dhclient(8) (DHCPv4), and tun0 received one via ppp(8) (IPCP). In this case, the resolvconf(8) is invoked for each, and /etc/resolv.conf will be updated with all of received information. This is how the resolvconf(8) works. However, the case that there are two or more RDNSS information sources on a single interface at the same time is still troublesome. DHCPv4 + DHCPv6 or rtsol + DHCPv4 on the same interface is a good example. In the latter case, rtsol and dhclient will try to register RDNSS information with the same interface id. As the result, RDNSS entries will be overwritten, and at worst the entries in /etc/resolv.conf will flap repeatedly. My proposal is adding a string representing the information source to the interface id which is used for resolvconf(8). Specifically, I would like to propose to use the following syntax throughout utilities that update /etc/resolv.conf via resolvconf(8): ifname:origin[:unique] "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example. Using this string as an interface id, resolvconf(8) can handle multiple RDNSS entries on a single interface without overwriting each other. Furthermore, priority control can be done with resolvconf.conf and "origin" and/or "unique" keyword in the string. To adopt this naming scheme, patches are needed for dhclient(8), rtsold(8), and all of other resolvconf(8)-aware utilities. There is almost no user-visible change; the difference is that multiple RDNSS entries on a single interface are aggregated and added into /etc/resolv.conf after patching them. Any objections to this? I am working on the necessary changes for utilities in the base system and planning to commit them if there is no strong objection. -- Hiroki ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk34430ACgkQTyzT2CeTzy2fggCfTUowGWcqNOjrnBpiWolleCJU RPEAn1d94CS0g34Nk1AqS4M/CW/jWY6c =WLhH -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_01_53_17_2011_553)---- From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 16:54:50 2011 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 E9EFB106566C for ; Wed, 15 Jun 2011 16:54:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9C5BA8FC1B for ; Wed, 15 Jun 2011 16:54:49 +0000 (UTC) Received: by vxc34 with SMTP id 34so681438vxc.13 for ; Wed, 15 Jun 2011 09:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s81y3N4MVQ+RpJpTLsX+PaSOHTi1YkbLzFdxmjT8Tac=; b=n50pZ/wYeNgG1NYxbBDbxS3o7I5UcUAiFbo7YhEgf6srk1DN6a9BCy7KV06gD2XCNj UiotckPo0Cm5F+TXHTB6aYe8leTz+wsNRkyE2XQ+GbRrr7qyMwhlDf22FHozwsGhq9JB IjzdUj01QmXoUF6KiS9LcBlDPS3dw9QQ6bxE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=iP3PXj2VE1fzyMubV9UWcTgOOSvErG1q1OB0p0GKjr6ji94agTVxVHHHMPgXravntS WAZgpheAuW8WOfN6mpCtyNQwtF6JM5el/68S91/hyvvWs6BrXQx/GdU5Ffdli89LsUrC bOdHOO2Tqy6rcdkFIJEFXVO3Xqal0NoPQdsf8= MIME-Version: 1.0 Received: by 10.52.32.98 with SMTP id h2mr77104vdi.227.1308156786943; Wed, 15 Jun 2011 09:53:06 -0700 (PDT) Received: by 10.52.115.138 with HTTP; Wed, 15 Jun 2011 09:53:06 -0700 (PDT) In-Reply-To: References: Date: Wed, 15 Jun 2011 09:53:06 -0700 Message-ID: From: Jack Vogel To: Mario Spinthiras Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: strange igb interface performance problems X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 16:54:50 -0000 LRO is not ON by default so there's no need to disable it :) I've just realized that I need to add HWTSO to the igb driver so VLAN's get use it, I will do that shortly. In the data you displayed earlier you had two different driver revisions on each end of your link, I suggest you get the latest, and have it on both ends and then see what your results look like. Regards, Jack On Wed, Jun 15, 2011 at 1:56 AM, Mario Spinthiras < spinthiras.mario@gmail.com> wrote: > Hi, > > To disable LRO I tried ifconfig igb1 -lro and I also tried adding the > sysctl params in loader.conf. Both did not result in any change. > > I'm going to have to find a way to use the new igb driver I guess, hoping > that would fix it maybe. > > > Regards, > Mario > From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 20:21:19 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D36C1065672; Wed, 15 Jun 2011 20:21:19 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 1BE6E8FC08; Wed, 15 Jun 2011 20:21:19 +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 56BF425D3860; Wed, 15 Jun 2011 20:21:18 +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 9D14115A1BFA; Wed, 15 Jun 2011 20:21:17 +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 prR8FTr3jDFK; Wed, 15 Jun 2011 20:21:16 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 3ADDA15A0DB5; Wed, 15 Jun 2011 20:21:16 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110616.015317.781291617533474654.hrs@allbsd.org> Date: Wed, 15 Jun 2011 20:21:15 +0000 Content-Transfer-Encoding: 7bit Message-Id: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> To: Hiroki Sato X-Mailer: Apple Mail (2.1084) Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 20:21:19 -0000 On Jun 15, 2011, at 4:53 PM, Hiroki Sato wrote: Hi, > ... > My proposal is adding a string representing the information source to > the interface id which is used for resolvconf(8). Specifically, I > would like to propose to use the following syntax throughout > utilities that update /etc/resolv.conf via resolvconf(8): > > ifname:origin[:unique] > > "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example. > Using this string as an interface id, resolvconf(8) can handle > multiple RDNSS entries on a single interface without overwriting each > other. Furthermore, priority control can be done with > resolvconf.conf and "origin" and/or "unique" keyword in the string. > > To adopt this naming scheme, patches are needed for dhclient(8), > rtsold(8), and all of other resolvconf(8)-aware utilities. There is > almost no user-visible change; the difference is that multiple RDNSS > entries on a single interface are aggregated and added into > /etc/resolv.conf after patching them. > > Any objections to this? I am working on the necessary changes for > utilities in the base system and planning to commit them if there is > no strong objection. having helped some friends running penguin OS in the past I have been confronted with what OpenSuse does. Apart from a completely over engineered framework they have the ability to sort entries by ifname or regex at least, which I am not sure our current openresolv.conf provides. I think all policy should go into that one config file as in order of interfaces and order of programs. I am not entirely sure I like "slaac" or "dhcp4". I wonder if progname would be sufficient in call cases either (I could well see a "dhclient" or another "fooapp" that can handle both v4 and v6) but in that case it would probably be a matter of third order -- address family. Example: prefer v6 intorder "tun* gre* gif* wlan* em*" or similar (maybe classes lik "wired" or similar. not sure how easily we could do that). progorder "dhcp* rt*" But then we also have the static manual config which would always go in from the config file. In short: yes I like the general idea. Details can be shaken out later. Priority more likely in the config file eventually rather than coded into programs. Have you discussed that with $upstream vendor as well or do we consider further changes to be simple enough to merge them in? /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 21:36:07 2011 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 D1AF4106566B; Wed, 15 Jun 2011 21:36:07 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id A2E268FC1F; Wed, 15 Jun 2011 21:36:07 +0000 (UTC) Received: by pzk27 with SMTP id 27so858349pzk.13 for ; Wed, 15 Jun 2011 14:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=zxol5m1NQSMordxxsxnz+WbRS8f1jOMPdrpl43vhfhM=; b=Agva9CdvtLI13M0wVH38wbaTmP5n9lrw9L9QhEEW6p2v0y3xuIK4XR3dRITRS9JUK9 JWBCM7tHucalxOEkijN8Uqpuv2jAh+6LW7mFTTfxNGTK2xVpsrdTWzsKCbUAsO1MaMmq dG1yBkEvXciNuhK5bQdYOm0xCJs1SlDKWvvqA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eU6vxyqEYnT16OWj1Nw0umlPlxjK6wd3LQcGg8hv9SykF5CBTocFRANexBSEGTtqCi FOF0WL9O4WNZ4aMQJFKZWYmc7CnvybnPWmwCq/syAxPgZKvEM/KVNnHj/Rg1cNpOSgPm KMhnsHjDs6W2Uzs8xxPRh1WBDcMSKFWyGf70w= MIME-Version: 1.0 Received: by 10.142.230.9 with SMTP id c9mr36134wfh.342.1308173766766; Wed, 15 Jun 2011 14:36:06 -0700 (PDT) Received: by 10.142.131.19 with HTTP; Wed, 15 Jun 2011 14:36:06 -0700 (PDT) In-Reply-To: <1743602447.20110607090156@nitronet.pl> References: <1743602447.20110607090156@nitronet.pl> Date: Wed, 15 Jun 2011 17:36:06 -0400 Message-ID: From: grarpamp To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-isp@freebsd.org Subject: Re: MPLS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 21:36:07 -0000 > Pawel wrote: >> I had notices some GSOC project in maybe 2008 >> on MPLS. There doesn't seem to be much current >> talk of this. So I am unsure, excluding the GSOC, >> of the overall picture of MPLS in FreeBSD. >> Is there any current work? Or directions planned? >> Overall interest / demand? > I wrote about same thing few days ago, and was pleasantly surprised > with http://freebsd.mpls.in/ I was not aware of that project as search did not turn up. Thanks for the link. From owner-freebsd-net@FreeBSD.ORG Wed Jun 15 22:44:36 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BDE7F106566B; Wed, 15 Jun 2011 22:44:36 +0000 (UTC) (envelope-from ray@ddteam.net) Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by mx1.freebsd.org (Postfix) with ESMTP id 24F778FC12; Wed, 15 Jun 2011 22:44:34 +0000 (UTC) Received: by fxm11 with SMTP id 11so1067494fxm.13 for ; Wed, 15 Jun 2011 15:44:34 -0700 (PDT) Received: by 10.223.127.210 with SMTP id h18mr187356fas.79.1308176361558; Wed, 15 Jun 2011 15:19:21 -0700 (PDT) Received: from rnote.ddteam.net (215-43-133-95.pool.ukrtel.net [95.133.43.215]) by mx.google.com with ESMTPS id 11sm472354fax.36.2011.06.15.15.19.18 (version=SSLv3 cipher=OTHER); Wed, 15 Jun 2011 15:19:19 -0700 (PDT) Date: Thu, 16 Jun 2011 01:19:10 +0300 From: Aleksandr Rybalko To: "Bjoern A. Zeeb" Message-Id: <20110616011910.c71b0ed6.ray@ddteam.net> In-Reply-To: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> X-Mailer: Sylpheed 3.1.0 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Hiroki Sato , net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 22:44:36 -0000 Hi, On Wed, 15 Jun 2011 20:21:15 +0000 "Bjoern A. Zeeb" wrote: > On Jun 15, 2011, at 4:53 PM, Hiroki Sato wrote: > > Hi, > > ... > > My proposal is adding a string representing the information source > > to the interface id which is used for resolvconf(8). Specifically, > > I would like to propose to use the following syntax throughout > > utilities that update /etc/resolv.conf via resolvconf(8): > > > > ifname:origin[:unique] > > > > "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example. > > Using this string as an interface id, resolvconf(8) can handle > > multiple RDNSS entries on a single interface without overwriting > > each other. Furthermore, priority control can be done with > > resolvconf.conf and "origin" and/or "unique" keyword in the string. > > > > To adopt this naming scheme, patches are needed for dhclient(8), > > rtsold(8), and all of other resolvconf(8)-aware utilities. There is > > almost no user-visible change; the difference is that multiple RDNSS > > entries on a single interface are aggregated and added into > > /etc/resolv.conf after patching them. > > > > Any objections to this? I am working on the necessary changes for > > utilities in the base system and planning to commit them if there is > > no strong objection. > > having helped some friends running penguin OS in the past I have been > confronted with what OpenSuse does. Apart from a completely over > engineered framework they have the ability to sort entries by ifname > or regex at least, which I am not sure our current openresolv.conf > provides. I think all policy should go into that one config file as > in order of interfaces and order of programs. > > I am not entirely sure I like "slaac" or "dhcp4". I wonder if > progname would be sufficient in call cases either (I could well see a > "dhclient" or another "fooapp" that can handle both v4 and v6) but in > that case it would probably be a matter of third order -- address > family. > > Example: > > prefer v6 > intorder "tun* gre* gif* wlan* em*" or similar (maybe classes lik > "wired" or similar. not sure how easily we could do that). > progorder "dhcp* rt*" Maybe better to add default but changeable preference for each iface, like STP do: 1000Base - 20 100Base - 200 PPP - 2000 sources able to give IPv6 info for as we can give more preference (1000Base w/ IPv6 info - 19, 100 w/ v6 - 199, etc.) > > But then we also have the static manual config which would always go > in from the config file. > > In short: yes I like the general idea. Details can be shaken out > later. Priority more likely in the config file eventually rather than > coded into programs. > > Have you discussed that with $upstream vendor as well or do we > consider further changes to be simple enough to merge them in? > > /bz > > -- > Bjoern A. Zeeb You have to have > visions! Stop bit received. Insert coin for new address family. > > _______________________________________________ > 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" Embedded world wait for it, to make FreeBSD based routers better than others :) -- Aleksandr Rybalko From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 05:05:10 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3855A106566B; Thu, 16 Jun 2011 05:05:10 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id CEF648FC15; Thu, 16 Jun 2011 05:05:09 +0000 (UTC) Received: from asuka.mahoroba.org (ume@ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) (user=ume mech=CRAM-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p5G53wI8052674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 14:04:46 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 16 Jun 2011 14:03:56 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (amd64-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 16 Jun 2011 14:04:46 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.1 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: Hiroki Sato , net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 05:05:10 -0000 Hi, >>>>> On Wed, 15 Jun 2011 20:21:15 +0000 >>>>> "Bjoern A. Zeeb" said: bzeeb> having helped some friends running penguin OS in the past I have been bzeeb> confronted with what OpenSuse does. Apart from a completely over bzeeb> engineered framework they have the ability to sort entries by ifname bzeeb> or regex at least, which I am not sure our current openresolv.conf bzeeb> provides. I think all policy should go into that one config file as bzeeb> in order of interfaces and order of programs. I'm not sure what OpenSuse does. But, openresolv does sort entries by ifname. You can put /etc/resolvconf.conf to modify the default policy. My /etc/resolvconf.conf is as follows for example: resolv_conf=/etc/resolv.conf resolv_conf_options=edns0 # If you run a local name server, you should uncomment the below line and # configure your subscribers configuration files below. #name_servers=127.0.0.1 #dynamic_order="tap[0-9]* tun[0-9]* ng[0-9]*:* ng[0-9]* vpn vpn[0-9]* ppp[0-9]* ippp[0-9]*" interface_order="lo lo[0-9]* [a-z]*[0-9]*:*" In my environment, dhclient adds the entry as em0, rtsold adds the entry as em0:slaac, and dhcp6c adds the entry as em0:dhcpv6. So, above conf prefer IPv6 over IPv4. The problem is that openresolv distinguish the entries just by an fname. We need to distinguish them by the source or by the address family, too. The proposal from hrs-san addresses this issue. Sincerely, -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 05:28:58 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A012E106564A for ; Thu, 16 Jun 2011 05:28:58 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 27B1E8FC08 for ; Thu, 16 Jun 2011 05:28:57 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5G5ShKi092003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 14:28:53 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5G5SekV004463; Thu, 16 Jun 2011 14:28:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 14:28:34 +0900 (JST) Message-Id: <20110616.142834.63956571381923731.hrs@allbsd.org> To: bzeeb-lists@lists.zabbadoz.net From: Hiroki Sato In-Reply-To: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_14_28_34_2011_922)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 14:28:55 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 05:28:58 -0000 ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bjoern A. Zeeb" wrote in <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net>: bz> I am not entirely sure I like "slaac" or "dhcp4". I wonder if progname bz> would be sufficient in call cases either (I could well see a "dhclient" bz> or another "fooapp" that can handle both v4 and v6) but in that case it bz> would probably be a matter of third order -- address family. bz> bz> Example: bz> bz> prefer v6 bz> intorder "tun* gre* gif* wlan* em*" or similar (maybe classes lik bz> "wired" or similar. not sure how easily we could do that). bz> progorder "dhcp* rt*" Our openresolv currently supports $interface_order with shell pattern matching only. What I thought was interface_order="lo lo[0-9]* *:ppp *:slaac *:dhcpv4 [a-z]*[0-9]*:*" or something like this. Actually the interface name in resolvconf(8)'s command line argument does not have to be the same as real interface names because it is used just for distinguishing the information source. My primary purpose is to prevent multiple RDNSS information on a single interface from overwriting /etc/resolv.conf anyway. It can be realized by just adding some additional label. Priority control based on ifname and/or protocol (or progname) needs no modification to the resolvconf(8) itself if we use this "interface name + label", and it looks flexible enough to me. What we need is a consistent expression for that and reasonable default value of $interface_order. Anyway, the main point here is whether adding an additional label to interface id is reasonable or not. AFAICC, there is no side effect by adding the ":origin" part. bz> Have you discussed that with $upstream vendor as well or do we consider bz> further changes to be simple enough to merge them in? No, I haven't discuss with the upstream yet because supporting ":origin[:unique]" part need no change on the resolvconf(8) side (I may be missing something here, though). An experimental patch for rtsold is [1] (note that this includes some noises) and one for dhclient is [2]. Basically these patches are just for adding ":origin" part. [1] http://people.allbsd.org/~hrs/FreeBSD/rtsold_aggr_20110616-3.diff [2] http://people.allbsd.org/~hrs/FreeBSD/dhclient_resolvconf_20110616-1.diff Note that it is possible to have multiple RDNSS sources on a single interface in the rtsold case (i.e. multiple routers sending RAs on a link). So "em0:slaac:[RA-source-address]" is used as the interface id for that. -- Hiroki ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk35lIIACgkQTyzT2CeTzy3tpACg2Xo7LntnObVCVMPjNxs2IVNl m8kAoMGVD2qzpMh5YAWHeqy1ek534XJC =xoyO -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_14_28_34_2011_922)---- From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 05:39:28 2011 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 30854106566C for ; Thu, 16 Jun 2011 05:39:28 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id E58458FC08 for ; Thu, 16 Jun 2011 05:39:27 +0000 (UTC) Received: (qmail 26273 invoked by uid 0); 16 Jun 2011 05:39:26 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jun 2011 05:39:26 -0000 Received: (qmail 26267 invoked by uid 90); 16 Jun 2011 05:39:26 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (AES256-SHA encrypted) SMTP; 16 Jun 2011 05:39:26 -0000 Message-ID: <4DF9970D.5000505@bway.net> Date: Thu, 16 Jun 2011 01:39:25 -0400 From: Charles Sprickman User-Agent: Postbox 2.1.4 (Macintosh/20110310) MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4DF54139.1050004@FreeBSD.org> <4DF56879.30204@bway.net> <4DF5761C.9040509@bway.net> In-Reply-To: <4DF5761C.9040509@bway.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 05:39:28 -0000 Just wanted to summarize after I was able to watch all this on another host. I ran tcpdump on the host that I was adding to the IPv6 network as well as on another host that would see all the broad^H^H^H multicast traffic for neighbor discovery. First I'll just lay out what appears to be the correct procedure for bringing a FreeBSD box up on an IPv6 network in an environment where you're using static IPv6 IPs. -Edit rc.conf to include your IPv6 IP(s) and default route, specify which interfaces will run IPv6, and enable IPv6: ipv6_enable="YES" ipv6_network_interfaces="lo0 bce1" ipv6_defaultrouter="2001:xxx:xxxx::1" ipv6_ifconfig_bce1="2001:xxx:xxxx:1::23/48" -Use sysctl to enable link-local addresses: # sysctl -w net.inet6.ip6.auto_linklocal=1 -Bounce the interface, which seems to kick something that triggers the kernel to setup link-local addresses: # ifconfig bce1 down up (that's literal - you don't need to down/up it in two commands) -Run the ipv6 rc.d script: # /etc/rc.d/network_ipv6 start What I observed was fairly interesting. I manually added the IPv6 IP and default route. At this point, address resolution (mapping L3 to L2) works fine with other hosts on the network. After spending many hours reading up on link-local and how ND (neighbor discovery) works in IPv6 (which I think is actually much more clever than ARP - ND is actually at layer 3 and uses multicast), it really didn't look to me like ND really relied on link-local addresses. As soon as the host has any IPv6 IP, it joins the multicast group (ff02::/16) and can see NA (neighbor advertisement) and ND traffic. In receiving NAs it learns L3-L2 mappings and in sending them other nodes learn L3-L2 mappings. Everything is peachy keen. It can even see the router. All these hosts are able to ping each other. What does not work is the default route. I could see outside traffic hitting the host (indicating the router had a L3-L2 mapping to the host) and I could see the host responding to pings from outside. But that traffic did not ever leave the host. I'm still fuzzy on the explanation, but the default route does not seem to stick to the external interface until the link-local address comes up, even though the host has learned the L2 address of the default gateway. Anyhow, it would be great if the procedure from bringing IPv6 up on a running host without a reboot could be documented somewhere. Seeing everything pingable inside the network might lead other v6 noobs like myself chasing off in all sorts of directions before giving up and rebooting. The whole thing was a wonderful learning experience though, but info on the guts of address resolution was hard to come by. It would be really great if the network_ipv6 script would toggle the link-local sysctl when run. Why it does not puzzles me. Thanks, Charles Charles Sprickman wrote: > (sending to list, accidentally missed "reply to all" when I replied to Doug) > > Doug Barton wrote: >> On 6/12/2011 3:30 PM, Charles Sprickman wrote: >>> Can anyone help me understand what the relationship is between address >>> resolution for the router >> I don't know what you mean by "address resolution for the router." > > Layer-2 to Layer-3 mapping and discovery. > >>> and link-local? Why is this required? Why >>> can I ping other hosts on the subnet without enabling link-local? >> link-local is required for IPv6. The gateway address should be the >> link-local address, not the GUA. > > What is the purpose then of the default route statement for IPv6 in > rc.conf and why have my providers offered up a non-link-local gateway > address? > > Thanks, > > Charles > From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 05:59:10 2011 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 DBC3C106564A for ; Thu, 16 Jun 2011 05:59:09 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 5DD688FC1B for ; Thu, 16 Jun 2011 05:59:08 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5G5wfD5092230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 14:58:51 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5G5wdWr004666; Thu, 16 Jun 2011 14:58:41 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 14:57:12 +0900 (JST) Message-Id: <20110616.145712.10896502890982069.hrs@allbsd.org> To: spork@bway.net From: Hiroki Sato In-Reply-To: <4DF9970D.5000505@bway.net> References: <4DF56879.30204@bway.net> <4DF5761C.9040509@bway.net> <4DF9970D.5000505@bway.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_14_57_12_2011_457)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 14:58:55 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 05:59:10 -0000 ----Security_Multipart(Thu_Jun_16_14_57_12_2011_457)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Sprickman wrote in <4DF9970D.5000505@bway.net>: sp> -Edit rc.conf to include your IPv6 IP(s) and default route, specify sp> which interfaces will run IPv6, and enable IPv6: sp> sp> ipv6_enable="YES" sp> ipv6_network_interfaces="lo0 bce1" sp> ipv6_defaultrouter="2001:xxx:xxxx::1" sp> ipv6_ifconfig_bce1="2001:xxx:xxxx:1::23/48" sp> sp> -Use sysctl to enable link-local addresses: sp> sp> # sysctl -w net.inet6.ip6.auto_linklocal=1 This is not needed when ipv6_enable="YES". sp> -Bounce the interface, which seems to kick something that triggers the sp> kernel to setup link-local addresses: sp> sp> # ifconfig bce1 down up sp> (that's literal - you don't need to down/up it in two commands) Ditto. sp> -Run the ipv6 rc.d script: sp> sp> # /etc/rc.d/network_ipv6 start I do not recommend to use the rc.d/network_ipv6 script for manual configuration because it often ends up an incomplete configuration as you experienced. Rebooting the system would be better. The rc.d/netif script on 9.X works well for that purpose without a reboot, though. sp> I'm still fuzzy on the explanation, but the default route does not seem sp> to stick to the external interface until the link-local address comes sp> up, even though the host has learned the L2 address of the default gateway. On IPv6 router, MLD works only when at least one LLA is configured on all of the interfaces. In short, ND will completely be broken on a router with a GUA and no LLA. LLA is a MUST for every IPv6-speaking interface, not for automatic router discovery only. This is because ICMPv6 heavily depends on it. Without LLA some unexpected and/or inconsistent behaviors can happen, especially on a router as you experienced. I would not recommend you to try to understand what will happen without LLA because it is quite complex and just ends up various kind of inconsistent behaviors. For why LLA is needed, the primary documents are RFC 3810, 4007, 4291, 4861, and 4884. -- Hiroki ----Security_Multipart(Thu_Jun_16_14_57_12_2011_457)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk35mzgACgkQTyzT2CeTzy0sKQCgzALF9a/CeifjO+wG01KcN0kQ t9kAniypnyiqVIqQuKGDnNOankhzH8qY =B/3f -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_14_57_12_2011_457)---- From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 07:12:15 2011 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 EE0351065670 for ; Thu, 16 Jun 2011 07:12:14 +0000 (UTC) (envelope-from spork@bway.net) Received: from xena.bway.net (xena.bway.net [216.220.96.26]) by mx1.freebsd.org (Postfix) with ESMTP id B80B88FC1D for ; Thu, 16 Jun 2011 07:12:14 +0000 (UTC) Received: (qmail 28316 invoked by uid 0); 16 Jun 2011 07:12:14 -0000 Received: from smtp.bway.net (216.220.96.25) by xena.bway.net with (DHE-RSA-AES256-SHA encrypted) SMTP; 16 Jun 2011 07:12:14 -0000 Received: (qmail 28308 invoked by uid 90); 16 Jun 2011 07:12:13 -0000 Received: from unknown (HELO hotlap.nat.fasttrackmonkey.com) (spork@96.57.144.66) by smtp.bway.net with (AES256-SHA encrypted) SMTP; 16 Jun 2011 07:12:13 -0000 Message-ID: <4DF9ACCC.5070506@bway.net> Date: Thu, 16 Jun 2011 03:12:12 -0400 From: Charles Sprickman User-Agent: Postbox 2.1.4 (Macintosh/20110310) MIME-Version: 1.0 To: Hiroki Sato References: <4DF56879.30204@bway.net> <4DF5761C.9040509@bway.net> <4DF9970D.5000505@bway.net> <20110616.145712.10896502890982069.hrs@allbsd.org> In-Reply-To: <20110616.145712.10896502890982069.hrs@allbsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 07:12:15 -0000 Hiroki Sato wrote: > Charles Sprickman wrote > in <4DF9970D.5000505@bway.net>: > > sp> -Edit rc.conf to include your IPv6 IP(s) and default route, specify > sp> which interfaces will run IPv6, and enable IPv6: > sp> > sp> ipv6_enable="YES" > sp> ipv6_network_interfaces="lo0 bce1" > sp> ipv6_defaultrouter="2001:xxx:xxxx::1" > sp> ipv6_ifconfig_bce1="2001:xxx:xxxx:1::23/48" > sp> > sp> -Use sysctl to enable link-local addresses: > sp> > sp> # sysctl -w net.inet6.ip6.auto_linklocal=1 > > This is not needed when ipv6_enable="YES". Correct, unless you have not rebooted. It would be nice to have a hook to enabling that in the ipv6 rc.d script though. > sp> -Bounce the interface, which seems to kick something that triggers the > sp> kernel to setup link-local addresses: > sp> > sp> # ifconfig bce1 down up > sp> (that's literal - you don't need to down/up it in two commands) > > Ditto. Correct. Unless you haven't rebooted... > sp> -Run the ipv6 rc.d script: > sp> > sp> # /etc/rc.d/network_ipv6 start > > I do not recommend to use the rc.d/network_ipv6 script for manual > configuration because it often ends up an incomplete configuration as > you experienced. Rebooting the system would be better. The > rc.d/netif script on 9.X works well for that purpose without a > reboot, though. OK. I think there are a fair number of environments (ie: server) where rebooting for an IP change wouldn't be acceptable. So I would like to make sure that my manual method is close enough that I can share info without leading others down the wrong path. Good to hear this will be easier in 9.x. > sp> I'm still fuzzy on the explanation, but the default route does not seem > sp> to stick to the external interface until the link-local address comes > sp> up, even though the host has learned the L2 address of the default gateway. > > On IPv6 router, MLD works only when at least one LLA is configured on > all of the interfaces. In short, ND will completely be broken on a > router with a GUA and no LLA. > > LLA is a MUST for every IPv6-speaking interface, not for automatic > router discovery only. This is because ICMPv6 heavily depends on it. > Without LLA some unexpected and/or inconsistent behaviors can happen, > especially on a router as you experienced. I'm puzzled by why hosts with static IPv6 IPs could communicate with each other. I noticed in some of my netstat output that even though the ff02 multicast network was in the table, it was only bound to the loopback. However I still logged multicast to/from the box. One of the RFCs also noted that multicast is limited in scope to the link-local address, so in theory, not even the host to host ND should have worked. I guess that's what threw me. > I would not recommend you to try to understand what will happen > without LLA because it is quite complex and just ends up various kind > of inconsistent behaviors. For why LLA is needed, the primary > documents are RFC 3810, 4007, 4291, 4861, and 4884. I knew I'd eventually have to read RFCs. :) I totally agree with you, and what I've been reading elsewhere suggests that ND really shouldn't work without a link-local interface enabled. I have to assume that the multicast traffic somehow still making its way onto the wire. Not sure if that's a bug or a feature or a quirk of how what's a L3 protocol (icmp6 multicast) gets mapped to L2. Thanks, Charles > -- Hiroki From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 07:43:25 2011 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 6A015106566C for ; Thu, 16 Jun 2011 07:43:25 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 19A7E8FC0C for ; Thu, 16 Jun 2011 07:43:23 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5G7h1SW092884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 16:43:11 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5G7gutn005498; Thu, 16 Jun 2011 16:42:58 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 16 Jun 2011 16:42:14 +0900 (JST) Message-Id: <20110616.164214.301126302041762988.hrs@allbsd.org> To: spork@bway.net From: Hiroki Sato In-Reply-To: <4DF9ACCC.5070506@bway.net> References: <4DF9970D.5000505@bway.net> <20110616.145712.10896502890982069.hrs@allbsd.org> <4DF9ACCC.5070506@bway.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Jun_16_16_42_14_2011_851)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Thu, 16 Jun 2011 16:43:12 +0900 (JST) X-Spam-Status: No, score=6.1 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_PBL, RCVD_IN_RP_RNBL, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 07:43:25 -0000 ----Security_Multipart(Thu_Jun_16_16_42_14_2011_851)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Sprickman wrote in <4DF9ACCC.5070506@bway.net>: sp> > LLA is a MUST for every IPv6-speaking interface, not for automatic sp> > router discovery only. This is because ICMPv6 heavily depends on it. sp> > Without LLA some unexpected and/or inconsistent behaviors can happen, sp> > especially on a router as you experienced. sp> sp> I'm puzzled by why hosts with static IPv6 IPs could communicate with sp> each other. I noticed in some of my netstat output that even though the sp> ff02 multicast network was in the table, it was only bound to the sp> loopback. However I still logged multicast to/from the box. One of the sp> RFCs also noted that multicast is limited in scope to the link-local sp> address, so in theory, not even the host to host ND should have worked. sp> I guess that's what threw me. This is because an L3 address to an L2 address resolution in NDP works in the host-to-host case by chance; addresses in the NDP messages do not have to have a link-local scope and FreeBSD's implementation uses a GUA if it is configured. The host-to-router case doesn't work properly because a router with no LLA never accepts multicast listener discovery messages. You can observe tcpdump output of the host-to-host case and the host-to-router case. The primary difference will be that the unspecified address ("::") is used in MLD report messages in the latter. -- Hiroki ----Security_Multipart(Thu_Jun_16_16_42_14_2011_851)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEUEABECAAYFAk35s9YACgkQTyzT2CeTzy3ZfwCfQZY/2jSY28vtpqqJOfoP4usP mmcAljlMNCERokmg2WYEfAgPhuDFUh4= =ERNg -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Jun_16_16_42_14_2011_851)---- From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 07:52:17 2011 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 9BD7F1065670 for ; Thu, 16 Jun 2011 07:52:17 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id DB6D48FC14 for ; Thu, 16 Jun 2011 07:52:16 +0000 (UTC) Received: (qmail 64122 invoked from network); 16 Jun 2011 07:25:35 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 16 Jun 2011 07:25:35 -0000 Date: Thu, 16 Jun 2011 09:25:35 +0200 (CEST) Message-Id: <20110616.092535.74688320.sthaug@nethelp.no> To: spork@bway.net From: sthaug@nethelp.no In-Reply-To: <4DF9ACCC.5070506@bway.net> References: <4DF9970D.5000505@bway.net> <20110616.145712.10896502890982069.hrs@allbsd.org> <4DF9ACCC.5070506@bway.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@FreeBSD.org, hrs@FreeBSD.org Subject: Re: link-local needed w/static IP and gateway? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 07:52:17 -0000 > > I do not recommend to use the rc.d/network_ipv6 script for manual > > configuration because it often ends up an incomplete configuration as > > you experienced. Rebooting the system would be better. The > > rc.d/netif script on 9.X works well for that purpose without a > > reboot, though. > > OK. I think there are a fair number of environments (ie: server) where > rebooting for an IP change wouldn't be acceptable. So I would like to > make sure that my manual method is close enough that I can share info > without leading others down the wrong path. Good to hear this will be > easier in 9.x. Agreed. It is vital to have a well defined procedure for bringing up IPv6 on a running system, without a complete reboot. Bouncing the interface may be acceptable - but far better would be to do without even that. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 13:00:23 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E59A8106564A; Thu, 16 Jun 2011 13:00:22 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 130AA8FC2A; Thu, 16 Jun 2011 13:00:19 +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 0494E25D3891; Thu, 16 Jun 2011 13:00:17 +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 3778715A1CBA; Thu, 16 Jun 2011 13:00:17 +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 Kv0yBg5tBe9D; Thu, 16 Jun 2011 13:00:16 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 1A7A615A1C59; Thu, 16 Jun 2011 13:00:15 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110616011910.c71b0ed6.ray@ddteam.net> Date: Thu, 16 Jun 2011 13:00:15 +0000 Content-Transfer-Encoding: 7bit Message-Id: <0EF81260-0EE8-4194-8AE7-CCE62958AE24@lists.zabbadoz.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> <20110616011910.c71b0ed6.ray@ddteam.net> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1084) Cc: Hiroki Sato , net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 13:00:23 -0000 On Jun 15, 2011, at 10:19 PM, Aleksandr Rybalko wrote: > Maybe better to add default but changeable preference for each iface, > like STP do: > 1000Base - 20 > 100Base - 200 > PPP - 2000 > > sources able to give IPv6 info for as we can give more preference > (1000Base w/ IPv6 info - 19, 100 w/ v6 - 199, etc.) I think that's completely off-scope for users, given it's still off-scope for some network ops folks;-) /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 Jun 16 13:00:36 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69A6D1065672; Thu, 16 Jun 2011 13:00:36 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 20A1A8FC1D; Thu, 16 Jun 2011 13:00:36 +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 065B225D3899; Thu, 16 Jun 2011 13:00:34 +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 894FA15A1C5A; Thu, 16 Jun 2011 13:00:34 +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 S1Pk6PnZfGL9; Thu, 16 Jun 2011 13:00:33 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 31BA815A1C59; Thu, 16 Jun 2011 13:00:32 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <20110616.142834.63956571381923731.hrs@allbsd.org> Date: Thu, 16 Jun 2011 13:00:32 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> <20110616.142834.63956571381923731.hrs@allbsd.org> To: Hiroki Sato , Hajimu UMEMOTO X-Mailer: Apple Mail (2.1084) Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 13:00:36 -0000 On Jun 16, 2011, at 5:28 AM, Hiroki Sato wrote: Hi Umemoto-san, Sato-san, > Our openresolv currently supports $interface_order with shell pattern > matching only. What I thought was > > interface_order="lo lo[0-9]* *:ppp *:slaac *:dhcpv4 [a-z]*[0-9]*:*" Hmm, indeed we do and I hadn't actually thought of collapsing the two. I think that's perfect. The only thing I am only still pondering - do we want it to be "slaac" "dchpv4" or the program name? I can see advantages with both. If we go with "slaac" etc. we might need to - at least for the three or so things from base, add a table to the man page like program: origin rtsol -> slaac rtsold -> slaac dhclient -> dhcpv4 ppp -> ppp as people may or may not be familiar enough with what the one or the other might mean. Maybe simply describing the cases will be good enough as well. I can imaging ports like mpd, ... to join this scheme and by then there might be different "ppp" or "dhcpv4", "dhcpv6" or even different "slaac". The advantage of this one is that if I prefer dhcpv6 on one interface it doesn't make a difference if I am going to use dippler, isc or wide. So I guess I am convinced that what you have is the best. Regards, Bjoern -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 13:40:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 297311065672 for ; Thu, 16 Jun 2011 13:40:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 008408FC13 for ; Thu, 16 Jun 2011 13:40:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5GDeAal027729 for ; Thu, 16 Jun 2011 13:40:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5GDeAQA027728; Thu, 16 Jun 2011 13:40:10 GMT (envelope-from gnats) Date: Thu, 16 Jun 2011 13:40:10 GMT Message-Id: <201106161340.p5GDeAQA027728@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: "Andrey V. Elsukov" Cc: Subject: Re: kern/157802: [dummynet] [panic] kernel panic in dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Andrey V. Elsukov" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2011 13:40:11 -0000 The following reply was made to PR kern/157802; it has been noted by GNATS. From: "Andrey V. Elsukov" To: bug-followup@FreeBSD.org, alexey_kovalenko@inbox.ru Cc: Subject: Re: kern/157802: [dummynet] [panic] kernel panic in dummynet Date: Thu, 16 Jun 2011 15:05:59 +0400 Hi, Alexey can you provide exact commands to reproduce this? -- WBR, Andrey V. Elsukov From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 14:36:45 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 37DFF106564A; Thu, 16 Jun 2011 14:36:45 +0000 (UTC) (envelope-from ume@mahoroba.org) Received: from mail.mahoroba.org (ent.mahoroba.org [IPv6:2001:2f0:104:8010::1]) by mx1.freebsd.org (Postfix) with ESMTP id CF2AD8FC17; Thu, 16 Jun 2011 14:36:44 +0000 (UTC) Received: from yuga.mahoroba.org (ume@yuga-m.mahoroba.org [IPv6:2001:2f0:104:801c:21b:d3ff:fe38:5381]) (user=ume mech=DIGEST-MD5 bits=0) by mail.mahoroba.org (8.14.4/8.14.4) with ESMTP/inet6 id p5GEaVrg089041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 23:36:36 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Thu, 16 Jun 2011 23:36:30 +0900 Message-ID: From: Hajimu UMEMOTO To: "Bjoern A. Zeeb" In-Reply-To: References: <20110616.015317.781291617533474654.hrs@allbsd.org> <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> <20110616.142834.63956571381923731.hrs@allbsd.org> User-Agent: xcite1.60> Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (=?ISO-2022-JP-2?B?R29qGyQoRCtXGyhC?=) APEL/10.8 Emacs/23.3 (i386-portbld-freebsd8.2) MULE/6.0 (HANACHIRUSATO) X-Operating-System: FreeBSD 8.2-STABLE X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.mahoroba.org [IPv6:2001:2f0:104:8010::1]); Thu, 16 Jun 2011 23:36:36 +0900 (JST) X-Virus-Scanned: clamav-milter 0.97.1 at asuka.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on asuka.mahoroba.org Cc: Hiroki Sato , net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 14:36:45 -0000 Hi, >>>>> On Thu, 16 Jun 2011 13:00:32 +0000 >>>>> "Bjoern A. Zeeb" said: bzeeb> I can imaging ports like mpd, ... to join this scheme and by then bzeeb> there might be different "ppp" or "dhcpv4", "dhcpv6" or even different bzeeb> "slaac". The advantage of this one is that if I prefer dhcpv6 on one bzeeb> interface it doesn't make a difference if I am going to use dippler, bzeeb> isc or wide. The IPv6CP doesn't treat DNS things, and it is DHCPv6 thing. So, about IPv6 over IPv6, dhcpv6 is enough. Further, the mpd uses ngN which is a dynamic interface. The resolvconf has a feature to treat a dynamic interface as special. So, it is treated as special by resolvconf. -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 20:12:12 2011 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 ADA97106566C for ; Thu, 16 Jun 2011 20:12:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.mail.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 714898FC0A for ; Thu, 16 Jun 2011 20:12:12 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAOFg+k2DaFvO/2dsb2JhbABShEmjErhdkGeBK4NygQoEkVmQEg X-IronPort-AV: E=Sophos;i="4.65,377,1304308800"; d="scan'208";a="124254353" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu-pri.mail.uoguelph.ca with ESMTP; 16 Jun 2011 16:01:34 -0400 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 15027B3F04; Thu, 16 Jun 2011 16:01:34 -0400 (EDT) Date: Thu, 16 Jun 2011 16:01:34 -0400 (EDT) From: Rick Macklem To: Artem Belevich Message-ID: <395930590.686693.1308254494066.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - IE7 (Win)/6.0.10_GA_2692) Cc: Rick Macklem , FreeBSD Net Subject: Re: amd + NFS reconnect = ICMP storm + unkillable process. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 20:12:12 -0000 > * We try to reconnect again, and again, and again.... > * the process in this state is unkillable > If you use the "intr" mount option, then an nfs reconnect should be killable. I know diddly about amd, so I can't help beyond that. rick From owner-freebsd-net@FreeBSD.ORG Thu Jun 16 23:14:38 2011 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 88F44106566C; Thu, 16 Jun 2011 23:14:38 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2E8A58FC14; Thu, 16 Jun 2011 23:14:37 +0000 (UTC) Received: by ywf7 with SMTP id 7so1459340ywf.13 for ; Thu, 16 Jun 2011 16:14:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=T7XTxqzuD0GX66kfkERKWv/DZWbzHILYtnXvmY+VmEs=; b=g/L1xfLfVqgIcVGK96U+wy9EkO5I4tnZheqVWvW9vWb7CnQA+XcjRdv4WXqPUELIGb 0aICHlf/LilDfnqXvQrx7kUy/h/jscFhfchD77zQs6XlAme+aj2JRQDUZ1UYGDGfsrfz DRy+1Doh24MXwtIFtm318TM3F3f5nB2/dLVdo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=u15oWab5syNtenB9OOrSewdgaL9tSL5v82jG+kzp6nhtPhLnW7VtzdCTap3fCnjhgj 11gt27PE3/C/vOlBwp/BqAhl7nDVEbi9PLTy0AqhNCZz0oxL/TLWaX17ocPc1T1GQvpc tzYdKp3Vf+KUuOLd7ZPmIX5Kvp1+UttZZQveg= MIME-Version: 1.0 Received: by 10.236.180.133 with SMTP id j5mr2247101yhm.68.1308266077211; Thu, 16 Jun 2011 16:14:37 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.61.73 with HTTP; Thu, 16 Jun 2011 16:14:37 -0700 (PDT) In-Reply-To: <395930590.686693.1308254494066.JavaMail.root@erie.cs.uoguelph.ca> References: <395930590.686693.1308254494066.JavaMail.root@erie.cs.uoguelph.ca> Date: Thu, 16 Jun 2011 16:14:37 -0700 X-Google-Sender-Auth: AOgZwifzf4RhaqIQz_kMvX-AEYM Message-ID: From: Artem Belevich To: Rick Macklem Content-Type: text/plain; charset=ISO-8859-1 Cc: Rick Macklem , FreeBSD Net Subject: Re: amd + NFS reconnect = ICMP storm + unkillable process. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 16 Jun 2011 23:14:38 -0000 On Thu, Jun 16, 2011 at 1:01 PM, Rick Macklem wrote: >> * We try to reconnect again, and again, and again.... >> * the process in this state is unkillable >> > If you use the "intr" mount option, then an nfs reconnect > should be killable. I know diddly about amd, so I can't > help beyond that. I'll give it a try. Amd does not have an option to mount itself with 'intr', so I'll need to hack it in. I did a bit more digging into the problem and it starts to look like amd may not be the culprit after all. I've captured the traffic during the issue and the very first thing that popped up in wireshark was that it reported a lot of retransmissions and duplicates: http://pastebin.com/PzcwKu1J It looks like the way we generate XID makes XID collisions possible/likely in some situations. I suspected that this could be what causes my problem, so I've hacked RPC code to generate XID the way opensolaris does -- start with a time-based value and then allocate XIDs sequentially. With this patch ( http://pastebin.com/PzcwKu1J ) collisions (and retransmits/duplicates reported by wireshark) mostly went away. Unfortunately, the problem remained. Now the capture during the problem looks like this: http://pastebin.com/3M6HZrcq Port 1022 is on amd side. Other ports belong to the NFS client in kernel. Normally there seems to be only one NFS client per NFS mount. I wonder how comes we ended up with many NFS clients actively calling GETATTR on the same file handle even though there's only *one* process stuck trying to do a stat() call? amd does reply to those requests just fine, but for some reason NFS client code in the kernel does not seem to see those replies. I didn't wrap my head around RPC code enough yet to figure out what could cause amd replies to be lost and what triggers reconnect on NFS client side. If you could nudge me in the right direction, I'd appreciate that. Thanks, --Artem From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 02:59:39 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 857F1106564A; Fri, 17 Jun 2011 02:59:39 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3639E8FC0C; Fri, 17 Jun 2011 02:59:38 +0000 (UTC) Received: by iyj12 with SMTP id 12so2379376iyj.13 for ; Thu, 16 Jun 2011 19:59:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=Gs+7bfhZ25j9UhZVj3p0eRfljp0aQ/RlzB9spxrR2PM=; b=E+dz3JkZHDnA/NSV2Of30qOA0+uFYuFom29CC4T7cPdWMltGerL7BPkftgFh0kEtFT HO9OMHuP1zS6sGC3VUrky85tW6u4dqXok169CYqRnHASjXKfOLHU19337WWEYZg/Bw0Q w/xbJmfOKwsBgcd3J/0D5/ABaZPXBx43CJ40Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=TFK5hOX8WwSbUnMIExy6ua/UdMbmh+iVwILW8eFqRV80V9Vu+iNwhcj7mC7Wn3Hvoh OSOln4DSKrCKmU84LkHKYi5noRswxRTx9pz7bGMMFrSieEEHHbmlXLmfCMWpxca43sK0 B2JIhXGIAR7MTcobwkKsV8R42bMIXZBCfL/Pc= Received: by 10.231.114.72 with SMTP id d8mr1326072ibq.105.1308278042082; Thu, 16 Jun 2011 19:34:02 -0700 (PDT) Received: from DataIX.net (adsl-108-73-113-243.dsl.klmzmi.sbcglobal.net [108.73.113.243]) by mx.google.com with ESMTPS id 10sm1142743ibn.20.2011.06.16.19.34.00 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 19:34:01 -0700 (PDT) Sender: The Command Line Kid Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p5H2Xx2e059087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 22:33:59 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p5H2XwJ5059086; Thu, 16 Jun 2011 22:33:58 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Thu, 16 Jun 2011 22:33:58 -0400 From: jhell To: Hiroki Sato Message-ID: <20110617023358.GB58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110617022950.GA58034@DataIX.net> Cc: net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] ( was [RFC] resolvconf(8) interface id ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 02:59:39 -0000 On Thu, Jun 16, 2011 at 10:29:50PM -0400, jhell wrote: > > > On Thu, Jun 16, 2011 at 01:53:17AM +0900, Hiroki Sato wrote: > > Hi, > > > > I would like your comments about the following issue and proposal. > > > > The background is as follows. The resolvconf(8) utility has been > > imported some time before to handle update of /etc/resolv.conf by > > using multiple RDNSS (recursive DNS server) information sources. The > > possible sources are ppp, rtsold, dhclient, mpd, etc. The > > resolvconf(8) prevents /etc/resolv.conf from being overwritten by > > multiple information sources disorderly. > > > > The RDNSS information is handled by resolvconf(8) in a per-interface > > basis. When a new RDNSS entry is provided on an interface, it will > > be registered to resolvconf(8)'s internal database with the interface > > id, and then resolvconf(8) will update /etc/resolv.conf. The > > resultant resolv.conf contains aggregate entries from all interfaces. > > For example, let's consider em0 received RDNSS information via > > dhclient(8) (DHCPv4), and tun0 received one via ppp(8) (IPCP). In > > this case, the resolvconf(8) is invoked for each, and > > /etc/resolv.conf will be updated with all of received information. > > This is how the resolvconf(8) works. > > > > However, the case that there are two or more RDNSS information > > sources on a single interface at the same time is still troublesome. > > DHCPv4 + DHCPv6 or rtsol + DHCPv4 on the same interface is a good > > example. In the latter case, rtsol and dhclient will try to register > > RDNSS information with the same interface id. As the result, RDNSS > > entries will be overwritten, and at worst the entries in > > /etc/resolv.conf will flap repeatedly. > > > > My proposal is adding a string representing the information source to > > the interface id which is used for resolvconf(8). Specifically, I > > would like to propose to use the following syntax throughout > > utilities that update /etc/resolv.conf via resolvconf(8): > > > > ifname:origin[:unique] > > > > "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example. > > Using this string as an interface id, resolvconf(8) can handle > > multiple RDNSS entries on a single interface without overwriting each > > other. Furthermore, priority control can be done with > > resolvconf.conf and "origin" and/or "unique" keyword in the string. > > > > To adopt this naming scheme, patches are needed for dhclient(8), > > rtsold(8), and all of other resolvconf(8)-aware utilities. There is > > almost no user-visible change; the difference is that multiple RDNSS > > entries on a single interface are aggregated and added into > > /etc/resolv.conf after patching them. > > > > Any objections to this? I am working on the necessary changes for > > utilities in the base system and planning to commit them if there is > > no strong objection. > > > > Not meaning to thread-jack here and this may have been discussed at one > point somewhere along the road but for dynamic utilities I would see the > following a plus. > > Gosh, Wouldnt it be something if we could store our dynamic resolver > information with the interface in the same sort of fashion that we store > our routing tables ? and then modify our routines in the library to look > them up via the "resolving tables" and think of resolv.conf as static > routing information only ? > > If we can already do this via resolvconf(8) in order to modify > resolv.conf how hard would it be to adjust to move in this direction ? > > This could also provide the ability to report how many hits on the > nameserver per interface etc etc... among other information just as like > what the routing information already does. > I appologize for the insta-reply, but thinking more along the lines of this it may come as even more of a benefit to tie this more into the routing table so so each route can have a dynamic nameserver attached to it so when setfib(8) is used a whole nother batch of nameserver could also be used or fall back to the standard resolv.conf. From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 02:59:52 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA89C1065672; Fri, 17 Jun 2011 02:59:52 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 97C0D8FC08; Fri, 17 Jun 2011 02:59:52 +0000 (UTC) Received: by mail-iy0-f182.google.com with SMTP id 12so2379376iyj.13 for ; Thu, 16 Jun 2011 19:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=xqF/F92nWSyot8xRrSKOOeByK88mdlz3bYNzOvFRAlw=; b=VBd/WTK6p3oYcq6Slo91kqHRZezOjVZ5jB170rnJ2ZxF6N3FAyrtoVmnmUvDfjpUTG MldFUa0/Ca7TMoiQzmnHbzL4xm8kQKMSelIRd2BzAuEnNjylLzRrwY1qr8Za5AuXDK8T 1JQKIfRymX6/ammXio9CbXAP1orlFQoF+IzyU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=T2IKsyOBULGeY7qJmo9arXSjnF1aYlAlxV/HS41d2vsqzKPy5cwjDKIH4IRn+J/Mvz T5KtrPM14W1gBAYpQGxvvJlcmvk81aSr9KVuSBZo/Qpx1a2r3Oyn6tAFlwFLfMDMop1f a4LKUwXqR7QQJ4OzMXh74xpGnhqmpO7XhP4RM= Received: by 10.42.177.131 with SMTP id bi3mr1503752icb.79.1308277797862; Thu, 16 Jun 2011 19:29:57 -0700 (PDT) Received: from DataIX.net (adsl-108-73-113-243.dsl.klmzmi.sbcglobal.net [108.73.113.243]) by mx.google.com with ESMTPS id d8sm2004465icy.21.2011.06.16.19.29.55 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 19:29:57 -0700 (PDT) Sender: The Command Line Kid Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p5H2TpQa058907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2011 22:29:52 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p5H2Tots058906; Thu, 16 Jun 2011 22:29:50 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Thu, 16 Jun 2011 22:29:50 -0400 From: jhell To: Hiroki Sato Message-ID: <20110617022950.GA58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <20110616.015317.781291617533474654.hrs@allbsd.org> Cc: net@freebsd.org Subject: Dynamin/Static Resolver Table [netstat like] ( was [RFC] resolvconf(8) interface id ) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 02:59:53 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2011 at 01:53:17AM +0900, Hiroki Sato wrote: > Hi, >=20 > I would like your comments about the following issue and proposal. >=20 > The background is as follows. The resolvconf(8) utility has been > imported some time before to handle update of /etc/resolv.conf by > using multiple RDNSS (recursive DNS server) information sources. The > possible sources are ppp, rtsold, dhclient, mpd, etc. The > resolvconf(8) prevents /etc/resolv.conf from being overwritten by > multiple information sources disorderly. >=20 > The RDNSS information is handled by resolvconf(8) in a per-interface > basis. When a new RDNSS entry is provided on an interface, it will > be registered to resolvconf(8)'s internal database with the interface > id, and then resolvconf(8) will update /etc/resolv.conf. The > resultant resolv.conf contains aggregate entries from all interfaces. > For example, let's consider em0 received RDNSS information via > dhclient(8) (DHCPv4), and tun0 received one via ppp(8) (IPCP). In > this case, the resolvconf(8) is invoked for each, and > /etc/resolv.conf will be updated with all of received information. > This is how the resolvconf(8) works. >=20 > However, the case that there are two or more RDNSS information > sources on a single interface at the same time is still troublesome. > DHCPv4 + DHCPv6 or rtsol + DHCPv4 on the same interface is a good > example. In the latter case, rtsol and dhclient will try to register > RDNSS information with the same interface id. As the result, RDNSS > entries will be overwritten, and at worst the entries in > /etc/resolv.conf will flap repeatedly. >=20 > My proposal is adding a string representing the information source to > the interface id which is used for resolvconf(8). Specifically, I > would like to propose to use the following syntax throughout > utilities that update /etc/resolv.conf via resolvconf(8): >=20 > ifname:origin[:unique] >=20 > "em0:dhcpv4" for dhclient, "em0:slaac" for rtsold, for example. > Using this string as an interface id, resolvconf(8) can handle > multiple RDNSS entries on a single interface without overwriting each > other. Furthermore, priority control can be done with > resolvconf.conf and "origin" and/or "unique" keyword in the string. >=20 > To adopt this naming scheme, patches are needed for dhclient(8), > rtsold(8), and all of other resolvconf(8)-aware utilities. There is > almost no user-visible change; the difference is that multiple RDNSS > entries on a single interface are aggregated and added into > /etc/resolv.conf after patching them. >=20 > Any objections to this? I am working on the necessary changes for > utilities in the base system and planning to commit them if there is > no strong objection. >=20 Not meaning to thread-jack here and this may have been discussed at one point somewhere along the road but for dynamic utilities I would see the following a plus. Gosh, Wouldnt it be something if we could store our dynamic resolver information with the interface in the same sort of fashion that we store our routing tables ? and then modify our routines in the library to look them up via the "resolving tables" and think of resolv.conf as static routing information only ? If we can already do this via resolvconf(8) in order to modify resolv.conf how hard would it be to adjust to move in this direction ? This could also provide the ability to report how many hits on the nameserver per interface etc etc... among other information just as like what the routing information already does. --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (FreeBSD) Comment: http://bit.ly/0x89D8547E iQEcBAEBAgAGBQJN+rweAAoJEJBXh4mJ2FR+4hgH/RHUOfgv8c/3Mk1Nl5CLEjsq tbuzZbZy0GrDlQyb1dvbRxpGlvS8xcf4BP240VuxdEz36qfGOsBaNFRFCeV0uCYr JLDo+enB22D/2bSXjWgVj4PEERgmzOVSkmQQ9dtVP3OPwnxSYymQ82DpeLBBSjjy +b/E5Hl77Kssi9kcxCxhNKwAgAyiPE0xQEyiAwK//2+tKRa0wy6VjB/ZJ9PViLPI oQqq8qxp/wAMmVyrsiFiXw31dkvniQePHf736cpIgEn0uNp9PCDdnRcg32isbYfv M+mAyNRkalVGXqtvdY3ZqOL66NW78fK6Sy8CgxSxs2paSFRKw3jiffnzmY5isek= =WBh5 -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 03:42:02 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 481AB106566B for ; Fri, 17 Jun 2011 03:42:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id BD9788FC19 for ; Fri, 17 Jun 2011 03:42:01 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5H3fLQu001788 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 12:41:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5H3fEDA016044; Fri, 17 Jun 2011 12:41:16 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Jun 2011 12:40:29 +0900 (JST) Message-Id: <20110617.124029.722784011683540958.hrs@allbsd.org> To: jhell@DataIX.net From: Hiroki Sato In-Reply-To: <20110617022950.GA58034@DataIX.net> <20110617023358.GB58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_17_12_40_29_2011_026)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Fri, 17 Jun 2011 12:41:35 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: net@FreeBSD.org Subject: Re: Dynamin/Static Resolver Table [netstat like] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 03:42:02 -0000 ----Security_Multipart(Fri_Jun_17_12_40_29_2011_026)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit jhell wrote in <20110617022950.GA58034@DataIX.net>: jh> Gosh, Wouldnt it be something if we could store our dynamic resolver jh> information with the interface in the same sort of fashion that we store jh> our routing tables ? and then modify our routines in the library to look jh> them up via the "resolving tables" and think of resolv.conf as static jh> routing information only ? jh> jh> If we can already do this via resolvconf(8) in order to modify jh> resolv.conf how hard would it be to adjust to move in this direction ? jhell wrote in <20110617023358.GB58034@DataIX.net>: jh> I appologize for the insta-reply, but thinking more along the lines of jh> this it may come as even more of a benefit to tie this more into the jh> routing table so so each route can have a dynamic nameserver attached to jh> it so when setfib(8) is used a whole nother batch of nameserver could jh> also be used or fall back to the standard resolv.conf. I am not sure of the benefit to adopt "same sort of fashion as the routing table" for RDNSS entries. What is your problem, and how does your idea solve it? -- Hiroki ----Security_Multipart(Fri_Jun_17_12_40_29_2011_026)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk36zK0ACgkQTyzT2CeTzy1QMQCgu1RPTcK/rJW5gx/3/Oz+IsOJ NVwAoNenH8qh4WA88rGNPJLf0LKkMseW =SJCG -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_17_12_40_29_2011_026)---- From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 04:19:34 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3C191106566C; Fri, 17 Jun 2011 04:19:34 +0000 (UTC) (envelope-from cmdlnkid@gmail.com) Received: from mail-iw0-f182.google.com (mail-iw0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id E137C8FC12; Fri, 17 Jun 2011 04:19:33 +0000 (UTC) Received: by iwr19 with SMTP id 19so1207388iwr.13 for ; Thu, 16 Jun 2011 21:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to; bh=7pF5ATQ6j8BH8aoXzuS87D59i0QJPbR238qWcnotL1s=; b=V9Q+Af9nLRNychKbc7O3vuYBHWeUZZvVlSKcR5flpv+IKF0OFpWmQuzr9aIoeEUtHx Y5hKjv1pzvWhWN8fqx9TfATE6fJzArb/+b/lVFVU8T1/Nw4PhiPqaIBzVMAKC9ESLPRM dGikBFkUIDpYq9u0rh2Rr4ZLQVWsnx757uJQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to; b=r2Fa0cYsotWnupZ/DcqirIve3RCjAgdGk64pqzTfR7l1g3XZv1kEe4vewzBYOifBPo 2/+g65U4b9tsAZqucCjD13E1DkIw6QVOGfYQpCOKRSp5zmBZjAmuD1ivb01do49WRq1a z57sUE1dZrTsP6GNdpHkNWVd9YffC+DObjfOU= Received: by 10.42.171.71 with SMTP id i7mr1475579icz.96.1308284373137; Thu, 16 Jun 2011 21:19:33 -0700 (PDT) Received: from DataIX.net (adsl-108-73-113-243.dsl.klmzmi.sbcglobal.net [108.73.113.243]) by mx.google.com with ESMTPS id ly7sm2114355icb.12.2011.06.16.21.19.31 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 16 Jun 2011 21:19:32 -0700 (PDT) Sender: The Command Line Kid Received: from DataIX.net (localhost [127.0.0.1]) by DataIX.net (8.14.4/8.14.4) with ESMTP id p5H4JT8C072715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 00:19:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Received: (from jhell@localhost) by DataIX.net (8.14.4/8.14.4/Submit) id p5H4JTu2072714; Fri, 17 Jun 2011 00:19:29 -0400 (EDT) (envelope-from jhell@DataIX.net) Date: Fri, 17 Jun 2011 00:19:29 -0400 From: jhell To: Hiroki Sato Message-ID: <20110617041929.GC58034@DataIX.net> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> <20110617.124029.722784011683540958.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110617.124029.722784011683540958.hrs@allbsd.org> Cc: net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 04:19:34 -0000 On Fri, Jun 17, 2011 at 12:40:29PM +0900, Hiroki Sato wrote: > jhell wrote > in <20110617022950.GA58034@DataIX.net>: > > jh> Gosh, Wouldnt it be something if we could store our dynamic resolver > jh> information with the interface in the same sort of fashion that we store > jh> our routing tables ? and then modify our routines in the library to look > jh> them up via the "resolving tables" and think of resolv.conf as static > jh> routing information only ? > jh> > jh> If we can already do this via resolvconf(8) in order to modify > jh> resolv.conf how hard would it be to adjust to move in this direction ? > > jhell wrote > in <20110617023358.GB58034@DataIX.net>: > > jh> I appologize for the insta-reply, but thinking more along the lines of > jh> this it may come as even more of a benefit to tie this more into the > jh> routing table so so each route can have a dynamic nameserver attached to > jh> it so when setfib(8) is used a whole nother batch of nameserver could > jh> also be used or fall back to the standard resolv.conf. > > I am not sure of the benefit to adopt "same sort of fashion as the > routing table" for RDNSS entries. What is your problem, and how does > your idea solve it? > Not that its a problem, I don't do much with dynamic configuration but suppose I would when it comes to IPv6 via rtadvd/rtsold and similiar configuration but not currently. What I see with resolvconf(8) is that we are trying to solve a dynamic nameserver problem on a interface basis and trying to find a way to classify that into a file that is in the same or similiar format as resolv.conf if I under everything correctly from your OP. Seeing how this happens on a interface basis as does the routing information for that information it makes sense to me that having a table similiar to that of our routing table, but for the nameservers would allow us to allocate & destroy that information at will when the interface became up/down by a dynamic configuration whether that be DHCP* rtsol/rtadv slaac etc... Rather than trying to come up with some sort of tagging or classification scheme for the way we store the information in a file and the way its read it really seems this what could be considered temporary information could be kept like the routing table. This would have its advantages for jail(8) and setfib(1) as well. Basically if its dynamic then it came in on a specific interface and is used by that interface and only used while that interface is available there for temporary much like the route information you would receive such as the default gateway that disapears when the interface disapears or is unconfigured. Why shouldnt we do the same thing with the nameservers ? in a similiar type of table ? or an addition to the topology of the existing routing table ? I don't know if I am exactly getting the point accross here that I am trying to make. Does someone else see the advantages of this ? does this make sense ? can someone else explain it the way I am thinking about it here ? From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 09:33:53 2011 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E108D106564A for ; Fri, 17 Jun 2011 09:33:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id 9A3F38FC08 for ; Fri, 17 Jun 2011 09:33:51 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p5H9XZEt003905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2011 18:33:46 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p5H9XW5O037597; Fri, 17 Jun 2011 18:33:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Fri, 17 Jun 2011 18:33:13 +0900 (JST) Message-Id: <20110617.183313.762844426550277034.hrs@allbsd.org> To: bzeeb-lists@lists.zabbadoz.net From: Hiroki Sato In-Reply-To: References: <6FE95AC6-CCB2-45B0-8347-AB31283EE144@lists.zabbadoz.net> <20110616.142834.63956571381923731.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Fri_Jun_17_18_33_13_2011_648)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Fri, 17 Jun 2011 18:33:47 +0900 (JST) X-Spam-Status: No, score=6.9 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, FAKEDWORD_EXCLAMATION,RCVD_IN_CHINA,RCVD_IN_CHINA_KR,RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL, X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: net@FreeBSD.org Subject: Re: [RFC] resolvconf(8) interface id X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 09:33:53 -0000 ----Security_Multipart(Fri_Jun_17_18_33_13_2011_648)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit "Bjoern A. Zeeb" wrote in : bz> The only thing I am only still pondering - do we want it to be bz> "slaac" "dchpv4" or the program name? I can see advantages with both. bz> If we go with "slaac" etc. we might need to - at least for the three or so bz> things from base, add a table to the man page like bz> program: origin bz> rtsol -> slaac bz> rtsold -> slaac bz> dhclient -> dhcpv4 bz> ppp -> ppp bz> as people may or may not be familiar enough with what the one or the bz> other might mean. Maybe simply describing the cases will be good bz> enough as well. bz> bz> I can imaging ports like mpd, ... to join this scheme and by then bz> there might be different "ppp" or "dhcpv4", "dhcpv6" or even different bz> "slaac". The advantage of this one is that if I prefer dhcpv6 on one bz> interface it doesn't make a difference if I am going to use dippler, bz> isc or wide. Yes, the reason why I chose a protocol name over a program name as the origin is exactly the same as what you think/feel. Documenting them is important for whichever we use---I am often confused with what name should be used for the daemon name field in /etc/hosts.allow and a !foo line in /etc/syslog.conf. Okay, I will give it a try to create a patchset for utilities that need /etc/resolv.conf update in the base system. -- Hiroki ----Security_Multipart(Fri_Jun_17_18_33_13_2011_648)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk37H1kACgkQTyzT2CeTzy31cwCgk30FWzCe66aVRGRkElFViK/W spYAn1eRLre5XxjDjNL07Qo/Vk9dY165 =5sX9 -----END PGP SIGNATURE----- ----Security_Multipart(Fri_Jun_17_18_33_13_2011_648)---- From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 11:34:22 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E341106572D; Fri, 17 Jun 2011 11:34:22 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 66C738FC08; Fri, 17 Jun 2011 11:34:22 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p5HBYMiY098174; Fri, 17 Jun 2011 11:34:22 GMT (envelope-from ae@freefall.freebsd.org) Received: (from ae@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p5HBYLhT098169; Fri, 17 Jun 2011 11:34:21 GMT (envelope-from ae) Date: Fri, 17 Jun 2011 11:34:21 GMT Message-Id: <201106171134.p5HBYLhT098169@freefall.freebsd.org> To: alexey_kovalenko@inbox.ru, ae@FreeBSD.org, freebsd-net@FreeBSD.org From: ae@FreeBSD.org Cc: Subject: Re: kern/157802: [dummynet] [panic] kernel panic in dummynet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 11:34:22 -0000 Synopsis: [dummynet] [panic] kernel panic in dummynet State-Changed-From-To: open->feedback State-Changed-By: ae State-Changed-When: Fri Jun 17 11:33:59 UTC 2011 State-Changed-Why: Feedback requested. http://www.freebsd.org/cgi/query-pr.cgi?pr=157802 From owner-freebsd-net@FreeBSD.ORG Fri Jun 17 12:19:25 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1F200106566C; Fri, 17 Jun 2011 12:19:25 +0000 (UTC) (envelope-from "."@babolo.ru) Received: from smtp1.babolo.ru (smtp1.babolo.ru [195.9.14.139]) by mx1.freebsd.org (Postfix) with ESMTP id 90B1B8FC1B; Fri, 17 Jun 2011 12:19:24 +0000 (UTC) Received: from cicuta.babolo.ru ([194.58.246.5]) by smtp1.babolo.ru (8.14.2/8.14.2) with SMTP id p5HC0Jjs042415; Fri, 17 Jun 2011 16:00:20 +0400 (MSD) (envelope-from .@babolo.ru) Received: (nullmailer pid 74965 invoked by uid 136); Fri, 17 Jun 2011 12:05:35 -0000 Date: Fri, 17 Jun 2011 16:05:35 +0400 From: Aleksandr A Babaylov <.@babolo.ru> To: Hiroki Sato Message-ID: <20110617120535.GA74911@babolo.ru> References: <20110616.015317.781291617533474654.hrs@allbsd.org> <20110617022950.GA58034@DataIX.net> <20110617.124029.722784011683540958.hrs@allbsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110617.124029.722784011683540958.hrs@allbsd.org> Cc: jhell@DataIX.net, net@freebsd.org Subject: Re: Dynamin/Static Resolver Table [netstat like] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 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, 17 Jun 2011 12:19:25 -0000 On Fri, Jun 17, 2011 at 12:40:29PM +0900, Hiroki Sato wrote: > jhell wrote > in <20110617022950.GA58034@DataIX.net>: > > jh> Gosh, Wouldnt it be something if we could store our dynamic resolver > jh> information with the interface in the same sort of fashion that we store > jh> our routing tables ? and then modify our routines in the library to look > jh> them up via the "resolving tables" and think of resolv.conf as static > jh> routing information only ? > jh> > jh> If we can already do this via resolvconf(8) in order to modify > jh> resolv.conf how hard would it be to adjust to move in this direction ? > > jhell wrote > in <20110617023358.GB58034@DataIX.net>: > > jh> I appologize for the insta-reply, but thinking more along the lines of > jh> this it may come as even more of a benefit to tie this more into the > jh> routing table so so each route can have a dynamic nameserver attached to > jh> it so when setfib(8) is used a whole nother batch of nameserver could > jh> also be used or fall back to the standard resolv.conf. > > I am not sure of the benefit to adopt "same sort of fashion as the > routing table" for RDNSS entries. What is your problem, and how does > your idea solve it? I think jhell's idea is overkill, but I like mount root read only. Symlinks are not beautiful.