From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 08:19:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A07CEB4F for ; Sun, 17 Feb 2013 08:19:32 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) by mx1.freebsd.org (Postfix) with ESMTP id 3FD40DEA for ; Sun, 17 Feb 2013 08:19:32 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id t57so4006512wey.13 for ; Sun, 17 Feb 2013 00:19:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=P0/369d24UQKIPU6QGSx9UBhMSdEOuR6Nu25ZCS0tRk=; b=bllEXeRb9RDvJzAbwEZt7+iaQZghGxHT1dA3cWaTJiWHXwdlKs2gN+rFRUmI8SFiXw 0LIR6+k6w1gzLt8vipijCaw0nxdrKwWJB8ub5f3JmUZz7HRXWnb5qjGgjwoxNK9jDeXu k8Ji8hz6tPdJXPG+pM1OJsRLb98adTMLl2YYKWs6XQdWNGu/BkaFJtcAz68ZhbWYSVlt FEW5tpscVf3zBeV0yIGMlFX+4apkXy5Pr9+AiLfvv8KWRg50gHmoZKvZZl0FXwpOZ9Eo w+97FcozIFm4uQru/goYtddxR0HQFPdMSqmZc1sSgixMEbpvPN2vdey/gI1qu0db/PUU 0S3g== X-Received: by 10.180.92.129 with SMTP id cm1mr14093952wib.10.1361089170542; Sun, 17 Feb 2013 00:19:30 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.23.199 with HTTP; Sun, 17 Feb 2013 00:19:10 -0800 (PST) In-Reply-To: References: From: h bagade Date: Sun, 17 Feb 2013 11:49:10 +0330 X-Google-Sender-Auth: Y2ER0ismWJOXrdEgJ46AV-6xmKY Message-ID: Subject: Re: failed to use getifaddrs on geli code To: Kevin Oberman Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 08:19:32 -0000 On Sat, Feb 16, 2013 at 10:23 PM, Kevin Oberman wrote: > On Sat, Feb 16, 2013 at 5:40 AM, h bagade wrote: > > Hi all, > > > > I need to change the geli code and I want to use "getifaddrs" function > > inside the code. I make and make install the code and it wasn't any > problem > > at all, but when I want to load the geom_eli.ko module, an error > occurred: > > kldload: can't load /boot/kernel/geom_eli.ko: Exec format error > > > > and in /var/log/messages, it stated: > > link_elf_obj: symbol getifaddrs undefined > > > > how can I solve this problem? > > Any hints or comments are really appreciated > > One possibility is that your sources from which you built the modified > geom_eli module are not the same as were used to build the kernel you > are running. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6558@gmail.com > I've build the kernel once again with the modified geli code and the error still exists! From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 08:24:11 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 718A2CC4 for ; Sun, 17 Feb 2013 08:24:11 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id D7F10DFE for ; Sun, 17 Feb 2013 08:24:10 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r1H8O75a012456; Sun, 17 Feb 2013 10:24:07 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r1H8O75a012456 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r1H8O7pR012455; Sun, 17 Feb 2013 10:24:07 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 17 Feb 2013 10:24:07 +0200 From: Konstantin Belousov To: h bagade Subject: Re: failed to use getifaddrs on geli code Message-ID: <20130217082407.GE2598@kib.kiev.ua> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="C94crkcyjafcjHxo" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,FREEMAIL_REPLY,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-net@freebsd.org, Kevin Oberman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 08:24:11 -0000 --C94crkcyjafcjHxo Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Feb 17, 2013 at 11:49:10AM +0330, h bagade wrote: > On Sat, Feb 16, 2013 at 10:23 PM, Kevin Oberman wrote: >=20 > > On Sat, Feb 16, 2013 at 5:40 AM, h bagade wrote: > > > Hi all, > > > > > > I need to change the geli code and I want to use "getifaddrs" function > > > inside the code. I make and make install the code and it wasn't any > > problem > > > at all, but when I want to load the geom_eli.ko module, an error > > occurred: > > > kldload: can't load /boot/kernel/geom_eli.ko: Exec format error > > > > > > and in /var/log/messages, it stated: > > > link_elf_obj: symbol getifaddrs undefined > > > > > > how can I solve this problem? > > > Any hints or comments are really appreciated > > > > One possibility is that your sources from which you built the modified > > geom_eli module are not the same as were used to build the kernel you > > are running. > > -- > > R. Kevin Oberman, Network Engineer > > E-mail: kob6558@gmail.com > > >=20 > I've build the kernel once again with the modified geli code and the error > still exists! getifaddrs(3) is usermode interface, exported from libc. You cannot use it from the kernel. --C94crkcyjafcjHxo Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRIJOmAAoJEJDCuSvBvK1B81cP/15/ppF03rvYD1zdXHOh30B1 m1WixRz4cRJPiIUb8yvLZm4RKqsOfd/vuCL/YY1jcwdsxWuaBxWZBEFzOJIvQ9Hc vkRBRdbZOLSniehH2PrwHz3bFNo1J/qWjVnS1JwWFlm/kLenjEHpBZ4SWzSDbAW4 PTuMF5DOHTx+Hg/8D3TZHzvnalUn3oN66F1SBr7i4IQoWjM5gwK7IIKABPPpkN/m qSXHR8ZYVGdfpq3aVnG53/3AmaU+ij4kzh7DvfOHoBCRe05m73HtljN1azGHxEqx pb1EUo1jXomrm/0GcOfksqvU9c8eKK7PHz5yHIgYS7Y9h0HWwL5his7KpL71uXZ4 OYMZK9SBpgisqYxsGVIBo3zNTDftEkjkkeIvG9wEuNu//no0Qo3oJxb1OFWPASbS BE05/34wrUak5gtRc7sul13NZkftgetNHbdRINavWdvMDjAYAZfesm1cC8dqGM+z i1h3QcpZhiLFFjgqFkNDJ65qmXYP/+An1byRW1iw+DfypfIxOFqMhEMg3cFhuI4W Emkrh4wGkV/1qKUkVsbRqL1R3lFU+U1XIDmA/bIqm2pCneR2n0LqA5l4oUkm040h QutDv8eGOunPQDuHj/U1LJuk0dd6jR8WooH1ydiy/wnYBuZ9cRLfysliC1XP4+dH RVzh1hldj0Y9fD+YSM3i =DmAK -----END PGP SIGNATURE----- --C94crkcyjafcjHxo-- From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 09:35:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6C7C14C8 for ; Sun, 17 Feb 2013 09:35:49 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 0625AF35 for ; Sun, 17 Feb 2013 09:35:48 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hi8so2514374wib.13 for ; Sun, 17 Feb 2013 01:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=DN+CoZV2hm8lPfgartKgDhJORJ5E23fOped51f9FqBc=; b=YZedDKosO1AlWxThsrEvPQJI4Y/AeC85oFdUJm/HDstMqiaDrU0MhxPNnulyD1OOEE fSqIqoNi/cz1dgleZTjwsecAKbRaoYPrEo19QjmkjPPAluO64NxVVhNxLPVkSjVFzSMj 34eKtMln8PuAjtAPo3S+GiyDlPDk9Ldjj25Gq/r91XTXoBM+lyYJ5i4SaHCuk8yICBWa YM7gONokkMvPGMJjnOSZ7/EeJnRkrzdkZCfebDBUYM2MP5aDuqTVPPbiZDltVDLcNsEv bW9jwLnzkKNSwkgGq7IM6qemjaBkLhv7aGZfKVljPPdk2q20zpLVs30TZ75LURxJcGSD yQtA== X-Received: by 10.180.87.170 with SMTP id az10mr12607477wib.3.1361093742202; Sun, 17 Feb 2013 01:35:42 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.23.199 with HTTP; Sun, 17 Feb 2013 01:35:22 -0800 (PST) In-Reply-To: <20130217082407.GE2598@kib.kiev.ua> References: <20130217082407.GE2598@kib.kiev.ua> From: h bagade Date: Sun, 17 Feb 2013 13:05:22 +0330 X-Google-Sender-Auth: rv-5NZgm1bXSHhvcGL_b3d6P-p4 Message-ID: Subject: Re: failed to use getifaddrs on geli code To: Konstantin Belousov Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, Kevin Oberman X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 09:35:49 -0000 On Sun, Feb 17, 2013 at 11:54 AM, Konstantin Belousov wrote: > On Sun, Feb 17, 2013 at 11:49:10AM +0330, h bagade wrote: > > On Sat, Feb 16, 2013 at 10:23 PM, Kevin Oberman > wrote: > > > > > On Sat, Feb 16, 2013 at 5:40 AM, h bagade wrote: > > > > Hi all, > > > > > > > > I need to change the geli code and I want to use "getifaddrs" > function > > > > inside the code. I make and make install the code and it wasn't any > > > problem > > > > at all, but when I want to load the geom_eli.ko module, an error > > > occurred: > > > > kldload: can't load /boot/kernel/geom_eli.ko: Exec format error > > > > > > > > and in /var/log/messages, it stated: > > > > link_elf_obj: symbol getifaddrs undefined > > > > > > > > how can I solve this problem? > > > > Any hints or comments are really appreciated > > > > > > One possibility is that your sources from which you built the modified > > > geom_eli module are not the same as were used to build the kernel you > > > are running. > > > -- > > > R. Kevin Oberman, Network Engineer > > > E-mail: kob6558@gmail.com > > > > > > > I've build the kernel once again with the modified geli code and the > error > > still exists! > > getifaddrs(3) is usermode interface, exported from libc. You cannot > use it from the kernel. > Thank you alot for your precise answer. So does anybody know which method I could replace to get out network interfaces properties? From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 15:51:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 26937E4C for ; Sun, 17 Feb 2013 15:51:50 +0000 (UTC) (envelope-from ihsan@grep.my) Received: from svc02-kul.b.n3labs.my (svc02-kul.b.n3labs.my [IPv6:2400:3700:10::61]) by mx1.freebsd.org (Postfix) with ESMTP id DDD7CCD5 for ; Sun, 17 Feb 2013 15:51:49 +0000 (UTC) Received: from [IPv6:2400:3700:49::7d9c:a406:7d96:95e5] (unknown [IPv6:2400:3700:49:0:7d9c:a406:7d96:95e5]) by svc02-kul.b.n3labs.my (Postfix) with ESMTPSA id ADD8EC60237 for ; Sun, 17 Feb 2013 23:51:39 +0800 (MYT) From: Ihsan Junaidi Ibrahim Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: getifaddrs() gif tunnel src/dst address Message-Id: Date: Sun, 17 Feb 2013 23:51:35 +0800 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 15:51:50 -0000 Hi, I've been trying to obtain gif tunnel addresses via getifaddrs() but = I've not been able to. The tunnel addresses can be inet/inet6 depending = on the scenario. I can however get the inet/inet6 address of the interface. Is there a way to get them? Also looking at if_gif.c, I notice that there's the following ioctl = flags: - SIOCGLIFPHYADDR - SIOCGIFPSRCADDR(_IN6)/SIOCGIFPDSTADDR(_IN6) - SIOCGIFPHYADDR/SIOCIFPHYADDR_IN6 that I can use to get the addresses however due to my limited knowledge, = I can't seem to figure them out. I believe getifaddrs() invoke one of these flags to return the = inet/inet6 address of the interface when the sa_family refers to = AF_INET/AF_INET6. I've tried matching AF_LINK and managed to match sockaddr_dl.sdl_type = with IFT_GIF but I'm not sure where the tunnel addresses are stored on = that structure. I'm hoping for the collective wisdom to assist me here. Thanks.= From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 21:14:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 26B3B9AA for ; Sun, 17 Feb 2013 21:14:15 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 079578F6 for ; Sun, 17 Feb 2013 21:14:14 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 030D73B00B for ; Sun, 17 Feb 2013 13:14:03 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Re: WTF? RPCPROG_NFS: RPC: Program not registered In-Reply-To: <689563329.3076797.1361028594307.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 17 Feb 2013 13:14:03 -0800 Message-ID: <18442.1361135643@server1.tristatelogic.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 21:14:15 -0000 In message <689563329.3076797.1361028594307.JavaMail.root@erie.cs.uoguelph.ca>, Rick Macklem wrote: >Ronald F. Guilmette wrote: >> nfs_server_flags="-h 192.168.1.2" >Add -t to these flags. It appears that the default is UDP only. YESSSS! Thank you. That did the trick alright. I gather than in the 9.x series, there is a new nfs server thing, yes? And I further gather than this one needs to new -t flag, yes? (Sigh. My own feeling is that tcp support should have been enabled by default... as in the past.) Anyway, thanks again for your help. Regards, rfg From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 22:10:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C54EB3C2 for ; Sun, 17 Feb 2013 22:10:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id 8E799A92 for ; Sun, 17 Feb 2013 22:10:25 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAFJUIVGDaFvO/2dsb2JhbABFhkm5VIEXc4IfAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdrBgysYJFAgSOMU4ENNAeCLYETA4hniw2COIEdiDuHAIMlT4EFNQ X-IronPort-AV: E=Sophos;i="4.84,683,1355115600"; d="scan'208";a="14516919" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 17 Feb 2013 17:10:25 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 22DB7B3F46; Sun, 17 Feb 2013 17:10:25 -0500 (EST) Date: Sun, 17 Feb 2013 17:10:25 -0500 (EST) From: Rick Macklem To: "Ronald F. Guilmette" Message-ID: <670072237.3089090.1361139025074.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <18442.1361135643@server1.tristatelogic.com> Subject: Re: WTF? RPCPROG_NFS: RPC: Program not registered MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.202] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 22:10:26 -0000 Ronald F. Guilmette wrote: > In message > <689563329.3076797.1361028594307.JavaMail.root@erie.cs.uoguelph.ca>, > Rick Macklem wrote: > > >Ronald F. Guilmette wrote: > >> nfs_server_flags="-h 192.168.1.2" > >Add -t to these flags. It appears that the default is UDP only. > > > YESSSS! Thank you. That did the trick alright. > > I gather than in the 9.x series, there is a new nfs server thing, yes? > > And I further gather than this one needs to new -t flag, yes? > > (Sigh. My own feeling is that tcp support should have been enabled by > default... as in the past.) > Nope. The old server used "-t" as well. The settings in /etc/default/rc.conf for nfs_server_flags="-t -u -n 4" You overrode those when you set nfs_server_flags. rick > Anyway, thanks again for your help. > > > Regards, > rfg > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Feb 17 23:02:49 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB816DB3 for ; Sun, 17 Feb 2013 23:02:49 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id AB9ADD86 for ; Sun, 17 Feb 2013 23:02:48 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id ED7383B00B for ; Sun, 17 Feb 2013 15:02:44 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: Re: WTF? RPCPROG_NFS: RPC: Program not registered In-Reply-To: <670072237.3089090.1361139025074.JavaMail.root@erie.cs.uoguelph.ca> Date: Sun, 17 Feb 2013 15:02:44 -0800 Message-ID: <19262.1361142164@server1.tristatelogic.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2013 23:02:49 -0000 In message <670072237.3089090.1361139025074.JavaMail.root@erie.cs.uoguelph.ca>, Rick Macklem wrote: >Ronald F. Guilmette wrote: >> In message >> <689563329.3076797.1361028594307.JavaMail.root@erie.cs.uoguelph.ca>, >> Rick Macklem wrote: >> >> >Ronald F. Guilmette wrote: >> >> nfs_server_flags="-h 192.168.1.2" >> >Add -t to these flags. It appears that the default is UDP only. >> >> >> YESSSS! Thank you. That did the trick alright. >> >> I gather than in the 9.x series, there is a new nfs server thing, yes? >> >> And I further gather than this one needs to new -t flag, yes? >> >> (Sigh. My own feeling is that tcp support should have been enabled by >> default... as in the past.) >> >Nope. The old server used "-t" as well. The settings in >/etc/default/rc.conf for >nfs_server_flags="-t -u -n 4" > >You overrode those when you set nfs_server_flags. Doh! Yes, it appears you are 100% correct. In the past, I had never before had *any* kind of nfs_server_flags= line in my /etc/rc.conf file. After my recent upgrade, I put one in, just to limit the interfaces to which NFS service would be provided, and apparently, in so doing, I utterly hobbled NFS service generally. That outcome certainly did not follow the "principal of least surprise". Oh well. All's well that ends well. Regards, rfg From owner-freebsd-net@FreeBSD.ORG Mon Feb 18 11:06:48 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E7BD6217 for ; Mon, 18 Feb 2013 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id D9BCEE2F for ; Mon, 18 Feb 2013 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1IB6mbK061621 for ; Mon, 18 Feb 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1IB6mZV061619 for freebsd-net@FreeBSD.org; Mon, 18 Feb 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2013 11:06:48 GMT Message-Id: <201302181106.r1IB6mZV061619@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2013 11:06:49 -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/176167 net [ipsec][lagg] using lagg and ipsec causes immediate pa o kern/176097 net [lagg] [patch] lagg/lacp broken when aggregated interf o kern/176027 net [em] [patch] flow control systcl consistency for em dr o kern/176026 net [tcp] [patch] TCP wrappers caused quite a lot of warni o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/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/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [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/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [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 f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [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 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [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 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 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/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [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 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [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 445 problems total. From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 03:06:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7DB8889B for ; Tue, 19 Feb 2013 03:06:03 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ia0-x230.google.com (mail-ia0-x230.google.com [IPv6:2607:f8b0:4001:c02::230]) by mx1.freebsd.org (Postfix) with ESMTP id 35923858 for ; Tue, 19 Feb 2013 03:06:03 +0000 (UTC) Received: by mail-ia0-f176.google.com with SMTP id i18so5556525iac.7 for ; Mon, 18 Feb 2013 19:06:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:subject:message-id:mime-version :content-type:content-disposition:user-agent; bh=QjqhAK93yaBPPijIE5yKd4LKC3FsQv0GZEh/420AmYw=; b=nXc3TU90PtD2lApWb2YKvmE8sr3802E0Jfe5yhYk0f/WQQkhcrqGVGpsoUMmAVAbXA nBLcspwBqvWOMVoFJmmaFog+zmMTIClUE92ox5R7xRFLzcl3TuaHlI6S7cqPQmfLJ1nW Y2z7t0rdZtxUBxgUrmDmZpRsH3kPBMP7591c5QQUL05A+S9AsbvF030eTaBNJAQfqhnC gitcqVKxiYQBXz1RKC8CoYlrQ2QKyCV2V0KgEDZsJxt358H8mbP2rVQJEvNUL9XJ2j2f 1s0HdMOPYKoyX0UwyOSZyMp6Gga4ygwXDwmsBtsQAA11xFoDMczvdngeVXsx5v1f1VkI CAWQ== X-Received: by 10.50.237.71 with SMTP id va7mr3728017igc.88.1361243162309; Mon, 18 Feb 2013 19:06:02 -0800 (PST) Received: from oddish ([66.11.160.25]) by mx.google.com with ESMTPS id ee5sm4469574igc.0.2013.02.18.19.06.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Feb 2013 19:06:01 -0800 (PST) Sender: Mark Johnston Date: Mon, 18 Feb 2013 22:05:52 -0500 From: Mark Johnston To: freebsd-net@freebsd.org Subject: NDP prefix list locking Message-ID: <20130219030552.GI9611@oddish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 03:06:03 -0000 Hi Everyone, For the past little while I've been tracking down some memory corruption issues that seem to be caused by a double free that can happen when destroying an IPv6-enabled interface or when removing an IPv6 address from an interface. The problem seems to be caused by a lack of locking for nd_prefix, the global IPv6 prefix list. There's a callout that periodically executes nd6_timer(), which purges expired prefixes (among other things). There's nothing preventing an expired prefix from being freed twice if a user happens to destroy the corresponding address or IP address at the same time. In fact, a prefix with an infinite lifetime can be double freed as well, since the first thing prelist_remove() does is set the input prefix's vltime field to 0. I'd like to fix this, and the patch below is my attempt at adding some locking to accesses of the prefix and default router lists. It's only received very light testing so far, but I was hoping that others could either review/test the patch, or suggest alternative approaches to fixing this. My approach here has been to add two rw locks - one for the prefix list and one for the default router list. I'm not very familiar with the NDP code so I'm very much open to comments and suggestions. :) Thanks, -Mark diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c index e260e5d..3cb327c 100644 --- a/sys/netinet6/in6.c +++ b/sys/netinet6/in6.c @@ -805,8 +805,11 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, */ pr = ia->ia6_ndpr; in6_purgeaddr(&ia->ia_ifa); - if (pr && pr->ndpr_refcnt == 0) + if (pr && pr->ndpr_refcnt == 0) { + ND_PREFIX_WLOCK(); prelist_remove(pr); + ND_PREFIX_WUNLOCK(); + } EVENTHANDLER_INVOKE(ifaddr_event, ifp); break; } diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c index fd420d8..d96340c 100644 --- a/sys/netinet6/nd6.c +++ b/sys/netinet6/nd6.c @@ -117,6 +117,9 @@ static int nd6_inuse, nd6_allocated; VNET_DEFINE(struct nd_drhead, nd_defrouter); VNET_DEFINE(struct nd_prhead, nd_prefix); +struct rwlock nd_prefix_rwlock; +struct rwlock nd_defrouter_rwlock; + VNET_DEFINE(int, nd6_recalc_reachtm_interval) = ND6_RECALC_REACHTM_INTERVAL; #define V_nd6_recalc_reachtm_interval VNET(nd6_recalc_reachtm_interval) @@ -143,6 +146,7 @@ nd6_init(void) { int i; + rw_init(&nd_prefix_rwlock, "nd_prefix rwlock"); LIST_INIT(&V_nd_prefix); all1_sa.sin6_family = AF_INET6; @@ -151,6 +155,7 @@ nd6_init(void) all1_sa.sin6_addr.s6_addr[i] = 0xff; /* initialization of the default router list */ + rw_init(&nd_defrouter_rwlock, "nd_defrouter rwlock"); TAILQ_INIT(&V_nd_defrouter); /* start timer */ @@ -586,10 +591,14 @@ nd6_timer(void *arg) nd6_timer, curvnet); /* expire default router list */ + ND_PREFIX_RLOCK(); + ND_DEFRTR_WLOCK(); TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { if (dr->expire && dr->expire < time_second) defrtrlist_del(dr); } + ND_DEFRTR_WUNLOCK(); + ND_PREFIX_RUNLOCK(); /* * expire interface addresses. @@ -664,6 +673,7 @@ nd6_timer(void *arg) } /* expire prefix list */ + ND_PREFIX_WLOCK(); LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { /* * check prefix lifetime. @@ -680,6 +690,7 @@ nd6_timer(void *arg) prelist_remove(pr); } } + ND_PREFIX_WUNLOCK(); CURVNET_RESTORE(); } @@ -770,6 +781,8 @@ nd6_purge(struct ifnet *ifp) * in the routing table, in order to keep additional side effects as * small as possible. */ + ND_PREFIX_RLOCK(); + ND_DEFRTR_WLOCK(); TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { if (dr->installed) continue; @@ -785,8 +798,11 @@ nd6_purge(struct ifnet *ifp) if (dr->ifp == ifp) defrtrlist_del(dr); } + ND_DEFRTR_WUNLOCK(); + ND_PREFIX_RUNLOCK(); /* Nuke prefix list entries toward ifp */ + ND_PREFIX_WLOCK(); LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { if (pr->ndpr_ifp == ifp) { /* @@ -808,6 +824,7 @@ nd6_purge(struct ifnet *ifp) prelist_remove(pr); } } + ND_PREFIX_WUNLOCK(); /* cancel default outgoing interface setting */ if (V_nd6_defifindex == ifp->if_index) @@ -898,6 +915,7 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) * If the address matches one of our on-link prefixes, it should be a * neighbor. */ + ND_PREFIX_RLOCK(); LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { if (pr->ndpr_ifp != ifp) continue; @@ -929,9 +947,12 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) } if (IN6_ARE_MASKED_ADDR_EQUAL(&pr->ndpr_prefix.sin6_addr, - &addr->sin6_addr, &pr->ndpr_mask)) + &addr->sin6_addr, &pr->ndpr_mask)) { + ND_PREFIX_RUNLOCK(); return (1); + } } + ND_PREFIX_RUNLOCK(); /* * If the address is assigned on the node of the other side of @@ -1229,6 +1250,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) * obsolete API, use sysctl under net.inet6.icmp6 */ bzero(drl, sizeof(*drl)); + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { if (i >= DRLSTSIZ) break; @@ -1241,6 +1263,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) drl->defrouter[i].if_index = dr->ifp->if_index; i++; } + ND_DEFRTR_RUNLOCK(); break; case SIOCGPRLST_IN6: /* @@ -1256,6 +1279,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) * how about separating ioctls into two? */ bzero(oprl, sizeof(*oprl)); + ND_PREFIX_RLOCK(); LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { struct nd_pfxrouter *pfr; int j; @@ -1301,6 +1325,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) i++; } + ND_PREFIX_RUNLOCK(); break; case OSIOCGIFINFO_IN6: @@ -1449,6 +1474,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) /* flush all the prefix advertised by routers */ struct nd_prefix *pr, *next; + ND_PREFIX_WLOCK(); LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, next) { struct in6_ifaddr *ia, *ia_next; @@ -1467,6 +1493,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) } prelist_remove(pr); } + ND_PREFIX_WUNLOCK(); break; } case SIOCSRTRFLUSH_IN6: @@ -1475,9 +1502,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) struct nd_defrouter *dr, *next; defrouter_reset(); + ND_PERFIX_RLOCK(); + ND_DEFRTR_WLOCK(); TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, next) { defrtrlist_del(dr); } + ND_DEFRTR_WUNLOCK(); + ND_PREFIX_RUNLOCK(); defrouter_select(); break; } @@ -2268,23 +2299,30 @@ nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) d.rtaddr.sin6_family = AF_INET6; d.rtaddr.sin6_len = sizeof(d.rtaddr); + error = sysctl_wire_old_buffer(req, 0); + if (error != 0) + return (error); + /* * XXX locking */ + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { d.rtaddr.sin6_addr = dr->rtaddr; error = sa6_recoverscope(&d.rtaddr); if (error != 0) - return (error); + break; d.flags = dr->flags; d.rtlifetime = dr->rtlifetime; d.expire = dr->expire; d.if_index = dr->ifp->if_index; error = SYSCTL_OUT(req, &d, sizeof(d)); if (error != 0) - return (error); + break; } - return (0); + ND_DEFRTR_RUNLOCK(); + + return (error); } static int @@ -2307,9 +2345,14 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) s6.sin6_family = AF_INET6; s6.sin6_len = sizeof(s6); + error = sysctl_wire_old_buffer(req, 0); + if (error != 0) + return (error); + /* * XXX locking */ + ND_PREFIX_RLOCK(); LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { p.prefix = pr->ndpr_prefix; if (sa6_recoverscope(&p.prefix)) { @@ -2341,7 +2384,7 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) p.advrtrs++; error = SYSCTL_OUT(req, &p, sizeof(p)); if (error != 0) - return (error); + break; LIST_FOREACH(pfr, &pr->ndpr_advrtrs, pfr_entry) { s6.sin6_addr = pfr->router->rtaddr; if (sa6_recoverscope(&s6)) @@ -2349,9 +2392,13 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) "scope error in prefix list (%s)\n", ip6_sprintf(ip6buf, &pfr->router->rtaddr)); error = SYSCTL_OUT(req, &s6, sizeof(s6)); - if (error != 0) + if (error != 0) { + ND_PREFIX_RUNLOCK(); return (error); + } } } - return (0); + ND_PREFIX_RUNLOCK(); + + return (error); } diff --git a/sys/netinet6/nd6.h b/sys/netinet6/nd6.h index 94202e1..bc5ff2d 100644 --- a/sys/netinet6/nd6.h +++ b/sys/netinet6/nd6.h @@ -38,6 +38,7 @@ #define RTF_ANNOUNCE RTF_PROTO2 #endif +#include #include #include @@ -341,6 +342,35 @@ VNET_DECLARE(int, nd6_onlink_ns_rfc4861); #define V_nd6_debug VNET(nd6_debug) #define V_nd6_onlink_ns_rfc4861 VNET(nd6_onlink_ns_rfc4861) +/* Lock to protect access to the nd_prefix list. */ +extern struct rwlock nd_prefix_rwlock; +#define ND_PREFIX_RLOCK() rw_rlock(&nd_prefix_rwlock) +#define ND_PREFIX_RUNLOCK() rw_runlock(&nd_prefix_rwlock) +#define ND_PREFIX_WLOCK() rw_wlock(&nd_prefix_rwlock) +#define ND_PREFIX_WUNLOCK() rw_wunlock(&nd_prefix_rwlock) +#define ND_PREFIX_LOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_LOCKED) +#define ND_PREFIX_RLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_RLOCKED) +#define ND_PREFIX_WLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_WLOCKED) +#define ND_PREFIX_WLOCK_OWNED() rw_wowned(&nd_prefix_rwlock) + +/* + * Lock to protect access to the nd_defrouter list. A shared lock should be + * acquired on the prefix list before acquiring an exclusive lock on the router + * list and calling defrouterlist_del() in order to avoid lock order reversals. + */ +extern struct rwlock nd_defrouter_rwlock; +#define ND_DEFRTR_RLOCK() rw_rlock(&nd_defrouter_rwlock) +#define ND_DEFRTR_RUNLOCK() rw_runlock(&nd_defrouter_rwlock) +#define ND_DEFRTR_WLOCK() rw_wlock(&nd_defrouter_rwlock) +#define ND_DEFRTR_WUNLOCK() rw_wunlock(&nd_defrouter_rwlock) +#define ND_DEFRTR_LOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ + RA_LOCKED) +#define ND_DEFRTR_RLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ + RA_RLOCKED) +#define ND_DEFRTR_WLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ + RA_WLOCKED) +#define ND_DEFRTR_WLOCK_OWNED() rw_wowned(&nd_defrouter_rwlock) + #define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) VNET_DECLARE(struct callout, nd6_timer_ch); diff --git a/sys/netinet6/nd6_rtr.c b/sys/netinet6/nd6_rtr.c index f6bae0c..e5c63b9 100644 --- a/sys/netinet6/nd6_rtr.c +++ b/sys/netinet6/nd6_rtr.c @@ -499,14 +499,16 @@ defrouter_addreq(struct nd_defrouter *new) struct nd_defrouter * defrouter_lookup(struct in6_addr *addr, struct ifnet *ifp) { - struct nd_defrouter *dr; + struct nd_defrouter *dr = NULL; + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { if (dr->ifp == ifp && IN6_ARE_ADDR_EQUAL(addr, &dr->rtaddr)) - return (dr); + break; } + ND_DEFRTR_RUNLOCK(); - return (NULL); /* search failed */ + return (dr); /* search failed */ } /* @@ -548,8 +550,10 @@ defrouter_reset(void) { struct nd_defrouter *dr; + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) defrouter_delreq(dr); + ND_DEFRTR_RUNLOCK(); /* * XXX should we also nuke any default routers in the kernel, by @@ -574,11 +578,13 @@ defrtrlist_del(struct nd_defrouter *dr) deldr = dr; defrouter_delreq(dr); } + ND_DEFRTR_WLOCK_ASSERT(); TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); /* * Also delete all the pointers to the router in each prefix lists. */ + ND_PREFIX_RLOCK_ASSERT(); LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { struct nd_pfxrouter *pfxrtr; if ((pfxrtr = pfxrtr_lookup(pr, dr)) != NULL) @@ -636,6 +642,7 @@ defrouter_select(void) * We just pick up the first reachable one (if any), assuming that * the ordering rule of the list described in defrtrlist_update(). */ + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { IF_AFDATA_RLOCK(dr->ifp); if (selected_dr == NULL && @@ -657,6 +664,8 @@ defrouter_select(void) " is installed\n"); } } + ND_DEFRTR_RUNLOCK(); + /* * If none of the default routers was found to be reachable, * round-robin the list regardless of preference. @@ -758,7 +767,9 @@ defrtrlist_update(struct nd_defrouter *new) * defrouter_select() below will handle routing * changes later. */ + ND_DEFRTR_WLOCK(); TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); + ND_DEFRTR_WUNLOCK(); n = dr; goto insert; } @@ -784,6 +795,7 @@ insert: */ /* insert at the end of the group */ + ND_DEFRTR_WLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { if (rtpref(n) > rtpref(dr)) break; @@ -792,6 +804,7 @@ insert: TAILQ_INSERT_BEFORE(dr, n, dr_entry); else TAILQ_INSERT_TAIL(&V_nd_defrouter, n, dr_entry); + ND_DEFRTR_WUNLOCK(); defrouter_select(); @@ -839,6 +852,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) { struct nd_prefix *search; + ND_PREFIX_RLOCK(); LIST_FOREACH(search, &V_nd_prefix, ndpr_entry) { if (key->ndpr_ifp == search->ndpr_ifp && key->ndpr_plen == search->ndpr_plen && @@ -847,6 +861,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) break; } } + ND_PREFIX_RUNLOCK(); return (search); } @@ -887,7 +902,9 @@ nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, new->ndpr_mask.s6_addr32[i]; /* link ndpr_entry to nd_prefix list */ + ND_PREFIX_WLOCK(); LIST_INSERT_HEAD(&V_nd_prefix, new, ndpr_entry); + ND_PREFIX_WUNLOCK(); /* ND_OPT_PI_FLAG_ONLINK processing */ if (new->ndpr_raf_onlink) { @@ -938,6 +955,7 @@ prelist_remove(struct nd_prefix *pr) return; /* notice here? */ /* unlink ndpr_entry from nd_prefix list */ + ND_PREFIX_WLOCK_ASSERT(); LIST_REMOVE(pr, ndpr_entry); /* free list of routers that adversed the prefix */ @@ -1339,6 +1357,8 @@ pfxlist_onlink_check() * Check if there is a prefix that has a reachable advertising * router. */ + if (!ND_PREFIX_WLOCK_OWNED()) + ND_PREFIX_RLOCK(); LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { if (pr->ndpr_raf_onlink && find_pfxlist_reachable_router(pr)) break; @@ -1349,6 +1369,7 @@ pfxlist_onlink_check() * that does not advertise any prefixes. */ if (pr == NULL) { + ND_DEFRTR_RLOCK(); TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { struct nd_prefix *pr0; @@ -1359,6 +1380,7 @@ pfxlist_onlink_check() if (pfxrtr != NULL) break; } + ND_DEFRTR_RUNLOCK(); } if (pr != NULL || (!TAILQ_EMPTY(&V_nd_defrouter) && pfxrtr == NULL)) { /* @@ -1454,6 +1476,8 @@ pfxlist_onlink_check() } } } + if (!ND_PREFIX_WLOCK_OWNED()) + ND_PREFIX_RUNLOCK(); /* * Changes on the prefix status might affect address status as well. @@ -1618,6 +1642,7 @@ nd6_prefix_onlink(struct nd_prefix *pr) * Although such a configuration is expected to be rare, we explicitly * allow it. */ + ND_PREFIX_RLOCK(); LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { if (opr == pr) continue; @@ -1627,9 +1652,12 @@ nd6_prefix_onlink(struct nd_prefix *pr) if (opr->ndpr_plen == pr->ndpr_plen && in6_are_prefix_equal(&pr->ndpr_prefix.sin6_addr, - &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) + &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) { + ND_PREFIX_RUNLOCK(); return (0); + } } + ND_PREFIX_RUNLOCK(); /* * We prefer link-local addresses as the associated interface address. @@ -1730,6 +1758,7 @@ nd6_prefix_offlink(struct nd_prefix *pr) * If there's one, try to make the prefix on-link on the * interface. */ + ND_PREFIX_LOCK_ASSERT(); LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { if (opr == pr) continue; From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 07:45:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B8392C99 for ; Tue, 19 Feb 2013 07:45:19 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by mx1.freebsd.org (Postfix) with ESMTP id 7BF7B1D1 for ; Tue, 19 Feb 2013 07:45:18 +0000 (UTC) Received: from [186.134.32.92] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U7hsd-0007QH-Vy; Tue, 19 Feb 2013 08:44:48 +0100 Message-ID: <51232D67.8040100@gont.com.ar> Date: Tue, 19 Feb 2013 04:44:39 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Net Subject: pcap DLT_NULL encapsulation X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 07:45:19 -0000 Folks, I've working on a libpcap-based program that sends packets over a gogoc-created tunnel. The gogoc-created interface is of type DLT_NULL. My understanding is that packets sent/received on such interface type include a 4-byte header that includes the address family as a 32-bit integer, in host byte order. Packets sent with tools such as ping6, get the corresponding header set to 0x1c (PF_INET6). However, packets sent with pcap_inject() get such header set to 0x1f, even when I explicitly set it to PF_INET6 (0x1c). >From a practical point of view, everything works ok (i.e., my packets *are* successfully sent over the tunnel). However, when sniffing traffic on my local host, I get a "AF unknown (31)", as in: --- cut here ---- 04:31:09.377625 AF Unknown (31), length 108: 0x0000: 6000 0000 0040 3aff 2001 05c0 1000 000a `....@:......... 0x0010: 0000 0000 0000 152d 2001 05c0 1000 000a .......-........ 0x0020: 0000 0000 0000 0108 8000 d368 667c 0000 ...........hf|.. ---- cut here ---- it looks like no matter what I write in that header, the contents never change when the packet hit the interface (i.e., once pcap_inject() is called, it seems those bytes are being rewritten). Is this a known issue with gogoc? Am I missing something else? Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@si6networks.com PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 10:57:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A5C62B6B for ; Tue, 19 Feb 2013 10:57:19 +0000 (UTC) (envelope-from markus.jan@seznam.cz) Received: from mail.metron.cz (smtp.metron.cz [109.238.32.53]) by mx1.freebsd.org (Postfix) with ESMTP id 5D00B3CF for ; Tue, 19 Feb 2013 10:57:18 +0000 (UTC) Received: from [10.252.0.120] (gw2.metron.cz [109.238.32.35]) by mail.metron.cz (Postfix) with ESMTP id 31A98A448 for ; Tue, 19 Feb 2013 11:49:32 +0100 (CET) Message-ID: <512358BB.1040609@seznam.cz> Date: Tue, 19 Feb 2013 11:49:31 +0100 From: Jan Markus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Netflow v9 with ng_netflow and nfdump Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 10:57:19 -0000 Hello, our Ministry of the interior now requires that IP traffic logs must contain MAC addresses of our clients. I am trying to fulfil this with Netflow v9 which (allegedly) should contain the MAC addresses of IP flows. But with no success so far... We have a mirror port on our core switch and capture the VLAN tagged packets on em1 NIC on our FreeBSD 9.1 server. Our netflow collector is configured like this: kldload ng_ether kldload ng_ksocket kldload ng_netflow ifconfig em1 promisc -arp up ngctl mkpeer em1: netflow lower iface0 ngctl name em1:lower netflow ngctl connect em1: netflow: upper out0 ngctl mkpeer netflow: ksocket export9 inet/dgram/udp ngctl msg netflow:export9 connect inet/127.0.0.1:9995 We capture the netflow packets on the same machine like this: nfcapd -p 9995 -S 2 -T all -D -l ./ But when I try to get the log like this: nfdump -r nfcapd.201302191051 > nfcapd.201302191051.out All I get is date, protocol, src and dst IP and port, and number of bytes, packets and flows. No information on MAC addresses whatsoever. What am I doing wrong? Thank you very much for your help, -Jan From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 13:33:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 78F25A7A for ; Tue, 19 Feb 2013 13:33:02 +0000 (UTC) (envelope-from fernando@gont.com.ar) Received: from web01.jbserver.net (web01.jbserver.net [93.186.182.34]) by mx1.freebsd.org (Postfix) with ESMTP id 46887D93 for ; Tue, 19 Feb 2013 13:33:01 +0000 (UTC) Received: from [186.134.32.92] (helo=[192.168.123.126]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1U7nJZ-0007Qo-8K; Tue, 19 Feb 2013 14:32:57 +0100 Message-ID: <51237F03.2030505@gont.com.ar> Date: Tue, 19 Feb 2013 10:32:51 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: FreeBSD Net Subject: IPv6 Toolkit v1.3.1 released! X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 13:33:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks, Thought you might be interested in this one... We are pleased to release the SI6 Networks' IPv6 Toolkit v1.3.1: a security assessment and trouble-shooting toolkit for the IPv6 protocol suite. The toolkit is available at: , where you can find a the usual tarball, a PGP-signed version of it, a link to the toolkit's GIT repository, etc. This release has a number of features: * It includes a full-fledged IPv6 address scanning tool (scan6) -- probably the only comprehensive IPv6 address scanning tool out there. Check out all the newly incorporated features! * It includes support for tunnels (in most of the tools). So if you are currently employing e.g. a free IPv6 tunnel to connect to the IPv6 Internet, you'll now be able t play with the tools using your tunnel. * Adds features that have been in our "todo list" for a while: + It includes manual pages in troff format for all the tools. + It includes a makefile, to easily build and install the tools, configuration file, manuals, etc., on your local system. The toolkit runs on (at least) the latest versions of Linux, FreeBSD (it's in the ports and packages, already), NetBSD, OpenBSD, and Mac OS X. Please send any bug reports and/or feature requests to . And you can stay tunned for updates on our Twitter: @SI6Networks. Thanks! Best regards, - -- Fernando Gont SI6 Networks e-mail: fgont@si6networks.com PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRI38CAAoJEJbuqe/Qdv/xvB4IANcsoVDeqAq6wl6meTxG7mT4 tbgwSui/mJfqjKMy+Ew0uurCFQVXGpunRriF86h4bzCRIhd3ObozR47W6s4cf8Ee MZP6os/DFMi+U9LU/eu/N6OKSy8rMf6akB7MgdKl++M3Gj40TNeXeqYDnGMT3c54 ieKA+j9/D9/xEaybh4Z9yamjNnBoeUNnuGXPsdE3iLKfMDvv8v6Mw4iiMoSoffRo 1eQgm7734VUOSUGpOt+bCEw4FIimRgT+VFRoYKmWK2CqOZMxG9GwaDFThhiU2t/A +nRB3S0WzpGekd13hicWJbngPqzj0psFShsUObsjAeHe2oYnuOKRkPa9Gpwoq7Y= =OjsN -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 15:49:14 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1910B66F for ; Tue, 19 Feb 2013 15:49:14 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id D6A54E9A for ; Tue, 19 Feb 2013 15:49:13 +0000 (UTC) Received: from dhcp170-36-red.yandex.net ([95.108.170.36]) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1U7pUp-0008F6-5Y; Tue, 19 Feb 2013 19:52:43 +0400 Message-ID: <51239ED1.6020609@FreeBSD.org> Date: Tue, 19 Feb 2013 19:48:33 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Jan Markus Subject: Re: Netflow v9 with ng_netflow and nfdump References: <512358BB.1040609@seznam.cz> In-Reply-To: <512358BB.1040609@seznam.cz> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 15:49:14 -0000 On 19.02.2013 14:49, Jan Markus wrote: > Hello, Hello. > > our Ministry of the interior now requires that IP traffic logs must > contain MAC addresses of our clients. I am trying to fulfil this with > Netflow v9 which (allegedly) should contain the MAC addresses of IP flows. Netflow version 9 is flexible and allows you to use only necessary fields grouped in 'templates'. Currently ng_netflow supports 2 statically-defined templates (for v4 and v6 L3+L4) and SRC_MAC/DST_MAC are not included there.. > > But with no success so far... > > We have a mirror port on our core switch and capture the VLAN tagged > packets on em1 NIC on our FreeBSD 9.1 server. > > Our netflow collector is configured like this: > > kldload ng_ether > kldload ng_ksocket > kldload ng_netflow > > ifconfig em1 promisc -arp up > > ngctl mkpeer em1: netflow lower iface0 > ngctl name em1:lower netflow > ngctl connect em1: netflow: upper out0 > ngctl mkpeer netflow: ksocket export9 inet/dgram/udp > ngctl msg netflow:export9 connect inet/127.0.0.1:9995 > > We capture the netflow packets on the same machine like this: > > nfcapd -p 9995 -S 2 -T all -D -l ./ > > But when I try to get the log like this: > > nfdump -r nfcapd.201302191051 > nfcapd.201302191051.out > > All I get is date, protocol, src and dst IP and port, and number of > bytes, packets and flows. No information on MAC addresses whatsoever. > > What am I doing wrong? > > Thank you very much for your help, > -Jan > > _______________________________________________ > 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" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 16:21:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 48E7D368 for ; Tue, 19 Feb 2013 16:21:59 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm29-vm0.bullet.mail.ne1.yahoo.com (nm29-vm0.bullet.mail.ne1.yahoo.com [98.138.91.43]) by mx1.freebsd.org (Postfix) with ESMTP id 1571B152 for ; Tue, 19 Feb 2013 16:21:57 +0000 (UTC) Received: from [98.138.90.57] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:50 -0000 Received: from [98.138.87.11] by tm10.bullet.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:49 -0000 Received: from [127.0.0.1] by omp1011.mail.ne1.yahoo.com with NNFMP; 19 Feb 2013 16:21:49 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 591377.58735.bm@omp1011.mail.ne1.yahoo.com Received: (qmail 41730 invoked by uid 60001); 19 Feb 2013 16:21:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361290909; bh=Z+wv8OSgj47AFbfe5TcXV1FhKNKNSzV8pfjMEr1GNUI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=b2FCrafDcKYHjqdCbStZIXTUZ7bCNa1XxIM1bbUv9qcTFyKsrpVonyGjeDHqaSj1ZKV+iP4j+XirUEE4vrbCP88dNfXdx4Z8q3oLOChPjBdqEt/ECw+WGN9RJf+R5Fb/WOlxH9x9TeifBJkA/GiNqVulzcBg/R//wbpYFJCGpq4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=1+7xa9C+zDfuM0veVn+l/CLay7rUk8oLW+dkVhgf54Wcoj83bivZyfSyy+r68473Js+n0DMBuByns4fCiCtfSochjFhlV3MRFATsZV3CuMrYxH7YJ3jirDYeOcFonLkjpxN92hGNomIB6gN6zWt1JL4aO/N+aQ6Xqxxr1Nc9BIc=; X-YMail-OSG: CJH1Rx8VM1kTHT.GNBHegKfprzsWnz1E2nm1N5y7meizZDS ija9VGeHi.6eyKk3x320QGp8_TbJl8GnMkxgGxurQABaIrAAdoySMUZDmdEY jRZ9akpAX0foDuFKunQVW0zwU4zJCQ5usTXltz9EgEEYEBUz8wKc0VgDT6CU P6KBg4Rfu8DsQQ23iLRHWB3TECx20C7E4pEn8MZ2spNliToGq6XINaP29T5c VUkcAHp1RQ3WT1cP_l9jErUeu2bvicj8JWtFp5d0hl0_aTrR6n2cE53kG9ks WpsJWN7zHPf1f8TdxyrKiKQcNpHZrf2MmnQ2I6.sM9dJBmngSQs_WUU1cZqW S0h9UKYCEmJMz_3I15SXjsj0b9692cIydPbZoNlvfoRUiOKJ8thfpP0mYTZc rk1RoO2Jmj.Ix.TG6hO0AEB4gpxXog6m40swKtj0nZgONiomBPzUkMAR4n_u kRsAYHqDmqpiv2rvf381Del2X58gouwKYY6kPwsBnU5BXJcxImWtUz7tAxWN z7w_vYqrQ4Jo1QRGFg07zfbGzETMXKyvb.fqhCUBd_IObs3ybY6TrmC6ff3W O_WRku0jMxrXzaxAZOacorzrf7YWBSeMSN7cPWkunNQtmoWg- Received: from [208.102.228.236] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 19 Feb 2013 08:21:49 PST X-Rocket-MIMEInfo: 001.001, aHR0cDovL3d3dy5iYXVlci1tYy5kZS9sbGNma3JyL3QyY3gzZWx6eXZmcS9oNms1Z3hrbjh2d2pqMmR2cGYBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 Message-ID: <1361290909.39265.YahooMailNeo@web121603.mail.ne1.yahoo.com> Date: Tue, 19 Feb 2013 08:21:49 -0800 (PST) From: Barney Cordoba Subject: Barney Cordoba To: freebsd-net@freebsd.org, erichsfreebsdlist , linimon , freebsd-isp@freebsd.org, khatfield , squid-users-subscribe@squid-cache.org, friends , freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Barney Cordoba List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 16:21:59 -0000 http://www.bauer-mc.de/llcfkrr/t2cx3elzyvfq/h6k5gxkn8vwjj2dvpf From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 17:02:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 75494EBD for ; Tue, 19 Feb 2013 17:02:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) by mx1.freebsd.org (Postfix) with ESMTP id 14E3764B for ; Tue, 19 Feb 2013 17:02:22 +0000 (UTC) Received: by mail-wg0-f47.google.com with SMTP id dr13so5545348wgb.26 for ; Tue, 19 Feb 2013 09:02:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=z0WDLfXNWSFCV2uaO33IC6KQMFS04qOESUyv+jO3RSY=; b=CBg4SwkTDd0MM1sJfEJhj8Wx37EiH94oPbSa1S7VkRhPJv5e8SdmH3DohReDGJj0rZ aBFoRCDzobXsuRxoqoTPn2VkZgGX8iNMQtxb8BhXC6SeH4s8mGga1jjqvvL1uICRx1q+ KGL9F/ZElnw7GtdnIPz9dTg57pJdgtkH4sxG/p3cnRQ1Z1JHv+XHin6Sh02K30IWeEky yZNWakPaJF6hwTdYsCwk66SULh2BlhoCUmbdKvQJVRg8Dy7hh3SYwGtOyzIXJcF6H2GO mw6eZInZ+9Qd5RNHbb7y61z3wMQZLZ7Ar9qvJaSPmxeNbC0BaW6GdOIEzuy75acBeLlA d/OQ== MIME-Version: 1.0 X-Received: by 10.180.93.234 with SMTP id cx10mr28856826wib.34.1361293335916; Tue, 19 Feb 2013 09:02:15 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 19 Feb 2013 09:02:15 -0800 (PST) In-Reply-To: <512358BB.1040609@seznam.cz> References: <512358BB.1040609@seznam.cz> Date: Tue, 19 Feb 2013 09:02:15 -0800 X-Google-Sender-Auth: _U09twirOqJf-siiHxQ73V1cZ4I Message-ID: Subject: Re: Netflow v9 with ng_netflow and nfdump From: Adrian Chadd To: Jan Markus Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:02:23 -0000 .. I assume that your netflow collector is positioned correctly so it can see the actual client MAC, rather than the MAC of the L3 gateway device? adrian On 19 February 2013 02:49, Jan Markus wrote: > Hello, > > our Ministry of the interior now requires that IP traffic logs must contain > MAC addresses of our clients. I am trying to fulfil this with Netflow v9 > which (allegedly) should contain the MAC addresses of IP flows. > > But with no success so far... > > We have a mirror port on our core switch and capture the VLAN tagged packets > on em1 NIC on our FreeBSD 9.1 server. > > Our netflow collector is configured like this: > > kldload ng_ether > kldload ng_ksocket > kldload ng_netflow > > ifconfig em1 promisc -arp up > > ngctl mkpeer em1: netflow lower iface0 > ngctl name em1:lower netflow > ngctl connect em1: netflow: upper out0 > ngctl mkpeer netflow: ksocket export9 inet/dgram/udp > ngctl msg netflow:export9 connect inet/127.0.0.1:9995 > > We capture the netflow packets on the same machine like this: > > nfcapd -p 9995 -S 2 -T all -D -l ./ > > But when I try to get the log like this: > > nfdump -r nfcapd.201302191051 > nfcapd.201302191051.out > > All I get is date, protocol, src and dst IP and port, and number of bytes, > packets and flows. No information on MAC addresses whatsoever. > > What am I doing wrong? > > Thank you very much for your help, > -Jan > > _______________________________________________ > 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 Feb 19 17:32:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 64109C69; Tue, 19 Feb 2013 17:32:26 +0000 (UTC) (envelope-from markus.jan@seznam.cz) Received: from smtp2.seznam.cz (smtp2.seznam.cz [77.75.76.43]) by mx1.freebsd.org (Postfix) with ESMTP id 932BE836; Tue, 19 Feb 2013 17:32:24 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=seznam.cz; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Smtpd:X-Seznam-User:X-Session:X-Country; b=oYdx6/s4UNtNYQN88n7AK/wYgIHqWkjMg5o22dMiZsW8reuzavAKNNLz1g+ga4zj4 /0awnm0SFdNLau0UPkEhVcPKQo8VKrKaD52NOuovHqozBnwhkDdaNd6O6JqnpiRlt53 Mvx4/eydKqvxI1aYBjJpCzk9Fdk5HcoBiQUF13E= Received: from [10.252.0.120] (gw2.metron.cz [109.238.32.35]) by email-relay2.ng.seznam.cz (Seznam SMTPD UNKNOWN@UNKNOWN) with ESMTP; Tue, 19 Feb 2013 18:32:23 +0100 (CET) Message-ID: <5123B726.5030403@seznam.cz> Date: Tue, 19 Feb 2013 18:32:22 +0100 From: Jan Markus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: Netflow v9 with ng_netflow and nfdump References: <512358BB.1040609@seznam.cz> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Smtpd: UNKNOWN@UNKNOWN X-Seznam-User: markus.jan@seznam.cz X-Session: 13 X-Country: CZ Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 17:32:26 -0000 On 02/19/2013 06:02 PM, Adrian Chadd wrote: > .. I assume that your netflow collector is positioned correctly so it > can see the actual client MAC, rather than the MAC of the L3 gateway > device? Yes, we've checked with tcpdump. The mirror port simply copies the packets as they flow from our clients to routers. One more way for logging IP->MAC binding would be periodical dump from our core switch. But the solution with Netflow v9 seems much more "elegant" I think. We are using Juniper EX4200 as our core switches and, as far as I know, they support only the sFlow - sampled flow. And we are required to log every connection. > > > > adrian > > On 19 February 2013 02:49, Jan Markus wrote: >> Hello, >> >> our Ministry of the interior now requires that IP traffic logs must contain >> MAC addresses of our clients. I am trying to fulfil this with Netflow v9 >> which (allegedly) should contain the MAC addresses of IP flows. >> >> But with no success so far... >> >> We have a mirror port on our core switch and capture the VLAN tagged packets >> on em1 NIC on our FreeBSD 9.1 server. >> >> Our netflow collector is configured like this: >> >> kldload ng_ether >> kldload ng_ksocket >> kldload ng_netflow >> >> ifconfig em1 promisc -arp up >> >> ngctl mkpeer em1: netflow lower iface0 >> ngctl name em1:lower netflow >> ngctl connect em1: netflow: upper out0 >> ngctl mkpeer netflow: ksocket export9 inet/dgram/udp >> ngctl msg netflow:export9 connect inet/127.0.0.1:9995 >> >> We capture the netflow packets on the same machine like this: >> >> nfcapd -p 9995 -S 2 -T all -D -l ./ >> >> But when I try to get the log like this: >> >> nfdump -r nfcapd.201302191051> nfcapd.201302191051.out >> >> All I get is date, protocol, src and dst IP and port, and number of bytes, >> packets and flows. No information on MAC addresses whatsoever. >> >> What am I doing wrong? >> >> Thank you very much for your help, >> -Jan >> >> _______________________________________________ >> 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 Feb 19 18:06:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6386626E for ; Tue, 19 Feb 2013 18:06:33 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id 04B39A9A for ; Tue, 19 Feb 2013 18:06:32 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so5173354wid.5 for ; Tue, 19 Feb 2013 10:06:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=K/2S3KA8UrUqq9YGhe1g88sBKxgZuDZzPwy/ztxwv5I=; b=JgQ04rzsxDk2Iktrl6y+PVIo3OyWiESc0PQtdtIsFUGqCC1e0bETMRIKH6j7R+sMiP J2NlYZqZ+N7yB/3lcTZ24fChWhTNxTCczqTDQDTWrumTtRj4AcLsXGxpyc9s2i5e0FnE FF83+hYwhV1FtyzzEJMq+TiYD7hbL1NOrN0ZMUkKlAJxwu77LJUSNQJZctmxzosrnSdg WtaVszUZ0L4zTZKOp3XG57dVWT+EMXi629hpkmZe3wYFMniaoI7zwJzJq1MMTG9jaK0H orb81VKsKxnvuHohlfA0JOHB8QR1r1+3EbLbslStS9qCmFaDFLr+nTjo1nmTmPC9pOiN +2Rg== MIME-Version: 1.0 X-Received: by 10.194.108.101 with SMTP id hj5mr28500718wjb.6.1361297192246; Tue, 19 Feb 2013 10:06:32 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Tue, 19 Feb 2013 10:06:32 -0800 (PST) In-Reply-To: <5123B726.5030403@seznam.cz> References: <512358BB.1040609@seznam.cz> <5123B726.5030403@seznam.cz> Date: Tue, 19 Feb 2013 10:06:32 -0800 X-Google-Sender-Auth: uHPsnzOUFGRiW5yta463FzC5Ymo Message-ID: Subject: Re: Netflow v9 with ng_netflow and nfdump From: Adrian Chadd To: Jan Markus Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:06:33 -0000 Ok. well, as long as you're situated in a place that lets you see the MAC addresses, you should be ok. You just need to hack the netflow module to include the source/destination mac address. adrian From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 18:42:42 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D2FEE226 for ; Tue, 19 Feb 2013 18:42:42 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 75403DAB for ; Tue, 19 Feb 2013 18:42:41 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id es5so5632256wgb.17 for ; Tue, 19 Feb 2013 10:42:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=MGHc8Ce5INH6bHlF/tFo19L58Nc6K5G/T5RjmCTYgvY=; b=I7uFUvZRkMPBgje9pCDr4BPytbT8oOCs3nRy4W3Y4LGZeoM8jrddpzqe2iV8qLmJTe 8xzO09L3EhRhK9y339VKbARBvVLHum5psu4+UFiy8rdf9DZ+sUBOch+np1xIUwiNXedk +USACJ6xaRQEr5dSuo7aIUkYxOF0OFB+MnagsKFdrlcKMf3r7qJl3toPD3fgt2npUgcJ jhjzGxtN8KTPi6u2GF+bGGmuPylOkNnvCmbnjEKPIubE/cKVStDXoxcEHJqVQCcxldrt 37ZhasdhpuhHMgbMAki0uxqYte2lbYLVo4D5PniZFMbHM0Fma2/27M+sklD5mEuEFoNH 5eCA== MIME-Version: 1.0 X-Received: by 10.194.83.105 with SMTP id p9mr28605225wjy.56.1361299360834; Tue, 19 Feb 2013 10:42:40 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.217.50.67 with HTTP; Tue, 19 Feb 2013 10:42:40 -0800 (PST) Date: Tue, 19 Feb 2013 18:42:40 +0000 X-Google-Sender-Auth: m0XX3ogl2p17O1r5NxHAl8RU44o Message-ID: Subject: Wallclock vs monotonic time in v6 expiry times? From: Alex Yong To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 18:42:42 -0000 Hi, I've been looking around in the IPv6 code recently and I noticed that time_second seems to be the clock of choice for calculating expiry times for prefixes, routers and addresses. Is there any specific reason it uses wall clock time and not time_uptime as this makes more sense to me? I'm referring to the kernel's internal representation of these expiry times, rather than what's exposed via sysctls. As an example, dr0.expire = time_second + dr0.rtlifetime; taken from sys/netinet6/nd6_rtr.c from nd6_ra_input. AlexY From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 19:51:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 742381F3 for ; Tue, 19 Feb 2013 19:51:45 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from nk11p00mm-asmtp004.mac.com (nk11p00mm-asmtp004.mac.com [17.158.161.3]) by mx1.freebsd.org (Postfix) with ESMTP id 5A00C28C for ; Tue, 19 Feb 2013 19:51:45 +0000 (UTC) Received: from cswiger1.apple.com ([17.209.4.71]) by nk11p00mm-asmtp004.mac.com (Oracle Communications Messaging Server 7u4-26.01(7.0.4.26.0) 64bit (built Jul 13 2012)) with ESMTPSA id <0MIH008BNDQ21T20@nk11p00mm-asmtp004.mac.com> for freebsd-net@freebsd.org; Tue, 19 Feb 2013 18:51:39 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.9.8327,1.0.431,0.0.0000 definitions=2013-02-19_03:2013-02-19,2013-02-18,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=5 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1203120001 definitions=main-1302190172 Subject: Re: Wallclock vs monotonic time in v6 expiry times? MIME-version: 1.0 (Apple Message framework v1085) Content-type: text/plain; charset=us-ascii From: Chuck Swiger In-reply-to: Date: Tue, 19 Feb 2013 10:51:38 -0800 Content-transfer-encoding: quoted-printable Message-id: References: To: Alex Yong X-Mailer: Apple Mail (2.1085) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 19:51:45 -0000 Hi-- On Feb 19, 2013, at 10:42 AM, Alex Yong wrote: > I've been looking around in the IPv6 code recently and I noticed that > time_second seems to be the clock of choice for calculating expiry = times > for prefixes, routers and addresses. Is there any specific reason it = uses > wall clock time and not time_uptime as this makes more sense to me? Sure. Sequence #s, retry timers, etc do better if based off of wall = clock time than if based off of uptime because realtime persists in moving forward = but uptime gets reset if the host crashes/reboots. RFC-793 discusses "Quiet Time" concept for TCP, but it applies = elsewhere. Regards, --=20 -Chuck From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 21:47:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id EAA0C7E1; Tue, 19 Feb 2013 21:47:57 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id 3C066994; Tue, 19 Feb 2013 21:47:56 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e52so3711247eek.34 for ; Tue, 19 Feb 2013 13:47:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rra2T5uMmaGwz3K7P+ycfucz+4PAF8sVxxJS1DgYDOA=; b=OsCJ//2u4w8Nbc6nIzaLRIJFXcT1F3DtWoJdZVqxyErbdY0CPsjg4p/TpIhKw2LC89 7hxfyhkhy9k7JcjV6gfSwsyuVE2yXruwINN4E50zKJEIqH8uXrfzwAI4B08K+j3panqe s9AwlwgWIhwLsugaTGVzrvslLDNSGuLDDlvVHxStVffUUppTlZYikFFVvyVn24xOHXcz bS7TaFinPNeX3tfhmgJxUfdF7JgHw4UvaAhj6EcSIai/WegTFoeJX+u4fs+RY2zLgBmV 0H1rGbeyeZpgfAhm0mnS/OtCK9mh7dYDNYOIyWI3HYuKh/9IflgL7KApq54vY2S5FDsr ijSw== MIME-Version: 1.0 X-Received: by 10.14.182.71 with SMTP id n47mr61508986eem.11.1361310475967; Tue, 19 Feb 2013 13:47:55 -0800 (PST) Received: by 10.223.161.80 with HTTP; Tue, 19 Feb 2013 13:47:55 -0800 (PST) In-Reply-To: <20130219030552.GI9611@oddish> References: <20130219030552.GI9611@oddish> Date: Tue, 19 Feb 2013 13:47:55 -0800 Message-ID: Subject: Re: NDP prefix list locking From: Vijay Singh To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 21:47:58 -0000 Mark, is this the panic you were hitting? PANIC : Bad list head 0xffffff800057e720 first->prev != head cpuid = 6 KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x3e panic() at panic+0x479 nd6_prelist_add() at nd6_prelist_add+0x236 prelist_remove() at prelist_remove+0x4c5 nd6_ra_input() at nd6_ra_input+0x8c2 icmp6_input() at icmp6_input+0x149e ip6_input() at ip6_input+0x14b2 netisr_dispatch_src() at netisr_dispatch_src+0x14a netisr_dispatch() at netisr_dispatch+0x20 ether_demux() at ether_demux+0x281 -vijay On Mon, Feb 18, 2013 at 7:05 PM, Mark Johnston wrote: > Hi Everyone, > > For the past little while I've been tracking down some memory corruption > issues that seem to be caused by a double free that can happen when > destroying an IPv6-enabled interface or when removing an IPv6 address > from an interface. > > The problem seems to be caused by a lack of locking for nd_prefix, the > global IPv6 prefix list. There's a callout that periodically executes > nd6_timer(), which purges expired prefixes (among other things). There's > nothing preventing an expired prefix from being freed twice if a user > happens to destroy the corresponding address or IP address at the same > time. In fact, a prefix with an infinite lifetime can be double freed as > well, since the first thing prelist_remove() does is set the input > prefix's vltime field to 0. > > I'd like to fix this, and the patch below is my attempt at adding some > locking to accesses of the prefix and default router lists. It's only > received very light testing so far, but I was hoping that others could > either review/test the patch, or suggest alternative approaches to > fixing this. My approach here has been to add two rw locks - one for > the prefix list and one for the default router list. I'm not very > familiar with the NDP code so I'm very much open to comments and > suggestions. :) > > Thanks, > -Mark > > diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c > index e260e5d..3cb327c 100644 > --- a/sys/netinet6/in6.c > +++ b/sys/netinet6/in6.c > @@ -805,8 +805,11 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, > */ > pr = ia->ia6_ndpr; > in6_purgeaddr(&ia->ia_ifa); > - if (pr && pr->ndpr_refcnt == 0) > + if (pr && pr->ndpr_refcnt == 0) { > + ND_PREFIX_WLOCK(); > prelist_remove(pr); > + ND_PREFIX_WUNLOCK(); > + } > EVENTHANDLER_INVOKE(ifaddr_event, ifp); > break; > } > diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c > index fd420d8..d96340c 100644 > --- a/sys/netinet6/nd6.c > +++ b/sys/netinet6/nd6.c > @@ -117,6 +117,9 @@ static int nd6_inuse, nd6_allocated; > VNET_DEFINE(struct nd_drhead, nd_defrouter); > VNET_DEFINE(struct nd_prhead, nd_prefix); > > +struct rwlock nd_prefix_rwlock; > +struct rwlock nd_defrouter_rwlock; > + > VNET_DEFINE(int, nd6_recalc_reachtm_interval) = ND6_RECALC_REACHTM_INTERVAL; > #define V_nd6_recalc_reachtm_interval VNET(nd6_recalc_reachtm_interval) > > @@ -143,6 +146,7 @@ nd6_init(void) > { > int i; > > + rw_init(&nd_prefix_rwlock, "nd_prefix rwlock"); > LIST_INIT(&V_nd_prefix); > > all1_sa.sin6_family = AF_INET6; > @@ -151,6 +155,7 @@ nd6_init(void) > all1_sa.sin6_addr.s6_addr[i] = 0xff; > > /* initialization of the default router list */ > + rw_init(&nd_defrouter_rwlock, "nd_defrouter rwlock"); > TAILQ_INIT(&V_nd_defrouter); > > /* start timer */ > @@ -586,10 +591,14 @@ nd6_timer(void *arg) > nd6_timer, curvnet); > > /* expire default router list */ > + ND_PREFIX_RLOCK(); > + ND_DEFRTR_WLOCK(); > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { > if (dr->expire && dr->expire < time_second) > defrtrlist_del(dr); > } > + ND_DEFRTR_WUNLOCK(); > + ND_PREFIX_RUNLOCK(); > > /* > * expire interface addresses. > @@ -664,6 +673,7 @@ nd6_timer(void *arg) > } > > /* expire prefix list */ > + ND_PREFIX_WLOCK(); > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { > /* > * check prefix lifetime. > @@ -680,6 +690,7 @@ nd6_timer(void *arg) > prelist_remove(pr); > } > } > + ND_PREFIX_WUNLOCK(); > CURVNET_RESTORE(); > } > > @@ -770,6 +781,8 @@ nd6_purge(struct ifnet *ifp) > * in the routing table, in order to keep additional side effects as > * small as possible. > */ > + ND_PREFIX_RLOCK(); > + ND_DEFRTR_WLOCK(); > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { > if (dr->installed) > continue; > @@ -785,8 +798,11 @@ nd6_purge(struct ifnet *ifp) > if (dr->ifp == ifp) > defrtrlist_del(dr); > } > + ND_DEFRTR_WUNLOCK(); > + ND_PREFIX_RUNLOCK(); > > /* Nuke prefix list entries toward ifp */ > + ND_PREFIX_WLOCK(); > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { > if (pr->ndpr_ifp == ifp) { > /* > @@ -808,6 +824,7 @@ nd6_purge(struct ifnet *ifp) > prelist_remove(pr); > } > } > + ND_PREFIX_WUNLOCK(); > > /* cancel default outgoing interface setting */ > if (V_nd6_defifindex == ifp->if_index) > @@ -898,6 +915,7 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) > * If the address matches one of our on-link prefixes, it should be a > * neighbor. > */ > + ND_PREFIX_RLOCK(); > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > if (pr->ndpr_ifp != ifp) > continue; > @@ -929,9 +947,12 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) > } > > if (IN6_ARE_MASKED_ADDR_EQUAL(&pr->ndpr_prefix.sin6_addr, > - &addr->sin6_addr, &pr->ndpr_mask)) > + &addr->sin6_addr, &pr->ndpr_mask)) { > + ND_PREFIX_RUNLOCK(); > return (1); > + } > } > + ND_PREFIX_RUNLOCK(); > > /* > * If the address is assigned on the node of the other side of > @@ -1229,6 +1250,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > * obsolete API, use sysctl under net.inet6.icmp6 > */ > bzero(drl, sizeof(*drl)); > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > if (i >= DRLSTSIZ) > break; > @@ -1241,6 +1263,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > drl->defrouter[i].if_index = dr->ifp->if_index; > i++; > } > + ND_DEFRTR_RUNLOCK(); > break; > case SIOCGPRLST_IN6: > /* > @@ -1256,6 +1279,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > * how about separating ioctls into two? > */ > bzero(oprl, sizeof(*oprl)); > + ND_PREFIX_RLOCK(); > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > struct nd_pfxrouter *pfr; > int j; > @@ -1301,6 +1325,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > i++; > } > + ND_PREFIX_RUNLOCK(); > > break; > case OSIOCGIFINFO_IN6: > @@ -1449,6 +1474,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > /* flush all the prefix advertised by routers */ > struct nd_prefix *pr, *next; > > + ND_PREFIX_WLOCK(); > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, next) { > struct in6_ifaddr *ia, *ia_next; > > @@ -1467,6 +1493,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > } > prelist_remove(pr); > } > + ND_PREFIX_WUNLOCK(); > break; > } > case SIOCSRTRFLUSH_IN6: > @@ -1475,9 +1502,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > struct nd_defrouter *dr, *next; > > defrouter_reset(); > + ND_PERFIX_RLOCK(); > + ND_DEFRTR_WLOCK(); > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, next) { > defrtrlist_del(dr); > } > + ND_DEFRTR_WUNLOCK(); > + ND_PREFIX_RUNLOCK(); > defrouter_select(); > break; > } > @@ -2268,23 +2299,30 @@ nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) > d.rtaddr.sin6_family = AF_INET6; > d.rtaddr.sin6_len = sizeof(d.rtaddr); > > + error = sysctl_wire_old_buffer(req, 0); > + if (error != 0) > + return (error); > + > /* > * XXX locking > */ > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > d.rtaddr.sin6_addr = dr->rtaddr; > error = sa6_recoverscope(&d.rtaddr); > if (error != 0) > - return (error); > + break; > d.flags = dr->flags; > d.rtlifetime = dr->rtlifetime; > d.expire = dr->expire; > d.if_index = dr->ifp->if_index; > error = SYSCTL_OUT(req, &d, sizeof(d)); > if (error != 0) > - return (error); > + break; > } > - return (0); > + ND_DEFRTR_RUNLOCK(); > + > + return (error); > } > > static int > @@ -2307,9 +2345,14 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > s6.sin6_family = AF_INET6; > s6.sin6_len = sizeof(s6); > > + error = sysctl_wire_old_buffer(req, 0); > + if (error != 0) > + return (error); > + > /* > * XXX locking > */ > + ND_PREFIX_RLOCK(); > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > p.prefix = pr->ndpr_prefix; > if (sa6_recoverscope(&p.prefix)) { > @@ -2341,7 +2384,7 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > p.advrtrs++; > error = SYSCTL_OUT(req, &p, sizeof(p)); > if (error != 0) > - return (error); > + break; > LIST_FOREACH(pfr, &pr->ndpr_advrtrs, pfr_entry) { > s6.sin6_addr = pfr->router->rtaddr; > if (sa6_recoverscope(&s6)) > @@ -2349,9 +2392,13 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > "scope error in prefix list (%s)\n", > ip6_sprintf(ip6buf, &pfr->router->rtaddr)); > error = SYSCTL_OUT(req, &s6, sizeof(s6)); > - if (error != 0) > + if (error != 0) { > + ND_PREFIX_RUNLOCK(); > return (error); > + } > } > } > - return (0); > + ND_PREFIX_RUNLOCK(); > + > + return (error); > } > diff --git a/sys/netinet6/nd6.h b/sys/netinet6/nd6.h > index 94202e1..bc5ff2d 100644 > --- a/sys/netinet6/nd6.h > +++ b/sys/netinet6/nd6.h > @@ -38,6 +38,7 @@ > #define RTF_ANNOUNCE RTF_PROTO2 > #endif > > +#include > #include > #include > > @@ -341,6 +342,35 @@ VNET_DECLARE(int, nd6_onlink_ns_rfc4861); > #define V_nd6_debug VNET(nd6_debug) > #define V_nd6_onlink_ns_rfc4861 VNET(nd6_onlink_ns_rfc4861) > > +/* Lock to protect access to the nd_prefix list. */ > +extern struct rwlock nd_prefix_rwlock; > +#define ND_PREFIX_RLOCK() rw_rlock(&nd_prefix_rwlock) > +#define ND_PREFIX_RUNLOCK() rw_runlock(&nd_prefix_rwlock) > +#define ND_PREFIX_WLOCK() rw_wlock(&nd_prefix_rwlock) > +#define ND_PREFIX_WUNLOCK() rw_wunlock(&nd_prefix_rwlock) > +#define ND_PREFIX_LOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_LOCKED) > +#define ND_PREFIX_RLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_RLOCKED) > +#define ND_PREFIX_WLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_WLOCKED) > +#define ND_PREFIX_WLOCK_OWNED() rw_wowned(&nd_prefix_rwlock) > + > +/* > + * Lock to protect access to the nd_defrouter list. A shared lock should be > + * acquired on the prefix list before acquiring an exclusive lock on the router > + * list and calling defrouterlist_del() in order to avoid lock order reversals. > + */ > +extern struct rwlock nd_defrouter_rwlock; > +#define ND_DEFRTR_RLOCK() rw_rlock(&nd_defrouter_rwlock) > +#define ND_DEFRTR_RUNLOCK() rw_runlock(&nd_defrouter_rwlock) > +#define ND_DEFRTR_WLOCK() rw_wlock(&nd_defrouter_rwlock) > +#define ND_DEFRTR_WUNLOCK() rw_wunlock(&nd_defrouter_rwlock) > +#define ND_DEFRTR_LOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > + RA_LOCKED) > +#define ND_DEFRTR_RLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > + RA_RLOCKED) > +#define ND_DEFRTR_WLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > + RA_WLOCKED) > +#define ND_DEFRTR_WLOCK_OWNED() rw_wowned(&nd_defrouter_rwlock) > + > #define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) > > VNET_DECLARE(struct callout, nd6_timer_ch); > diff --git a/sys/netinet6/nd6_rtr.c b/sys/netinet6/nd6_rtr.c > index f6bae0c..e5c63b9 100644 > --- a/sys/netinet6/nd6_rtr.c > +++ b/sys/netinet6/nd6_rtr.c > @@ -499,14 +499,16 @@ defrouter_addreq(struct nd_defrouter *new) > struct nd_defrouter * > defrouter_lookup(struct in6_addr *addr, struct ifnet *ifp) > { > - struct nd_defrouter *dr; > + struct nd_defrouter *dr = NULL; > > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > if (dr->ifp == ifp && IN6_ARE_ADDR_EQUAL(addr, &dr->rtaddr)) > - return (dr); > + break; > } > + ND_DEFRTR_RUNLOCK(); > > - return (NULL); /* search failed */ > + return (dr); /* search failed */ > } > > /* > @@ -548,8 +550,10 @@ defrouter_reset(void) > { > struct nd_defrouter *dr; > > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) > defrouter_delreq(dr); > + ND_DEFRTR_RUNLOCK(); > > /* > * XXX should we also nuke any default routers in the kernel, by > @@ -574,11 +578,13 @@ defrtrlist_del(struct nd_defrouter *dr) > deldr = dr; > defrouter_delreq(dr); > } > + ND_DEFRTR_WLOCK_ASSERT(); > TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); > > /* > * Also delete all the pointers to the router in each prefix lists. > */ > + ND_PREFIX_RLOCK_ASSERT(); > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > struct nd_pfxrouter *pfxrtr; > if ((pfxrtr = pfxrtr_lookup(pr, dr)) != NULL) > @@ -636,6 +642,7 @@ defrouter_select(void) > * We just pick up the first reachable one (if any), assuming that > * the ordering rule of the list described in defrtrlist_update(). > */ > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > IF_AFDATA_RLOCK(dr->ifp); > if (selected_dr == NULL && > @@ -657,6 +664,8 @@ defrouter_select(void) > " is installed\n"); > } > } > + ND_DEFRTR_RUNLOCK(); > + > /* > * If none of the default routers was found to be reachable, > * round-robin the list regardless of preference. > @@ -758,7 +767,9 @@ defrtrlist_update(struct nd_defrouter *new) > * defrouter_select() below will handle routing > * changes later. > */ > + ND_DEFRTR_WLOCK(); > TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); > + ND_DEFRTR_WUNLOCK(); > n = dr; > goto insert; > } > @@ -784,6 +795,7 @@ insert: > */ > > /* insert at the end of the group */ > + ND_DEFRTR_WLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > if (rtpref(n) > rtpref(dr)) > break; > @@ -792,6 +804,7 @@ insert: > TAILQ_INSERT_BEFORE(dr, n, dr_entry); > else > TAILQ_INSERT_TAIL(&V_nd_defrouter, n, dr_entry); > + ND_DEFRTR_WUNLOCK(); > > defrouter_select(); > > @@ -839,6 +852,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) > { > struct nd_prefix *search; > > + ND_PREFIX_RLOCK(); > LIST_FOREACH(search, &V_nd_prefix, ndpr_entry) { > if (key->ndpr_ifp == search->ndpr_ifp && > key->ndpr_plen == search->ndpr_plen && > @@ -847,6 +861,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) > break; > } > } > + ND_PREFIX_RUNLOCK(); > > return (search); > } > @@ -887,7 +902,9 @@ nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, > new->ndpr_mask.s6_addr32[i]; > > /* link ndpr_entry to nd_prefix list */ > + ND_PREFIX_WLOCK(); > LIST_INSERT_HEAD(&V_nd_prefix, new, ndpr_entry); > + ND_PREFIX_WUNLOCK(); > > /* ND_OPT_PI_FLAG_ONLINK processing */ > if (new->ndpr_raf_onlink) { > @@ -938,6 +955,7 @@ prelist_remove(struct nd_prefix *pr) > return; /* notice here? */ > > /* unlink ndpr_entry from nd_prefix list */ > + ND_PREFIX_WLOCK_ASSERT(); > LIST_REMOVE(pr, ndpr_entry); > > /* free list of routers that adversed the prefix */ > @@ -1339,6 +1357,8 @@ pfxlist_onlink_check() > * Check if there is a prefix that has a reachable advertising > * router. > */ > + if (!ND_PREFIX_WLOCK_OWNED()) > + ND_PREFIX_RLOCK(); > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > if (pr->ndpr_raf_onlink && find_pfxlist_reachable_router(pr)) > break; > @@ -1349,6 +1369,7 @@ pfxlist_onlink_check() > * that does not advertise any prefixes. > */ > if (pr == NULL) { > + ND_DEFRTR_RLOCK(); > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > struct nd_prefix *pr0; > > @@ -1359,6 +1380,7 @@ pfxlist_onlink_check() > if (pfxrtr != NULL) > break; > } > + ND_DEFRTR_RUNLOCK(); > } > if (pr != NULL || (!TAILQ_EMPTY(&V_nd_defrouter) && pfxrtr == NULL)) { > /* > @@ -1454,6 +1476,8 @@ pfxlist_onlink_check() > } > } > } > + if (!ND_PREFIX_WLOCK_OWNED()) > + ND_PREFIX_RUNLOCK(); > > /* > * Changes on the prefix status might affect address status as well. > @@ -1618,6 +1642,7 @@ nd6_prefix_onlink(struct nd_prefix *pr) > * Although such a configuration is expected to be rare, we explicitly > * allow it. > */ > + ND_PREFIX_RLOCK(); > LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { > if (opr == pr) > continue; > @@ -1627,9 +1652,12 @@ nd6_prefix_onlink(struct nd_prefix *pr) > > if (opr->ndpr_plen == pr->ndpr_plen && > in6_are_prefix_equal(&pr->ndpr_prefix.sin6_addr, > - &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) > + &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) { > + ND_PREFIX_RUNLOCK(); > return (0); > + } > } > + ND_PREFIX_RUNLOCK(); > > /* > * We prefer link-local addresses as the associated interface address. > @@ -1730,6 +1758,7 @@ nd6_prefix_offlink(struct nd_prefix *pr) > * If there's one, try to make the prefix on-link on the > * interface. > */ > + ND_PREFIX_LOCK_ASSERT(); > LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { > if (opr == pr) > continue; > _______________________________________________ > 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 Feb 19 22:05:58 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 39C71DBE for ; Tue, 19 Feb 2013 22:05:58 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by mx1.freebsd.org (Postfix) with ESMTP id CAC42A7F for ; Tue, 19 Feb 2013 22:05:57 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id d12so2967281eaa.24 for ; Tue, 19 Feb 2013 14:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=m0c58CJDCb+GJKETKMakaAydZn/7AkqY/7us3R1fDBY=; b=vT6DF/q3pyeBkVbHhQJZxcxD/kDgSmmM4n/NvLEkpsGiR5RofBgJZJ8VPt2ZKAIOZk P+Clw1o2YkoY/NOnJgZx3oJGZuQZtDrFTUVLBR0o0nTSgPVAJ22T/C26u+polP01dnvO 7Xfv/b7e/CeRJOD+w0bEdxKcgU9nsv4D7J7QuicaVCrBIn4YS360LvGLktftbukHMl3b Ayor8ZbFud1mVxJ3Rux45O0YM478hIXk9S78krv4YHeWfu0w/m5XOa20N/LBaZPQVuq1 yGLmfyqn11y5VofuicJzvojfEJ4prhdxvp+dd3PWrMi5ebAQ7og7AfYUrAHLDtJ6O7ip op9w== MIME-Version: 1.0 X-Received: by 10.14.173.196 with SMTP id v44mr61095038eel.29.1361311551348; Tue, 19 Feb 2013 14:05:51 -0800 (PST) Received: by 10.223.161.80 with HTTP; Tue, 19 Feb 2013 14:05:51 -0800 (PST) Date: Tue, 19 Feb 2013 14:05:51 -0800 Message-ID: Subject: Possible optimization in ether_output() From: Vijay Singh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:05:58 -0000 Hi, this patch gives a modest performance improvement here @work. Please consider. [/u/vijay/bsd/CODE/cur/sys/net]# svn diff if_ethersubr.c Index: if_ethersubr.c =================================================================== --- if_ethersubr.c (revision 247012) +++ if_ethersubr.c (working copy) @@ -160,6 +160,7 @@ struct pf_mtag *t; int loop_copy = 1; int hlen; /* link layer header length */ + int use_lle_directly = 0; if (ro != NULL) { if (!(m->m_flags & (M_BCAST | M_MCAST))) @@ -184,7 +185,7 @@ #ifdef INET case AF_INET: if (lle != NULL && (lle->la_flags & LLE_VALID)) - memcpy(edst, &lle->ll_addr.mac16, sizeof(edst)); + use_lle_directly = 1; else error = arpresolve(ifp, rt0, m, dst, edst, &lle); if (error) @@ -222,7 +223,7 @@ #ifdef INET6 case AF_INET6: if (lle != NULL && (lle->la_flags & LLE_VALID)) - memcpy(edst, &lle->ll_addr.mac16, sizeof(edst)); + use_lle_directly = 1; else error = nd6_storelladdr(ifp, m, dst, (u_char *)edst, &lle); if (error) @@ -317,9 +318,13 @@ if (m == NULL) senderr(ENOBUFS); eh = mtod(m, struct ether_header *); - (void)memcpy(&eh->ether_type, &type, - sizeof(eh->ether_type)); - (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); + eh->ether_type = type; + if (use_lle_directly) { + memcpy(eh->ether_dhost, &lle->ll_addr.mac16, + sizeof(eh->ether_dhost)); + } else { + (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); + } if (hdrcmplt) (void)memcpy(eh->ether_shost, esrc, sizeof(eh->ether_shost)); From owner-freebsd-net@FreeBSD.ORG Tue Feb 19 22:48:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 603E0C50 for ; Tue, 19 Feb 2013 22:48:48 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-ie0-x229.google.com (ie-in-x0229.1e100.net [IPv6:2607:f8b0:4001:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id 15256D2D for ; Tue, 19 Feb 2013 22:48:48 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 13so9367132iea.0 for ; Tue, 19 Feb 2013 14:48:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=3UbQGUDB6nfNvZBs7TVmIdRO8SJN0Z9PqiYGqMar7Qg=; b=dQgqLRXQ1T16ugV2llMuEHBQ7LEYqUeLOJsKx8N7+nu/2z/IDXZta3ETFm+PUXKN43 L2fq2++bZkRUjinGY3Ssn5FPurdUZj01AJXqCkHWbHWgdU596Pbh+8btdoOmx3C8MBQw vHtxZYCyj0cbpurS7BlftMqYswXsm82Y/0z1Mj5S06B8rBSfHsiVbJitK+KlmtSTN+yL NsyiOsaXmx9qyFwKSfCwYm0VTzCxAX9cOMDc2rNrZn7kXbmVeR+jXVArZOGMg0S7BjsB Edn2mlfm1Bx/cvgoVYt46JDSUejG/kikBS0CMa8bsQzNyAFu38h0MOPt9NLS/3aV4DL4 Paqg== X-Received: by 10.50.187.225 with SMTP id fv1mr10225387igc.96.1361314127564; Tue, 19 Feb 2013 14:48:47 -0800 (PST) Received: from oddish.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPS id fa6sm14424854igb.2.2013.02.19.14.48.45 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Feb 2013 14:48:46 -0800 (PST) Sender: Mark Johnston Date: Tue, 19 Feb 2013 17:48:30 -0500 From: Mark Johnston To: Vijay Singh Subject: Re: NDP prefix list locking Message-ID: <20130219224830.GA2143@oddish.sandvine.com> References: <20130219030552.GI9611@oddish> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2013 22:48:48 -0000 On Tue, Feb 19, 2013 at 01:47:55PM -0800, Vijay Singh wrote: > Mark, is this the panic you were hitting? It was a double free, so I was seeing panics in different parts of the kernel - in my case it was kqueue and netgraph, among other places. I only managed to track it down to the prefix list code by adding some debugging code to malloc/free. Even now I can't prove that the panics I saw were caused by the double free I described below. But the corruption I saw occured with structures that come from the same uma zone as a struct nd_prefix, and I can make the double free happen quickly by 1. bumping up the nd6_timer callout frequency to say 100/s, and 2. creating and destroying interfaces in a loop, i.e. something like while true; do ngctl mkpeer iface inet inet; ifconfig ng0 up ngctl shutdown ng0: done Assigning and removing IPv6 addresses in a loop should also do the trick. I also don't see how the stack below can happen - prelist_remove() doesn't call nd6_prelist_add(). Can you resolve those offsets to line numbers? > > PANIC : Bad list head 0xffffff800057e720 first->prev != head > cpuid = 6 > KDB: stack backtrace: > kdb_backtrace() at kdb_backtrace+0x3e > panic() at panic+0x479 > nd6_prelist_add() at nd6_prelist_add+0x236 > prelist_remove() at prelist_remove+0x4c5 > nd6_ra_input() at nd6_ra_input+0x8c2 > icmp6_input() at icmp6_input+0x149e > ip6_input() at ip6_input+0x14b2 > netisr_dispatch_src() at netisr_dispatch_src+0x14a > netisr_dispatch() at netisr_dispatch+0x20 > ether_demux() at ether_demux+0x281 > > -vijay > > On Mon, Feb 18, 2013 at 7:05 PM, Mark Johnston wrote: > > Hi Everyone, > > > > For the past little while I've been tracking down some memory corruption > > issues that seem to be caused by a double free that can happen when > > destroying an IPv6-enabled interface or when removing an IPv6 address > > from an interface. > > > > The problem seems to be caused by a lack of locking for nd_prefix, the > > global IPv6 prefix list. There's a callout that periodically executes > > nd6_timer(), which purges expired prefixes (among other things). There's > > nothing preventing an expired prefix from being freed twice if a user > > happens to destroy the corresponding address or IP address at the same > > time. In fact, a prefix with an infinite lifetime can be double freed as > > well, since the first thing prelist_remove() does is set the input > > prefix's vltime field to 0. > > > > I'd like to fix this, and the patch below is my attempt at adding some > > locking to accesses of the prefix and default router lists. It's only > > received very light testing so far, but I was hoping that others could > > either review/test the patch, or suggest alternative approaches to > > fixing this. My approach here has been to add two rw locks - one for > > the prefix list and one for the default router list. I'm not very > > familiar with the NDP code so I'm very much open to comments and > > suggestions. :) > > > > Thanks, > > -Mark > > > > diff --git a/sys/netinet6/in6.c b/sys/netinet6/in6.c > > index e260e5d..3cb327c 100644 > > --- a/sys/netinet6/in6.c > > +++ b/sys/netinet6/in6.c > > @@ -805,8 +805,11 @@ in6_control(struct socket *so, u_long cmd, caddr_t data, > > */ > > pr = ia->ia6_ndpr; > > in6_purgeaddr(&ia->ia_ifa); > > - if (pr && pr->ndpr_refcnt == 0) > > + if (pr && pr->ndpr_refcnt == 0) { > > + ND_PREFIX_WLOCK(); > > prelist_remove(pr); > > + ND_PREFIX_WUNLOCK(); > > + } > > EVENTHANDLER_INVOKE(ifaddr_event, ifp); > > break; > > } > > diff --git a/sys/netinet6/nd6.c b/sys/netinet6/nd6.c > > index fd420d8..d96340c 100644 > > --- a/sys/netinet6/nd6.c > > +++ b/sys/netinet6/nd6.c > > @@ -117,6 +117,9 @@ static int nd6_inuse, nd6_allocated; > > VNET_DEFINE(struct nd_drhead, nd_defrouter); > > VNET_DEFINE(struct nd_prhead, nd_prefix); > > > > +struct rwlock nd_prefix_rwlock; > > +struct rwlock nd_defrouter_rwlock; > > + > > VNET_DEFINE(int, nd6_recalc_reachtm_interval) = ND6_RECALC_REACHTM_INTERVAL; > > #define V_nd6_recalc_reachtm_interval VNET(nd6_recalc_reachtm_interval) > > > > @@ -143,6 +146,7 @@ nd6_init(void) > > { > > int i; > > > > + rw_init(&nd_prefix_rwlock, "nd_prefix rwlock"); > > LIST_INIT(&V_nd_prefix); > > > > all1_sa.sin6_family = AF_INET6; > > @@ -151,6 +155,7 @@ nd6_init(void) > > all1_sa.sin6_addr.s6_addr[i] = 0xff; > > > > /* initialization of the default router list */ > > + rw_init(&nd_defrouter_rwlock, "nd_defrouter rwlock"); > > TAILQ_INIT(&V_nd_defrouter); > > > > /* start timer */ > > @@ -586,10 +591,14 @@ nd6_timer(void *arg) > > nd6_timer, curvnet); > > > > /* expire default router list */ > > + ND_PREFIX_RLOCK(); > > + ND_DEFRTR_WLOCK(); > > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { > > if (dr->expire && dr->expire < time_second) > > defrtrlist_del(dr); > > } > > + ND_DEFRTR_WUNLOCK(); > > + ND_PREFIX_RUNLOCK(); > > > > /* > > * expire interface addresses. > > @@ -664,6 +673,7 @@ nd6_timer(void *arg) > > } > > > > /* expire prefix list */ > > + ND_PREFIX_WLOCK(); > > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { > > /* > > * check prefix lifetime. > > @@ -680,6 +690,7 @@ nd6_timer(void *arg) > > prelist_remove(pr); > > } > > } > > + ND_PREFIX_WUNLOCK(); > > CURVNET_RESTORE(); > > } > > > > @@ -770,6 +781,8 @@ nd6_purge(struct ifnet *ifp) > > * in the routing table, in order to keep additional side effects as > > * small as possible. > > */ > > + ND_PREFIX_RLOCK(); > > + ND_DEFRTR_WLOCK(); > > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, ndr) { > > if (dr->installed) > > continue; > > @@ -785,8 +798,11 @@ nd6_purge(struct ifnet *ifp) > > if (dr->ifp == ifp) > > defrtrlist_del(dr); > > } > > + ND_DEFRTR_WUNLOCK(); > > + ND_PREFIX_RUNLOCK(); > > > > /* Nuke prefix list entries toward ifp */ > > + ND_PREFIX_WLOCK(); > > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, npr) { > > if (pr->ndpr_ifp == ifp) { > > /* > > @@ -808,6 +824,7 @@ nd6_purge(struct ifnet *ifp) > > prelist_remove(pr); > > } > > } > > + ND_PREFIX_WUNLOCK(); > > > > /* cancel default outgoing interface setting */ > > if (V_nd6_defifindex == ifp->if_index) > > @@ -898,6 +915,7 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) > > * If the address matches one of our on-link prefixes, it should be a > > * neighbor. > > */ > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > > if (pr->ndpr_ifp != ifp) > > continue; > > @@ -929,9 +947,12 @@ nd6_is_new_addr_neighbor(struct sockaddr_in6 *addr, struct ifnet *ifp) > > } > > > > if (IN6_ARE_MASKED_ADDR_EQUAL(&pr->ndpr_prefix.sin6_addr, > > - &addr->sin6_addr, &pr->ndpr_mask)) > > + &addr->sin6_addr, &pr->ndpr_mask)) { > > + ND_PREFIX_RUNLOCK(); > > return (1); > > + } > > } > > + ND_PREFIX_RUNLOCK(); > > > > /* > > * If the address is assigned on the node of the other side of > > @@ -1229,6 +1250,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > * obsolete API, use sysctl under net.inet6.icmp6 > > */ > > bzero(drl, sizeof(*drl)); > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > if (i >= DRLSTSIZ) > > break; > > @@ -1241,6 +1263,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > drl->defrouter[i].if_index = dr->ifp->if_index; > > i++; > > } > > + ND_DEFRTR_RUNLOCK(); > > break; > > case SIOCGPRLST_IN6: > > /* > > @@ -1256,6 +1279,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > * how about separating ioctls into two? > > */ > > bzero(oprl, sizeof(*oprl)); > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > > struct nd_pfxrouter *pfr; > > int j; > > @@ -1301,6 +1325,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > > > i++; > > } > > + ND_PREFIX_RUNLOCK(); > > > > break; > > case OSIOCGIFINFO_IN6: > > @@ -1449,6 +1474,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > /* flush all the prefix advertised by routers */ > > struct nd_prefix *pr, *next; > > > > + ND_PREFIX_WLOCK(); > > LIST_FOREACH_SAFE(pr, &V_nd_prefix, ndpr_entry, next) { > > struct in6_ifaddr *ia, *ia_next; > > > > @@ -1467,6 +1493,7 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > } > > prelist_remove(pr); > > } > > + ND_PREFIX_WUNLOCK(); > > break; > > } > > case SIOCSRTRFLUSH_IN6: > > @@ -1475,9 +1502,13 @@ nd6_ioctl(u_long cmd, caddr_t data, struct ifnet *ifp) > > struct nd_defrouter *dr, *next; > > > > defrouter_reset(); > > + ND_PERFIX_RLOCK(); > > + ND_DEFRTR_WLOCK(); > > TAILQ_FOREACH_SAFE(dr, &V_nd_defrouter, dr_entry, next) { > > defrtrlist_del(dr); > > } > > + ND_DEFRTR_WUNLOCK(); > > + ND_PREFIX_RUNLOCK(); > > defrouter_select(); > > break; > > } > > @@ -2268,23 +2299,30 @@ nd6_sysctl_drlist(SYSCTL_HANDLER_ARGS) > > d.rtaddr.sin6_family = AF_INET6; > > d.rtaddr.sin6_len = sizeof(d.rtaddr); > > > > + error = sysctl_wire_old_buffer(req, 0); > > + if (error != 0) > > + return (error); > > + > > /* > > * XXX locking > > */ > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > d.rtaddr.sin6_addr = dr->rtaddr; > > error = sa6_recoverscope(&d.rtaddr); > > if (error != 0) > > - return (error); > > + break; > > d.flags = dr->flags; > > d.rtlifetime = dr->rtlifetime; > > d.expire = dr->expire; > > d.if_index = dr->ifp->if_index; > > error = SYSCTL_OUT(req, &d, sizeof(d)); > > if (error != 0) > > - return (error); > > + break; > > } > > - return (0); > > + ND_DEFRTR_RUNLOCK(); > > + > > + return (error); > > } > > > > static int > > @@ -2307,9 +2345,14 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > > s6.sin6_family = AF_INET6; > > s6.sin6_len = sizeof(s6); > > > > + error = sysctl_wire_old_buffer(req, 0); > > + if (error != 0) > > + return (error); > > + > > /* > > * XXX locking > > */ > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > > p.prefix = pr->ndpr_prefix; > > if (sa6_recoverscope(&p.prefix)) { > > @@ -2341,7 +2384,7 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > > p.advrtrs++; > > error = SYSCTL_OUT(req, &p, sizeof(p)); > > if (error != 0) > > - return (error); > > + break; > > LIST_FOREACH(pfr, &pr->ndpr_advrtrs, pfr_entry) { > > s6.sin6_addr = pfr->router->rtaddr; > > if (sa6_recoverscope(&s6)) > > @@ -2349,9 +2392,13 @@ nd6_sysctl_prlist(SYSCTL_HANDLER_ARGS) > > "scope error in prefix list (%s)\n", > > ip6_sprintf(ip6buf, &pfr->router->rtaddr)); > > error = SYSCTL_OUT(req, &s6, sizeof(s6)); > > - if (error != 0) > > + if (error != 0) { > > + ND_PREFIX_RUNLOCK(); > > return (error); > > + } > > } > > } > > - return (0); > > + ND_PREFIX_RUNLOCK(); > > + > > + return (error); > > } > > diff --git a/sys/netinet6/nd6.h b/sys/netinet6/nd6.h > > index 94202e1..bc5ff2d 100644 > > --- a/sys/netinet6/nd6.h > > +++ b/sys/netinet6/nd6.h > > @@ -38,6 +38,7 @@ > > #define RTF_ANNOUNCE RTF_PROTO2 > > #endif > > > > +#include > > #include > > #include > > > > @@ -341,6 +342,35 @@ VNET_DECLARE(int, nd6_onlink_ns_rfc4861); > > #define V_nd6_debug VNET(nd6_debug) > > #define V_nd6_onlink_ns_rfc4861 VNET(nd6_onlink_ns_rfc4861) > > > > +/* Lock to protect access to the nd_prefix list. */ > > +extern struct rwlock nd_prefix_rwlock; > > +#define ND_PREFIX_RLOCK() rw_rlock(&nd_prefix_rwlock) > > +#define ND_PREFIX_RUNLOCK() rw_runlock(&nd_prefix_rwlock) > > +#define ND_PREFIX_WLOCK() rw_wlock(&nd_prefix_rwlock) > > +#define ND_PREFIX_WUNLOCK() rw_wunlock(&nd_prefix_rwlock) > > +#define ND_PREFIX_LOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_LOCKED) > > +#define ND_PREFIX_RLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_RLOCKED) > > +#define ND_PREFIX_WLOCK_ASSERT() rw_assert(&nd_prefix_rwlock, RA_WLOCKED) > > +#define ND_PREFIX_WLOCK_OWNED() rw_wowned(&nd_prefix_rwlock) > > + > > +/* > > + * Lock to protect access to the nd_defrouter list. A shared lock should be > > + * acquired on the prefix list before acquiring an exclusive lock on the router > > + * list and calling defrouterlist_del() in order to avoid lock order reversals. > > + */ > > +extern struct rwlock nd_defrouter_rwlock; > > +#define ND_DEFRTR_RLOCK() rw_rlock(&nd_defrouter_rwlock) > > +#define ND_DEFRTR_RUNLOCK() rw_runlock(&nd_defrouter_rwlock) > > +#define ND_DEFRTR_WLOCK() rw_wlock(&nd_defrouter_rwlock) > > +#define ND_DEFRTR_WUNLOCK() rw_wunlock(&nd_defrouter_rwlock) > > +#define ND_DEFRTR_LOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > > + RA_LOCKED) > > +#define ND_DEFRTR_RLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > > + RA_RLOCKED) > > +#define ND_DEFRTR_WLOCK_ASSERT() rw_assert(&nd_defrouter_rwlock, \ > > + RA_WLOCKED) > > +#define ND_DEFRTR_WLOCK_OWNED() rw_wowned(&nd_defrouter_rwlock) > > + > > #define nd6log(x) do { if (V_nd6_debug) log x; } while (/*CONSTCOND*/ 0) > > > > VNET_DECLARE(struct callout, nd6_timer_ch); > > diff --git a/sys/netinet6/nd6_rtr.c b/sys/netinet6/nd6_rtr.c > > index f6bae0c..e5c63b9 100644 > > --- a/sys/netinet6/nd6_rtr.c > > +++ b/sys/netinet6/nd6_rtr.c > > @@ -499,14 +499,16 @@ defrouter_addreq(struct nd_defrouter *new) > > struct nd_defrouter * > > defrouter_lookup(struct in6_addr *addr, struct ifnet *ifp) > > { > > - struct nd_defrouter *dr; > > + struct nd_defrouter *dr = NULL; > > > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > if (dr->ifp == ifp && IN6_ARE_ADDR_EQUAL(addr, &dr->rtaddr)) > > - return (dr); > > + break; > > } > > + ND_DEFRTR_RUNLOCK(); > > > > - return (NULL); /* search failed */ > > + return (dr); /* search failed */ > > } > > > > /* > > @@ -548,8 +550,10 @@ defrouter_reset(void) > > { > > struct nd_defrouter *dr; > > > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) > > defrouter_delreq(dr); > > + ND_DEFRTR_RUNLOCK(); > > > > /* > > * XXX should we also nuke any default routers in the kernel, by > > @@ -574,11 +578,13 @@ defrtrlist_del(struct nd_defrouter *dr) > > deldr = dr; > > defrouter_delreq(dr); > > } > > + ND_DEFRTR_WLOCK_ASSERT(); > > TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); > > > > /* > > * Also delete all the pointers to the router in each prefix lists. > > */ > > + ND_PREFIX_RLOCK_ASSERT(); > > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > > struct nd_pfxrouter *pfxrtr; > > if ((pfxrtr = pfxrtr_lookup(pr, dr)) != NULL) > > @@ -636,6 +642,7 @@ defrouter_select(void) > > * We just pick up the first reachable one (if any), assuming that > > * the ordering rule of the list described in defrtrlist_update(). > > */ > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > IF_AFDATA_RLOCK(dr->ifp); > > if (selected_dr == NULL && > > @@ -657,6 +664,8 @@ defrouter_select(void) > > " is installed\n"); > > } > > } > > + ND_DEFRTR_RUNLOCK(); > > + > > /* > > * If none of the default routers was found to be reachable, > > * round-robin the list regardless of preference. > > @@ -758,7 +767,9 @@ defrtrlist_update(struct nd_defrouter *new) > > * defrouter_select() below will handle routing > > * changes later. > > */ > > + ND_DEFRTR_WLOCK(); > > TAILQ_REMOVE(&V_nd_defrouter, dr, dr_entry); > > + ND_DEFRTR_WUNLOCK(); > > n = dr; > > goto insert; > > } > > @@ -784,6 +795,7 @@ insert: > > */ > > > > /* insert at the end of the group */ > > + ND_DEFRTR_WLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > if (rtpref(n) > rtpref(dr)) > > break; > > @@ -792,6 +804,7 @@ insert: > > TAILQ_INSERT_BEFORE(dr, n, dr_entry); > > else > > TAILQ_INSERT_TAIL(&V_nd_defrouter, n, dr_entry); > > + ND_DEFRTR_WUNLOCK(); > > > > defrouter_select(); > > > > @@ -839,6 +852,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) > > { > > struct nd_prefix *search; > > > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(search, &V_nd_prefix, ndpr_entry) { > > if (key->ndpr_ifp == search->ndpr_ifp && > > key->ndpr_plen == search->ndpr_plen && > > @@ -847,6 +861,7 @@ nd6_prefix_lookup(struct nd_prefixctl *key) > > break; > > } > > } > > + ND_PREFIX_RUNLOCK(); > > > > return (search); > > } > > @@ -887,7 +902,9 @@ nd6_prelist_add(struct nd_prefixctl *pr, struct nd_defrouter *dr, > > new->ndpr_mask.s6_addr32[i]; > > > > /* link ndpr_entry to nd_prefix list */ > > + ND_PREFIX_WLOCK(); > > LIST_INSERT_HEAD(&V_nd_prefix, new, ndpr_entry); > > + ND_PREFIX_WUNLOCK(); > > > > /* ND_OPT_PI_FLAG_ONLINK processing */ > > if (new->ndpr_raf_onlink) { > > @@ -938,6 +955,7 @@ prelist_remove(struct nd_prefix *pr) > > return; /* notice here? */ > > > > /* unlink ndpr_entry from nd_prefix list */ > > + ND_PREFIX_WLOCK_ASSERT(); > > LIST_REMOVE(pr, ndpr_entry); > > > > /* free list of routers that adversed the prefix */ > > @@ -1339,6 +1357,8 @@ pfxlist_onlink_check() > > * Check if there is a prefix that has a reachable advertising > > * router. > > */ > > + if (!ND_PREFIX_WLOCK_OWNED()) > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(pr, &V_nd_prefix, ndpr_entry) { > > if (pr->ndpr_raf_onlink && find_pfxlist_reachable_router(pr)) > > break; > > @@ -1349,6 +1369,7 @@ pfxlist_onlink_check() > > * that does not advertise any prefixes. > > */ > > if (pr == NULL) { > > + ND_DEFRTR_RLOCK(); > > TAILQ_FOREACH(dr, &V_nd_defrouter, dr_entry) { > > struct nd_prefix *pr0; > > > > @@ -1359,6 +1380,7 @@ pfxlist_onlink_check() > > if (pfxrtr != NULL) > > break; > > } > > + ND_DEFRTR_RUNLOCK(); > > } > > if (pr != NULL || (!TAILQ_EMPTY(&V_nd_defrouter) && pfxrtr == NULL)) { > > /* > > @@ -1454,6 +1476,8 @@ pfxlist_onlink_check() > > } > > } > > } > > + if (!ND_PREFIX_WLOCK_OWNED()) > > + ND_PREFIX_RUNLOCK(); > > > > /* > > * Changes on the prefix status might affect address status as well. > > @@ -1618,6 +1642,7 @@ nd6_prefix_onlink(struct nd_prefix *pr) > > * Although such a configuration is expected to be rare, we explicitly > > * allow it. > > */ > > + ND_PREFIX_RLOCK(); > > LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { > > if (opr == pr) > > continue; > > @@ -1627,9 +1652,12 @@ nd6_prefix_onlink(struct nd_prefix *pr) > > > > if (opr->ndpr_plen == pr->ndpr_plen && > > in6_are_prefix_equal(&pr->ndpr_prefix.sin6_addr, > > - &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) > > + &opr->ndpr_prefix.sin6_addr, pr->ndpr_plen)) { > > + ND_PREFIX_RUNLOCK(); > > return (0); > > + } > > } > > + ND_PREFIX_RUNLOCK(); > > > > /* > > * We prefer link-local addresses as the associated interface address. > > @@ -1730,6 +1758,7 @@ nd6_prefix_offlink(struct nd_prefix *pr) > > * If there's one, try to make the prefix on-link on the > > * interface. > > */ > > + ND_PREFIX_LOCK_ASSERT(); > > LIST_FOREACH(opr, &V_nd_prefix, ndpr_entry) { > > if (opr == pr) > > continue; > > _______________________________________________ > > freebsd-net@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-net > > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 01:46:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A5DFE2F3; Wed, 20 Feb 2013 01:46:55 +0000 (UTC) (envelope-from lstewart@room52.net) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3AB8988C; Wed, 20 Feb 2013 01:46:54 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 43F047E81E; Wed, 20 Feb 2013 12:46:46 +1100 (EST) Message-ID: <51242B05.1040003@room52.net> Date: Wed, 20 Feb 2013 12:46:45 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> In-Reply-To: <511C3FB8.40506@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 01:46:55 -0000 *crickets chirping* Time to move this discussion forward... On 02/14/13 12:36, Lawrence Stewart wrote: > On 02/14/13 01:48, Andre Oppermann wrote: >> On 13.02.2013 15:26, Lawrence Stewart wrote: >>> On 02/13/13 21:27, Andre Oppermann wrote: >>>> On 13.02.2013 09:25, Lawrence Stewart wrote: >>>>> The idea is useful. I'd just like to discuss the implementation >>>>> specifics a little further before recommending whether the patch should >>>>> go in as is to provide a stop gap, or we rework the patch to be a >>>>> little >>>>> less specific in readiness for the future work I have in mind. [snip] >>> We could initially map "low delay at all costs" to a TCP stack meaning >>> of "disable idle window reset" and expand the meaning later (e.g. >>> relaxing the silly window checks as briefly discussed in the other >>> thread). >> >> Ugh, if you go that far fork it, obtain a fresh protocol number and don't >> call it TCP anymore. > > You're channelling Joe Touch ;) > > What exactly is TCP? As far as interop is concerned, it's just a wire > protocol - as long as I format my headers/segments correctly and ignore > options I don't understand, I can communicate with other TCP stacks, > many of which implement a different set of TCP features and options. > > The dynamics of the protocol have evolved significantly over time and > continue to do so because of its ubiquity - it flows freely across the > public internet and gets used for all manner of things it wasn't > initially designed to handle (well). A lot of the dynamics are also > controlled by optional parameters. > > So no, we don't need a new protocol number. We need to provide knobs > that allow people to tune TCP dynamics to their particular use case. [snip] >>> We need to figure out how to provide the functionality in FreeBSD >>> proper, and a CC module is not the answer. >> >> I totally disagree. This functionality (removal) is not at all a part >> of TCP and should not be supported directly. > > I don't understand how you can argue that idle window resetting is an > intrinsic and non negotiable part of TCP. There is no one true set of > options and features that is TCP. It is not only one idea. > > Let's work on providing a rich set of knobs to tune every aspect of our > TCP stack's dynamics and operation that don't break wire format, set > conservative defaults and document everything thoroughly. If any robust counter-arguments exist, now is the time for us to hear them. I haven't read anything thus far which convinces me that we should not provide knobs to tune our stack's dynamics. In the absence of any compelling counter-arguments, I would like to propose the following: - We rename the net.inet.tcp.experimental sysctl node introduced in r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the initcwnd10 sysctl under this node. - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable and default it to 0. Only when it is changed to 1 will we allow starkly non standards compliant behaviour to be enabled in the stack. As a more complex but expressive alternative, we can make the sysctl take a bit mask or CSV string which specifies which non-standard options the sys admin permits (I'd prefer this as we can easily test non-standard options like IW10 in head without blanket enabling all non standard behaviour). - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl variable, and use it to enable/disable window-reset-after-idle behaviour as proposed by John. - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a more generic sockopt and/or mechanism for per-application tuning of all options which affect stack dynamics (both standard and non-standard options). I'm open to suggestions on what this could/should look like. Thoughts? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 02:37:56 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 527D1B28; Wed, 20 Feb 2013 02:37:56 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-we0-x231.google.com (mail-we0-x231.google.com [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 941ABA22; Wed, 20 Feb 2013 02:37:55 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so6128926wer.36 for ; Tue, 19 Feb 2013 18:37:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6cVMV/Y4pEAlirTUL55dNS2afqD/JMKXGAeXhLu+RNU=; b=SUwEhSmavm8Rj7bpJ5yRL6k70U7/792QrLTrWFZ/cTCDu5ZDb4lKuSjJC/4agBuWg9 2Owem6CVt0LBPRpEmTATr1skR4C7f3/DsJcVEi7TdyOadRVqqFXq9CF3WTxFx96ErD4C 23bIGKuV5XTqMHXGTMwddRA1R5WZPs4Fy3teyJgmJAqACmdN4K4g4cnr3NZsKPWoYPTf M6derwW08dUckps5gmvUgVpxNoM2A48f6az7SHYzL/e1OaPiYrCqBc8+Izi4iBwAtjwc lvNfwt3fjzg1DuGDY25VzFwDzLQxvJlxgOdLKj+4M562fwDLnSlipxRf8Qd5B5WJRjlM YSFQ== MIME-Version: 1.0 X-Received: by 10.180.105.232 with SMTP id gp8mr30860113wib.33.1361327874600; Tue, 19 Feb 2013 18:37:54 -0800 (PST) Received: by 10.194.163.232 with HTTP; Tue, 19 Feb 2013 18:37:54 -0800 (PST) In-Reply-To: <51242B05.1040003@room52.net> References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> <51242B05.1040003@room52.net> Date: Wed, 20 Feb 2013 10:37:54 +0800 Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Sepherosa Ziehau To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: Andre Oppermann , John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 02:37:56 -0000 On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote: > *crickets chirping* > > Time to move this discussion forward... > > > If any robust counter-arguments exist, now is the time for us to hear > them. I haven't read anything thus far which convinces me that we should > not provide knobs to tune our stack's dynamics. > > In the absence of any compelling counter-arguments, I would like to > propose the following: > > - We rename the net.inet.tcp.experimental sysctl node introduced in > r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the > initcwnd10 sysctl under this node. > > - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable > and default it to 0. Only when it is changed to 1 will we allow starkly > non standards compliant behaviour to be enabled in the stack. As a more > complex but expressive alternative, we can make the sysctl take a bit > mask or CSV string which specifies which non-standard options the sys > admin permits (I'd prefer this as we can easily test non-standard > options like IW10 in head without blanket enabling all non standard > behaviour). > > - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl > variable, and use it to enable/disable window-reset-after-idle behaviour > as proposed by John. > > - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a > more generic sockopt and/or mechanism for per-application tuning of all > options which affect stack dynamics (both standard and non-standard > options). I'm open to suggestions on what this could/should look like. Lawrence, A route metric? BTW, as for IW10, it could also become a route metric (as proposed by the draft author's presentation http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) John, I came across this draft several days ago, you may be interested: http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-00 This one is a bit old, but it is still interesting to read (cited by the above draft): http://tools.ietf.org/html/draft-hughes-restart-00 Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 03:59:11 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD2E76B4; Wed, 20 Feb 2013 03:59:11 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 70CE3DE9; Wed, 20 Feb 2013 03:59:11 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id D60707E824; Wed, 20 Feb 2013 14:59:08 +1100 (EST) Message-ID: <51244A0C.8000800@freebsd.org> Date: Wed, 20 Feb 2013 14:59:08 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> <51242B05.1040003@room52.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Andre Oppermann , John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 03:59:11 -0000 Hi Sephe, On 02/20/13 13:37, Sepherosa Ziehau wrote: > On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote: >> *crickets chirping* >> >> Time to move this discussion forward... >> >> >> If any robust counter-arguments exist, now is the time for us to hear >> them. I haven't read anything thus far which convinces me that we should >> not provide knobs to tune our stack's dynamics. >> >> In the absence of any compelling counter-arguments, I would like to >> propose the following: >> >> - We rename the net.inet.tcp.experimental sysctl node introduced in >> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the >> initcwnd10 sysctl under this node. I should also add that I think initcwnd10 should be changed to initcwnd and take the number of segments as a value. >> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable >> and default it to 0. Only when it is changed to 1 will we allow starkly >> non standards compliant behaviour to be enabled in the stack. As a more >> complex but expressive alternative, we can make the sysctl take a bit >> mask or CSV string which specifies which non-standard options the sys >> admin permits (I'd prefer this as we can easily test non-standard >> options like IW10 in head without blanket enabling all non standard >> behaviour). To be clear, my proposal is that specifying an allowed option in net.inet.tcp.nonstandard.allowed would not enable it as the default on all connections, but would allow the per-application mechanism we define to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would enable the option as default for all connections. >> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl >> variable, and use it to enable/disable window-reset-after-idle behaviour >> as proposed by John. >> >> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a >> more generic sockopt and/or mechanism for per-application tuning of all >> options which affect stack dynamics (both standard and non-standard >> options). I'm open to suggestions on what this could/should look like. > > Lawrence, > > A route metric? BTW, as for IW10, it could also become a route metric > (as proposed by the draft author's presentation > http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) Are you suggesting having the ability to set knobs as route metrics in addition to sysctl and a per-app mechanism? If so then I am very much in favour of this. Assuming an option has been allowed in net.inet.tcp.nonstandard.allowed, it should be able to be set by an application or on a route, perhaps with a precedence hierarchy of app request trumps route metric trumps system default setting? Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 05:31:52 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AD250976; Wed, 20 Feb 2013 05:31:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8561D1B6; Wed, 20 Feb 2013 05:31:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1K5VqZH085013; Wed, 20 Feb 2013 05:31:52 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1K5VqEA085009; Wed, 20 Feb 2013 05:31:52 GMT (envelope-from linimon) Date: Wed, 20 Feb 2013 05:31:52 GMT Message-Id: <201302200531.r1K5VqEA085009@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 05:31:52 -0000 Old Synopsis: [driver] Update ixgbe to 2.4.10 (latest official driver) New Synopsis: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 20 05:31:31 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176281 From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 07:50:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 27F83741; Wed, 20 Feb 2013 07:50:02 +0000 (UTC) (envelope-from araujo@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 03A538B8; Wed, 20 Feb 2013 07:50:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1K7o1Sf008556; Wed, 20 Feb 2013 07:50:01 GMT (envelope-from araujo@freefall.freebsd.org) Received: (from araujo@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1K7o1cB008552; Wed, 20 Feb 2013 07:50:01 GMT (envelope-from araujo) Date: Wed, 20 Feb 2013 07:50:01 GMT Message-Id: <201302200750.r1K7o1cB008552@freefall.freebsd.org> To: araujo@FreeBSD.org, freebsd-net@FreeBSD.org, jfv@FreeBSD.org From: araujo@FreeBSD.org Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 07:50:02 -0000 Synopsis: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) Responsible-Changed-From-To: freebsd-net->jfv Responsible-Changed-By: araujo Responsible-Changed-When: Wed Feb 20 07:50:01 UTC 2013 Responsible-Changed-Why: jfv@ is the Intel guy! :) http://www.freebsd.org/cgi/query-pr.cgi?pr=176281 From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 08:48:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 02F99874; Wed, 20 Feb 2013 08:48:26 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8EC75C1F; Wed, 20 Feb 2013 08:48:25 +0000 (UTC) Received: by mail-vb0-f54.google.com with SMTP id l1so4867049vba.27 for ; Wed, 20 Feb 2013 00:48:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Df18RofF7yIGpMpzwVdLYAICQBFWSAYlvsdwhu9Wxy4=; b=FGDn4KFWUAJpYDUf9elRoXsnDkiDYGlOKSFW2oD0Vne32F2RbIxTZuVFyT/iph/2zM uxRe5jtJ63/OqkaXYoEVLZrw05WBIBudTeAdHme04rlBJofwQBZrIZUCMzeJJJTXFd3X bojZQ1glYDrjPUxRL3j6t7I0M7GK9GGFcshxGVUd8+PFkPlTKwWtNWP/ozgdDSSd1aBR bWsqWy1DTvYe4+3mCrSeYuP5JvXJr7LWEH3VDqSqz6Oj1WUGN9iJ3HOWi2t4MzHOwb7d B+7+sHHSevfjyIAhUz0UD0sqyQu7AZuzboKvV2HHsYbZrxlpu7bvcKRKdDPGYZWVC9fB rqNQ== MIME-Version: 1.0 X-Received: by 10.58.161.41 with SMTP id xp9mr25036853veb.56.1361350098686; Wed, 20 Feb 2013 00:48:18 -0800 (PST) Received: by 10.220.191.132 with HTTP; Wed, 20 Feb 2013 00:48:18 -0800 (PST) In-Reply-To: <201302200750.r1K7o1cB008552@freefall.freebsd.org> References: <201302200750.r1K7o1cB008552@freefall.freebsd.org> Date: Wed, 20 Feb 2013 00:48:18 -0800 Message-ID: Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) From: Jack Vogel To: araujo@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jfv@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:48:26 -0000 LOL, I'm the one that makes the internal drivers, so there's no need for someone else here to be making patches, the changes will becoming, we move on different timelines sometimes. Jack On Tue, Feb 19, 2013 at 11:50 PM, wrote: > Synopsis: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) > > Responsible-Changed-From-To: freebsd-net->jfv > Responsible-Changed-By: araujo > Responsible-Changed-When: Wed Feb 20 07:50:01 UTC 2013 > Responsible-Changed-Why: > jfv@ is the Intel guy! :) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=176281 > From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 08:52:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B4C43981; Wed, 20 Feb 2013 08:52:10 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) by mx1.freebsd.org (Postfix) with ESMTP id 276C3CC1; Wed, 20 Feb 2013 08:52:09 +0000 (UTC) Received: by mail-wg0-f53.google.com with SMTP id fn15so6322556wgb.20 for ; Wed, 20 Feb 2013 00:52:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=GfriIvEgyfu94uphvR9+JHxVm6k7lRFD6l5i/dTn6t0=; b=y1H2X3Oxbr9/XZzwFdMmssLUjG/HBoEmt0LzlottTFhAsl3I9Wh/ANGR59Z6/uZgn4 X94V1jr+6WjcYst3wHH+6nCkEitswtBomy9CT64hPD5qQa6i13RnfT8by+l36qGQG033 MOej/csyCC4SOB6/TR7krXVk1P0veVTZTWd16dKnYOUn2McHTynQlspy5xFHtrc/sBMB ft6pEI9GonG5BPNDoxPquhck/3PJUTwMdZCeIpLWePobU59V335/EhZMN7XyWGH2Ft3s Caz5tnRaPClY/umbiL4gTxHH7bkyMzpVB8xnm5dYFnZfsp3PUq40o30leW/anfsMPFvh EWEQ== MIME-Version: 1.0 X-Received: by 10.194.5.196 with SMTP id u4mr26847188wju.47.1361350323097; Wed, 20 Feb 2013 00:52:03 -0800 (PST) Received: by 10.180.81.4 with HTTP; Wed, 20 Feb 2013 00:52:02 -0800 (PST) In-Reply-To: References: <201302200750.r1K7o1cB008552@freefall.freebsd.org> Date: Wed, 20 Feb 2013 16:52:02 +0800 Message-ID: Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) From: Marcelo Araujo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jfv@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 08:52:10 -0000 2013/2/20 Jack Vogel > LOL, I'm the one that makes the internal drivers, so there's > no need for someone else here to be making patches, the > changes will becoming, we move on different timelines sometimes. > > > Hello Jack, Yes, I do know you are the right guy in charge of these drivers. But as I'm using 9.1-RELEASE and of course, the ixgbe in a product, I need at least the driver 2.4.10 that seems to have better performance then the latest one. By the way, thanks by all your work, would be great have the 2.5.0 driver on FreeBSD 9-STABLE. :D Do you have plan to do that? Any MFC? Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 10:57:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0C22D98C for ; Wed, 20 Feb 2013 10:57:04 +0000 (UTC) (envelope-from bored_to_death85@yahoo.com) Received: from nm29-vm0.bullet.mail.bf1.yahoo.com (nm29-vm0.bullet.mail.bf1.yahoo.com [98.139.213.166]) by mx1.freebsd.org (Postfix) with ESMTP id 7DDE96B2 for ; Wed, 20 Feb 2013 10:57:03 +0000 (UTC) Received: from [98.139.215.140] by nm29.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 Received: from [98.139.212.209] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 Received: from [127.0.0.1] by omp1018.mail.bf1.yahoo.com with NNFMP; 20 Feb 2013 10:56:55 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 906578.49968.bm@omp1018.mail.bf1.yahoo.com Received: (qmail 75409 invoked by uid 60001); 20 Feb 2013 10:56:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1361357815; bh=yZVlJoxIfyDQPFZhcUGbHjuml5jh/b55+yxoeWD8h+U=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=2MBBd9ogY+tbIqYm4x8k1Xs4I02Yo/F+wM1FqLamAN+Fjti4QGG0sA1V9qTOZTeYB2opJvJozcyEGq+Lx1vo6zlu09dkv4LtO+jqswNWvSw0A12mW3mlZd3LYURTu4YP+8nhBfwiepNHWs8CLhE8fiLjpQu+0eaI8AtlgbUCV3w= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=GBMRxWo56PuWJ2wedhgKyX5Ge1E7PYrRnBS8GPeXn6DBxamf6autoLo7ak7eTIS+wdLQSQUuI6MnoPVYiX/efV1383rsI98fs+BGXoBLqkHE2cMK0mS1d4lH3+KxL3eVANwUB/w1TaND/i2iVpwLQR48wYrenrdhxQ0sD9rhszY=; X-YMail-OSG: j6csv8QVM1kWNcZz2Ka2k_Q6fOk8hU0ysrHo0hWMYVnO319 NSTiG9J8_ny4g0bKoUmjWwqdxr1SYj8xO.fpEQfEAdsiGUtY1TeCJzEYHXht DuvzwuqAwkQJzSzQQ4r.GpSzZorjb0HW5FGzCc3w8H77Q4oSKyFxSDDZ1nv_ lErIYi8x2b6o07KAWU_zsmRqHBRLR2ibBRtHfNFubjbce7.XRfeMZtgV6T9s 0M.ypOuSharY3lDuQcFPU7nKIm1uTCfB4BSB2T9VxWrb1hQcT3Dr58rbKoKI _iSxpdRqZlygUVv4GUUANoRojLEXyFhzg5wrW_etqW8osPX6U1SpdIg.LaEB dsyy0uDG9R39dqh9THAZu1ELHYnwCy9JldVcPxgoL4Etsp.8nE7WAv0DdQie aiu.PW5JWdi1GFRowd05oJm16hYJ8aMHg6qkBqZ0uA23nXTVRg1_3pOa_4yF GzId8olck_zrngP.8ZH9Pwic7PDUiMXo2ZxXZtJ.._jGZ_ICokegKWmUzw15 oBYdf7wWNoRbagJa9ZUXSkhJT_NLDmjPMVLHD.VfhiRhsMuww21fRYoZtI0H 6Eb_OqVtUJhyx0udxcJb_H_RHLLyNx_i60vLOhQdaAZfu.UpR4ezhlI7Wy8f NUhLfa8kkLKxJLgVj1EU- Received: from [94.183.246.198] by web165005.mail.bf1.yahoo.com via HTTP; Wed, 20 Feb 2013 02:56:55 PST X-Rocket-MIMEInfo: 001.001, aGksCgpJIGhhdmUgMiBGcmVlQlNEOC4yIHN5c3RlbXMuIEkgaGF2ZSBhIHBvaW50LXRvLXBvaW50IGludGVyZmFjZSAobXlpZjApIG9uIGVhY2ggc2lkZSBjb25uZWN0ZWQgdG9nZXRoZXIsIGJ1dCBvbiBlYWNoIHNpZGUgSSBkb24ndCBrbm93IElQIGFkZHJlc3Mgb2YgdGhlIG90aGVyIHNpZGUuIHRvIG1ha2UgdGhlIGNvbm5lY3Rpb24gd29yaywgT24gZWFjaCBzaWRlIEkgc2V0IElQIGFkZHJlc3MgKDIuMi4yLjMyLzI0IGFuZCAyLjIuMi4zMy8yNCkgYW5kIGFkZGVkIGEgcm91dGUgd2hpY2ggc2VuZHMgYWwBMAEBAQE- X-Mailer: YahooMailWebService/0.8.134.513 Message-ID: <1361357815.70014.YahooMailNeo@web165005.mail.bf1.yahoo.com> Date: Wed, 20 Feb 2013 02:56:55 -0800 (PST) From: "M. V." Subject: point-to-point network with unknown peer ip address To: "freebsd-net@freebsd.org" MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "M. V." List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 10:57:04 -0000 hi,=0A=0AI have 2 FreeBSD8.2 systems. I have a point-to-point interface (my= if0) on each side connected together, but on each side I don't know IP addr= ess of the other side. to make the connection work, On each side I set IP a= ddress (2.2.2.32/24 and 2.2.2.33/24) and added a route which sends all traf= fic to the network to interface:=0A#route add 2.2.2.0/24 -interface myif0= =0A=0A#ifconfig myif0=0Amyif0: flags=3D89d1 metric 0 mtu 1500=0A=0A=0Anow my routing table loo= ks like this:=0A=0A#netstat -r=0A=0ADestination=A0Gateway=A0Flags=A0 Refs= =A0 Use=A0 Netif Expire=0A...=0A2.2.2.0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 myif0= =A0=A0=A0 =A0 US=A0 =A0 =A00=A0=A0=A0=A0=A0=A0 145=A0=A0=A0 myif0=0A=0A2.2.= 2.32=A0=A0=A0=A0=A0=A0=A0=A0 link#9=A0 =A0=A0UH=A0=A0=A0=A0 0=A0=A0=A0=A0= =A0=A0 0=A0=A0=A0=A0=A0=A0=A0 lo0=0A...=0A=0Anow, from one side if I ping t= he other side (say 2.2.2.33/24) everything seems ok. but if I ping any othe= r IP in the network (say 2.2.2.100/24) the other endpoint sends back packet= + an ICMP REDIRECT packet. but sender doesn't care about the received ICMP= -REDIRECT and resends packet to interface. this causes a loop and each pack= et is being sent back and forth till its TTL expires.=0A=0Amy sysctl output= :=0A...=0A=0Anet.inet.ip.redirect: 1=0Anet.inet.icmp.drop_redirect: 0=0A...= =0A=0A=0Anow I wanted to ask:=0A- is there any other way to do this? how ca= n I manipulate routes to have a working point-to-point interface with an un= known peer ip address?=A0=0A- if not, shouldn't FreeBSD handle received ICM= P-REDIRECT and stop sending packet to interface after that? how can I make = this happen?=0A=0A=0A=0Athank you.=0A From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 15:16:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 76CD6DEF for ; Wed, 20 Feb 2013 15:16:27 +0000 (UTC) (envelope-from annonymouse@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 00AD0A56 for ; Wed, 20 Feb 2013 15:16:26 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id r5so6662712wey.32 for ; Wed, 20 Feb 2013 07:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=aBgslAgjzMHtluydoKvhMse8KprF1vM1JE+JXu0Gnf4=; b=tM66UArjPPzBeDy3tF7fUIZGtQsXeF/1mmyaOnNmeOYfzgfwUQ+J6MNNgJzj52FoHY rAbPrfi4L9gtrnFotwicmh1kpct2lE8F/aRijEQXy/y4g3ZAc8GWudtgHmjCn3Ihb8v2 r7+A6/bFg9gjkiAXm9upDFeKnWpwkl3joUcuxyk19jl0hu866zknY8k4bctgxp2XsAKI TC3z8M5jvkIWTehu9A4/wSFUDbg+F/Qg0cmdt+Ob/pDD+sw9tMzXqRDN0CBhzyLRp+N6 C0XfhAfW/oskIOetLNaBlkkRyLJeeKJqTgVfR+a8VsxrQ3cPRzb68B2nmEwP29xegXrK pv1g== MIME-Version: 1.0 X-Received: by 10.180.88.168 with SMTP id bh8mr18880193wib.15.1361373377380; Wed, 20 Feb 2013 07:16:17 -0800 (PST) Sender: annonymouse@gmail.com Received: by 10.217.50.67 with HTTP; Wed, 20 Feb 2013 07:16:17 -0800 (PST) In-Reply-To: References: Date: Wed, 20 Feb 2013 15:16:17 +0000 X-Google-Sender-Auth: -bnWrEbMtsHPhPgcpvIIWbUmCWU Message-ID: Subject: Re: Wallclock vs monotonic time in v6 expiry times? From: Alex Yong To: Chuck Swiger Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:16:27 -0000 Thanks Chuck for the quick response, On 19 February 2013 18:51, Chuck Swiger wrote: > > Sequence #s, retry timers, etc do better if based off of wall clock time > than if based off of uptime because realtime persists in moving forward but > uptime gets reset if the host crashes/reboots. > > RFC-793 discusses "Quiet Time" concept for TCP, but it applies elsewhere. > > I take your point that it doesn't hurt to use wall clock time always assuming sensible clock stability on your system, as with Quiet Time optimizations and DHCP leases (to pick two examples) anything else wouldn't make sense. However is there any specific reason in the case of v6 prefixes and default routers to do this? As as far as I can tell the kernel does not store these expiry times in non-volatile storage, and neither does rtsold. I don't think it matters if it's monotonic time or not here, as long as you do the appropriate conversion when passing these values up to userland. If you wanted to persist prefixes/default routers across a crash/boot you could do all of this in userland with a modified rtsold or similar, much like with DHCP leases. Or am I missing something? AlexY From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 15:49:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A85EF21F; Wed, 20 Feb 2013 15:49:15 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 871BED7E; Wed, 20 Feb 2013 15:49:15 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id DACADB9C0; Wed, 20 Feb 2013 10:49:14 -0500 (EST) From: John Baldwin To: Sepherosa Ziehau Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Wed, 20 Feb 2013 08:52:36 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> <51242B05.1040003@room52.net> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201302200852.37270.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 20 Feb 2013 10:49:14 -0500 (EST) Cc: Lawrence Stewart , Andre Oppermann , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 15:49:15 -0000 On Tuesday, February 19, 2013 9:37:54 pm Sepherosa Ziehau wrote: > John, > > I came across this draft several days ago, you may be interested: > http://tools.ietf.org/html/draft-ietf-tcpm-newcwv-00 Yes, that is extremely relevant. My application does use its own rate-limiting. And now that I've read this in full, this does seem to very much be what I want and is a better solution than ignoring idle handling entirely. Ironic that this was posted a few weeks after my patch. :) Clearly this is not an isolated workflow. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Feb 20 18:01:04 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1BA8817C; Wed, 20 Feb 2013 18:01:04 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 8706B834; Wed, 20 Feb 2013 18:01:03 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so7227100veb.32 for ; Wed, 20 Feb 2013 10:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=MLnxBbSHuYQpfKRQXrAXnjyfVPgDAwrNVXDVmpvZONA=; b=lebFbUNXyGwwYz58aaYmhcHBJRaZ2V0UdSIkxIMSVskdTkpWquEUV0iwIohDqiCRm0 tGQK7Wqa8B2NRXXsfUO9vOD5TnOa/iIwliw3mWCvYRWsIzZs4dQ+Wvxkzwu7TQ2hXPnD TrndC3DHe6uhw78dzZ7ZfG/rAHjZ1pYmnTzbFfWs5KmO6tyocVLRg03ebUs9jlfs+nlu IjVQ2GWZgRr3gmgO7XY0BgdqZCRIscGBpAiFDmuSiwxKS/MlhX3RGtHZU2ah540THJCJ kjY96KFKzBxikst5J/i+FwV80A2xceI8fRcm7o7lEEyXd8xhMR8xPdO8A6IHBUpy5cCT TsfA== MIME-Version: 1.0 X-Received: by 10.52.66.41 with SMTP id c9mr23506806vdt.32.1361383257027; Wed, 20 Feb 2013 10:00:57 -0800 (PST) Received: by 10.220.191.132 with HTTP; Wed, 20 Feb 2013 10:00:56 -0800 (PST) In-Reply-To: References: <201302200750.r1K7o1cB008552@freefall.freebsd.org> Date: Wed, 20 Feb 2013 10:00:56 -0800 Message-ID: Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) From: Jack Vogel To: araujo@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jfv@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 18:01:04 -0000 Sorry, I know there are always new people that may not know me. I am the driver developer at Intel specifically for FreeBSD, and for various reasons there are multiple release paths for my code, an internal one that ends up being on the Intel web site, and the community path which ends up in the public source. I do my best to keep them in sync but at times due to how busy I am with what, they may vary a bit, but that should always be a temporary situation that I will remedy. I have been busy for a number of weeks on an important internal project but that's winding down and I'm playing catch-up at the moment, so this stuff should get sync'ed up soon. Regards, Jack On Wed, Feb 20, 2013 at 12:52 AM, Marcelo Araujo wrote: > > > 2013/2/20 Jack Vogel > >> LOL, I'm the one that makes the internal drivers, so there's >> no need for someone else here to be making patches, the >> changes will becoming, we move on different timelines sometimes. >> >> >> > Hello Jack, > > Yes, I do know you are the right guy in charge of these drivers. > But as I'm using 9.1-RELEASE and of course, the ixgbe in a product, I need > at least the driver 2.4.10 that seems to have better performance then the > latest one. > > By the way, thanks by all your work, would be great have the 2.5.0 driver > on FreeBSD 9-STABLE. :D > > Do you have plan to do that? Any MFC? > > Best Regards, > -- > Marcelo Araujo > araujo@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 01:49:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 499DE965; Thu, 21 Feb 2013 01:49:47 +0000 (UTC) (envelope-from araujobsdport@gmail.com) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by mx1.freebsd.org (Postfix) with ESMTP id AFD31AB7; Thu, 21 Feb 2013 01:49:46 +0000 (UTC) Received: by mail-wi0-f172.google.com with SMTP id ez12so6949236wid.5 for ; Wed, 20 Feb 2013 17:49:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=6PSl1Zodbgh/LML8v48kd2TBgZPkPNizbNKJGUSnLwQ=; b=qfk8J8wGXjOKOAjtCOPjqjJIzBjIrLzw1xgo8oeVqZTu05PKQzVKIJcgw/SQgpYh6n WCt7XODKRXN4akCUWHBCZ1QzsjjvVQ8ybix2vSX2x+2ZFnrIzBwNdKG0bMPUyQs3Z7zU o+/QNkdUklP2QdnE7WAAYKbo+B4ggds7zNmJrRnBxx03mEHwhojZsVxlBWpzqTwJF0AM PSAr86UjT0ckpNstK2IltxG9DPRbBnUVtM48xz4sg6GwemkYr1ZL3TuQFLSV2Uehk/yd hUR1YdkfEnNDsOggfLEWKgfA6rrwKMGT0b/jvgELgKGGH5J186xF+CCTXhTNytSzcDnr 5bTg== MIME-Version: 1.0 X-Received: by 10.194.92.65 with SMTP id ck1mr37804179wjb.54.1361411380405; Wed, 20 Feb 2013 17:49:40 -0800 (PST) Received: by 10.180.81.4 with HTTP; Wed, 20 Feb 2013 17:49:40 -0800 (PST) In-Reply-To: References: <201302200750.r1K7o1cB008552@freefall.freebsd.org> Date: Thu, 21 Feb 2013 09:49:40 +0800 Message-ID: Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) From: Marcelo Araujo To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jfv@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: araujo@FreeBSD.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 01:49:47 -0000 2013/2/21 Jack Vogel > Sorry, I know there are always new people that may not know me. I am the > driver developer at > Intel specifically for FreeBSD, and for various reasons there are multiple > release paths for my > code, an internal one that ends up being on the Intel web site, and the > community path which > ends up in the public source. I do my best to keep them in sync but at > times due to how busy > I am with what, they may vary a bit, but that should always be a temporary > situation that I will > remedy. > > I have been busy for a number of weeks on an important internal project > but that's winding down > and I'm playing catch-up at the moment, so this stuff should get sync'ed > up soon. > > Jack, Thanks by all work you have done. And a lot of people know you as the guy in charge of Intel drives! In my case, as I really need at least the driver 2.4.10 and I didn't see any MFC on HEAD(driver 2.5.0), I decide to send the patch. Hopefully you will find time to update the driver. Thank you once again! Best Regards, -- Marcelo Araujo araujo@FreeBSD.org From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 04:00:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 45C808AE for ; Thu, 21 Feb 2013 04:00:05 +0000 (UTC) (envelope-from debian-users-admin@debian.or.jp) Received: from osdn.debian.or.jp (osdn.debian.or.jp [202.221.179.41]) by mx1.freebsd.org (Postfix) with ESMTP id 1D79FFBB for ; Thu, 21 Feb 2013 04:00:04 +0000 (UTC) Received: from lists.debian.or.jp (osdn.debian.or.jp [202.221.179.41]) by osdn.debian.or.jp (Postfix) with ESMTP id C82C3C2E38 for ; Thu, 21 Feb 2013 12:15:31 +0900 (JST) Date: Thu, 21 Feb 2013 12:15:31 +0900 From: debian-users-admin@debian.or.jp Subject: Subscribe request result (debian-users ML) To: freebsd-net@freebsd.org Message-Id: <201302211215.FMLAAA1357.debian-users@debian.or.jp> References: <20130221031530.5C350C2E36@osdn.debian.or.jp> X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)] X-ML-Info: If you have a question, please contact debian-users-admin@debian.or.jp; Mime-Version: 1.0 Content-Type: text/plain; charset=iso-2022-jp X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: debian-users-ctl@debian.or.jp List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 04:00:05 -0000 Hi, I am the fml ML manager for the ML . --debian-users@debian.or.jp, Be Seeing You! ************************************************************ If you have any questions or problems, please contact debian-users-admin@debian.or.jp ************************************************************ From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 05:02:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 144315D6; Thu, 21 Feb 2013 05:02:37 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) by mx1.freebsd.org (Postfix) with ESMTP id A5572254; Thu, 21 Feb 2013 05:02:36 +0000 (UTC) Received: by mail-vc0-f173.google.com with SMTP id fy27so2602361vcb.18 for ; Wed, 20 Feb 2013 21:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=z8sXyRjI9Yo5fjAXZ9es2abK1i8KufZY1e3rp24rVsY=; b=RYtkT+tGUwhoNm48Y/2G/MX3y7bziE95TVEqWfWiTkF2jC1jS4BabsRoPBJvbPRp8n 1tHQY9bdcnxEwkvlhmRu59DIMronjeRJppY6bgUSg4c+qdVXSY5bnIfdvoYtL6IibrWN CaVv9ri3v1zECaKg/K0rYCXOImqb5HbboMa3zjcbFkYs/qf0sdWmzdp9POrU64P0KplH MHE9nazhDQ2aQpnGpIvbNz7/ehXxVlO5oejUbZXY8upRR1wZzKs8e07F7cZmvcM2cKQ5 Eh4Xlr5+y3fxR88K7kF5DMwMxFJaRVdGnIdAfcVSh+mktj1mJ285mTCBq/ZjF9RbhEct 5G8w== MIME-Version: 1.0 X-Received: by 10.52.19.239 with SMTP id i15mr25724869vde.47.1361422955809; Wed, 20 Feb 2013 21:02:35 -0800 (PST) Received: by 10.220.191.132 with HTTP; Wed, 20 Feb 2013 21:02:35 -0800 (PST) In-Reply-To: References: <201302200750.r1K7o1cB008552@freefall.freebsd.org> Date: Wed, 20 Feb 2013 21:02:35 -0800 Message-ID: Subject: Re: kern/176281: [ixgbe] [patch] Update ixgbe to 2.4.10 (latest official driver) From: Jack Vogel To: araujo@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: jfv@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 05:02:37 -0000 On Wed, Feb 20, 2013 at 5:49 PM, Marcelo Araujo wrote: > > > 2013/2/21 Jack Vogel > >> Sorry, I know there are always new people that may not know me. I am the >> driver developer at >> Intel specifically for FreeBSD, and for various reasons there are >> multiple release paths for my >> code, an internal one that ends up being on the Intel web site, and the >> community path which >> ends up in the public source. I do my best to keep them in sync but at >> times due to how busy >> I am with what, they may vary a bit, but that should always be a >> temporary situation that I will >> remedy. >> >> I have been busy for a number of weeks on an important internal project >> but that's winding down >> and I'm playing catch-up at the moment, so this stuff should get sync'ed >> up soon. >> >> > Jack, > > Thanks by all work you have done. > > And a lot of people know you as the guy in charge of Intel drives! In my > case, as I really need at least the driver 2.4.10 and I didn't see any MFC > on HEAD(driver 2.5.0), I decide to send the patch. > > Hopefully you will find time to update the driver. Thank you once again! > > > Thanks, and don't worry, the driver from HEAD will be headed back to stable/9 just as soon as I am able. Jack From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 14:57:01 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EEE927CE; Thu, 21 Feb 2013 14:57:01 +0000 (UTC) (envelope-from sepherosa@gmail.com) Received: from mail-vb0-f49.google.com (mail-vb0-f49.google.com [209.85.212.49]) by mx1.freebsd.org (Postfix) with ESMTP id 77FF9A6C; Thu, 21 Feb 2013 14:57:01 +0000 (UTC) Received: by mail-vb0-f49.google.com with SMTP id s24so5758028vbi.36 for ; Thu, 21 Feb 2013 06:56:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nnnNyJISK9kMGcbVigKXW3umKBrklZusviFCkQPXuY0=; b=cNXsG4Th/MVAoBOkABtSGyNqrGh7EyZg5GWu1SQ5oPTwih+IlxhktdAMvfpeI7giTk 4BeJ9QlOz1K7v3V4EKyJg+MIz1BOOKjA7N1S/e193hmPyUZAJnMR3BzbvnTlTN4agw2F gFhN97NgjSO7Qds5z0+WAQjlfXHi/uvJhCsVGv2fgOfqZuy2PJ+nv4VNdZs8NAP0ktBF /HrP3hI8vgtQTPUUe+h3HF4M0G4+rPjsYQIuDnd5auxXSr7JUThdSzgAWwKAbaz5hpQo fZo68QUqEJd0TVpIyaRlcIzPcCrJC/ejoRvfm8LFfdVnsFmZfkWuj4CuW8d8D03JqIQE PgVg== MIME-Version: 1.0 X-Received: by 10.52.99.42 with SMTP id en10mr18857440vdb.37.1361438400971; Thu, 21 Feb 2013 01:20:00 -0800 (PST) Received: by 10.58.143.73 with HTTP; Thu, 21 Feb 2013 01:20:00 -0800 (PST) In-Reply-To: <51244A0C.8000800@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> <51242B05.1040003@room52.net> <51244A0C.8000800@freebsd.org> Date: Thu, 21 Feb 2013 17:20:00 +0800 Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Sepherosa Ziehau To: Lawrence Stewart Content-Type: text/plain; charset=ISO-8859-1 Cc: Andre Oppermann , John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 14:57:02 -0000 On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart wrote: > Hi Sephe, > > On 02/20/13 13:37, Sepherosa Ziehau wrote: >> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote: >>> *crickets chirping* >>> >>> Time to move this discussion forward... >>> >>> >>> If any robust counter-arguments exist, now is the time for us to hear >>> them. I haven't read anything thus far which convinces me that we should >>> not provide knobs to tune our stack's dynamics. >>> >>> In the absence of any compelling counter-arguments, I would like to >>> propose the following: >>> >>> - We rename the net.inet.tcp.experimental sysctl node introduced in >>> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the >>> initcwnd10 sysctl under this node. > > I should also add that I think initcwnd10 should be changed to initcwnd > and take the number of segments as a value. Yeah, I would suggest the same. > >>> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable >>> and default it to 0. Only when it is changed to 1 will we allow starkly >>> non standards compliant behaviour to be enabled in the stack. As a more >>> complex but expressive alternative, we can make the sysctl take a bit >>> mask or CSV string which specifies which non-standard options the sys >>> admin permits (I'd prefer this as we can easily test non-standard >>> options like IW10 in head without blanket enabling all non standard >>> behaviour). > > To be clear, my proposal is that specifying an allowed option in > net.inet.tcp.nonstandard.allowed would not enable it as the default on > all connections, but would allow the per-application mechanism we define > to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would > enable the option as default for all connections. > >>> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl >>> variable, and use it to enable/disable window-reset-after-idle behaviour >>> as proposed by John. >>> >>> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a >>> more generic sockopt and/or mechanism for per-application tuning of all >>> options which affect stack dynamics (both standard and non-standard >>> options). I'm open to suggestions on what this could/should look like. >> >> Lawrence, >> >> A route metric? BTW, as for IW10, it could also become a route metric >> (as proposed by the draft author's presentation >> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) > > Are you suggesting having the ability to set knobs as route metrics in > addition to sysctl and a per-app mechanism? If so then I am very much in > favour of this. Assuming an option has been allowed in > net.inet.tcp.nonstandard.allowed, it should be able to be set by an > application or on a route, perhaps with a precedence hierarchy of app > request trumps route metric trumps system default setting? I suggest using route metrics in addition to the global sysctls; route metrics take precedence over global sysctls. I don't object the per-socket settings though. However, IMHO, these options (IW10 and ignoring idle restart, and probably others) are administrative, so applications probably should not mess with them. Best Regards, sephe -- Tomorrow Will Never Die From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 19:01:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A984FDC4 for ; Thu, 21 Feb 2013 19:01:59 +0000 (UTC) (envelope-from peter@rulingia.com) Received: from vps.rulingia.com (host-122-100-2-194.octopus.com.au [122.100.2.194]) by mx1.freebsd.org (Postfix) with ESMTP id 2C8141CC for ; Thu, 21 Feb 2013 19:01:58 +0000 (UTC) Received: from server.rulingia.com (c220-239-237-213.belrs5.nsw.optusnet.com.au [220.239.237.213]) by vps.rulingia.com (8.14.5/8.14.5) with ESMTP id r1LJ1nmM082027 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Feb 2013 06:01:49 +1100 (EST) (envelope-from peter@rulingia.com) X-Bogosity: Ham, spamicity=0.000000 Received: from server.rulingia.com (localhost.rulingia.com [127.0.0.1]) by server.rulingia.com (8.14.5/8.14.5) with ESMTP id r1LJ1hxf014998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2013 06:01:43 +1100 (EST) (envelope-from peter@server.rulingia.com) Received: (from peter@localhost) by server.rulingia.com (8.14.5/8.14.5/Submit) id r1LJ1hDX014997; Fri, 22 Feb 2013 06:01:43 +1100 (EST) (envelope-from peter) Date: Fri, 22 Feb 2013 06:01:43 +1100 From: Peter Jeremy To: "M. V." Subject: Re: point-to-point network with unknown peer ip address Message-ID: <20130221190143.GC44920@server.rulingia.com> References: <1361357815.70014.YahooMailNeo@web165005.mail.bf1.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="DSayHWYpDlRfCAAQ" Content-Disposition: inline In-Reply-To: <1361357815.70014.YahooMailNeo@web165005.mail.bf1.yahoo.com> X-PGP-Key: http://www.rulingia.com/keys/peter.pgp User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 19:01:59 -0000 --DSayHWYpDlRfCAAQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2013-Feb-20 02:56:55 -0800, "M. V." wrote: >I have 2 FreeBSD8.2 systems. I have a point-to-point interface >(myif0) on each side connected together, but on each side I don't >know IP address of the other side. to make the connection work, On >each side I set IP address (2.2.2.32/24 and 2.2.2.33/24) and added a >route which sends all traffic to the network to interface: > >#route add 2.2.2.0/24 -interface myif0 > >#ifconfig myif0 >myif0: flags=3D89d1 metric 0 mtu 1500 I'm not certain what you are trying to achieve but point-to-point links would normally be /32, not /24. >now, from one side if I ping the other side (say 2.2.2.33/24) >everything seems ok. but if I ping any other IP in the network (say >2.2.2.100/24) the other endpoint sends back packet + an ICMP REDIRECT >packet. 2.2.2.100 is not a valid address in the network you have described. Where did you expect you expect the packet to be sent? >my sysctl output: >... > >net.inet.ip.redirect: 1 >net.inet.icmp.drop_redirect: 0 >... You don't say what you are trying to achieve but my crystal ball says that you want net.inet.ip.forwarding=3D1 on the remote system. --=20 Peter Jeremy --DSayHWYpDlRfCAAQ Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlEmbxcACgkQ/opHv/APuIcxMwCglklwqwunTrufuRYs4n4jHdB7 vTUAnRmn2EcBWBvdZ464a+MdXayvBOWd =Qep8 -----END PGP SIGNATURE----- --DSayHWYpDlRfCAAQ-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 21 22:20:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 714EB166 for ; Thu, 21 Feb 2013 22:20:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 60C027D for ; Thu, 21 Feb 2013 22:20:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1LMK1G6043510 for ; Thu, 21 Feb 2013 22:20:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1LMK1hS043509; Thu, 21 Feb 2013 22:20:01 GMT (envelope-from gnats) Date: Thu, 21 Feb 2013 22:20:01 GMT Message-Id: <201302212220.r1LMK1hS043509@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: John Baldwin Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: John Baldwin List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 22:20:01 -0000 The following reply was made to PR kern/172113; it has been noted by GNATS. From: John Baldwin To: bug-followup@freebsd.org, egrosbein@rdtc.ru Cc: Subject: Re: kern/172113: [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4): m_getjcl: invalid cluster type Date: Thu, 21 Feb 2013 17:12:55 -0500 An update on this. I think we should just use a workaround as this seems to be specific to a certain set of motherboards. This is the fix I'm using locally: Index: if_igb.c =================================================================== --- if_igb.c (revision 243732) +++ if_igb.c (working copy) @@ -1522,6 +1522,15 @@ u32 newitr = 0; bool more_rx; + /* + * The onboard adapters on certain SuperMicro X8* boards + * trigger a spurious interrupt during boot. Since it + * occurs before the interface is fully configured it + * triggers a panic. Ignore the interrupt instead. + */ + if (!(adapter->ifp->if_drv_flags & IFF_DRV_RUNNING)) + return; + E1000_WRITE_REG(&adapter->hw, E1000_EIMC, que->eims); ++que->irqs; -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Fri Feb 22 01:40:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2C5C0285; Fri, 22 Feb 2013 01:40:54 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 8EEC1BDE; Fri, 22 Feb 2013 01:40:53 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 5F6547E824; Fri, 22 Feb 2013 12:40:45 +1100 (EST) Message-ID: <5126CC9D.9010409@freebsd.org> Date: Fri, 22 Feb 2013 12:40:45 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Sepherosa Ziehau Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> <511C3FB8.40506@freebsd.org> <51242B05.1040003@room52.net> <51244A0C.8000800@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Andre Oppermann , John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 01:40:54 -0000 On 02/21/13 20:20, Sepherosa Ziehau wrote: > On Wed, Feb 20, 2013 at 11:59 AM, Lawrence Stewart wrote: >> Hi Sephe, >> >> On 02/20/13 13:37, Sepherosa Ziehau wrote: >>> On Wed, Feb 20, 2013 at 9:46 AM, Lawrence Stewart wrote: >>>> *crickets chirping* >>>> >>>> Time to move this discussion forward... >>>> >>>> >>>> If any robust counter-arguments exist, now is the time for us to hear >>>> them. I haven't read anything thus far which convinces me that we should >>>> not provide knobs to tune our stack's dynamics. >>>> >>>> In the absence of any compelling counter-arguments, I would like to >>>> propose the following: >>>> >>>> - We rename the net.inet.tcp.experimental sysctl node introduced in >>>> r242266 for IW10 support to net.inet.tcp.nonstandard, and re-parent the >>>> initcwnd10 sysctl under this node. >> >> I should also add that I think initcwnd10 should be changed to initcwnd >> and take the number of segments as a value. > > Yeah, I would suggest the same. > >> >>>> - We introduce a new net.inet.tcp.nonstandard.allowed sysctl variable >>>> and default it to 0. Only when it is changed to 1 will we allow starkly >>>> non standards compliant behaviour to be enabled in the stack. As a more >>>> complex but expressive alternative, we can make the sysctl take a bit >>>> mask or CSV string which specifies which non-standard options the sys >>>> admin permits (I'd prefer this as we can easily test non-standard >>>> options like IW10 in head without blanket enabling all non standard >>>> behaviour). >> >> To be clear, my proposal is that specifying an allowed option in >> net.inet.tcp.nonstandard.allowed would not enable it as the default on >> all connections, but would allow the per-application mechanism we define >> to set the option. Setting net.inet.tcp.nonstandard.option_x to 1 would >> enable the option as default for all connections. >> >>>> - We introduce a new net.inet.tcp.nonstandard.noidlereset sysctl >>>> variable, and use it to enable/disable window-reset-after-idle behaviour >>>> as proposed by John. >>>> >>>> - We don't introduce a TF_IGNOREIDLE sockopt, and instead introduce a >>>> more generic sockopt and/or mechanism for per-application tuning of all >>>> options which affect stack dynamics (both standard and non-standard >>>> options). I'm open to suggestions on what this could/should look like. >>> >>> Lawrence, >>> >>> A route metric? BTW, as for IW10, it could also become a route metric >>> (as proposed by the draft author's presentation >>> http://www.ietf.org/proceedings/79/slides/tcpm-0.pdf) >> >> Are you suggesting having the ability to set knobs as route metrics in >> addition to sysctl and a per-app mechanism? If so then I am very much in >> favour of this. Assuming an option has been allowed in >> net.inet.tcp.nonstandard.allowed, it should be able to be set by an >> application or on a route, perhaps with a precedence hierarchy of app >> request trumps route metric trumps system default setting? > > I suggest using route metrics in addition to the global sysctls; Agreed. > route metrics take precedence over global sysctls. Agreed. > I don't object the per-socket settings though. However, IMHO, these > options (IW10 and ignoring idle restart, and probably others) are > administrative, so applications probably should not mess with them. Messing with individual options like IW10 on a per-socket basis is definitely in the "generally should not" basket, but I would not want to stop an application from doing so subject to the option being specified by the administrator in the net.inet.tcp.nonstandard.allowed option list. What I expect applications would want to do more frequently is hint the socket with a higher level goal e.g. "I want maximum throughput", "I want low latency", etc. This can come later though. I think we have enough agreement on the basic infrastructure to move forward at this point with some patches. I would initially like to get the basic sysctl infrastructure to support all this sorted, then look at supporting these options as route metrics, and finally look at the higher level API. Anyone else with further input, please speak up! Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Fri Feb 22 10:53:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7AF0331C for ; Fri, 22 Feb 2013 10:53:23 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 416E9704 for ; Fri, 22 Feb 2013 10:53:23 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1U8qJA-000J3N-Bd; Fri, 22 Feb 2013 14:56:52 +0400 Message-ID: <51274D99.1070009@FreeBSD.org> Date: Fri, 22 Feb 2013 14:51:05 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: Possible optimization in ether_output() References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 10:53:23 -0000 On 20.02.2013 02:05, Vijay Singh wrote: > Hi, this patch gives a modest performance improvement here @work. > Please consider. > > [/u/vijay/bsd/CODE/cur/sys/net]# svn diff if_ethersubr.c > Index: if_ethersubr.c > =================================================================== > --- if_ethersubr.c (revision 247012) > +++ if_ethersubr.c (working copy) > @@ -160,6 +160,7 @@ > struct pf_mtag *t; > int loop_copy = 1; > int hlen; /* link layer header length */ > + int use_lle_directly = 0; > > if (ro != NULL) { > if (!(m->m_flags& (M_BCAST | M_MCAST))) > @@ -184,7 +185,7 @@ > #ifdef INET > case AF_INET: > if (lle != NULL&& (lle->la_flags& LLE_VALID)) > - memcpy(edst,&lle->ll_addr.mac16, sizeof(edst)); > + use_lle_directly = 1; > else > error = arpresolve(ifp, rt0, m, dst, edst,&lle); > if (error) > @@ -222,7 +223,7 @@ > #ifdef INET6 > case AF_INET6: > if (lle != NULL&& (lle->la_flags& LLE_VALID)) > - memcpy(edst,&lle->ll_addr.mac16, sizeof(edst)); > + use_lle_directly = 1; > else > error = nd6_storelladdr(ifp, m, dst, (u_char *)edst,&lle); > if (error) > @@ -317,9 +318,13 @@ > if (m == NULL) > senderr(ENOBUFS); > eh = mtod(m, struct ether_header *); > - (void)memcpy(&eh->ether_type,&type, > - sizeof(eh->ether_type)); > - (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); > + eh->ether_type = type; > + if (use_lle_directly) { > + memcpy(eh->ether_dhost,&lle->ll_addr.mac16, > + sizeof(eh->ether_dhost)); This is use-after-free since lle is returned unlocked by arpresolve(). This probably can be changed by supplying eh directly instead of edst, but this is tricky, too. I'm currently working on new arp stack implementation where such problems are handled more efficient. > + } else { > + (void)memcpy(eh->ether_dhost, edst, sizeof (edst)); > + } > if (hdrcmplt) > (void)memcpy(eh->ether_shost, esrc, > sizeof(eh->ether_shost)); > _______________________________________________ > 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 Sat Feb 23 03:54:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B2FF35AC for ; Sat, 23 Feb 2013 03:54:20 +0000 (UTC) (envelope-from freebsd@hub.org) Received: from hub.org (hub.org [200.46.208.146]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA5EA0F for ; Sat, 23 Feb 2013 03:54:20 +0000 (UTC) Received: from maia.hub.org (unknown [200.46.151.189]) by hub.org (Postfix) with ESMTP id 9DF9A1D658A5 for ; Fri, 22 Feb 2013 23:54:12 -0400 (AST) Received: from hub.org ([200.46.208.146]) by maia.hub.org (mx1.hub.org [200.46.151.189]) (amavisd-maia, port 10024) with ESMTP id 54068-03 for ; Sat, 23 Feb 2013 03:54:11 +0000 (UTC) Received: from [192.168.0.52] (S01067cb21b2ff4ca.gv.shawcable.net [24.108.26.71]) by hub.org (Postfix) with ESMTPA id BC9EE1D658A4 for ; Fri, 22 Feb 2013 23:54:10 -0400 (AST) From: Marc Fournier Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: FreeBSD 9.1-RELEASE + bge0 == watchdog timeout Date: Fri, 22 Feb 2013 19:54:07 -0800 References: To: freebsd-net@freebsd.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 03:54:20 -0000 We just picked up 5 new HP DL 360p Gen8 E5-2630 2P servers =85 just = installed 9.1-RELEASE, and it looks like all of the hardware is detected = properly, and being configured =85=20 After reboot, I start getting the 'watchdog timeout - resetting' message = on bge0 =85 I've searched the web, and found the references to setting: hw.bge.allow_asf=3D"0" hw.pci.enable_msi=3D"0" but after reboot with those set in /boot/loader.conf (and confirmed via = sysctl -a after login), its still doing it =85 Looking at sysctl -a, even though: hw.pci.enable_msi=3D"0" is set, I do see: dev.bge.0.msi=3D1 dev.bge.1.msi=3D1 dev.bge.2.msi=3D1 dev.bge.3.msi=3D1 still all set to 1 =85 is that right? Don't know if this is useful, but, again, according to sysctl -a: dev.bge.0.%desc: Broadcom unknown BCM5719, ASIC rev. 0x5719001 =3D=3D=3D If I do an 'ifconfig bge0', it does show the interface as being active, = but I can't ping out on it =85 I even found someone's reference to doing a 'ifconfig bge0 -tso = -vlanhwtso' and tried that =85 no go =85 Something else I can look at? Thx From owner-freebsd-net@FreeBSD.ORG Sat Feb 23 14:32:01 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 749E4AE6 for ; Sat, 23 Feb 2013 14:32:01 +0000 (UTC) (envelope-from ihsan@grep.my) Received: from svc02-kul.b.n3labs.my (svc02-kul.b.n3labs.my [124.108.16.61]) by mx1.freebsd.org (Postfix) with ESMTP id 24FD4F63 for ; Sat, 23 Feb 2013 14:32:00 +0000 (UTC) Received: from [IPv6:2400:3700:49::9d5b:f003:b040:19ea] (unknown [IPv6:2400:3700:49:0:9d5b:f003:b040:19ea]) by svc02-kul.b.n3labs.my (Postfix) with ESMTPSA id 4593DC60237 for ; Sat, 23 Feb 2013 22:31:50 +0800 (MYT) From: Ihsan Junaidi Ibrahim Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: SIOCIFCREATE and SIOCIFCREATE2 difference Message-Id: <8EEF3678-6911-4BC7-A440-DAA3588EF826@grep.my> Date: Sat, 23 Feb 2013 22:32:11 +0800 To: "freebsd-net@freebsd.org" Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2013 14:32:01 -0000 Hi, What's the internal difference between these two ioctl socket flags? = I've looked at sockio.h and notice that they refer to different = identifiers. I've created gif(4) via both flags and they both seem to work. Why prefer one over the other? ihsan=