From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 05:24:46 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 180E3C30 for ; Mon, 26 Nov 2012 05:24:46 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id 167428FC08 for ; Mon, 26 Nov 2012 05:24:44 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qAQ5ONEQ082313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 14:24:35 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qAQ5OLHb054850; Mon, 26 Nov 2012 14:24:22 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 26 Nov 2012 14:23:22 +0900 (JST) Message-Id: <20121126.142322.2280620686470349020.hrs@allbsd.org> To: yanegomi@gmail.com Subject: Re: net.inet6.icmp6.nd6_useloopback - what is it supposed to do? From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Nov_26_14_23_22_2012_258)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 26 Nov 2012 14:24:36 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org 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: Mon, 26 Nov 2012 05:24:46 -0000 ----Security_Multipart(Mon_Nov_26_14_23_22_2012_258)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Garrett Cooper wrote in : ya> Hi, ya> I've been TAHI testing FreeBSD 7.x sources for the past couple ya> months and over the course of my testing via the TAHI IPv6 conformance ya> test, I changed the knob value from net.inet6.icmp6.nd6_useloopback=1 ya> -> net.inet6.icmp6.nd6_useloopback=0 and ran into a slew of errors ya> with the addr.p2 phase-1 TAHI tests. ya> I was wondering if someone could describe what the beforementioned ya> sysctl is supposed to do from a functional perspective, how it might ya> tie into other IPv6 RFCs (if applicable), and if disabled how it would ya> affect a system with IPv6 enabled. It is for whether a loopback address (::1) is used as the destination for traffic toward one of the locally-configured IPv6 addresses. In the original implementation it is in rtrequest(), but the current FreeBSD's one it just means if a loopback route will be installed or not upon the lo0 interface initialization, not in RTM_RESOLVE. So, if setting nd6_useloopback to 0, no loopback route will be installed and some THAI test will fail, I think. -- Hiroki ----Security_Multipart(Mon_Nov_26_14_23_22_2012_258)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlCy/MoACgkQTyzT2CeTzy1iHwCfSveop9OJXh4yhfeE2smZMDJR aU0AoMZqDDBaE6brlgZR36khoYD81uss =EHiF -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Nov_26_14_23_22_2012_258)---- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 06:44:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A13D2B9F for ; Mon, 26 Nov 2012 06:44:49 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 378C68FC12 for ; Mon, 26 Nov 2012 06:44:48 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so7520647eek.13 for ; Sun, 25 Nov 2012 22:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=zA9oYi2QQL2/QYMfZxg9YFMM/IxKm+z3UCJ0+JRthlk=; b=IKdjICp8QPuO9vZ2ADfydKs7xI+vER84GHJPhtIT3TwM3aPe233elBknivwq95uMpm F0pVpp9TF19KbQGV19FpqQlBk1hg7rEsEb0wBtEtoYtkWR6GjTRcQqMSxaElXiWHx+XX F6bNUKS9jlWiOCJFLMh7sZzhI6Nax9hfZm+7Mb68gJQCQk78sLt55rCA621RG7uHqC+p aDUU402KUysZqShS5U07t+ynWUvxKtPNzo5DosHLRucPeFkqKR3N2kKN9GtONTv9oX2x 9vfEfvbQK9S4mEsMTdNrW44iT5v3+tCFRUewgk3XRTtkUzRhmZFl/GrfdVmJoH+XvZvK hMdA== MIME-Version: 1.0 Received: by 10.14.176.68 with SMTP id a44mr42460207eem.1.1353912282379; Sun, 25 Nov 2012 22:44:42 -0800 (PST) Received: by 10.14.3.133 with HTTP; Sun, 25 Nov 2012 22:44:42 -0800 (PST) Date: Sun, 25 Nov 2012 22:44:42 -0800 Message-ID: Subject: A small patch for sys/netinet6/in6_src.c 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: Mon, 26 Nov 2012 06:44:49 -0000 Really trivial change. /u/vijay/bsd/CODE/cur# svn diff sys/netinet6/in6_src.c Index: sys/netinet6/in6_src.c =================================================================== --- sys/netinet6/in6_src.c (revision 243309) +++ sys/netinet6/in6_src.c (working copy) @@ -597,11 +597,6 @@ if (ron->ro_rt == NULL) { in6_rtalloc(ron, fibnum); /* multi path case? */ if (ron->ro_rt == NULL) { - /* XXX-BZ WT.? */ - if (ron->ro_rt) { - RTFREE(ron->ro_rt); - ron->ro_rt = NULL; - } error = EHOSTUNREACH; goto done; } From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 07:35:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 676C328F; Mon, 26 Nov 2012 07:35:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 9FE918FC0C; Mon, 26 Nov 2012 07:35:58 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so2622991wib.13 for ; Sun, 25 Nov 2012 23:35:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=n3Late0VkjNGhqd1Pcf2wKTDuA1YzeWrfUBzg6W06eQ=; b=cGnmY64aB0uCVkiWkwF1FiSZdtTsNNcddrH901VXLUxewsCmwBXuBaqygxHCrowzOf mC8EmGBe6aFXmh3b1haIsxcVLN+tnTjri11NEEoD7n9Iwsk3d74AJQq5MWPdN/pZ+4j8 deOIjD5CfywLxp8dKkJ6PfhQf2BJr1HkcEdNf2O1pBFXF6pfJDKocKav4zREppfktQwd +3Q4R30yilZyERjLvGs1VtXyayVh7pAkji9PHhzgj70w57SSgKLcRCGf06/MUTf06Dxb BzBha1Y6t3OSo4UmxWPxfbT6XFFWmpfxVb2dZqL9n5PQ3NOQ4WzTLZV1lnZRs6PoA+SU 9W0g== MIME-Version: 1.0 Received: by 10.216.200.160 with SMTP id z32mr3825318wen.53.1353915351982; Sun, 25 Nov 2012 23:35:51 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Sun, 25 Nov 2012 23:35:51 -0800 (PST) In-Reply-To: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> Date: Sun, 25 Nov 2012 23:35:51 -0800 X-Google-Sender-Auth: WyesVZTwx_BSL3yFx-zC1r0VdlQ Message-ID: Subject: Re: LOR in rtsock/ifnet From: Adrian Chadd To: Rui Paulo Content-Type: text/plain; charset=ISO-8859-1 Cc: "" , "Andrey V. Elsukov" , Hiroki Sato 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, 26 Nov 2012 07:35:59 -0000 DO we know which commit triggered this? Adrian On 21 November 2012 16:31, Rui Paulo wrote: > I just started seeing this on r243286. > > lock order reversal: > 1st 0xfffffe0001b40400 if_addr_lock (if_addr_lock) @ /usr/home/rpaulo/freebsd/head/sys/net/rtsock.c:1818 > 2nd 0xffffffff80c693f8 ifnet_rw (ifnet_rw) @ /usr/home/rpaulo/freebsd/head/sys/net/if.c:241 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b > kdb_backtrace() at kdb_backtrace+0x39 > witness_checkorder() at witness_checkorder+0xc37 > __rw_rlock() at __rw_rlock+0x8c > ifnet_byindex() at ifnet_byindex+0x22 > sa6_recoverscope() at sa6_recoverscope+0x7b > rt_msg2() at rt_msg2+0x1a2 > sysctl_rtsock() at sysctl_rtsock+0x68c > sysctl_root() at sysctl_root+0x1d7 > userland_sysctl() at userland_sysctl+0x192 > sys___sysctl() at sys___sysctl+0x74 > amd64_syscall() at amd64_syscall+0x265 > Xfast_syscall() at Xfast_syscall+0xfb > --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x8011813ea, rsp = 0x7fffffffd408, rbp = 0x7fffffffd440 --- > > Regards, > -- > Rui Paulo > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 07:38:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D13FF348; Mon, 26 Nov 2012 07:38:45 +0000 (UTC) (envelope-from rpaulo@freebsd.org) Received: from felyko.com (felyko.com [IPv6:2607:f2f8:a528::3:1337:ca7]) by mx1.freebsd.org (Postfix) with ESMTP id B16488FC08; Mon, 26 Nov 2012 07:38:45 +0000 (UTC) Received: from [IPv6:2601:9:4d00:85:696c:f701:f570:7e35] (unknown [IPv6:2601:9:4d00:85:696c:f701:f570:7e35]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by felyko.com (Postfix) with ESMTPSA id 7B73A3981E; Sun, 25 Nov 2012 23:38:39 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: LOR in rtsock/ifnet From: Rui Paulo In-Reply-To: Date: Sun, 25 Nov 2012 23:38:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> To: Adrian Chadd X-Mailer: Apple Mail (2.1499) Cc: "" , "Andrey V. Elsukov" , Hiroki Sato 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, 26 Nov 2012 07:38:45 -0000 On 25 Nov 2012, at 23:35, Adrian Chadd wrote: > DO we know which commit triggered this? I haven't bisected. Regards, -- Rui Paulo From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 07:48:35 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AC08E710; Mon, 26 Nov 2012 07:48:35 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id E02EE8FC15; Mon, 26 Nov 2012 07:48:34 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qAQ7mHKu099923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Nov 2012 16:48:28 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qAQ7mGtg056289; Mon, 26 Nov 2012 16:48:17 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Mon, 26 Nov 2012 16:48:09 +0900 (JST) Message-Id: <20121126.164809.1810866108604245881.hrs@allbsd.org> To: rpaulo@FreeBSD.org, ae@FreeBSD.org Subject: Re: LOR in rtsock/ifnet From: Hiroki Sato In-Reply-To: <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Mon_Nov_26_16_48_09_2012_771)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Mon, 26 Nov 2012 16:48:28 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org, adrian@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, 26 Nov 2012 07:48:35 -0000 ----Security_Multipart(Mon_Nov_26_16_48_09_2012_771)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rui Paulo wrote in <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org>: rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: rp> rp> > DO we know which commit triggered this? rp> rp> rp> I haven't bisected. I do not think my commit triggered it because it occurred in rt_msg2(). Andrey, can you take a look at this? -- Hiroki ----Security_Multipart(Mon_Nov_26_16_48_09_2012_771)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlCzHrkACgkQTyzT2CeTzy0DdwCdEmzVRfIJaot4kcco/Yn8Xjl8 JU0AnixNSikhQSzr1yNCETYFejfSHESR =MYwE -----END PGP SIGNATURE----- ----Security_Multipart(Mon_Nov_26_16_48_09_2012_771)---- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 11:06:48 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CD6A587 for ; Mon, 26 Nov 2012 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 002E18FC16 for ; Mon, 26 Nov 2012 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAQB6ls2019463 for ; Mon, 26 Nov 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAQB6le1019461 for freebsd-net@FreeBSD.org; Mon, 26 Nov 2012 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 26 Nov 2012 11:06:47 GMT Message-Id: <201211261106.qAQB6le1019461@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, 26 Nov 2012 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/173481 net [NFS] RH63 NFSv4 client does not reconnect to FreeBSD o kern/173479 net [nfs] chown and chgrp operations fail between FreeBSD 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/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171697 net [ip6] [ndp] panic when changing routes 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/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow 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 430 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 18:26:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A91C24BC; Mon, 26 Nov 2012 18:26:54 +0000 (UTC) (envelope-from mjguzik@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 78FFC8FC08; Mon, 26 Nov 2012 18:26:53 +0000 (UTC) Received: by mail-wg0-f50.google.com with SMTP id 12so204883wgh.31 for ; Mon, 26 Nov 2012 10:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=f+883EFVzwNsc/CKm++ZytZ3bqBDicRBUznzhuGe9tY=; b=p0IEpg4w6ZKE9aMr/+TF/+vbMC38ArfN7djnptI/75aMiuL2bM0v2m9r2FB8Jy5K/p t6lnoMwQtKQG4UE9MjPbgGV5u4cQPbzR/CENfuDxUCBXAFi6I4x59UjTSx1sbOqTxabq mq8FgSxKIEM/qtIYCXLMUu1TKWSECNLygH38c6UFhJS6qULpk1Q8fRe1szu7E0XAJvF/ SCm3WC4Vu56k18jM6o0JUgsDqQJoDDfeerworMpwtakch4n9Fy4XpcEWQNEsZOa6P/5I a2RrepiiEqlVuPZrvqYeI/rGW7ci1C6XIa1PeDWLJ2XAHoe5yz115Awn8kT3bzHoVnWD /fFw== Received: by 10.180.7.199 with SMTP id l7mr19204897wia.15.1353954412444; Mon, 26 Nov 2012 10:26:52 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id i6sm128450wix.5.2012.11.26.10.26.50 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 10:26:51 -0800 (PST) Date: Mon, 26 Nov 2012 19:26:42 +0100 From: Mateusz Guzik To: Hiroki Sato Subject: Re: LOR in rtsock/ifnet Message-ID: <20121126182642.GB17080@dft-labs.eu> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> <20121126.164809.1810866108604245881.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121126.164809.1810866108604245881.hrs@allbsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ae@FreeBSD.org, adrian@FreeBSD.org, rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 18:26:54 -0000 On Mon, Nov 26, 2012 at 04:48:09PM +0900, Hiroki Sato wrote: > Rui Paulo wrote > in <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org>: > > rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: > rp> > rp> > DO we know which commit triggered this? > rp> > rp> > rp> I haven't bisected. > > I do not think my commit triggered it because it occurred in > rt_msg2(). Andrey, can you take a look at this? > I'm booting i386 on VirtualBox and I have two em interfaces, em0 is configured to get ip from DHCP and the other one is untouched. I don't get this lor with r243186, but I see it with r243187. I'm happy to provide more information if needed. -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 22:31:03 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CF8F757B; Mon, 26 Nov 2012 22:31:03 +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 13B6F8FC0C; Mon, 26 Nov 2012 22:31:02 +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 1Td7G1-0008Ux-5r; Tue, 27 Nov 2012 02:34:29 +0400 Message-ID: <50B3ED9B.1070500@FreeBSD.org> Date: Tue, 27 Nov 2012 02:30:51 +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: Gleb Smirnoff Subject: Re: [CFT] ipfw SMP-ready dynamic states References: <50A29F57.6090701@yandex-team.ru> <20121114154741.GE29772@nginx.com> In-Reply-To: <20121114154741.GE29772@nginx.com> Content-Type: multipart/mixed; boundary="------------080207080509080105000605" Cc: "Alexander V. Chernikov" , freebsd-ipfw@FreeBSD.org, Luigi Rizzo , "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, 26 Nov 2012 22:31:03 -0000 This is a multi-part message in MIME format. --------------080207080509080105000605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 14.11.2012 19:47, Gleb Smirnoff wrote: > On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote: > A> So, we can do the following: > A> 1) lock increments/decrements via some separate mutex > A> 2) do nothing > A> 3) take some combined approach: > > 4) Take it via uma_zone_getcur(ipfw_dyn_rule_zone); It acquired zone lock to collect per-cpu item data, but uma_zone_set_max() did the trick. > Patch updated: * UMA zone is now allocated per-VNET instance * dyn_max limits is now enforced by UMA code * some (serious) bugs removed from limiting code If there are no objections, I plan to commit this patch to base on Thursday. --------------080207080509080105000605 Content-Type: text/plain; name="ipfw_dyn2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ipfw_dyn2.diff" Index: sys/netpfil/ipfw/ip_fw_sockopt.c =================================================================== --- sys/netpfil/ipfw/ip_fw_sockopt.c (revision 243526) +++ sys/netpfil/ipfw/ip_fw_sockopt.c (working copy) @@ -382,7 +382,7 @@ del_entry(struct ip_fw_chain *chain, uint32_t arg) continue; l = RULESIZE(rule); chain->static_len -= l; - ipfw_remove_dyn_children(rule); + ipfw_expire_dyn_rules(chain, rule, RESVD_SET); rule->x_next = chain->reap; chain->reap = rule; } @@ -925,7 +925,7 @@ ipfw_getrules(struct ip_fw_chain *chain, void *buf dst->timestamp += boot_seconds; bp += l; } - ipfw_get_dynamic(&bp, ep); /* protected by the dynamic lock */ + ipfw_get_dynamic(chain, &bp, ep); /* protected by the dynamic lock */ return (bp - (char *)buf); } Index: sys/netpfil/ipfw/ip_fw_private.h =================================================================== --- sys/netpfil/ipfw/ip_fw_private.h (revision 243526) +++ sys/netpfil/ipfw/ip_fw_private.h (working copy) @@ -175,7 +175,9 @@ enum { /* result for matching dynamic rules */ * and only to release the result of lookup_dyn_rule(). * Eventually we may implement it with a callback on the function. */ -void ipfw_dyn_unlock(void); +struct ip_fw_chain; +void ipfw_expire_dyn_rules(struct ip_fw_chain *, struct ip_fw *, int); +void ipfw_dyn_unlock(ipfw_dyn_rule *q); struct tcphdr; struct mbuf *ipfw_send_pkt(struct mbuf *, struct ipfw_flow_id *, @@ -185,11 +187,9 @@ int ipfw_install_state(struct ip_fw *rule, ipfw_in ipfw_dyn_rule *ipfw_lookup_dyn_rule(struct ipfw_flow_id *pkt, int *match_direction, struct tcphdr *tcp); void ipfw_remove_dyn_children(struct ip_fw *rule); -void ipfw_get_dynamic(char **bp, const char *ep); +void ipfw_get_dynamic(struct ip_fw_chain *chain, char **bp, const char *ep); -void ipfw_dyn_attach(void); /* uma_zcreate .... */ -void ipfw_dyn_detach(void); /* uma_zdestroy ... */ -void ipfw_dyn_init(void); /* per-vnet initialization */ +void ipfw_dyn_init(struct ip_fw_chain *); /* per-vnet initialization */ void ipfw_dyn_uninit(int); /* per-vnet deinitialization */ int ipfw_dyn_len(void); @@ -259,6 +259,9 @@ struct sockopt; /* used by tcp_var.h */ #define IPFW_WLOCK(p) rw_wlock(&(p)->rwmtx) #define IPFW_WUNLOCK(p) rw_wunlock(&(p)->rwmtx) +#define IPFW_UH_RLOCK_ASSERT(_chain) rw_assert(&(_chain)->uh_lock, RA_RLOCKED) +#define IPFW_UH_WLOCK_ASSERT(_chain) rw_assert(&(_chain)->uh_lock, RA_WLOCKED) + #define IPFW_UH_RLOCK(p) rw_rlock(&(p)->uh_lock) #define IPFW_UH_RUNLOCK(p) rw_runlock(&(p)->uh_lock) #define IPFW_UH_WLOCK(p) rw_wlock(&(p)->uh_lock) Index: sys/netpfil/ipfw/ip_fw_dynamic.c =================================================================== --- sys/netpfil/ipfw/ip_fw_dynamic.c (revision 243526) +++ sys/netpfil/ipfw/ip_fw_dynamic.c (working copy) @@ -95,7 +95,7 @@ __FBSDID("$FreeBSD$"); * The lifetime of dynamic rules is regulated by dyn_*_lifetime, * measured in seconds and depending on the flags. * - * The total number of dynamic rules is stored in dyn_count. + * The total number of dynamic rules is equal to UMA zone items count. * The max number of dynamic rules is dyn_max. When we reach * the maximum number of rules we do not create anymore. This is * done to avoid consuming too much memory, but also too much @@ -111,38 +111,34 @@ __FBSDID("$FreeBSD$"); * passes through the firewall. XXX check the latter!!! */ +struct ipfw_dyn_bucket { + struct mtx mtx; /* Bucket protecting lock */ + ipfw_dyn_rule *head; /* Pointer to first rule */ +}; + /* * Static variables followed by global ones */ -static VNET_DEFINE(ipfw_dyn_rule **, ipfw_dyn_v); -static VNET_DEFINE(u_int32_t, dyn_buckets); +static VNET_DEFINE(struct ipfw_dyn_bucket *, ipfw_dyn_v); +static VNET_DEFINE(u_int32_t, dyn_buckets_max); static VNET_DEFINE(u_int32_t, curr_dyn_buckets); static VNET_DEFINE(struct callout, ipfw_timeout); #define V_ipfw_dyn_v VNET(ipfw_dyn_v) -#define V_dyn_buckets VNET(dyn_buckets) +#define V_dyn_buckets_max VNET(dyn_buckets_max) #define V_curr_dyn_buckets VNET(curr_dyn_buckets) #define V_ipfw_timeout VNET(ipfw_timeout) -static uma_zone_t ipfw_dyn_rule_zone; -#ifndef __FreeBSD__ -DEFINE_SPINLOCK(ipfw_dyn_mtx); -#else -static struct mtx ipfw_dyn_mtx; /* mutex guarding dynamic rules */ -#endif +static VNET_DEFINE(uma_zone_t, ipfw_dyn_rule_zone); +#define V_ipfw_dyn_rule_zone VNET(ipfw_dyn_rule_zone) -#define IPFW_DYN_LOCK_INIT() \ - mtx_init(&ipfw_dyn_mtx, "IPFW dynamic rules", NULL, MTX_DEF) -#define IPFW_DYN_LOCK_DESTROY() mtx_destroy(&ipfw_dyn_mtx) -#define IPFW_DYN_LOCK() mtx_lock(&ipfw_dyn_mtx) -#define IPFW_DYN_UNLOCK() mtx_unlock(&ipfw_dyn_mtx) -#define IPFW_DYN_LOCK_ASSERT() mtx_assert(&ipfw_dyn_mtx, MA_OWNED) +#define IPFW_BUCK_LOCK_INIT(b) \ + mtx_init(&(b)->mtx, "IPFW dynamic bucket", NULL, MTX_DEF) +#define IPFW_BUCK_LOCK_DESTROY(b) \ + mtx_destroy(&(b)->mtx) +#define IPFW_BUCK_LOCK(i) mtx_lock(&V_ipfw_dyn_v[(i)].mtx) +#define IPFW_BUCK_UNLOCK(i) mtx_unlock(&V_ipfw_dyn_v[(i)].mtx) +#define IPFW_BUCK_ASSERT(i) mtx_assert(&V_ipfw_dyn_v[(i)].mtx, MA_OWNED) -void -ipfw_dyn_unlock(void) -{ - IPFW_DYN_UNLOCK(); -} - /* * Timeouts for various events in handing dynamic rules. */ @@ -171,33 +167,42 @@ static VNET_DEFINE(u_int32_t, dyn_short_lifetime); static VNET_DEFINE(u_int32_t, dyn_keepalive_interval); static VNET_DEFINE(u_int32_t, dyn_keepalive_period); static VNET_DEFINE(u_int32_t, dyn_keepalive); +static VNET_DEFINE(time_t, dyn_keepalive_last); #define V_dyn_keepalive_interval VNET(dyn_keepalive_interval) #define V_dyn_keepalive_period VNET(dyn_keepalive_period) #define V_dyn_keepalive VNET(dyn_keepalive) +#define V_dyn_keepalive_last VNET(dyn_keepalive_last) -static VNET_DEFINE(u_int32_t, dyn_count); /* # of dynamic rules */ static VNET_DEFINE(u_int32_t, dyn_max); /* max # of dynamic rules */ -#define V_dyn_count VNET(dyn_count) +#define DYN_COUNT uma_zone_get_cur(V_ipfw_dyn_rule_zone) #define V_dyn_max VNET(dyn_max) +static int last_log; /* Log ratelimiting */ + +static void ipfw_dyn_tick(void *vnetx); +static void check_dyn_rules(struct ip_fw_chain *, struct ip_fw *, + int, int, int); #ifdef SYSCTL_NODE +static int sysctl_ipfw_dyn_count(SYSCTL_HANDLER_ARGS); +static int sysctl_ipfw_dyn_max(SYSCTL_HANDLER_ARGS); + SYSBEGIN(f2) SYSCTL_DECL(_net_inet_ip_fw); SYSCTL_VNET_UINT(_net_inet_ip_fw, OID_AUTO, dyn_buckets, - CTLFLAG_RW, &VNET_NAME(dyn_buckets), 0, - "Number of dyn. buckets"); + CTLFLAG_RW, &VNET_NAME(dyn_buckets_max), 0, + "Max number of dyn. buckets"); SYSCTL_VNET_UINT(_net_inet_ip_fw, OID_AUTO, curr_dyn_buckets, CTLFLAG_RD, &VNET_NAME(curr_dyn_buckets), 0, "Current Number of dyn. buckets"); -SYSCTL_VNET_UINT(_net_inet_ip_fw, OID_AUTO, dyn_count, - CTLFLAG_RD, &VNET_NAME(dyn_count), 0, +SYSCTL_VNET_PROC(_net_inet_ip_fw, OID_AUTO, dyn_count, + CTLTYPE_UINT|CTLFLAG_RD, 0, 0, sysctl_ipfw_dyn_count, "IU", "Number of dyn. rules"); -SYSCTL_VNET_UINT(_net_inet_ip_fw, OID_AUTO, dyn_max, - CTLFLAG_RW, &VNET_NAME(dyn_max), 0, +SYSCTL_VNET_PROC(_net_inet_ip_fw, OID_AUTO, dyn_max, + CTLTYPE_UINT|CTLFLAG_RW, 0, 0, sysctl_ipfw_dyn_max, "IU", "Max number of dyn. rules"); SYSCTL_VNET_UINT(_net_inet_ip_fw, OID_AUTO, dyn_ack_lifetime, CTLFLAG_RW, &VNET_NAME(dyn_ack_lifetime), 0, @@ -244,7 +249,7 @@ hash_packet6(struct ipfw_flow_id *id) * and we want to find both in the same bucket. */ static __inline int -hash_packet(struct ipfw_flow_id *id) +hash_packet(struct ipfw_flow_id *id, int buckets) { u_int32_t i; @@ -254,7 +259,7 @@ static __inline int else #endif /* INET6 */ i = (id->dst_ip) ^ (id->src_ip) ^ (id->dst_port) ^ (id->src_port); - i &= (V_curr_dyn_buckets - 1); + i &= (buckets - 1); return i; } @@ -286,124 +291,19 @@ print_dyn_rule_flags(struct ipfw_flow_id *id, int } log(log_flags, "ipfw: %s type %d %s %d -> %s %d, %d %s\n", prefix, dyn_type, src, id->src_port, dst, - id->dst_port, V_dyn_count, postfix); + id->dst_port, DYN_COUNT, postfix); } #define print_dyn_rule(id, dtype, prefix, postfix) \ print_dyn_rule_flags(id, dtype, LOG_DEBUG, prefix, postfix) -/** - * unlink a dynamic rule from a chain. prev is a pointer to - * the previous one, q is a pointer to the rule to delete, - * head is a pointer to the head of the queue. - * Modifies q and potentially also head. - */ -#define UNLINK_DYN_RULE(prev, head, q) { \ - ipfw_dyn_rule *old_q = q; \ - \ - /* remove a refcount to the parent */ \ - if (q->dyn_type == O_LIMIT) \ - q->parent->count--; \ - V_dyn_count--; \ - DEB(print_dyn_rule(&q->id, q->dyn_type, "unlink entry", "left");) \ - if (prev != NULL) \ - prev->next = q = q->next; \ - else \ - head = q = q->next; \ - uma_zfree(ipfw_dyn_rule_zone, old_q); } - #define TIME_LEQ(a,b) ((int)((a)-(b)) <= 0) -/** - * Remove dynamic rules pointing to "rule", or all of them if rule == NULL. - * - * If keep_me == NULL, rules are deleted even if not expired, - * otherwise only expired rules are removed. - * - * The value of the second parameter is also used to point to identify - * a rule we absolutely do not want to remove (e.g. because we are - * holding a reference to it -- this is the case with O_LIMIT_PARENT - * rules). The pointer is only used for comparison, so any non-null - * value will do. - */ -static void -remove_dyn_rule(struct ip_fw *rule, ipfw_dyn_rule *keep_me) -{ - static u_int32_t last_remove = 0; - -#define FORCE (keep_me == NULL) - - ipfw_dyn_rule *prev, *q; - int i, pass = 0, max_pass = 0; - - IPFW_DYN_LOCK_ASSERT(); - - if (V_ipfw_dyn_v == NULL || V_dyn_count == 0) - return; - /* do not expire more than once per second, it is useless */ - if (!FORCE && last_remove == time_uptime) - return; - last_remove = time_uptime; - - /* - * because O_LIMIT refer to parent rules, during the first pass only - * remove child and mark any pending LIMIT_PARENT, and remove - * them in a second pass. - */ -next_pass: - for (i = 0 ; i < V_curr_dyn_buckets ; i++) { - for (prev=NULL, q = V_ipfw_dyn_v[i] ; q ; ) { - /* - * Logic can become complex here, so we split tests. - */ - if (q == keep_me) - goto next; - if (rule != NULL && rule != q->rule) - goto next; /* not the one we are looking for */ - if (q->dyn_type == O_LIMIT_PARENT) { - /* - * handle parent in the second pass, - * record we need one. - */ - max_pass = 1; - if (pass == 0) - goto next; - if (FORCE && q->count != 0 ) { - /* XXX should not happen! */ - printf("ipfw: OUCH! cannot remove rule," - " count %d\n", q->count); - } - } else { - if (!FORCE && - !TIME_LEQ( q->expire, time_uptime )) - goto next; - } - if (q->dyn_type != O_LIMIT_PARENT || !q->count) { - UNLINK_DYN_RULE(prev, V_ipfw_dyn_v[i], q); - continue; - } -next: - prev=q; - q=q->next; - } - } - if (pass++ < max_pass) - goto next_pass; -} - -void -ipfw_remove_dyn_children(struct ip_fw *rule) -{ - IPFW_DYN_LOCK(); - remove_dyn_rule(rule, NULL /* force removal */); - IPFW_DYN_UNLOCK(); -} - /* - * Lookup a dynamic rule, locked version. + * Lookup a dynamic rule */ static ipfw_dyn_rule * -lookup_dyn_rule_locked(struct ipfw_flow_id *pkt, int *match_direction, +lookup_dyn_rule_locked(struct ipfw_flow_id *pkt, int i, int *match_direction, struct tcphdr *tcp) { /* @@ -414,23 +314,17 @@ static ipfw_dyn_rule * #define MATCH_FORWARD 1 #define MATCH_NONE 2 #define MATCH_UNKNOWN 3 - int i, dir = MATCH_NONE; + int dir = MATCH_NONE; ipfw_dyn_rule *prev, *q = NULL; - IPFW_DYN_LOCK_ASSERT(); + IPFW_BUCK_ASSERT(i); - if (V_ipfw_dyn_v == NULL) - goto done; /* not found */ - i = hash_packet(pkt); - for (prev = NULL, q = V_ipfw_dyn_v[i]; q != NULL;) { + for (prev = NULL, q = V_ipfw_dyn_v[i].head; q; prev = q, q = q->next) { if (q->dyn_type == O_LIMIT_PARENT && q->count) - goto next; - if (TIME_LEQ(q->expire, time_uptime)) { /* expire entry */ - UNLINK_DYN_RULE(prev, V_ipfw_dyn_v[i], q); continue; - } + if (pkt->proto != q->id.proto || q->dyn_type == O_LIMIT_PARENT) - goto next; + continue; if (IS_IP6_FLOW_ID(pkt)) { if (IN6_ARE_ADDR_EQUAL(&pkt->src_ip6, &q->id.src_ip6) && @@ -463,17 +357,14 @@ static ipfw_dyn_rule * break; } } -next: - prev = q; - q = q->next; } if (q == NULL) goto done; /* q = NULL, not found */ if (prev != NULL) { /* found and not in front */ prev->next = q->next; - q->next = V_ipfw_dyn_v[i]; - V_ipfw_dyn_v[i] = q; + q->next = V_ipfw_dyn_v[i].head; + V_ipfw_dyn_v[i].head = q; } if (pkt->proto == IPPROTO_TCP) { /* update state according to flags */ uint32_t ack; @@ -556,42 +447,108 @@ ipfw_lookup_dyn_rule(struct ipfw_flow_id *pkt, int struct tcphdr *tcp) { ipfw_dyn_rule *q; + int i; - IPFW_DYN_LOCK(); - q = lookup_dyn_rule_locked(pkt, match_direction, tcp); + i = hash_packet(pkt, V_curr_dyn_buckets); + + IPFW_BUCK_LOCK(i); + q = lookup_dyn_rule_locked(pkt, i, match_direction, tcp); if (q == NULL) - IPFW_DYN_UNLOCK(); + IPFW_BUCK_UNLOCK(i); /* NB: return table locked when q is not NULL */ return q; } -static void -realloc_dynamic_table(void) +/* + * Unlock bucket mtx + * @p - pointer to dynamic rule + */ +void +ipfw_dyn_unlock(ipfw_dyn_rule *q) { - IPFW_DYN_LOCK_ASSERT(); + IPFW_BUCK_UNLOCK(q->bucket); +} + +static int +resize_dynamic_table(struct ip_fw_chain *chain, int nbuckets) +{ + int i, k, nbuckets_old; + ipfw_dyn_rule *q; + struct ipfw_dyn_bucket *dyn_v, *dyn_v_old; + + /* Check if given number is power of 2 and less than 64k */ + if ((nbuckets > 65536) || (!powerof2(nbuckets))) + return 1; + + CTR3(KTR_NET, "%s: resize dynamic hash: %d -> %d", __func__, + V_curr_dyn_buckets, nbuckets); + + /* Allocate and initialize new hash */ + dyn_v = malloc(nbuckets * sizeof(ipfw_dyn_rule), M_IPFW, + M_WAITOK | M_ZERO); + + for (i = 0 ; i < nbuckets; i++) + IPFW_BUCK_LOCK_INIT(&dyn_v[i]); + /* - * Try reallocation, make sure we have a power of 2 and do - * not allow more than 64k entries. In case of overflow, - * default to 1024. + * Call upper half lock, as get_map() do to ease + * read-only access to dynamic rules hash from sysctl */ + IPFW_UH_WLOCK(chain); - if (V_dyn_buckets > 65536) - V_dyn_buckets = 1024; - if ((V_dyn_buckets & (V_dyn_buckets-1)) != 0) { /* not a power of 2 */ - V_dyn_buckets = V_curr_dyn_buckets; /* reset */ - return; + /* + * Acquire chain write lock to permit hash access + * for main traffic path without additional locks + */ + IPFW_WLOCK(chain); + + /* Save old values */ + nbuckets_old = V_curr_dyn_buckets; + dyn_v_old = V_ipfw_dyn_v; + + /* Skip relinking if array is not set up */ + if (V_ipfw_dyn_v == NULL) + V_curr_dyn_buckets = 0; + + /* Re-link all dynamic states */ + for (i = 0 ; i < V_curr_dyn_buckets ; i++) { + while (V_ipfw_dyn_v[i].head != NULL) { + /* Remove from current chain */ + q = V_ipfw_dyn_v[i].head; + V_ipfw_dyn_v[i].head = q->next; + + /* Get new hash value */ + k = hash_packet(&q->id, nbuckets); + q->bucket = k; + /* Add to the new head */ + q->next = dyn_v[k].head; + dyn_v[k].head = q; + } } - V_curr_dyn_buckets = V_dyn_buckets; - if (V_ipfw_dyn_v != NULL) - free(V_ipfw_dyn_v, M_IPFW); - for (;;) { - V_ipfw_dyn_v = malloc(V_curr_dyn_buckets * sizeof(ipfw_dyn_rule *), - M_IPFW, M_NOWAIT | M_ZERO); - if (V_ipfw_dyn_v != NULL || V_curr_dyn_buckets <= 2) - break; - V_curr_dyn_buckets /= 2; + + /* Update current pointers/buckets values */ + V_curr_dyn_buckets = nbuckets; + V_ipfw_dyn_v = dyn_v; + + IPFW_WUNLOCK(chain); + + IPFW_UH_WUNLOCK(chain); + + /* Start periodic callout on initial creation */ + if (dyn_v_old == NULL) { + callout_reset_on(&V_ipfw_timeout, hz, ipfw_dyn_tick, curvnet, 0); + return (0); } + + /* Destroy all mutexes */ + for (i = 0 ; i < nbuckets_old ; i++) + IPFW_BUCK_LOCK_DESTROY(&dyn_v_old[i]); + + /* Free old hash */ + free(dyn_v_old, M_IPFW); + + return 0; } /** @@ -605,33 +562,30 @@ ipfw_lookup_dyn_rule(struct ipfw_flow_id *pkt, int * - "parent" rules for the above (O_LIMIT_PARENT). */ static ipfw_dyn_rule * -add_dyn_rule(struct ipfw_flow_id *id, u_int8_t dyn_type, struct ip_fw *rule) +add_dyn_rule(struct ipfw_flow_id *id, int i, u_int8_t dyn_type, struct ip_fw *rule) { ipfw_dyn_rule *r; - int i; - IPFW_DYN_LOCK_ASSERT(); + IPFW_BUCK_ASSERT(i); - if (V_ipfw_dyn_v == NULL || - (V_dyn_count == 0 && V_dyn_buckets != V_curr_dyn_buckets)) { - realloc_dynamic_table(); - if (V_ipfw_dyn_v == NULL) - return NULL; /* failed ! */ - } - i = hash_packet(id); - - r = uma_zalloc(ipfw_dyn_rule_zone, M_NOWAIT | M_ZERO); + r = uma_zalloc(V_ipfw_dyn_rule_zone, M_NOWAIT | M_ZERO); if (r == NULL) { - printf ("ipfw: sorry cannot allocate state\n"); + if (last_log != time_uptime) { + last_log = time_uptime; + log(LOG_DEBUG, "ipfw: %s: Cannot allocate rule\n", + __func__); + } return NULL; } - /* increase refcount on parent, and set pointer */ + /* + * refcount on parent is already incremented, so + * it is safe to use parent unlocked. + */ if (dyn_type == O_LIMIT) { ipfw_dyn_rule *parent = (ipfw_dyn_rule *)rule; if ( parent->dyn_type != O_LIMIT_PARENT) panic("invalid parent"); - parent->count++; r->parent = parent; rule = parent->rule; } @@ -644,9 +598,8 @@ static ipfw_dyn_rule * r->count = 0; r->bucket = i; - r->next = V_ipfw_dyn_v[i]; - V_ipfw_dyn_v[i] = r; - V_dyn_count++; + r->next = V_ipfw_dyn_v[i].head; + V_ipfw_dyn_v[i].head = r; DEB(print_dyn_rule(id, dyn_type, "add dyn entry", "total");) return r; } @@ -656,40 +609,40 @@ static ipfw_dyn_rule * * If the lookup fails, then install one. */ static ipfw_dyn_rule * -lookup_dyn_parent(struct ipfw_flow_id *pkt, struct ip_fw *rule) +lookup_dyn_parent(struct ipfw_flow_id *pkt, int *pindex, struct ip_fw *rule) { ipfw_dyn_rule *q; - int i; + int i, is_v6; - IPFW_DYN_LOCK_ASSERT(); + is_v6 = IS_IP6_FLOW_ID(pkt); + i = hash_packet( pkt, V_curr_dyn_buckets ); + *pindex = i; + IPFW_BUCK_LOCK(i); + for (q = V_ipfw_dyn_v[i].head ; q != NULL ; q=q->next) + if (q->dyn_type == O_LIMIT_PARENT && + rule== q->rule && + pkt->proto == q->id.proto && + pkt->src_port == q->id.src_port && + pkt->dst_port == q->id.dst_port && + ( + (is_v6 && + IN6_ARE_ADDR_EQUAL(&(pkt->src_ip6), + &(q->id.src_ip6)) && + IN6_ARE_ADDR_EQUAL(&(pkt->dst_ip6), + &(q->id.dst_ip6))) || + (!is_v6 && + pkt->src_ip == q->id.src_ip && + pkt->dst_ip == q->id.dst_ip) + ) + ) { + q->expire = time_uptime + V_dyn_short_lifetime; + DEB(print_dyn_rule(pkt, q->dyn_type, + "lookup_dyn_parent found", "");) + return q; + } - if (V_ipfw_dyn_v) { - int is_v6 = IS_IP6_FLOW_ID(pkt); - i = hash_packet( pkt ); - for (q = V_ipfw_dyn_v[i] ; q != NULL ; q=q->next) - if (q->dyn_type == O_LIMIT_PARENT && - rule== q->rule && - pkt->proto == q->id.proto && - pkt->src_port == q->id.src_port && - pkt->dst_port == q->id.dst_port && - ( - (is_v6 && - IN6_ARE_ADDR_EQUAL(&(pkt->src_ip6), - &(q->id.src_ip6)) && - IN6_ARE_ADDR_EQUAL(&(pkt->dst_ip6), - &(q->id.dst_ip6))) || - (!is_v6 && - pkt->src_ip == q->id.src_ip && - pkt->dst_ip == q->id.dst_ip) - ) - ) { - q->expire = time_uptime + V_dyn_short_lifetime; - DEB(print_dyn_rule(pkt, q->dyn_type, - "lookup_dyn_parent found", "");) - return q; - } - } - return add_dyn_rule(pkt, O_LIMIT_PARENT, rule); + /* Add virtual limiting rule */ + return add_dyn_rule(pkt, i, O_LIMIT_PARENT, rule); } /** @@ -702,14 +655,16 @@ int ipfw_install_state(struct ip_fw *rule, ipfw_insn_limit *cmd, struct ip_fw_args *args, uint32_t tablearg) { - static int last_log; ipfw_dyn_rule *q; + int i; DEB(print_dyn_rule(&args->f_id, cmd->o.opcode, "install_state", "");) + + i = hash_packet(&args->f_id, V_curr_dyn_buckets); - IPFW_DYN_LOCK(); + IPFW_BUCK_LOCK(i); - q = lookup_dyn_rule_locked(&args->f_id, NULL, NULL); + q = lookup_dyn_rule_locked(&args->f_id, i, NULL, NULL); if (q != NULL) { /* should never occur */ DEB( @@ -718,26 +673,20 @@ ipfw_install_state(struct ip_fw *rule, ipfw_insn_l printf("ipfw: %s: entry already present, done\n", __func__); }) - IPFW_DYN_UNLOCK(); + IPFW_BUCK_UNLOCK(i); return (0); } - if (V_dyn_count >= V_dyn_max) - /* Run out of slots, try to remove any expired rule. */ - remove_dyn_rule(NULL, (ipfw_dyn_rule *)1); + /* + * State limiting is done via uma(9) zone limiting. + * Save pointer to newly-installed rule and reject + * packet if add_dyn_rule() returned NULL. + * Note q is currently set to NULL. + */ - if (V_dyn_count >= V_dyn_max) { - if (last_log != time_uptime) { - last_log = time_uptime; - printf("ipfw: %s: Too many dynamic rules\n", __func__); - } - IPFW_DYN_UNLOCK(); - return (1); /* cannot install, notify caller */ - } - switch (cmd->o.opcode) { case O_KEEP_STATE: /* bidir rule */ - add_dyn_rule(&args->f_id, O_KEEP_STATE, rule); + q = add_dyn_rule(&args->f_id, i, O_KEEP_STATE, rule); break; case O_LIMIT: { /* limit number of sessions */ @@ -745,6 +694,7 @@ ipfw_install_state(struct ip_fw *rule, ipfw_insn_l ipfw_dyn_rule *parent; uint32_t conn_limit; uint16_t limit_mask = cmd->limit_mask; + int pindex; conn_limit = (cmd->conn_limit == IP_FW_TABLEARG) ? tablearg : cmd->conn_limit; @@ -778,46 +728,65 @@ ipfw_install_state(struct ip_fw *rule, ipfw_insn_l id.src_port = args->f_id.src_port; if (limit_mask & DYN_DST_PORT) id.dst_port = args->f_id.dst_port; - if ((parent = lookup_dyn_parent(&id, rule)) == NULL) { + + /* + * We have to release lock for previous bucket to + * avoid possible deadlock + */ + IPFW_BUCK_UNLOCK(i); + + if ((parent = lookup_dyn_parent(&id, &pindex, rule)) == NULL) { printf("ipfw: %s: add parent failed\n", __func__); - IPFW_DYN_UNLOCK(); + IPFW_BUCK_UNLOCK(pindex); return (1); } if (parent->count >= conn_limit) { - /* See if we can remove some expired rule. */ - remove_dyn_rule(rule, parent); - if (parent->count >= conn_limit) { - if (V_fw_verbose && last_log != time_uptime) { - last_log = time_uptime; - char sbuf[24]; - last_log = time_uptime; - snprintf(sbuf, sizeof(sbuf), - "%d drop session", - parent->rule->rulenum); - print_dyn_rule_flags(&args->f_id, - cmd->o.opcode, - LOG_SECURITY | LOG_DEBUG, - sbuf, "too many entries"); - } - IPFW_DYN_UNLOCK(); - return (1); + if (V_fw_verbose && last_log != time_uptime) { + last_log = time_uptime; + char sbuf[24]; + last_log = time_uptime; + snprintf(sbuf, sizeof(sbuf), + "%d drop session", + parent->rule->rulenum); + print_dyn_rule_flags(&args->f_id, + cmd->o.opcode, + LOG_SECURITY | LOG_DEBUG, + sbuf, "too many entries"); } + IPFW_BUCK_UNLOCK(pindex); + return (1); } - add_dyn_rule(&args->f_id, O_LIMIT, (struct ip_fw *)parent); + /* Increment counter on parent */ + parent->count++; + IPFW_BUCK_UNLOCK(pindex); + + IPFW_BUCK_LOCK(i); + q = add_dyn_rule(&args->f_id, i, O_LIMIT, (struct ip_fw *)parent); + if (q == NULL) { + /* Decrement index and notify caller */ + IPFW_BUCK_UNLOCK(i); + IPFW_BUCK_LOCK(pindex); + parent->count--; + IPFW_BUCK_UNLOCK(pindex); + return (1); + } break; } default: printf("ipfw: %s: unknown dynamic rule type %u\n", __func__, cmd->o.opcode); - IPFW_DYN_UNLOCK(); - return (1); } + if (q == NULL) { + IPFW_BUCK_UNLOCK(i); + return (1); /* Notify caller about failure */ + } + /* XXX just set lifetime */ - lookup_dyn_rule_locked(&args->f_id, NULL, NULL); + lookup_dyn_rule_locked(&args->f_id, i, NULL, NULL); - IPFW_DYN_UNLOCK(); + IPFW_BUCK_UNLOCK(i); return (0); } @@ -996,24 +965,87 @@ ipfw_dyn_send_ka(struct mbuf **mtailp, ipfw_dyn_ru } /* - * This procedure is only used to handle keepalives. It is invoked - * every dyn_keepalive_period + * This procedure is used to perform various maintance + * on dynamic hash list. Currently it is called every second. */ static void -ipfw_tick(void * vnetx) +ipfw_dyn_tick(void * vnetx) { - struct mbuf *m0, *m, *mnext, **mtailp; - struct ip *h; - int i; - ipfw_dyn_rule *q; + struct ip_fw_chain *chain; + int check_ka = 0; #ifdef VIMAGE struct vnet *vp = vnetx; #endif CURVNET_SET(vp); - if (V_dyn_keepalive == 0 || V_ipfw_dyn_v == NULL || V_dyn_count == 0) - goto done; + chain = &V_layer3_chain; + + /* Run keepalive checks every keepalive_interval iff ka is enabled */ + if ((V_dyn_keepalive_last + V_dyn_keepalive_interval >= time_uptime) && + (V_dyn_keepalive != 0)) { + V_dyn_keepalive_last = time_uptime; + check_ka = 1; + } + + check_dyn_rules(chain, NULL, RESVD_SET, check_ka, 1); + + callout_reset_on(&V_ipfw_timeout, hz, ipfw_dyn_tick, vnetx, 0); + + CURVNET_RESTORE(); +} + + +/* + * Walk thru all dynamic states doing generic maintance: + * 1) free expired states + * 2) free all states based on deleted rule / set + * 3) send keepalives for states if needed + * + * @chain - pointer to current ipfw rules chain + * @rule - delete all states originated by given rule if != NULL + * @set - delete all states originated by any rule in set @set if != RESVD_SET + * @check_ka - perform checking/sending keepalives + * @timer - indicate call from timer routine. + * + * Timer routine must call this function unlocked to permit + * sending keepalives/resizing table. + * + * Others has to call function with IPFW_UH_WLOCK held. + * + * Write lock is needed to ensure that unused parent rules + * are not freed by other instance (see stage 2, 3) + */ +static void +check_dyn_rules(struct ip_fw_chain *chain, struct ip_fw *rule, + int set, int check_ka, int timer) +{ + struct mbuf *m0, *m, *mnext, **mtailp; + struct ip *h; + int i, dyn_count, new_buckets = 0, max_buckets; + int expired = 0, expired_limits = 0, parents = 0, total = 0; + ipfw_dyn_rule *q, *q_prev, *q_next; + ipfw_dyn_rule *exp_head, **exptailp; + ipfw_dyn_rule *exp_lhead, **expltailp; + + KASSERT(V_ipfw_dyn_v != NULL, ("%s: dynamic table not allocated", + __func__)); + + /* Avoid possible LOR */ + KASSERT(!check_ka || timer, ("%s: keepalive check with lock held", + __func__)); + + if (DYN_COUNT == 0) + return; + + /* Expired states */ + exp_head = NULL; + exptailp = &exp_head; + + /* Expired limit states */ + exp_lhead = NULL; + expltailp = &exp_lhead; + /* * We make a chain of packets to go out here -- not deferring * until after we drop the IPFW dynamic rule lock would result @@ -1022,27 +1054,203 @@ static void */ m0 = NULL; mtailp = &m0; - IPFW_DYN_LOCK(); + + /* Protect from hash resizing */ + if (timer != 0) + IPFW_UH_WLOCK(chain); + else { + IPFW_UH_WLOCK_ASSERT(chain); + } + +#define NEXT_RULE() { q_prev = q; q = q->next ; continue; } + + /* Stage 1: perform requested deletion */ for (i = 0 ; i < V_curr_dyn_buckets ; i++) { - for (q = V_ipfw_dyn_v[i] ; q ; q = q->next ) { - if (q->dyn_type == O_LIMIT_PARENT) - continue; - if (TIME_LEQ(q->expire, time_uptime)) - continue; /* too late, rule expired */ + IPFW_BUCK_LOCK(i); + for (q = V_ipfw_dyn_v[i].head, q_prev = q ; q ; ) { + /* account every rule */ + total++; - if (q->id.proto != IPPROTO_TCP) + /* Skip parent rules at all */ + if (q->dyn_type == O_LIMIT_PARENT) { + parents++; + NEXT_RULE(); + } + + /* + * Remove rules which are: + * 1) expired + * 2) created by given rule + * 3) created by any rule in given set + */ + if ((TIME_LEQ(q->expire, time_uptime)) || + ((rule != NULL) && (q->rule == rule)) || + ((set != RESVD_SET) && (q->rule->set == set))) { + /* Unlink q from current list */ + if (q == V_ipfw_dyn_v[i].head) + V_ipfw_dyn_v[i].head = q->next; + else + q_prev->next = q->next; + q->next = NULL; + + /* queue q to expire list */ + if (q->dyn_type != O_LIMIT) { + *exptailp = q; + exptailp = &(*exptailp)->next; + DEB(print_dyn_rule(&q->id, q->dyn_type, + "unlink entry", "left"); + ) + } else { + /* Separate list for limit rules */ + *expltailp = q; + expltailp = &(*expltailp)->next; + expired_limits++; + DEB(print_dyn_rule(&q->id, q->dyn_type, + "unlink limit entry", "left"); + ) + } + + q = q_prev->next; + expired++; continue; - if ( (q->state & BOTH_SYN) != BOTH_SYN) - continue; - if (TIME_LEQ(time_uptime + V_dyn_keepalive_interval, - q->expire)) - continue; /* too early */ + } - mtailp = ipfw_dyn_send_ka(mtailp, q); + /* + * Check if we need to send keepalive: + * we need to ensure if is time to do KA, + * this is established TCP session, and + * expire time is within keepalive interval + */ + if ((check_ka != 0) && (q->id.proto == IPPROTO_TCP) && + ((q->state & BOTH_SYN) == BOTH_SYN) && + (TIME_LEQ(q->expire, time_uptime + + V_dyn_keepalive_interval))) + mtailp = ipfw_dyn_send_ka(mtailp, q); + + NEXT_RULE(); } + IPFW_BUCK_UNLOCK(i); } - IPFW_DYN_UNLOCK(); + /* Stage 2: decrement counters from O_LIMIT parents */ + if (expired_limits != 0) { + /* + * XXX: Note that deleting set with more than one + * heavily-used LIMIT rules can result in overwhelming + * locking due to lack of per-hash value sorting + * + * We should probably think about: + * 1) pre-allocating hash of size, say, + * MAX(16, V_curr_dyn_buckets / 1024) + * 2) checking if expired_limits is large enough + * 3) If yes, init hash (or its part), re-link + * current list and start decrementing procedure in + * each bucket separately + */ + + /* + * Small optimization: do not unlock bucket until + * we see the next item resides in different bucket + */ + if (exp_lhead != NULL) { + i = exp_lhead->parent->bucket; + IPFW_BUCK_LOCK(i); + } + for (q = exp_lhead; q != NULL; q = q->next) { + if (i != q->parent->bucket) { + IPFW_BUCK_UNLOCK(i); + i = q->parent->bucket; + IPFW_BUCK_LOCK(i); + } + + /* Decrease parent refcount */ + q->parent->count--; + } + if (exp_lhead != NULL) + IPFW_BUCK_UNLOCK(i); + } + + /* + * We protectet ourselves from unused parent deletion by + * holding UH write lock. + */ + + /* Stage 3: remove unused parent rules */ + if ((parents != 0) && (expired != 0)) { + for (i = 0 ; i < V_curr_dyn_buckets ; i++) { + IPFW_BUCK_LOCK(i); + for (q = V_ipfw_dyn_v[i].head, q_prev = q ; q ; ) { + if (q->dyn_type != O_LIMIT_PARENT) + NEXT_RULE(); + + if (q->count != 0) + NEXT_RULE(); + + /* Parent rule without consumers */ + + /* Unlink q from current list */ + if (q == V_ipfw_dyn_v[i].head) + V_ipfw_dyn_v[i].head = q->next; + else + q_prev->next = q->next; + q->next = NULL; + + /* Add to expired list */ + *exptailp = q; + exptailp = &(*exptailp)->next; + + DEB(print_dyn_rule(&q->id, q->dyn_type, + "unlink parent entry", "left"); + ) + + expired++; + + q = q->next; + } + IPFW_BUCK_UNLOCK(i); + } + } + +#undef NEXT_RULE + + /* + * Check if we need to resize hash: + * if current number of states exceeds number of buckes in hash, + * grow hash size to the minimum power of 2 which is bigger than + * current states count. Limit hash size by 64k. + */ + max_buckets = (V_dyn_buckets_max > 65536) ? 65536 : V_dyn_buckets_max; + + dyn_count = DYN_COUNT; + + if ((dyn_count > V_curr_dyn_buckets * 2) && (dyn_count < max_buckets)) { + new_buckets = V_curr_dyn_buckets; + while (new_buckets < dyn_count) { + new_buckets *= 2; + + if (new_buckets >= max_buckets) + break; + } + } + + if (timer != 0) + IPFW_UH_WUNLOCK(chain); + + /* Finally delete old states ad limits if any */ + for (q = exp_head; q != NULL; q = q_next) { + q_next = q->next; + uma_zfree(V_ipfw_dyn_rule_zone, q); + } + + for (q = exp_lhead; q != NULL; q = q_next) { + q_next = q->next; + uma_zfree(V_ipfw_dyn_rule_zone, q); + } + + /* The rest code should be called from timer routine only */ + if (timer == 0) + return; + /* Send keepalive packets if any */ for (m = m0; m != NULL; m = mnext) { mnext = m->m_nextpkt; @@ -1055,34 +1263,33 @@ static void ip6_output(m, NULL, NULL, 0, NULL, NULL, NULL); #endif } -done: - callout_reset_on(&V_ipfw_timeout, V_dyn_keepalive_period * hz, - ipfw_tick, vnetx, 0); - CURVNET_RESTORE(); + + /* Run table resize without holding any locks */ + if (new_buckets != 0) + resize_dynamic_table(chain, new_buckets); } +/* + * Deletes all dynamic rules originated by given rule or all rules in + * given set. Specify RESVD_SET to indicate set should not be used. + * @chain - pointer to current ipfw rules chain + * @rule - delete all states originated by given rule if != NULL + * @set - delete all states originated by any rule in set @set if != RESVD_SET + * + * Function has to be called with IPFW_UH_WLOCK held. + */ void -ipfw_dyn_attach(void) +ipfw_expire_dyn_rules(struct ip_fw_chain *chain, struct ip_fw *rule, int set) { - ipfw_dyn_rule_zone = uma_zcreate("IPFW dynamic rule", - sizeof(ipfw_dyn_rule), NULL, NULL, NULL, NULL, - UMA_ALIGN_PTR, 0); - IPFW_DYN_LOCK_INIT(); + check_dyn_rules(chain, rule, set, 0, 0); } void -ipfw_dyn_detach(void) +ipfw_dyn_init(struct ip_fw_chain *chain) { - uma_zdestroy(ipfw_dyn_rule_zone); - IPFW_DYN_LOCK_DESTROY(); -} - -void -ipfw_dyn_init(void) -{ V_ipfw_dyn_v = NULL; - V_dyn_buckets = 256; /* must be power of 2 */ + V_dyn_buckets_max = 256; /* must be power of 2 */ V_curr_dyn_buckets = 256; /* must be power of 2 */ V_dyn_ack_lifetime = 300; @@ -1095,32 +1302,109 @@ void V_dyn_keepalive_interval = 20; V_dyn_keepalive_period = 5; V_dyn_keepalive = 1; /* do send keepalives */ + V_dyn_keepalive = time_uptime; V_dyn_max = 4096; /* max # of dynamic rules */ + + V_ipfw_dyn_rule_zone = uma_zcreate("IPFW dynamic rule", + sizeof(ipfw_dyn_rule), NULL, NULL, NULL, NULL, + UMA_ALIGN_PTR, 0); + + /* Enforce limit on dynamic rules */ + uma_zone_set_max(V_ipfw_dyn_rule_zone, V_dyn_max); + callout_init(&V_ipfw_timeout, CALLOUT_MPSAFE); - callout_reset_on(&V_ipfw_timeout, hz, ipfw_tick, curvnet, 0); + + /* + * This can potentially be done on first dynamic rule + * being added to chain. + */ + resize_dynamic_table(chain, V_curr_dyn_buckets); } void ipfw_dyn_uninit(int pass) { - if (pass == 0) + int i; + + if (pass == 0) { callout_drain(&V_ipfw_timeout); - else { - if (V_ipfw_dyn_v != NULL) - free(V_ipfw_dyn_v, M_IPFW); + return; } + + if (V_ipfw_dyn_v != NULL) { + /* + * Skip deleting all dynamic states - + * uma_zdestroy() does this more efficiently; + */ + + /* Destroy all mutexes */ + for (i = 0 ; i < V_curr_dyn_buckets ; i++) + IPFW_BUCK_LOCK_DESTROY(&V_ipfw_dyn_v[i]); + free(V_ipfw_dyn_v, M_IPFW); + V_ipfw_dyn_v = NULL; + } + + uma_zdestroy(V_ipfw_dyn_rule_zone); } +#ifdef SYSCTL_NODE +/* + * Get/set maximum number of dynamic states in given VNET instance. + */ +static int +sysctl_ipfw_dyn_max(SYSCTL_HANDLER_ARGS) +{ + int error; + unsigned int nstates; + + nstates = V_dyn_max; + + error = sysctl_handle_int(oidp, &nstates, 0, req); + /* Read operation or some error */ + if ((error != 0) || (req->newptr == NULL)) + return (error); + + V_dyn_max = nstates; + uma_zone_set_max(V_ipfw_dyn_rule_zone, V_dyn_max); + + return (0); +} + +/* + * Get current number of dynamic states in given VNET instance. + */ +static int +sysctl_ipfw_dyn_count(SYSCTL_HANDLER_ARGS) +{ + int error; + unsigned int nstates; + + nstates = DYN_COUNT; + + error = sysctl_handle_int(oidp, &nstates, 0, req); + + return (error); +} +#endif + +/* + * Returns number of dynamic rules. + */ int ipfw_dyn_len(void) { + return (V_ipfw_dyn_v == NULL) ? 0 : - (V_dyn_count * sizeof(ipfw_dyn_rule)); + (DYN_COUNT * sizeof(ipfw_dyn_rule)); } +/* + * Fill given buffer with dynamic states. + * IPFW_UH_RLOCK has to be held while calling. + */ void -ipfw_get_dynamic(char **pbp, const char *ep) +ipfw_get_dynamic(struct ip_fw_chain *chain, char **pbp, const char *ep) { ipfw_dyn_rule *p, *last = NULL; char *bp; @@ -1130,9 +1414,11 @@ void return; bp = *pbp; - IPFW_DYN_LOCK(); - for (i = 0 ; i < V_curr_dyn_buckets; i++) - for (p = V_ipfw_dyn_v[i] ; p != NULL; p = p->next) { + IPFW_UH_RLOCK_ASSERT(chain); + + for (i = 0 ; i < V_curr_dyn_buckets; i++) { + IPFW_BUCK_LOCK(i); + for (p = V_ipfw_dyn_v[i].head ; p != NULL; p = p->next) { if (bp + sizeof *p <= ep) { ipfw_dyn_rule *dst = (ipfw_dyn_rule *)bp; @@ -1161,7 +1447,9 @@ void bp += sizeof(ipfw_dyn_rule); } } - IPFW_DYN_UNLOCK(); + IPFW_BUCK_UNLOCK(i); + } + if (last != NULL) /* mark last dynamic rule */ bzero(&last->next, sizeof(last)); *pbp = bp; Index: sys/netpfil/ipfw/ip_fw2.c =================================================================== --- sys/netpfil/ipfw/ip_fw2.c (revision 243526) +++ sys/netpfil/ipfw/ip_fw2.c (working copy) @@ -2046,7 +2046,7 @@ do { \ f->rulenum, f->id); cmd = ACTION_PTR(f); l = f->cmd_len - f->act_ofs; - ipfw_dyn_unlock(); + ipfw_dyn_unlock(q); cmdlen = 0; match = 1; break; @@ -2525,7 +2525,6 @@ ipfw_init(void) { int error = 0; - ipfw_dyn_attach(); /* * Only print out this stuff the first time around, * when called from the sysinit code. @@ -2579,7 +2578,6 @@ ipfw_destroy(void) { ipfw_log_bpf(0); /* uninit */ - ipfw_dyn_detach(); printf("IP firewall unloaded\n"); } @@ -2637,7 +2635,7 @@ vnet_ipfw_init(const void *unused) chain->id = rule->id = 1; IPFW_LOCK_INIT(chain); - ipfw_dyn_init(); + ipfw_dyn_init(chain); /* First set up some values that are compile time options */ V_ipfw_vnet_ready = 1; /* Open for business */ --------------080207080509080105000605-- From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 22:42:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CB47290E for ; Mon, 26 Nov 2012 22:42:20 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 979638FC0C for ; Mon, 26 Nov 2012 22:42:20 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so3192027dad.13 for ; Mon, 26 Nov 2012 14:42:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:user-agent:mime-version :content-type; bh=jlJYvM8okAT9pCg15jpLcXBbP25P9Tdg4mZAG585K7w=; b=qFzKtftt7LRYv2A4No98V8JLBMrBErQYAtPo1Yr7/YQRGg8LBAWMkYTp0k0jvlwcew YrzJAtaCnFbwGXWLEXG/HqznACOkPEjPDs3nEAnaf8g9CV9YGRDPhFpOUCvQmZgG5hUG ELOGhjeOcTPl8i0rxs/YqX8GnlbwsKruj5V7lIxY0g8/JY4KCl9cqNZeK6PvYGbAtAvV 9rkjtqUd9CgWDMum9Hve4MsytNPx1q4Nm3m9U91WLGVoK3wPUpD5Q2xL0YFkzO7M0xpV 3SvE97HFxtgASkbYr7ZNh9U6kULAVhUCPcF7wxxM6srJIPM5/fK9HcK/44H4rg5cUT0l Cd0g== Received: by 10.68.191.10 with SMTP id gu10mr41243446pbc.115.1353969740035; Mon, 26 Nov 2012 14:42:20 -0800 (PST) Received: from c-24-19-191-56.hsd1.wa.comcast.net (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id is3sm9436380pbc.6.2012.11.26.14.42.17 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 26 Nov 2012 14:42:18 -0800 (PST) Date: Mon, 26 Nov 2012 14:42:10 -0800 (PST) From: Garrett Cooper To: freebsd-net@FreeBSD.org Subject: [RFC] Better document net.inet6 sysctls and prune dead sysctls Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII 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, 26 Nov 2012 22:42:21 -0000 Hi all, As noted in a previous thread, I set out to better document the net.inet6 sysctls after having to tweak the knobs to get things to work for TAHI, and this is the resulting draft (so far). I also took the liberty of removing the ip6_rr_prune and icmp6_redirtimeout sysctls because they weren't in use anywhere else in the sys/... portion of the tree. I was wondering if there are any points that should be corrected/clarified before I submit a PR with the resulting patch. Thanks! -Garrett Index: sys/netinet6/in6_proto.c =================================================================== --- sys/netinet6/in6_proto.c (revision 242903) +++ sys/netinet6/in6_proto.c (working copy) @@ -409,8 +409,6 @@ VNET_DEFINE(int, ip6_auto_flowlabel) = 1; VNET_DEFINE(int, ip6_use_deprecated) = 1;/* allow deprecated addr * (RFC2462 5.5.4) */ -VNET_DEFINE(int, ip6_rr_prune) = 5; /* router renumbering prefix - * walk list every 5 sec. */ VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for multicast? */ VNET_DEFINE(int, ip6_v6only) = 1; @@ -443,7 +441,6 @@ /* ICMPV6 parameters */ VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ /* control how to respond to NI queries */ VNET_DEFINE(int, icmp6_nodeinfo) = @@ -515,15 +512,20 @@ } SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, CTLFLAG_RW, - &VNET_NAME(ip6_forwarding), 0, ""); + &VNET_NAME(ip6_forwarding), 0, + "Forward IPv6 packets via node."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_SENDREDIRECTS, redirect, CTLFLAG_RW, - &VNET_NAME(ip6_sendredirects), 0, ""); + &VNET_NAME(ip6_sendredirects), 0, + "Redirect IPv6 packets via node."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFHLIM, hlim, CTLFLAG_RW, - &VNET_NAME(ip6_defhlim), 0, ""); + &VNET_NAME(ip6_defhlim), 0, + "Default hop limit for IPv6 unicast packets."); SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_STATS, stats, CTLFLAG_RW, - &VNET_NAME(ip6stat), ip6stat, ""); + &VNET_NAME(ip6stat), ip6stat, + "IPv6 statistics."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, - CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, + "Maximum number of fragmented packets to process."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, "Default value of per-interface flag for accepting ICMPv6 Router" @@ -535,57 +537,74 @@ "default router list."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_NORBIT_RAIF, norbit_raif, CTLFLAG_RW, &VNET_NAME(ip6_norbit_raif), 0, - "Always set 0 to R flag in ICMPv6 NA messages when accepting RA" - " on the interface."); + "Always set 0 to R flag in ICMPv6 NA messages when accepting RA " + "on the interface."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RFC6204W3, rfc6204w3, CTLFLAG_RW, &VNET_NAME(ip6_rfc6204w3), 0, "Accept the default router list from ICMPv6 RA messages even " "when packet forwarding enabled."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_KEEPFAITH, keepfaith, CTLFLAG_RW, - &VNET_NAME(ip6_keepfaith), 0, ""); + &VNET_NAME(ip6_keepfaith), 0, + ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_LOG_INTERVAL, log_interval, - CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, + "Period for throttling logging for high-traffic IPv6 operations (in " + "seconds)."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_HDRNESTLIMIT, hdrnestlimit, - CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, + "Maximum number of nested header options to process."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DAD_COUNT, dad_count, CTLFLAG_RW, - &VNET_NAME(ip6_dad_count), 0, ""); + &VNET_NAME(ip6_dad_count), 0, + "Number of Duplicate Address Detection attempts to try before " + "disabling interface. Setting the value to 0 disables DAD."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_FLOWLABEL, auto_flowlabel, - CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, + "Automatically attach a flowlabel to IPv6 packets."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFMCASTHLIM, defmcasthlim, - CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, + "Default hop limit for IPv6 multicast packets."); SYSCTL_STRING(_net_inet6_ip6, IPV6CTL_KAME_VERSION, kame_version, CTLFLAG_RD, __KAME_VERSION, 0, ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEPRECATED, use_deprecated, - CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, ""); -SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RR_PRUNE, rr_prune, CTLFLAG_RW, - &VNET_NAME(ip6_rr_prune), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, + "Use deprecated IPv6 support."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USETEMPADDR, use_tempaddr, - CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, + "Use a temporary address when establishing address via SLAAC."); SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPPLTIME, temppltime, CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_preferred_lifetime), 0, - sysctl_ip6_temppltime, "I", ""); + sysctl_ip6_temppltime, "I", + "Preferred lifetime (in seconds) for a temporary address"); SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPVLTIME, tempvltime, CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_valid_lifetime), 0, - sysctl_ip6_tempvltime, "I", ""); + sysctl_ip6_tempvltime, "I", + "Valid lifetime (in seconds) for a temporary address."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_V6ONLY, v6only, CTLFLAG_RW, - &VNET_NAME(ip6_v6only), 0, ""); + &VNET_NAME(ip6_v6only), 0, + "Allow IPv4-mapped IPv6 addresses per RFC 3493."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_LINKLOCAL, auto_linklocal, CTLFLAG_RW, &VNET_NAME(ip6_auto_linklocal), 0, "Default value of per-interface flag for automatically adding an IPv6" " link-local address to interfaces when attached"); SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_RIP6STATS, rip6stats, CTLFLAG_RW, - &VNET_NAME(rip6stat), rip6stat, ""); + &VNET_NAME(rip6stat), rip6stat, + "RIP6 statistics."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_PREFER_TEMPADDR, prefer_tempaddr, - CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, + "Prefer the temporary address assigned when performing NUD."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEFAULTZONE, use_defaultzone, - CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0,""); + CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0, + "Use the default scope zone if not explicitly provided."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGS, maxfrags, CTLFLAG_RW, - &VNET_NAME(ip6_maxfrags), 0, ""); + &VNET_NAME(ip6_maxfrags), 0, + "Maximum number of fragments to hold in the reassembly queue."); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MCAST_PMTU, mcast_pmtu, CTLFLAG_RW, - &VNET_NAME(ip6_mcast_pmtu), 0, ""); + &VNET_NAME(ip6_mcast_pmtu), 0, + "Enable multicast pMTU discovery."); #ifdef IPSTEALTH SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_STEALTH, stealth, CTLFLAG_RW, - &VNET_NAME(ip6stealth), 0, ""); + &VNET_NAME(ip6stealth), 0, + "IPv6 stealth mode. No hop limit decrementation on forwarding."); #endif #ifdef FLOWTABLE @@ -594,35 +613,45 @@ #define V_ip6_output_flowtable_size VNET(ip6_output_flowtable_size) SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, output_flowtable_size, CTLFLAG_RDTUN, - &VNET_NAME(ip6_output_flowtable_size), 2048, - "number of entries in the per-cpu output flow caches"); + &VNET_NAME(ip6_output_flowtable_size), 2048, + "number of entries in the per-cpu output flow caches"); #endif /* net.inet6.icmp6 */ SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRACCEPT, rediraccept, - CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, ""); -SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRTIMEOUT, redirtimeout, - CTLFLAG_RW, &VNET_NAME(icmp6_redirtimeout), 0, ""); + CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, + "Accept and process router redirects."); SYSCTL_VNET_STRUCT(_net_inet6_icmp6, ICMPV6CTL_STATS, stats, CTLFLAG_RW, - &VNET_NAME(icmp6stat), icmp6stat, ""); + &VNET_NAME(icmp6stat), icmp6stat, + "ICMPv6 statistics."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, CTLFLAG_RW, - &VNET_NAME(nd6_prune), 0, ""); + &VNET_NAME(nd6_prune), 0, + "Period (in seconds) for performing nd6 expiration checks of default " + "routes and prefix lists"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DELAY, nd6_delay, CTLFLAG_RW, - &VNET_NAME(nd6_delay), 0, ""); + &VNET_NAME(nd6_delay), 0, + "Delay (in seconds) before performing NUD on stale nodes."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, + "Maximum number of unicast queries to perform via nd6."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MMAXTRIES, nd6_mmaxtries, - CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, + "Maximum number of multicast queries to perform via nd6."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_USELOOPBACK, nd6_useloopback, - CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, + "Use loopback interface for local traffic"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_NODEINFO, nodeinfo, CTLFLAG_RW, - &VNET_NAME(icmp6_nodeinfo), 0, ""); + &VNET_NAME(icmp6_nodeinfo), 0, + "Node information state."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ERRPPSLIMIT, errppslimit, - CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, ""); + CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, + "Packets per second limit for ICMPv6 queries."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MAXNUDHINT, nd6_maxnudhint, - CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, + "Maximum number of upper layer hints."); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DEBUG, nd6_debug, CTLFLAG_RW, &VNET_NAME(nd6_debug), 0, ""); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_ONLINKNSRFC4861, - nd6_onlink_ns_rfc4861, CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), - 0, "Accept 'on-link' nd6 NS in compliance with RFC 4861."); + nd6_onlink_ns_rfc4861, + CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), 0, + "Accept 'on-link' nd6 NS in compliance with RFC 4861."); From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 23:16:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 891AA3BA for ; Mon, 26 Nov 2012 23:16:33 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 1F2338FC12 for ; Mon, 26 Nov 2012 23:16:32 +0000 (UTC) Received: by mail-ee0-f54.google.com with SMTP id c13so8186736eek.13 for ; Mon, 26 Nov 2012 15:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=Kt69pYSllWVlkM5egGZ+qFMSxlsNilNuLz4XsG3iErg=; b=aC7R+xRDxIo4P+lLQq12o7Wcfa2Kv76Z2HUzI8MdT0uYlF9q/EHSKO/byeNcYTqqhp lhBdoaxK5+CszTUIckXBL819+HdGTa3WTQ7HiBAvsIdBw2Oq7Od0UxTRcWbN+uXXtBXb Fzzf8J4gRxSKuT4ntSlYbDGHH72yCg0Ob2T7yOCqEYDwh5YaxObulbVgYzldiZEyxvYA C3EUBxASNVm2+/2zg+GlYP3n1vkZBytsF7hT3Xvyji+MFB3XKOq4X9GAd1tLS1uPO9v+ J6HS3WXkQMuV5HfH2UEbf9Y8m+aLQgoaJMTZZ3jmO/eNxxgEXXqKWlhG4UUIKMKlVNID PZ3Q== MIME-Version: 1.0 Received: by 10.14.216.193 with SMTP id g41mr50912813eep.37.1353971792245; Mon, 26 Nov 2012 15:16:32 -0800 (PST) Received: by 10.14.97.77 with HTTP; Mon, 26 Nov 2012 15:16:31 -0800 (PST) Date: Mon, 26 Nov 2012 15:16:31 -0800 Message-ID: Subject: Network monitoring with FreeBSD From: Kurt Buff To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:16:33 -0000 If this belongs on a different list, please let me know... I've long used ntop, but the current version in ports is missing a feature that I found incredibly useful, and I'm seeking an alternative. I'm running several small FreeBSD 9 boxen monitoring my HP switches on their mirror ports, and ntop 3.x could give the the top 3 talkers when I clicked on a graph of the network load statistics, but under 4.x that no longer seems to be the case, and 5.x isn't in the ports tree yet. I'd love to dive deeper into who is talking, and what traffic is passing on my network, and I'm pretty dedicated to using FreeBSD, as I've not liked any Linux I've ever touched. I've perused ports/net and ports/net-mgmt, and there are a bewildering number of options. If anyone has recommendations, I'd like to hear it. Kurt From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 23:30:01 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5E31FBBB for ; Mon, 26 Nov 2012 23:30: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 420A88FC17 for ; Mon, 26 Nov 2012 23:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAQNU1WD001992 for ; Mon, 26 Nov 2012 23:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAQNU1QP001987; Mon, 26 Nov 2012 23:30:01 GMT (envelope-from gnats) Date: Mon, 26 Nov 2012 23:30:01 GMT Message-Id: <201211262330.qAQNU1QP001987@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Christopher D. Harrison" Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Christopher D. Harrison" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:30:01 -0000 The following reply was made to PR kern/173479; it has been noted by GNATS. From: "Christopher D. Harrison" To: bug-followup@FreeBSD.org, jas@cse.yorku.ca Cc: Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client Date: Mon, 26 Nov 2012 17:23:15 -0600 The same problem also occurs in FreeBSD 9.0 release. -C From owner-freebsd-net@FreeBSD.ORG Mon Nov 26 23:30:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1A26ACBF for ; Mon, 26 Nov 2012 23:30:35 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id DD5108FC08 for ; Mon, 26 Nov 2012 23:30:34 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id bi5so2772067pad.13 for ; Mon, 26 Nov 2012 15:30:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WwmpUYPfucT53ysrHuvtIKebGOrlx43pRnZVjZeVDoQ=; b=to7S0YCVMzKzCR4GM9snYbXUGiec+l0G9i2nSg0d0bzEGrE58vEqfnTrMJ1xo6Slv8 7nzfoiobgL5LJ5Fu4JTRr7QA7ynSqZISvuZHWvF4LBQMBwYgf0yOnYTzEzVE+kN+k9oi rRI8Sc7XeoXPoNbf2UqQHsh1eZwjvkJHrqB0coZBQw2JhEvHQ/cg6jQQKuVHnGuv31ax 5/XJjzr9pF1Bau1g9Z2mdzBRhJggW//5a1rpwIhicKZn3QKDDy82VuRNHgezPN95H1WK AUeFXEmSvt1eVYngeBnFxQQKZOUo4ABfT9FF7/yFJAdYUeVKtR4RlaymtUpPqnN+QObc fkFA== MIME-Version: 1.0 Received: by 10.68.235.71 with SMTP id uk7mr42517100pbc.10.1353972628767; Mon, 26 Nov 2012 15:30:28 -0800 (PST) Received: by 10.68.8.2 with HTTP; Mon, 26 Nov 2012 15:30:28 -0800 (PST) Received: by 10.68.8.2 with HTTP; Mon, 26 Nov 2012 15:30:28 -0800 (PST) In-Reply-To: References: Date: Mon, 26 Nov 2012 18:30:28 -0500 Message-ID: Subject: Re: Network monitoring with FreeBSD From: Kevin Wilcox To: Kurt Buff Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 23:30:35 -0000 On Nov 26, 2012 6:16 PM, "Kurt Buff" wrote: > I'd love to dive deeper into who is talking, and what traffic is > passing on my network, and I'm pretty dedicated to using FreeBSD, as > I've not liked any Linux I've ever touched. I use a mix of cacti and ipAudit (for netflow and per-IP stats; it also provides top-talker information). It's a little aged but it fits many of my needs. kmw From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 00:34:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2316D45 for ; Tue, 27 Nov 2012 00:34:13 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [211.29.132.183]) by mx1.freebsd.org (Postfix) with ESMTP id 54C348FC08 for ; Tue, 27 Nov 2012 00:34:12 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail02.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qAR0Y9An020594 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 11:34:10 +1100 Date: Tue, 27 Nov 2012 11:34:09 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls In-Reply-To: Message-ID: <20121127103538.O1832@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-Cloudmark-Score: 0 X-Optus-Cloudmark-Analysis: v=2.0 cv=fbv1UDsF c=1 sm=1 a=rYZvcZmzkesA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=dgaFysBZQSQA:10 a=mUydJnGCSdSKuuA0hSUA:9 a=CjuIK1q_8ugA:10 a=Kd67w19eVAcCM6Ni:21 a=ZoC2DmuD_hRW0KRI:21 a=bxQHXO5Py4tHmhUgaywp5w==:117 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, 27 Nov 2012 00:34:13 -0000 On Mon, 26 Nov 2012, Garrett Cooper wrote: > As noted in a previous thread, I set out to better document the > net.inet6 sysctls after having to tweak the knobs to get things to work for > TAHI, and this is the resulting draft (so far). I also took the liberty of > removing the ip6_rr_prune and icmp6_redirtimeout sysctls because they weren't > in use anywhere else in the sys/... portion of the tree. I was wondering if > there are any points that should be corrected/clarified before I submit a PR > with the resulting patch. It would be good to fix the style bugs when changing lots. > Index: sys/netinet6/in6_proto.c > =================================================================== > --- sys/netinet6/in6_proto.c (revision 242903) > +++ sys/netinet6/in6_proto.c (working copy) > @@ -443,7 +441,6 @@ > > /* ICMPV6 parameters */ > VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ > -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ > VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ > /* control how to respond to NI queries */ > VNET_DEFINE(int, icmp6_nodeinfo) = > @@ -515,15 +512,20 @@ > } > > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, CTLFLAG_RW, > - &VNET_NAME(ip6_forwarding), 0, ""); > + &VNET_NAME(ip6_forwarding), 0, > + "Forward IPv6 packets via node."); All the sysctl names spell ipv6 without a v. This is hard to fix. This bug is missing in the names of the sysctl numbers, but it is a bug to used named numbers instead of OID_AUTO in code newer than OID_AUTO, and ipv6 is much newer. New style bug in almost every description. Sysctl descriptions are not normally terminated by a ".". Old style bug in almost every ipv6 sysctl. Large SYSCTL declarations are normally normally-indented, with 4-space continuation indents. This rule is broken farily consistenly in ipv6 sysctl. More ivp4 SYSCTL descriptions are actually formatted normally. > @@ -594,35 +613,45 @@ > #define V_ip6_output_flowtable_size > VNET(ip6_output_flowtable_size) > > SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, output_flowtable_size, > CTLFLAG_RDTUN, > - &VNET_NAME(ip6_output_flowtable_size), 2048, > - "number of entries in the per-cpu output flow caches"); > + &VNET_NAME(ip6_output_flowtable_size), 2048, > + "number of entries in the per-cpu output flow caches"); > ... Here the formatting change is backwards (from normal continuation indent to abnormal ipv6 continuation indent. This and some other old sysctl descriptions have differnent style bugs: they are normally terminated (not with a '.'), but are not normally capitalized (with capaitals). > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, > CTLFLAG_RW, Some mailer mangled the formatting (the line isn't too long and shouldn't have been mangled). > - &VNET_NAME(nd6_prune), 0, ""); > + &VNET_NAME(nd6_prune), 0, > + "Period (in seconds) for performing nd6 expiration checks of default > " More mangling by some mailer. > + "routes and prefix lists"); However, the string is too long. The message is obfuscated by splitting it. This keeps the line length short in the source code, but it is still too long in the output. Sysctl descriptions should be no longer than 50 or 60 characters, since the sysctl name will expand the output by 20 or 30 characters. sysctl names longer than 20 or 30 are a larger bug, since they are hard to write as well as hard to read. This sysctl description is normally terminated (not with a "."). > ... > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, > - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); > + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, > + "Maximum number of unicast queries to perform via nd6."); Another type of sysctl misformatting is generated by names that are so verbose that CTLFLAG* cannot be formatted normally (on the first line). I missed earlier instances of these bugs. Statistic on output style in sysctl descriptions: on freefall now: sysctl -da: 3546 lines sysctl -da | grep -v ': *$': 3192 lines [this filters out sysctls with null descriptions. The output is misformatted with a space before the null description] sysctl -nda: 3546 lines sysctl -nda | grep -v '^: *$': 3192 lines [since this 3192 is the same as the number of sysctls with non-null descreiptions, there must be no multi-line descriptions with embedded newlines] sysctl -nda | grep -v '^: *$' | grep -v '^[A-Z]': 1555 lines [most of non-capitalizations are style bugs. The last 1395 of them are automatically generated for device sysctls. This is part of 5 lines of automatically generated spam for device sysctls (descriptions are duplicated ad spamium for %desc, %driver, %location, %pnpinfo and %parent). A few are correct because they are for a proper name or keyword or a number] sysctl -nda | grep -v '^: *$' | grep '\.$': 74 lines [the style bug of terminating with a '.' is uncommon. In a few cases it goes with the larger style bug of a multi-line description] sysctl -nda | grep -v '^: *$' | grep '.... [81 dots]': 11 lines [these lines are too long even without the sysctl names. Abnormal termination is denser than usual in these lines (8 of 11)] sysctl -nda | grep -v '^: *$' | grep '\..*\.': 8 lines [2 of these are for multi-sentence descriptions]. Bruce From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 01:58:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 447E4342 for ; Tue, 27 Nov 2012 01:58:40 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id B59418FC0C for ; Tue, 27 Nov 2012 01:58:39 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so11338452lah.13 for ; Mon, 26 Nov 2012 17:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FOeO223jQ6FkNa/is4HkwSAtiaFnZluN8vNMcbogfGU=; b=KbjrWEPyr/ftPZUuyYYJSOH5xIoq1rrbg/Jqd4y00p6667oT1TwgSAzcbNBYiR1xah gB+Vp4muGjtNNRBtaMP5n8g8+Xcx86o76/+TMqoOm4ijyofR3bjqcI/eOmH7KaYd6A3f CgdsgV/f82Me0Dx1tZ1PCtJxwiZu5xzsEF3BKOHOf24VeYneuGKLaZLH22dm6pKd8pD2 cfibdaWuGNAv9LOLw1IP1tXXB41JN/nWVA1FL4oS7ZVeuDIgJSU5ZvJy8697GqKyj7Sq hXcJsPuqkkv00nqML5x2daKFbmpMEGuOIHAl363LIYuCuWIgCiF5r3nRVCwqgQY0qXrf hpaw== MIME-Version: 1.0 Received: by 10.152.108.37 with SMTP id hh5mr13046915lab.52.1353981518049; Mon, 26 Nov 2012 17:58:38 -0800 (PST) Received: by 10.112.144.101 with HTTP; Mon, 26 Nov 2012 17:58:37 -0800 (PST) In-Reply-To: <20121127103538.O1832@besplex.bde.org> References: <20121127103538.O1832@besplex.bde.org> Date: Mon, 26 Nov 2012 17:58:37 -0800 Message-ID: Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls From: Garrett Cooper To: Bruce Evans 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, 27 Nov 2012 01:58:40 -0000 On Mon, Nov 26, 2012 at 4:34 PM, Bruce Evans wrote: > On Mon, 26 Nov 2012, Garrett Cooper wrote: > >> As noted in a previous thread, I set out to better document the >> net.inet6 sysctls after having to tweak the knobs to get things to work for >> TAHI, and this is the resulting draft (so far). I also took the liberty of >> removing the ip6_rr_prune and icmp6_redirtimeout sysctls because they >> weren't in use anywhere else in the sys/... portion of the tree. I was >> wondering if there are any points that should be corrected/clarified before >> I submit a PR with the resulting patch. > > It would be good to fix the style bugs when changing lots. Awesome feedback Bruce! Could you please submit a PR with all of the generic recommendations you provided so they're added to the FreeBSD dev handbook/style(9)/or another appropriate "public" area and this data won't be lost in the "sands of time"/mailing list archives? I'll modify my patch and resubmit sometime soon. Thanks! -Garrett PS alpine probably was naughty reformatting things when I used ^J. From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 03:19:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 275F7364 for ; Tue, 27 Nov 2012 03:19:25 +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 CADFA8FC0C for ; Tue, 27 Nov 2012 03:19:24 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAAExtFCDaFvO/2dsb2JhbABEDoYauwmCHgEBAQQBAQEgKyALBRYRAwECAQICDRIHAikBCR4IBggHBAEcBIdsDK1DknOBIosVG4FKgUmBEwOIXop2gi2BHI8ogjIwK4FKNQ X-IronPort-AV: E=Sophos;i="4.83,325,1352091600"; d="scan'208";a="2105869" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 26 Nov 2012 22:19:17 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id C3BF2B3F14; Mon, 26 Nov 2012 22:19:17 -0500 (EST) Date: Mon, 26 Nov 2012 22:19:17 -0500 (EST) From: Rick Macklem To: "Christopher D. Harrison" Message-ID: <619707319.854111.1353986357789.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <201211262330.qAQNU1QP001987@freefall.freebsd.org> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] 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: Tue, 27 Nov 2012 03:19:25 -0000 Christopher D. Harrison wrote: > The following reply was made to PR kern/173479; it has been noted by > GNATS. > > From: "Christopher D. Harrison" > To: bug-followup@FreeBSD.org, jas@cse.yorku.ca > Cc: > Subject: Re: kern/173479: [nfs] chown and chgrp operations fail > between FreeBSD > 9.1RC3 NFSv4 server and RH63 NFSv4 client > Date: Mon, 26 Nov 2012 17:23:15 -0600 > > The same problem also occurs in FreeBSD 9.0 release. > -C > In case you didn't see the previous discussions, this happens for Linux 3.3 or later kernels, where the default is to put the uid in a string for the owner and owner_group attributes. RFC-3530, which has not yet been replaced as the RFC for NFSv4.0 does not recommend this. A requirement for client support of this is in an internet draft called rfc3530bis, but this has not become an RFC yet. I think the Linux folks "jumped the gun" when they made this the default. You can change this using a sysctl on the server, so that it uses the @ format recommended by RFC-3530 or you can upgrade to stable/9, which does have client support for the uid in a string. (The "uid in a string" was added mainly to support NFSv4 root mounts for diskless clients.) This PR will be closed when I get home next week and can do so. rick > _______________________________________________ > 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 Nov 27 05:02:59 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1BDEB42F for ; Tue, 27 Nov 2012 05:02:59 +0000 (UTC) (envelope-from harrison@biostat.wisc.edu) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id D92668FC08 for ; Tue, 27 Nov 2012 05:02:58 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0ME400I02OKR6000@smtpauth1.wiscmail.wisc.edu> for freebsd-net@FreeBSD.org; Mon, 26 Nov 2012 22:02:51 -0600 (CST) Received: from seal.biostat.wisc.edu (seal.biostat.wisc.edu [144.92.73.36]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0ME400HIQOKJ6500@smtpauth1.wiscmail.wisc.edu>; Mon, 26 Nov 2012 22:02:43 -0600 (CST) Date: Mon, 26 Nov 2012 22:02:43 -0600 From: "Christopher D. Harrison" Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client In-reply-to: <619707319.854111.1353986357789.JavaMail.root@erie.cs.uoguelph.ca> Sender: harrison@biostat.wisc.edu To: Rick Macklem Message-id: <50B43B63.7040007@biostat.wisc.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=144.92.73.36 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.27.35416, SenderIP=144.92.73.36 References: <619707319.854111.1353986357789.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7 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, 27 Nov 2012 05:02:59 -0000 do you know what that sysctl attr is called? -C On 11/26/12 21:19, Rick Macklem wrote: > Christopher D. Harrison wrote: >> The following reply was made to PR kern/173479; it has been noted by >> GNATS. >> >> From: "Christopher D. Harrison" >> To: bug-followup@FreeBSD.org, jas@cse.yorku.ca >> Cc: >> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail >> between FreeBSD >> 9.1RC3 NFSv4 server and RH63 NFSv4 client >> Date: Mon, 26 Nov 2012 17:23:15 -0600 >> >> The same problem also occurs in FreeBSD 9.0 release. >> -C >> > In case you didn't see the previous discussions, this happens for > Linux 3.3 or later kernels, where the default is to put the uid in > a string for the owner and owner_group attributes. RFC-3530, which > has not yet been replaced as the RFC for NFSv4.0 does not recommend > this. A requirement for client support of this is in an internet > draft called rfc3530bis, but this has not become an RFC yet. > > I think the Linux folks "jumped the gun" when they made this the > default. You can change this using a sysctl on the server, so that > it uses the@ format recommended by RFC-3530 or > you can upgrade to stable/9, which does have client support for > the uid in a string. (The "uid in a string" was added mainly to > support NFSv4 root mounts for diskless clients.) > > This PR will be closed when I get home next week and can do so. > > rick > >> _______________________________________________ >> 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 Nov 27 05:54:47 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 44A3423D; Tue, 27 Nov 2012 05:54:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.64.117]) by mx1.freebsd.org (Postfix) with ESMTP id B6B858FC13; Tue, 27 Nov 2012 05:54:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qAR5sjCN010271; Tue, 27 Nov 2012 09:54:45 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qAR5si3w010270; Tue, 27 Nov 2012 09:54:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 27 Nov 2012 09:54:44 +0400 From: Gleb Smirnoff To: "Alexander V. Chernikov" Subject: Re: [CFT] ipfw SMP-ready dynamic states Message-ID: <20121127055444.GR84121@glebius.int.ru> References: <50A29F57.6090701@yandex-team.ru> <20121114154741.GE29772@nginx.com> <50B3ED9B.1070500@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <50B3ED9B.1070500@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Alexander V. Chernikov" , freebsd-ipfw@FreeBSD.org, Luigi Rizzo , "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, 27 Nov 2012 05:54:47 -0000 On Tue, Nov 27, 2012 at 02:30:51AM +0400, Alexander V. Chernikov wrote: A> On 14.11.2012 19:47, Gleb Smirnoff wrote: A> > On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote: A> > A> So, we can do the following: A> > A> 1) lock increments/decrements via some separate mutex A> > A> 2) do nothing A> > A> 3) take some combined approach: A> > A> > 4) Take it via uma_zone_getcur(ipfw_dyn_rule_zone); A> It acquired zone lock to collect per-cpu item data, but A> uma_zone_set_max() did the trick. A> > A> A> Patch updated: A> * UMA zone is now allocated per-VNET instance Why? This only leads to more waste in allocator. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 09:33:39 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 405D5A90 for ; Tue, 27 Nov 2012 09:33:39 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id F3A8A8FC08 for ; Tue, 27 Nov 2012 09:33:37 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so13872961obc.13 for ; Tue, 27 Nov 2012 01:33:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=qts9SKK64QMM+/gRGzJuSHQrH95G4L1xg3BXh6I5bX0=; b=gC5yjMiVuQ7HgJ+BucL6wZlWNWGouSgyv6cokJ1mHZzpTJBRiGUF8ISYBxHUOjrkDe KbT1SgpVnL90VepegWLowdcW8V+k/zilPaDIcREEbRso4bNh1+hLQ4GhT30i5s2gqs/u f3LmIlxpX80Pw0L4ZcJYpk7PlGawEUUH41uonVrPcDquuL8MVoZ9yzqZGRPbDstJtQq/ aE0pLetfDPdPKniv4pwwcsPlNY13g6hZytbQFw6is6fUZ8vPieI/klap2E6HyNyQlBgx iTRnHvWnj5b7EXV47iIzmIZZfdxF/g9/KgbneQpuFg7k+mGe3DGnrDmof8GZHES58xQi HNSg== MIME-Version: 1.0 Received: by 10.60.19.162 with SMTP id g2mr12246922oee.73.1354008817563; Tue, 27 Nov 2012 01:33:37 -0800 (PST) Received: by 10.60.101.167 with HTTP; Tue, 27 Nov 2012 01:33:37 -0800 (PST) Date: Tue, 27 Nov 2012 04:33:37 -0500 Message-ID: Subject: Ralink RT2860 Driver Code From: Ramanujan Seshadri 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, 27 Nov 2012 09:33:39 -0000 Hello, Can i know how to get the MPDU's aggregated in each AMPDU in a ralink driver code for RT2860. I saw the existing counters of ralink and tried to get some info, but was not very useful. Any help is greatly appreciated. Thanks ram From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 12:32:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 3A44A75F for ; Tue, 27 Nov 2012 12:32:13 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from ffe5.ukr.net (ffe5.ukr.net [195.214.192.21]) by mx1.freebsd.org (Postfix) with ESMTP id D83D08FC08 for ; Tue, 27 Nov 2012 12:32:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Date:Message-Id:From:To:References:In-Reply-To:Subject:Cc:Content-Type:Content-Transfer-Encoding:MIME-Version; bh=j1+K3aSIMlgDCQwGfx4dLcAQsMKyKcCf+kmfMP94Ll8=; b=ILEKX7SaHdavFV9uEVTfFTqdHCeXbVXNLN4mreZuozyepUI85ddZWK57/abixVwgyz8hRyAHNn7brykqmeTVfSJue77MxO4Vgs0ntxT4FXYaHVRqZ5p237qQmceHywYPXWhVhFWjsOII/oRQOaaZfgOh66EptXtlw7OnOzdXy2Q=; Received: from mail by ffe5.ukr.net with local ID 1TdJp9-000JLI-IA ; Tue, 27 Nov 2012 13:59:35 +0200 MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: binary Content-Type: text/plain; charset="windows-1251" Subject: Re: Network monitoring with FreeBSD In-Reply-To: References: To: "Kurt Buff" From: "Vitaliy Tokarenko" X-Mailer: freemail.ukr.net 4.0 Message-Id: <70230.1354017575.14465304679660847104@ffe5.ukr.net> X-Browser: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0 Date: Tue, 27 Nov 2012 13:59:35 +0200 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, 27 Nov 2012 12:32:13 -0000 Try pmacct. This is lightweight and feature-rich tool for accounting and network statistics. http://svnweb.freebsd.org/ports/head/net-mgmt/pmacct/ --- Original message --- From: "Kurt Buff" To: freebsd-net@freebsd.org Date: 27 November 2012, 01:16:45 Subject: Network monitoring with FreeBSD > If this belongs on a different list, please let me know... > > I've long used ntop, but the current version in ports is missing a > feature that I found incredibly useful, and I'm seeking an > alternative. > > I'm running several small FreeBSD 9 boxen monitoring my HP switches on > their mirror ports, and ntop 3.x could give the the top 3 talkers when > I clicked on a graph of the network load statistics, but under 4.x > that no longer seems to be the case, and 5.x isn't in the ports tree > yet. > > I'd love to dive deeper into who is talking, and what traffic is > passing on my network, and I'm pretty dedicated to using FreeBSD, as > I've not liked any Linux I've ever touched. > > I've perused ports/net and ports/net-mgmt, and there are a bewildering > number of options. If anyone has recommendations, I'd like to hear it. > > Kurt > _______________________________________________ > 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 Nov 27 13:56:19 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF17CED9; Tue, 27 Nov 2012 13:56:19 +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 403058FC0C; Tue, 27 Nov 2012 13:56:19 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1TdLhS-000G6r-7h; Tue, 27 Nov 2012 17:59:46 +0400 Message-ID: <50B4C5D3.4070701@FreeBSD.org> Date: Tue, 27 Nov 2012 17:53:23 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120627 Thunderbird/13.0.1 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: [CFT] ipfw SMP-ready dynamic states References: <50A29F57.6090701@yandex-team.ru> <20121114154741.GE29772@nginx.com> <50B3ED9B.1070500@FreeBSD.org> <20121127055444.GR84121@glebius.int.ru> In-Reply-To: <20121127055444.GR84121@glebius.int.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: "Alexander V. Chernikov" , freebsd-ipfw@FreeBSD.org, Luigi Rizzo , "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, 27 Nov 2012 13:56:19 -0000 On 27.11.2012 09:54, Gleb Smirnoff wrote: > On Tue, Nov 27, 2012 at 02:30:51AM +0400, Alexander V. Chernikov wrote: > A> On 14.11.2012 19:47, Gleb Smirnoff wrote: > A> > On Tue, Nov 13, 2012 at 11:28:23PM +0400, Alexander V. Chernikov wrote: > A> > A> So, we can do the following: > A> > A> 1) lock increments/decrements via some separate mutex > A> > A> 2) do nothing > A> > A> 3) take some combined approach: > A> > > A> > 4) Take it via uma_zone_getcur(ipfw_dyn_rule_zone); > A> It acquired zone lock to collect per-cpu item data, but > A> uma_zone_set_max() did the trick. > A> > > A> > A> Patch updated: > A> * UMA zone is now allocated per-VNET instance > > Why? This only leads to more waste in allocator. To be able to enforce state limit per-instance as it currently works. > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 13:56:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C827AFBD for ; Tue, 27 Nov 2012 13:56:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 812B28FC14 for ; Tue, 27 Nov 2012 13:56:57 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAHnFtFCDaFvO/2dsb2JhbABEDoYbuweCHgEBAQMBAQEBICsgCwUWEQMBAgECAg0SBwIpAQkeCAYIBwQBHASHZgYMrWGCPZBOgSKLEQsQgxOBEwOIXop2gi2BHI8ogjJbgUoXHg X-IronPort-AV: E=Sophos;i="4.83,328,1352091600"; d="scan'208";a="1981420" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 27 Nov 2012 08:55:48 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id DD30BB4023; Tue, 27 Nov 2012 08:55:48 -0500 (EST) Date: Tue, 27 Nov 2012 08:55:48 -0500 (EST) From: Rick Macklem To: "Christopher D. Harrison" Message-ID: <283018325.862373.1354024548865.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <50B43B63.7040007@biostat.wisc.edu> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.203] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@FreeBSD.org, Jason Keltz 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, 27 Nov 2012 13:56:57 -0000 Christopher D. Harrison wrote: > do you know what that sysctl attr is called? > -C > I don't recall it and it seems I've deleted his email, but Jason Keltz (which I've cc'd) emailed it to me and hopefully can remember it. rick ps: When I get it this time, I'll write it down in my note book. I'm "old and old fashioned", so that's how I remember stuff;-) > On 11/26/12 21:19, Rick Macklem wrote: > > Christopher D. Harrison wrote: > >> The following reply was made to PR kern/173479; it has been noted > >> by > >> GNATS. > >> > >> From: "Christopher D. Harrison" > >> To: bug-followup@FreeBSD.org, jas@cse.yorku.ca > >> Cc: > >> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail > >> between FreeBSD > >> 9.1RC3 NFSv4 server and RH63 NFSv4 client > >> Date: Mon, 26 Nov 2012 17:23:15 -0600 > >> > >> The same problem also occurs in FreeBSD 9.0 release. > >> -C > >> > > In case you didn't see the previous discussions, this happens for > > Linux 3.3 or later kernels, where the default is to put the uid in > > a string for the owner and owner_group attributes. RFC-3530, which > > has not yet been replaced as the RFC for NFSv4.0 does not recommend > > this. A requirement for client support of this is in an internet > > draft called rfc3530bis, but this has not become an RFC yet. > > > > I think the Linux folks "jumped the gun" when they made this the > > default. You can change this using a sysctl on the server, so that > > it uses the@ format recommended by RFC-3530 or > > you can upgrade to stable/9, which does have client support for > > the uid in a string. (The "uid in a string" was added mainly to > > support NFSv4 root mounts for diskless clients.) > > > > This PR will be closed when I get home next week and can do so. > > > > rick > > > >> _______________________________________________ > >> freebsd-net@freebsd.org mailing list > >> http://lists.freebsd.org/mailman/listinfo/freebsd-net > >> To unsubscribe, send any mail to > >> "freebsd-net-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 14:20:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C2680596 for ; Tue, 27 Nov 2012 14:20:06 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm29-vm3.bullet.mail.ne1.yahoo.com (nm29-vm3.bullet.mail.ne1.yahoo.com [98.138.91.159]) by mx1.freebsd.org (Postfix) with ESMTP id 616BA8FC0C for ; Tue, 27 Nov 2012 14:20:06 +0000 (UTC) Received: from [98.138.90.56] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 14:18:07 -0000 Received: from [98.138.88.238] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 14:18:07 -0000 Received: from [127.0.0.1] by omp1038.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 14:18:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 720201.76171.bm@omp1038.mail.ne1.yahoo.com Received: (qmail 59048 invoked by uid 60001); 27 Nov 2012 14:18:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354025887; bh=cgbMhnyxxtImrv8uB9SeeGc6H/Nq1yCYWYefDPeLxHA=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=gtG2wCCkW66/sw1tdNsCtvaKNeo6dX3dcwGa9nG3cFVW1HpeNH+LhcNVdF3QScgTliH8nOikYNmjmGwMzhszSLGTqBLmagMUZCa3fPoRchhiqiK9f2hNjGq3SRubGLETXtynwoszhGw4cm/7UZzKIq99hp/XSjKM/Ie2E/KNqUw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:MIME-Version:Content-Type; b=nxshANZZouSqFbx0aQoB9WcqbCuGVReDGtQuUAWmj9Ex9ogAEvycc8sup1yIIUEzKT64UR3CFlXTi5T+icTFO34H5FgBXlCqgEnF57+BNbByMkoSCn0BI4RHJTC76dk1G4mkHfr6kWkgTCj1s34gsMTxMzk6E0m7qywSwklYk7Q=; X-YMail-OSG: flWW54cVM1k_qkg2gT24jT4achMZ27YJKFXNAREb_hZDwWg huJVLl7ueJajYQAniLw8PlLP6yENbP01x3YJBIYnxWkfBRRQa_eXfV3PUtBu 6wk29Q3opdMQ38j6dKoQFHRFze0i8izy1xZd9iG2NdhddR6nrIakwrIhDBsD kn.o4xOg4b4J0A0RCnIHQVJnsGLZfU3Itoe9pXe1T_bu75M4BC7OJ68QMegV 89rC9lXPvc8pxL.O78H9dJV6sOW99lUyWwMBBG6lpPVlWqvVYW697QMpUh26 EpjCCqwfwYw6DawO6471u3nc.FSXrhDzOQ33su_3kkzf49bKKDi1IAe.GeWQ 3tc2QCr4h5xS9zGEDwhdiPXPL_MCX9rDwErtqevQvakRX28ltd3_RpKqdgNo RNxzgrYOAcUUFHPji463LsvHJJjCTo7.G0tt5hmrXahIkXrx56HTrX96tYo0 A2voi8IjdEBqonqUT.AapXmlUoybwUsQTkrU7DbW9iTH7iQpRET3n985zCgc 5TbpO2as- Received: from [174.48.128.27] by web121602.mail.ne1.yahoo.com via HTTP; Tue, 27 Nov 2012 06:18:07 PST X-Rocket-MIMEInfo: 001.001, SnVzdCBhIHByb2dyYW1taW5nIG5vdGUsIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3Igc29tZSBjYXNlcyBpZiB0aGUgCnNvZnRjL2FkYXB0ZXIgc3RydWN0dXJlcyBmb3IgbGVtIGFuZCBlbSB3ZXJlIHN5bmNlZCB3aXRoIGFsbCBvZiB0aGUgCmNvbW1vbiBzdHVmZiBhdCB0aGUgdG9wIG9mIHRoZSBzdHJ1Y3R1cmVzLCBzbyB5b3UgY291bGQgYWNjZXNzIHRoZSBkZXYKb3IgaHcgZnJvbSB0aGUgc29mdGMgd2l0aG91dCBoYXZpbmcgdG8ga25vdyB3aGljaCBmbGF2b3Igb2YgZHJpdmVyIGl0CmlzLiBQdXR0aW5nIG4BMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.127.475 Message-ID: <1354025887.50656.YahooMailClassic@web121602.mail.ne1.yahoo.com> Date: Tue, 27 Nov 2012 06:18:07 -0800 (PST) From: Barney Cordoba Subject: regarding em and lem To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: jfvogel@gmail.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: Tue, 27 Nov 2012 14:20:06 -0000 Just a programming note, it would be useful for some cases if the softc/adapter structures for lem and em were synced with all of the common stuff at the top of the structures, so you could access the dev or hw from the softc without having to know which flavor of driver it is. Putting non-common stuff at the end is a good programming practice. It's also not a bad idea to put an identifier in there, such as is_lem, because it's not easy to figure out naturally. BC From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 14:21:56 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0A51A64B for ; Tue, 27 Nov 2012 14:21:56 +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 BB92F8FC0C for ; Tue, 27 Nov 2012 14:21:54 +0000 (UTC) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TdLgX-0002UX-F4; Tue, 27 Nov 2012 14:58:52 +0100 Message-ID: <50B4C714.6080206@gont.com.ar> Date: Tue, 27 Nov 2012 10:58:44 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Net Subject: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts 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, 27 Nov 2012 14:21:56 -0000 Folks, FYI. This is might affect FreeBSD users employing e.g. OpenVPN: . For a project such as OpenVPN, a (portable) fix might be non-trivial. However, I guess FreeBSD might hook some PF rules when establishing the VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is certainly not the most desirable fix, but still probably better than having your supposedly-secured traffic being sent in the clear). P.S.: Please check the corresponding thread (same "Subject") on the tech@openbsd.org mailing-list, since they have some patches for some of these issues... Thanks, -- 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 Nov 27 14:35:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 11F83960 for ; Tue, 27 Nov 2012 14:35:10 +0000 (UTC) (envelope-from seth.mos@dds.nl) Received: from rotring.dds.nl (rotring.dds.nl [85.17.178.138]) by mx1.freebsd.org (Postfix) with ESMTP id BAE1F8FC08 for ; Tue, 27 Nov 2012 14:35:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by rotring.dds.nl (Postfix) with ESMTP id AC2F858D56 for ; Tue, 27 Nov 2012 15:29:41 +0100 (CET) Received: from [10.0.2.53] (edge-pf.coltex.nl [91.227.27.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rotring.dds.nl (Postfix) with ESMTPSA id 8EF7958C29 for ; Tue, 27 Nov 2012 15:29:36 +0100 (CET) Message-ID: <50B4CE50.4060508@dds.nl> Date: Tue, 27 Nov 2012 15:29:36 +0100 From: Seth Mos User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts References: <50B4C714.6080206@gont.com.ar> In-Reply-To: <50B4C714.6080206@gont.com.ar> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.5 at rotring X-Virus-Status: Clean X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 14:35:10 -0000 Op 27-11-2012 14:58, Fernando Gont schreef: > Folks, > > FYI. This is might affect FreeBSD users employing e.g. OpenVPN: > . > > For a project such as OpenVPN, a (portable) fix might be non-trivial. > However, I guess FreeBSD might hook some PF rules when establishing the > VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is > certainly not the most desirable fix, but still probably better than > having your supposedly-secured traffic being sent in the clear). No need for filtering. Just forward the traffic over the tunnel. The newer OpenVPN already supports IPv6 and both servers and clients are actively out in the wild. Even the Android OpenVPN client supports both stacks. Our OpenVPN server for road warriors sends a IPv6 prefix to be used on OpenVPN as well as a IPv4 address. It works well. Regards, Seth From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 14:53:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D680F21A for ; Tue, 27 Nov 2012 14:53:14 +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 912678FC14 for ; Tue, 27 Nov 2012 14:53:14 +0000 (UTC) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TdMWS-0003u7-4e; Tue, 27 Nov 2012 15:52:28 +0100 Message-ID: <50B4D3A5.9090107@gont.com.ar> Date: Tue, 27 Nov 2012 11:52:21 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Seth Mos Subject: Re: VPN traffic leaks in IPv6/IPv4 dual-stack networks/hosts References: <50B4C714.6080206@gont.com.ar> <50B4CE50.4060508@dds.nl> In-Reply-To: <50B4CE50.4060508@dds.nl> 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, 27 Nov 2012 14:53:14 -0000 On 11/27/2012 11:29 AM, Seth Mos wrote: >> >> For a project such as OpenVPN, a (portable) fix might be non-trivial. >> However, I guess FreeBSD might hook some PF rules when establishing the >> VPN tunnel, such that e.g. all v6 traffic is filtered (yes, this is >> certainly not the most desirable fix, but still probably better than >> having your supposedly-secured traffic being sent in the clear). > > No need for filtering. Just forward the traffic over the tunnel. How do you implement that magic? Or, put another way, how does the client behave if you, e.g., get an ICMPv6 Redirect, a more-specific route by means of the Route Information Option or Prefix Information Option in an RA, etc. I discussed this issue with one of the OpenVPN developers, and he noted that they were still vulnerable to this kind of thing. > Our OpenVPN server for road warriors sends a IPv6 prefix to be used on > OpenVPN as well as a IPv4 address. It works well. The questions is: what happens when under attack? (please see above) Cheers, -- 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 Nov 27 15:21:50 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0F7A8E49 for ; Tue, 27 Nov 2012 15:21:50 +0000 (UTC) (envelope-from jas@cse.yorku.ca) Received: from bronze.cs.yorku.ca (bronze.cs.yorku.ca [130.63.95.34]) by mx1.freebsd.org (Postfix) with ESMTP id C89D28FC08 for ; Tue, 27 Nov 2012 15:21:48 +0000 (UTC) Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtp (Exim 4.76) (envelope-from ) id 1TdMJk-00042t-SL; Tue, 27 Nov 2012 09:39:21 -0500 Message-ID: <50B4D098.8030705@cse.yorku.ca> Date: Tue, 27 Nov 2012 09:39:20 -0500 From: Jason Keltz User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:10.0.9) Gecko/20121011 Thunderbird/10.0.9 MIME-Version: 1.0 To: Rick Macklem Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client References: <283018325.862373.1354024548865.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <283018325.862373.1354024548865.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.0 X-Spam-Level: - X-Spam-Report: Content preview: Hi Rick/Christopher, Yes ... Create a file /etc/modprobe.d, say "nfs.conf" and put in it: [...] Content analysis details: (-1.0 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SHORTCIRCUIT Not all rules were run, due to a shortcircuited rule -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP Cc: freebsd-net@FreeBSD.org, "Christopher D. Harrison" 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, 27 Nov 2012 15:21:50 -0000 Hi Rick/Christopher, Yes ... Create a file /etc/modprobe.d, say "nfs.conf" and put in it: options nfs nfs4_disable_idmapping=N ... and the problem will be solved. Jason. On 11/27/2012 08:55 AM, Rick Macklem wrote: > Christopher D. Harrison wrote: >> do you know what that sysctl attr is called? >> -C >> > I don't recall it and it seems I've deleted his email, but Jason Keltz > (which I've cc'd) emailed it to me and hopefully can remember it. > > rick > ps: When I get it this time, I'll write it down in my note book. > I'm "old and old fashioned", so that's how I remember stuff;-) > >> On 11/26/12 21:19, Rick Macklem wrote: >>> Christopher D. Harrison wrote: >>>> The following reply was made to PR kern/173479; it has been noted >>>> by >>>> GNATS. >>>> >>>> From: "Christopher D. Harrison" >>>> To: bug-followup@FreeBSD.org, jas@cse.yorku.ca >>>> Cc: >>>> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail >>>> between FreeBSD >>>> 9.1RC3 NFSv4 server and RH63 NFSv4 client >>>> Date: Mon, 26 Nov 2012 17:23:15 -0600 >>>> >>>> The same problem also occurs in FreeBSD 9.0 release. >>>> -C >>>> >>> In case you didn't see the previous discussions, this happens for >>> Linux 3.3 or later kernels, where the default is to put the uid in >>> a string for the owner and owner_group attributes. RFC-3530, which >>> has not yet been replaced as the RFC for NFSv4.0 does not recommend >>> this. A requirement for client support of this is in an internet >>> draft called rfc3530bis, but this has not become an RFC yet. >>> >>> I think the Linux folks "jumped the gun" when they made this the >>> default. You can change this using a sysctl on the server, so that >>> it uses the@ format recommended by RFC-3530 or >>> you can upgrade to stable/9, which does have client support for >>> the uid in a string. (The "uid in a string" was added mainly to >>> support NFSv4 root mounts for diskless clients.) >>> >>> This PR will be closed when I get home next week and can do so. >>> >>> rick >>> >>>> _______________________________________________ >>>> freebsd-net@freebsd.org mailing list >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>> To unsubscribe, send any mail to >>>> "freebsd-net-unsubscribe@freebsd.org" >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 16:43:10 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E0F23103 for ; Tue, 27 Nov 2012 16:43:09 +0000 (UTC) (envelope-from harrison@biostat.wisc.edu) Received: from adsum.doit.wisc.edu (adsum.doit.wisc.edu [144.92.197.210]) by mx1.freebsd.org (Postfix) with ESMTP id A92738FC14 for ; Tue, 27 Nov 2012 16:43:09 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII; format=flowed Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) id <0ME500308NRWMZ00@smtpauth1.wiscmail.wisc.edu> for freebsd-net@FreeBSD.org; Tue, 27 Nov 2012 10:43:08 -0600 (CST) Received: from seal.biostat.wisc.edu (seal.biostat.wisc.edu [144.92.73.36]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 7u2-7.05 32bit (built Jul 30 2009)) with ESMTPSA id <0ME50036ANRTHI00@smtpauth1.wiscmail.wisc.edu>; Tue, 27 Nov 2012 10:43:06 -0600 (CST) Date: Tue, 27 Nov 2012 10:43:05 -0600 From: "Christopher D. Harrison" Subject: Re: kern/173479: [nfs] chown and chgrp operations fail between FreeBSD 9.1RC3 NFSv4 server and RH63 NFSv4 client In-reply-to: <50B4D098.8030705@cse.yorku.ca> Sender: harrison@biostat.wisc.edu To: Jason Keltz Message-id: <50B4ED99.1070108@biostat.wisc.edu> X-Spam-Report: AuthenticatedSender=yes, SenderIP=144.92.73.36 X-Spam-PmxInfo: Server=avs-15, Version=5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2012.11.27.163615, SenderIP=144.92.73.36 References: <283018325.862373.1354024548865.JavaMail.root@erie.cs.uoguelph.ca> <50B4D098.8030705@cse.yorku.ca> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.7) Gecko/20120825 Thunderbird/10.0.7 Cc: freebsd-net@FreeBSD.org, Rick Macklem 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, 27 Nov 2012 16:43:10 -0000 I will give it a try. Thanks for your quick response!!! -C On 11/27/12 08:39, Jason Keltz wrote: > Hi Rick/Christopher, > > Yes ... > > Create a file /etc/modprobe.d, say "nfs.conf" and put in it: > > options nfs nfs4_disable_idmapping=N > > ... and the problem will be solved. > > Jason. > > On 11/27/2012 08:55 AM, Rick Macklem wrote: >> Christopher D. Harrison wrote: >>> do you know what that sysctl attr is called? >>> -C >>> >> I don't recall it and it seems I've deleted his email, but Jason Keltz >> (which I've cc'd) emailed it to me and hopefully can remember it. >> >> rick >> ps: When I get it this time, I'll write it down in my note book. >> I'm "old and old fashioned", so that's how I remember stuff;-) >> >>> On 11/26/12 21:19, Rick Macklem wrote: >>>> Christopher D. Harrison wrote: >>>>> The following reply was made to PR kern/173479; it has been noted >>>>> by >>>>> GNATS. >>>>> >>>>> From: "Christopher D. Harrison" >>>>> To: bug-followup@FreeBSD.org, jas@cse.yorku.ca >>>>> Cc: >>>>> Subject: Re: kern/173479: [nfs] chown and chgrp operations fail >>>>> between FreeBSD >>>>> 9.1RC3 NFSv4 server and RH63 NFSv4 client >>>>> Date: Mon, 26 Nov 2012 17:23:15 -0600 >>>>> >>>>> The same problem also occurs in FreeBSD 9.0 release. >>>>> -C >>>>> >>>> In case you didn't see the previous discussions, this happens for >>>> Linux 3.3 or later kernels, where the default is to put the uid in >>>> a string for the owner and owner_group attributes. RFC-3530, which >>>> has not yet been replaced as the RFC for NFSv4.0 does not recommend >>>> this. A requirement for client support of this is in an internet >>>> draft called rfc3530bis, but this has not become an RFC yet. >>>> >>>> I think the Linux folks "jumped the gun" when they made this the >>>> default. You can change this using a sysctl on the server, so that >>>> it uses the@ format recommended by RFC-3530 or >>>> you can upgrade to stable/9, which does have client support for >>>> the uid in a string. (The "uid in a string" was added mainly to >>>> support NFSv4 root mounts for diskless clients.) >>>> >>>> This PR will be closed when I get home next week and can do so. >>>> >>>> rick >>>> >>>>> _______________________________________________ >>>>> freebsd-net@freebsd.org mailing list >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>>> To unsubscribe, send any mail to >>>>> "freebsd-net-unsubscribe@freebsd.org" >>> _______________________________________________ >>> freebsd-net@freebsd.org mailing list >>> http://lists.freebsd.org/mailman/listinfo/freebsd-net >>> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 17:00:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EF7240F for ; Tue, 27 Nov 2012 17:00:54 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 27A0F8FC18 for ; Tue, 27 Nov 2012 17:00:53 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so4215700eaa.13 for ; Tue, 27 Nov 2012 09:00:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q1gOnLOD/8fnDuNRlfU2Kqg+m5hmIU13Px2ztdTuWGA=; b=XCl0hB5H+k8rOaGB21D7miF8FgrQ7bMvpCZXLH5VvOyh+zlQ8u086Q+B6bQMCThFPQ pWS6n3tqnqmrTFBgJ0MgSMR3tKO+O8K1KOniK3OgNO1Bq6xoHsTtpZKzZTrR5HZzM44S CyC6Z81FcpaZGVU3M/m02cqvorAkc2MuznrW3qaEWMHFoShuAIz9tMmM1YTcPzxsTZrB KwPhhMwfLStcRfh7CANA/gX1LgJjqI/W91muLkhw2g49cv7kbfIKsINsDtyF5Y7utAG7 iIPNCtbjVf3Fe7w1i/I9ca07PnmcDUjcMXf874MDAl2C9EbN7/TXc8nIsThHhmS+QD03 rOCg== MIME-Version: 1.0 Received: by 10.14.211.135 with SMTP id w7mr60256267eeo.4.1354035652923; Tue, 27 Nov 2012 09:00:52 -0800 (PST) Received: by 10.223.203.195 with HTTP; Tue, 27 Nov 2012 09:00:52 -0800 (PST) In-Reply-To: <70230.1354017575.14465304679660847104@ffe5.ukr.net> References: <70230.1354017575.14465304679660847104@ffe5.ukr.net> Date: Tue, 27 Nov 2012 09:00:52 -0800 Message-ID: Subject: Re: Network monitoring with FreeBSD From: Kurt Buff To: Vitaliy Tokarenko Content-Type: text/plain; charset=UTF-8 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, 27 Nov 2012 17:00:54 -0000 Will take a look - thanks. On Tue, Nov 27, 2012 at 3:59 AM, Vitaliy Tokarenko wrote: > > Try pmacct. This is lightweight and feature-rich tool for accounting and network statistics. > > http://svnweb.freebsd.org/ports/head/net-mgmt/pmacct/ > > --- Original message --- > From: "Kurt Buff" > To: freebsd-net@freebsd.org > Date: 27 November 2012, 01:16:45 > Subject: Network monitoring with FreeBSD > > > > >> If this belongs on a different list, please let me know... >> >> I've long used ntop, but the current version in ports is missing a >> feature that I found incredibly useful, and I'm seeking an >> alternative. >> >> I'm running several small FreeBSD 9 boxen monitoring my HP switches on >> their mirror ports, and ntop 3.x could give the the top 3 talkers when >> I clicked on a graph of the network load statistics, but under 4.x >> that no longer seems to be the case, and 5.x isn't in the ports tree >> yet. >> >> I'd love to dive deeper into who is talking, and what traffic is >> passing on my network, and I'm pretty dedicated to using FreeBSD, as >> I've not liked any Linux I've ever touched. >> >> I've perused ports/net and ports/net-mgmt, and there are a bewildering >> number of options. If anyone has recommendations, I'd like to hear it. >> >> Kurt >> _______________________________________________ >> 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 Nov 27 17:01:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AFFCF4BA for ; Tue, 27 Nov 2012 17:01:45 +0000 (UTC) (envelope-from kurt.buff@gmail.com) Received: from mail-ea0-f182.google.com (mail-ea0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3CBCB8FC16 for ; Tue, 27 Nov 2012 17:01:45 +0000 (UTC) Received: by mail-ea0-f182.google.com with SMTP id a14so4216124eaa.13 for ; Tue, 27 Nov 2012 09:01:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=11VMI60z5RpotGzGtg04K2NUwStGdn3Exxrp2hvoCfI=; b=OLI2VbkG8Ydss/0WrbVgKWQriQ+XCNziL7mwxZZBO6L5EpggsqELrS6O2fqBpwvlwv xtUVSEzqI812U4UP2xVK3lE3zEnCs61WlEXSQOWZpt14YczJW+DPehjV4UzVJstrepJx sdUdtaPYDnm1M79+bmUEUgoM3sRN+lwXiVbgiow0HcueYE+KDPgYsCflRkzDYmnJPhQH Cn/a/x9nWujcjcmglHv3/iQydUBMcyHQdKnH+tGuZQc1ZzWNyzQSFI1YPttfL3ZJfZUS Ef/nf2sWogVQofWhcGe1+Un/P/6nX2gPp2bcgr04XbvKE3tadq40DcJyCP0Kfw9UZfvg 4Pww== MIME-Version: 1.0 Received: by 10.14.177.1 with SMTP id c1mr59888716eem.8.1354035704417; Tue, 27 Nov 2012 09:01:44 -0800 (PST) Received: by 10.223.203.195 with HTTP; Tue, 27 Nov 2012 09:01:44 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 09:01:44 -0800 Message-ID: Subject: Re: Network monitoring with FreeBSD From: Kurt Buff To: Kevin Wilcox Content-Type: text/plain; charset=UTF-8 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, 27 Nov 2012 17:01:45 -0000 On Mon, Nov 26, 2012 at 3:30 PM, Kevin Wilcox wrote: > > On Nov 26, 2012 6:16 PM, "Kurt Buff" wrote: > >> I'd love to dive deeper into who is talking, and what traffic is >> passing on my network, and I'm pretty dedicated to using FreeBSD, as >> I've not liked any Linux I've ever touched. > > I use a mix of cacti and ipAudit (for netflow and per-IP stats; it also > provides top-talker information). It's a little aged but it fits many of my > needs. > > kmw Sorry - I rushed through and didn't reply to the list. Thanks for the suggestion, and I will take a close look at it. Kurt From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 19:11:57 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5B318D8A for ; Tue, 27 Nov 2012 19:11:57 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm10.bullet.mail.ne1.yahoo.com (nm10.bullet.mail.ne1.yahoo.com [98.138.90.73]) by mx1.freebsd.org (Postfix) with ESMTP id 0E9898FC14 for ; Tue, 27 Nov 2012 19:11:56 +0000 (UTC) Received: from [98.138.90.55] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 19:11:48 -0000 Received: from [98.138.226.131] by tm8.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 19:11:48 -0000 Received: from [127.0.0.1] by smtp218.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 19:11:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1354043508; bh=d+IGx8EnaEZMxWpYtjCapZBWhtGcGlOqLhOs4tzXIrs=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=aRo5GNngcI4kUVF0bzwSX2PT3BYjMZM7KFFeo342B09LrvQQbvZhb91ZhML0f7jxRdyXTqny1tjCMXW+RDi6107teARaQvtcBGMoZTjxcbd2qOvvROns2Ekr2O1OYkUHvuDmV8sg53+vm4dMLK7olV4K6t1MWeidoaFhJoqYdfw= X-Yahoo-Newman-Id: 748123.95415.bm@smtp218.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2LutLAYVM1mURkFoXO0AiZQZ6k1BFuoi_JNIFXyPjcll8hV k1OYiFF7YKHGgBue2Z8Nq3Ea4FEzWm637m9RrIXBXf_JMHyBhEzQASy.kQkU _hwZJNuAfX5L7SD9um0v.PVGvkUuo4FA4_OWbA9s4mZfMMUCglyOBFB1dQcR nbKKzmtrnd38nvbE74Yu2A_0J_HHdWBfKxI_ZrUovoBA2riDGj1T.wmeFGgt glC6zl6hX3WZ3sZNK7PFlwAQUob1cOqNXnOJCiVLmFIA9c4m8UN5YjlrQGWD URZnp1lS5._014AED85HiSr36HQuj.gYE1A095BXtZtgCl_DTBH8jQzj1tNA TggpYyHCWIwbW7sGBZ9xC4TY5dH6q4DxXb1laRjJ4LZTrEAn_B2fbuZIiH2S J8hkKm_XfHbakxetAu3seip7cV.rVm3KuS_dI3hAh.jYdGFWR4LZFQn5gV4y l7tWQE5Xs0dgyN1bUmmvZI6SCHhzDeHvVlQTFPjkglHSslvA.618o6g7Xggn jolwRhgIoRjFl1zvgdT2_186At8FVYnFV.g2ZLeOf_9lC2B_NhKMJbQ4SMVq MFumC9cuu9RD6Xzcsqn4y_qrN_4MqWE__ayqHeiwn0i.og9OplnaAIXJGJg- - X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vc0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp218.mail.ne1.yahoo.com with SMTP; 27 Nov 2012 11:11:48 -0800 PST Received: by mail-vc0-f182.google.com with SMTP id fo13so17302473vcb.13 for ; Tue, 27 Nov 2012 11:11:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.226.67 with SMTP id iv3mr25491318vcb.57.1354043507972; Tue, 27 Nov 2012 11:11:47 -0800 (PST) Received: by 10.58.182.72 with HTTP; Tue, 27 Nov 2012 11:11:47 -0800 (PST) Date: Tue, 27 Nov 2012 12:11:47 -0700 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: PseudoCylon To: Ramanujan Seshadri 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, 27 Nov 2012 19:11:57 -0000 > ------------------------------ > > Message: 12 > Date: Tue, 27 Nov 2012 04:33:37 -0500 > From: Ramanujan Seshadri > To: freebsd-net@freebsd.org > Subject: Ralink RT2860 Driver Code > Message-ID: > > Content-Type: text/plain; charset=ISO-8859-1 > > Hello, > Can i know how to get the MPDU's aggregated in each AMPDU in a ralink > driver code for RT2860. I saw the existing counters of ralink and tried to > get some info, but was not very useful. > Any help is greatly appreciated. > https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan What info are you trying to get? AK > Thanks > ram > > > ------------------------------ > > _______________________________________________ > 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" > > End of freebsd-net Digest, Vol 504, Issue 2 > ******************************************* From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 20:23:04 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 15F5A3E5 for ; Tue, 27 Nov 2012 20:23:04 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id C5ADB8FC16 for ; Tue, 27 Nov 2012 20:23:03 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so16508279oag.13 for ; Tue, 27 Nov 2012 12:23:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d262btW3vQwowJyCy3XY+PzmSdhgmd/yMR+iByYQH4Y=; b=LlzV1JpoUpNzL4DW5ksCtAKz7N6xVFd09c03h4oBt2w3LhlHXHwG4t/hgKT+rjI02K nGtw8mnt4cjRpEWwLoCw2qham/fys/nIdqf/Drhn0ShKsBZxBHHzCRmqlk2qci0X9+BD qDQnxqdrVhWFJEdZfJzHVP5x+iH8A3dy2SkLZWdYXXJl/hFxzHd4wAUungReHwsBxIdF uyfQNBEytzvKiWyB70m3HJrRVjnIuNF4N6kq11A0lqhAAZ+9Y7rr/oF+QvNShCUWNhkw U/u9toT6pp3wjd2k8KNrGV2ALsCZsvZVP54h//5zat7Y3SGoZkPz2lFHVGIPUBQhsxVn D9GA== MIME-Version: 1.0 Received: by 10.182.157.82 with SMTP id wk18mr860369obb.26.1354047783258; Tue, 27 Nov 2012 12:23:03 -0800 (PST) Received: by 10.60.101.167 with HTTP; Tue, 27 Nov 2012 12:23:03 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 15:23:03 -0500 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: Ramanujan Seshadri To: PseudoCylon 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: Tue, 27 Nov 2012 20:23:04 -0000 I want to know how many MPDU's are aggregated in each AMPDU transmission. -ram On Tue, Nov 27, 2012 at 2:11 PM, PseudoCylon wrote: > > ------------------------------ > > > > Message: 12 > > Date: Tue, 27 Nov 2012 04:33:37 -0500 > > From: Ramanujan Seshadri > > To: freebsd-net@freebsd.org > > Subject: Ralink RT2860 Driver Code > > Message-ID: > > C58L7YAp+YGk3PZ2VJG9toaKWcBHHi7xsaxth6-KYf0d6xg@mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hello, > > Can i know how to get the MPDU's aggregated in each AMPDU in a ralink > > driver code for RT2860. I saw the existing counters of ralink and tried > to > > get some info, but was not very useful. > > Any help is greatly appreciated. > > > > https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan > > What info are you trying to get? > > > AK > > > Thanks > > ram > > > > > > ------------------------------ > > > > _______________________________________________ > > 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" > > > > End of freebsd-net Digest, Vol 504, Issue 2 > > ******************************************* > From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 22:27:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A3E2D142; Tue, 27 Nov 2012 22:27:21 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id BB0168FC1B; Tue, 27 Nov 2012 22:27:20 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so9830175lbb.13 for ; Tue, 27 Nov 2012 14:27:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=6x4rTu2nHbaSWlFbT7SDCryzG8A5fxpamr9ZK/c2TYk=; b=PFBqzXk7ApITqsBuvpFOBDVx+t5Se7rFA72iaIqx107KcA553PLz5vg+0CfkcNwje+ jx5VFSDvLmbETVG9OYx5PLKujw7UremtAAGPGNzdvaZ0fy3bDbPxbqNE3MI1Z3rYh4aJ vbFjCd0YML3XOx/OlKnfOMq4+WagBoXphrdyVrP4BSVWNgAEsSm1NZbpOWSawP1krqsV +nliSaDYPQEDDDJU649m5juHo9IbkF8yIDD3+8RSFUP/7qAQiy+euZxUnYr90KrUufE8 qBMlSPFoIshG3WIAw3tVv+bI7wIkNqMnzd6MSnBHiZly4FtWY8KXTztsR6EOTHrDXh9H if+A== MIME-Version: 1.0 Received: by 10.152.105.44 with SMTP id gj12mr16234840lab.19.1354055239725; Tue, 27 Nov 2012 14:27:19 -0800 (PST) Received: by 10.112.61.33 with HTTP; Tue, 27 Nov 2012 14:27:19 -0800 (PST) Date: Tue, 27 Nov 2012 17:27:19 -0500 Message-ID: Subject: 9.1-RC3 IGB dropping connections. From: Zaphod Beeblebrox To: FreeBSD Stable , FreeBSD Hackers , FreeBSD Net 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, 27 Nov 2012 22:27:21 -0000 I've got an Intel server motherboard with 4x igb (and 1x em) on it. The motherboard in question is the S3420GPRX and the IGB's show up as: igb0: port 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1bc4000-0xb1bc7fff irq 19 at device 0.0 on pci3 igb0: Using MSIX interrupts with 9 vectors igb0: Ethernet address: 00:1e:67:3a:d5:40 igb0: Bound queue 0 to cpu 0 igb0: Bound queue 1 to cpu 1 igb0: Bound queue 2 to cpu 2 igb0: Bound queue 3 to cpu 3 igb0: Bound queue 4 to cpu 4 igb0: Bound queue 5 to cpu 5 igb0: Bound queue 6 to cpu 6 igb0: Bound queue 7 to cpu 7 ... now... I have this machine (right now) on the local lan with my windows 7 workstation and putty sees the ssh connection as dropped often. I say often --- in that it can happen in a minute or two... it often seems to happen when there is active output going to the window (like a download counter running), but I also say "often" in that... it seems slightly random... but it _is_ incessant... as in very "often." This seems like something that we should ship with 9.1... From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 23:08:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 48C3C8D6; Tue, 27 Nov 2012 23:08:00 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 625738FC14; Tue, 27 Nov 2012 23:07:59 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so12431342lah.13 for ; Tue, 27 Nov 2012 15:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=/+dEsfSBwi9Ec6ZJUK1KL01whzSyaWktFaaIVnSqnyg=; b=iq4txiyF/DKrQVsDII+bBvyvJBvEOCg1xLUGaoSXZ/CtnY7cJ54fil9gWzzWS7xMro /vurX0lye6HVsrKKFDSPFf7U43hvvv0PdPVddozu25lbBnW3uvgK10529ghI7HnQ3uiH ZvDS+gCzR1rKUQ/Dy7WyLsjvTxwHAOtTOObEGtIVLych06je2szQojKoOCwto5ix7Oc6 S0X7BO3WRaMKdypD5+t0bIvA9sGiG7oFz6QeaUEg1wWI65CpHuvh1B1//+724awuWGoY gqzw+54GHivLL9ujHxr/u9+z4ZBWSO2woj0T3IhoBQzqdGMWGj3KQM4VKJ4BbSS7Oa3P 1+tw== MIME-Version: 1.0 Received: by 10.112.103.5 with SMTP id fs5mr7400465lbb.23.1354057676946; Tue, 27 Nov 2012 15:07:56 -0800 (PST) Received: by 10.112.61.33 with HTTP; Tue, 27 Nov 2012 15:07:56 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 18:07:56 -0500 Message-ID: Subject: Re: 9.1-RC3 IGB dropping connections. From: Zaphod Beeblebrox To: FreeBSD Stable , FreeBSD Hackers , FreeBSD Net 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, 27 Nov 2012 23:08:00 -0000 A further update to my problem: it only seems to occur when there is largely traffic "out" ie: the window is active with ... but typing in the window seems to prevent the effect. From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 23:10:40 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A2F13B8F for ; Tue, 27 Nov 2012 23:10:40 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm40-vm2.bullet.mail.ne1.yahoo.com (nm40-vm2.bullet.mail.ne1.yahoo.com [98.138.229.178]) by mx1.freebsd.org (Postfix) with ESMTP id 2F1DB8FC08 for ; Tue, 27 Nov 2012 23:10:40 +0000 (UTC) Received: from [98.138.90.50] by nm40.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 23:07:36 -0000 Received: from [98.138.226.62] by tm3.bullet.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 23:07:36 -0000 Received: from [127.0.0.1] by smtp213.mail.ne1.yahoo.com with NNFMP; 27 Nov 2012 23:07:36 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1354057655; bh=H9OAgMeMljH2jEE6sXFzEdiqLxzRknoR1hISThYHUA0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=4QvqIzMCX3FxOEjnEvlIvnmq+9eK2JUO7OVp5to6LH+jwlTb2zyH6KI87FRfh0LuZO77bAe7WFJu2/J8zrJ1EbrTz4CpqgsEG8f0e3toIH9Tmm0jlKRU/w2wR/S/EAjK4N+h+bQ4THaDhOeLVhPmom+S7w+fS1UwDgiHQlNpb4I= X-Yahoo-Newman-Id: 994524.94061.bm@smtp213.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _e864gcVM1mwpAD_7Xw6jvmAgGy6peQG4GBDoxVM75w._xw DfUONrFTWgq3Ott0s8YIESssyzeWMC2e.T4hj5_t4GcvxTgEnh37EN0UW._g 1c9m0voL9l5pABg069QZLrk96YKfeJQEZ.PqBoA3QUBnWDNI4Q97lwmkBZ58 Vw.2UDer9.Gn_wk8j.gtN1Mj.bdY64Ty8Xvpe9JvQNhc0ZtMtxs0oKeGMx28 SnSKHPwzWwRObAac1OqxWcuKd_yOheCzR0Mq0jS0wn7dLIuE65Y5fqAS8cpb FqPHDl1jzJ6TI0ROLlRkVojxzEJ43bV20bch8xnKr7i5KG.6sEtgmDQgxB_n .5SPX9g_mljT7NlxFBzvC4d0XeU4ow22IxllbHxC2Tk0gowEnQt7bo1j2pzI gIPAZHEf6EEIAl69UU3yfxY8GkybZKVcd6cA2VBli.aKGCBuAirwAlkqfmA0 9RPxaQNpisE0Wj76PJVoj.CIPa9YeQoPD3TGo6Hhoam5nnbYpF9v58Lo9VBm 8n225eeFO8ZtDXWiKcaLZRgItBaJM8saOQB8HjpGB8fMCIsZHQ0HTHZCeTHk XWMCNZgCqIJ3d.p7X2_ymOn082SIVPbybkQkh0Hw7OXzJN_rHPZs1b2gu_w- - X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-ia0-f182.google.com (moonlightakkiy@209.85.210.182 with plain) by smtp213.mail.ne1.yahoo.com with SMTP; 27 Nov 2012 15:07:35 -0800 PST Received: by mail-ia0-f182.google.com with SMTP id x2so11844542iad.13 for ; Tue, 27 Nov 2012 15:07:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.40.229 with SMTP id a5mr20120127igl.59.1354057655502; Tue, 27 Nov 2012 15:07:35 -0800 (PST) Received: by 10.64.44.141 with HTTP; Tue, 27 Nov 2012 15:07:35 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 16:07:35 -0700 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: PseudoCylon To: Ramanujan Seshadri 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, 27 Nov 2012 23:10:40 -0000 On Tue, Nov 27, 2012 at 1:23 PM, Ramanujan Seshadri wrote: > I want to know how many MPDU's are aggregated in each AMPDU transmission. You could use following statistic counters RT2860_TX_AGG_CNT0 to 7 https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_runreg.h#line186 Each 32-bit little-endian read-on-clear register contains 2 16-bit counters (total 16 16-bit counters). counter at offset 0x1720 MPDU count 1 counter at offset 0x1722 MPDU count 2 ... counter at offset 0x173c MPDU count 15 counter at offset 0x173e MPDU count >= 16 These regs are identical on RT2800 and RT2700 (pci/usb). Example (see #if 0 part) https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_run.c#line2493 You can only find out statistical numbers (total Tx counts past X sec). You cannot find out an MPDU count in a particular packet, i.e. an aggregated packet just Tx'd, unless you read the counters on each Tx. AK > > -ram > > > On Tue, Nov 27, 2012 at 2:11 PM, PseudoCylon > wrote: >> >> > ------------------------------ >> > >> > Message: 12 >> > Date: Tue, 27 Nov 2012 04:33:37 -0500 >> > From: Ramanujan Seshadri >> > To: freebsd-net@freebsd.org >> > Subject: Ralink RT2860 Driver Code >> > Message-ID: >> > >> > >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > Hello, >> > Can i know how to get the MPDU's aggregated in each AMPDU in a ralink >> > driver code for RT2860. I saw the existing counters of ralink and tried >> > to >> > get some info, but was not very useful. >> > Any help is greatly appreciated. >> > >> >> https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan >> >> What info are you trying to get? >> >> >> AK >> >> > Thanks >> > ram >> > >> > >> > ------------------------------ >> > >> > _______________________________________________ >> > 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" >> > >> > End of freebsd-net Digest, Vol 504, Issue 2 >> > ******************************************* > > From owner-freebsd-net@FreeBSD.ORG Tue Nov 27 23:15:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 282EFE2D; Tue, 27 Nov 2012 23:15:13 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 93E928FC08; Tue, 27 Nov 2012 23:15:12 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so17614106vcb.13 for ; Tue, 27 Nov 2012 15:15:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d5S50J9057WUI3BvtZmoHtGMbN+ZQQGbwgDv687Z5Ws=; b=S4vdGVOrB00Lr1ni3ktlvze9gqJZDGVnAuu1031ogrkgydafNJ4NZkhwlz8/AI/RT+ Xi7dF2QMQxN2PY6VVGO4KHXCUM+DerpyGmHqJ55nFvf3TxEz9+Pdilqrme1ipTDoLjtG pbRN41Iqoq6fXYcVR+aeIVfiZsfW7C2ZpKd62OCtRLpdwc/IPku0UV6w509UUNuzNJa2 qrCehHFkrssHyOYOda6cRjkiMThRyk3REWefChYCjXI6cQOldJ6aU5ea5fZ4NzVeuH8P 02PiZJGj4VnQs6J8c8scsAR+ZLVU9Fy8ovRuYZoGggsXysmAgPGswvRZ3P3VQT4TVO1l FBAQ== MIME-Version: 1.0 Received: by 10.58.55.198 with SMTP id u6mr27555378vep.35.1354058111603; Tue, 27 Nov 2012 15:15:11 -0800 (PST) Received: by 10.59.3.165 with HTTP; Tue, 27 Nov 2012 15:15:11 -0800 (PST) In-Reply-To: References: Date: Tue, 27 Nov 2012 15:15:11 -0800 Message-ID: Subject: Re: 9.1-RC3 IGB dropping connections. From: Jack Vogel To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:15:13 -0000 Something in your environment, have lots of users with this driver in very demanding environments and I have not been seeing reports of this sort. Jack On Tue, Nov 27, 2012 at 2:27 PM, Zaphod Beeblebrox wrote: > I've got an Intel server motherboard with 4x igb (and 1x em) on it. > The motherboard in question is the S3420GPRX and the IGB's show up as: > > igb0: port > 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1bc4000-0xb1bc7fff irq 19 > at device 0.0 on pci3 > igb0: Using MSIX interrupts with 9 vectors > igb0: Ethernet address: 00:1e:67:3a:d5:40 > igb0: Bound queue 0 to cpu 0 > igb0: Bound queue 1 to cpu 1 > igb0: Bound queue 2 to cpu 2 > igb0: Bound queue 3 to cpu 3 > igb0: Bound queue 4 to cpu 4 > igb0: Bound queue 5 to cpu 5 > igb0: Bound queue 6 to cpu 6 > igb0: Bound queue 7 to cpu 7 > > ... now... I have this machine (right now) on the local lan with my > windows 7 workstation and putty sees the ssh connection as dropped > often. I say often --- in that it can happen in a minute or two... it > often seems to happen when there is active output going to the window > (like a download counter running), but I also say "often" in that... > it seems slightly random... but it _is_ incessant... as in very > "often." > > This seems like something that we should ship with 9.1... > _______________________________________________ > 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 Nov 27 23:19:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 16211363 for ; Tue, 27 Nov 2012 23:19:43 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 72C2D8FC13 for ; Tue, 27 Nov 2012 23:19:42 +0000 (UTC) Received: (qmail 37440 invoked from network); 28 Nov 2012 00:51:15 -0000 Received: from unknown (HELO [62.48.0.94]) ([62.48.0.94]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 28 Nov 2012 00:51:15 -0000 Message-ID: <50B54AE7.3040901@freebsd.org> Date: Wed, 28 Nov 2012 00:21:11 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Zaphod Beeblebrox Subject: Re: 9.1-RC3 IGB dropping connections. References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 23:19:43 -0000 On 27.11.2012 23:27, Zaphod Beeblebrox wrote: > I've got an Intel server motherboard with 4x igb (and 1x em) on it. > The motherboard in question is the S3420GPRX and the IGB's show up as: > > igb0: port > 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1bc4000-0xb1bc7fff irq 19 > at device 0.0 on pci3 > igb0: Using MSIX interrupts with 9 vectors > igb0: Ethernet address: 00:1e:67:3a:d5:40 > igb0: Bound queue 0 to cpu 0 > igb0: Bound queue 1 to cpu 1 > igb0: Bound queue 2 to cpu 2 > igb0: Bound queue 3 to cpu 3 > igb0: Bound queue 4 to cpu 4 > igb0: Bound queue 5 to cpu 5 > igb0: Bound queue 6 to cpu 6 > igb0: Bound queue 7 to cpu 7 > > ... now... I have this machine (right now) on the local lan with my > windows 7 workstation and putty sees the ssh connection as dropped > often. I say often --- in that it can happen in a minute or two... it > often seems to happen when there is active output going to the window > (like a download counter running), but I also say "often" in that... > it seems slightly random... but it _is_ incessant... as in very > "often." r243570 in CURRENT should likely fix this issue. It's only 27 hours old and hasn't been MFC'd yet. > This seems like something that we should ship with 9.1... -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 00:04:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 04FFC14E; Wed, 28 Nov 2012 00:04:37 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id E3B5A8FC12; Wed, 28 Nov 2012 00:04:35 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so9890367lbb.13 for ; Tue, 27 Nov 2012 16:04:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=jApgb7ZMT+nFwY7qUJ1IHjdJUtoyhK5DnSZD4rrknjQ=; b=UzH8D2smXYyEFQhppmULBaWmeCkfaTYwqfyL6/IsT64i+CsGn0pL8O3n6ba7zYER3J Zf3wCvpWatfaUS5CJxIt6Ezr2TiSVEOC58LYGFppHtQ9ZTLVWoHM9BrzGgep1vX19ytH 50an8YN/CL/nEalDvwiyX7/BvZ9C/ntSugtiYaFjgpVf+4+Jtb8KyjWXVMEg82dlUpGa 3Mo8DD0UFDo4BF9PVik1/2fF2IP2x1z5IwXKcF0wYjkt6ikVM5uB9MyrSQptNIVPCL9P zI9o2HJXged/ioqepMVj3CAhk5lsRePXdY1tFj3o6+N30h9l9AHuYgrHovUxrAyTwiH0 X0tw== MIME-Version: 1.0 Received: by 10.112.101.232 with SMTP id fj8mr3665447lbb.83.1354061074686; Tue, 27 Nov 2012 16:04:34 -0800 (PST) Received: by 10.112.61.33 with HTTP; Tue, 27 Nov 2012 16:04:34 -0800 (PST) In-Reply-To: <50B54AE7.3040901@freebsd.org> References: <50B54AE7.3040901@freebsd.org> Date: Tue, 27 Nov 2012 19:04:34 -0500 Message-ID: Subject: Re: 9.1-RC3 IGB dropping connections. From: Zaphod Beeblebrox To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 00:04:37 -0000 To Jack Vogel's comment, this problem only seems to occur on systems that are exceedingly lightly loaded (in this case, not yet in production and I'm the only one using it). On Tue, Nov 27, 2012 at 6:21 PM, Andre Oppermann wrote: > r243570 in CURRENT should likely fix this issue. It's only 27 hours old > and hasn't been MFC'd yet. I'm not sure this addresses what I'm seeing. It's a pause the the traffic in the shell that is "fixed" by causing some traffic on the return channel (watching for the pause --- and then hitting enter a few times seems to fix it). I'd expect that TCP retransmission should take care of this regularly ... but in this case, it doesn't... for whatever reason ... From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 01:18:43 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0DDDDDFB; Wed, 28 Nov 2012 01:18:43 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-vc0-f182.google.com (mail-vc0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6B83F8FC16; Wed, 28 Nov 2012 01:18:42 +0000 (UTC) Received: by mail-vc0-f182.google.com with SMTP id fo13so17722779vcb.13 for ; Tue, 27 Nov 2012 17:18:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G7uEvtoyRtwp/N4FeZkS59lK1Bj+ms2J+BE9pK0JmmI=; b=mfqyr/XnK04dNgV0PHd6t7uK9GXaeVoDZfaArqGHR3Bn0wp7VUq1MFLlVTe1h2lXD3 eXUNsN1CYbK7XPSmJju0Pkw0H+LTUwRhrl44pbtm/Kfpn3d2xY/f2izoaqx/IEjgbb/v o4a/lPLXjUJogHIWsgk3M07M1lFTZ4DnNHFDSFKHarCmkRkqBIg9pqBIeUv3oR8Pn3SK gW5aTtDghPLb4hCqZaelafVcdG65wM+JMxOUT+8WKY1GD7slr90cNAFJmF3hFsgy+5Xp D7KZTuu+28BhWlMxDEn8rA15TH0m70rnHIPm2InzFa/TWW9Kzj1VvJPQSVcAbVnd6qzl djxA== MIME-Version: 1.0 Received: by 10.52.32.229 with SMTP id m5mr23930818vdi.5.1354065521599; Tue, 27 Nov 2012 17:18:41 -0800 (PST) Received: by 10.59.3.165 with HTTP; Tue, 27 Nov 2012 17:18:41 -0800 (PST) In-Reply-To: References: <50B54AE7.3040901@freebsd.org> Date: Tue, 27 Nov 2012 17:18:41 -0800 Message-ID: Subject: Re: 9.1-RC3 IGB dropping connections. From: Jack Vogel To: Zaphod Beeblebrox Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: FreeBSD Hackers , Andre Oppermann , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 01:18:43 -0000 On Tue, Nov 27, 2012 at 4:04 PM, Zaphod Beeblebrox wrote: > To Jack Vogel's comment, this problem only seems to occur on systems > that are exceedingly lightly loaded (in this case, not yet in > production and I'm the only one using it). > > On Tue, Nov 27, 2012 at 6:21 PM, Andre Oppermann > wrote: > > > r243570 in CURRENT should likely fix this issue. It's only 27 hours old > > and hasn't been MFC'd yet. > > I'm not sure this addresses what I'm seeing. It's a pause the the > traffic in the shell that is "fixed" by causing some traffic on the > return channel (watching for the pause --- and then hitting enter a > few times seems to fix it). I'd expect that TCP retransmission should > take care of this regularly ... but in this case, it doesn't... for > whatever reason ... > > You say it drops the connection but show no specifics, may I see the system message file from boot til it happens. Also how about a pciconf -lv while you're at it. Jack From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 02:26:14 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B115D2A3; Wed, 28 Nov 2012 02:26:14 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id 6E5368FC08; Wed, 28 Nov 2012 02:26:14 +0000 (UTC) Received: from [192.168.43.26] (pyroxene.sentex.ca [199.212.134.18]) by smarthost1.sentex.ca (8.14.5/8.14.5) with ESMTP id qAS2Q9j1090272; Tue, 27 Nov 2012 21:26:09 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <50B57632.6050004@sentex.net> Date: Tue, 27 Nov 2012 21:25:54 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Zaphod Beeblebrox Subject: Re: 9.1-RC3 IGB dropping connections. References: In-Reply-To: X-Enigmail-Version: 1.4.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.72 on 64.7.153.18 Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 02:26:14 -0000 On 11/27/2012 5:27 PM, Zaphod Beeblebrox wrote: > I've got an Intel server motherboard with 4x igb (and 1x em) on it. > The motherboard in question is the S3420GPRX and the IGB's show up as: > > igb0: port > 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1bc4000-0xb1bc7fff irq 19 > at device 0.0 on pci3 > igb0: Using MSIX interrupts with 9 vectors > igb0: Ethernet address: 00:1e:67:3a:d5:40 > igb0: Bound queue 0 to cpu 0 > > ... now... I have this machine (right now) on the local lan with my > windows 7 workstation and putty sees the ssh connection as dropped > often. I say often --- in that it can happen in a minute or two... it > often seems to happen when there is active output going to the window > (like a download counter running), but I also say "often" in that... > it seems slightly random... but it _is_ incessant... as in very > "often." > Are you using pf ? Also, did you confirm it is the igb nic and not something more general ? e.g. if you put in a different nic, does the problem go away ? If you are using pf, lets see the rules. ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 02:38:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1629D6CD for ; Wed, 28 Nov 2012 02:38:28 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm34.bullet.mail.ne1.yahoo.com (nm34.bullet.mail.ne1.yahoo.com [98.138.229.27]) by mx1.freebsd.org (Postfix) with ESMTP id B21648FC18 for ; Wed, 28 Nov 2012 02:38:27 +0000 (UTC) Received: from [98.138.226.179] by nm34.bullet.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 02:36:11 -0000 Received: from [98.138.89.253] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 02:36:11 -0000 Received: from [127.0.0.1] by omp1045.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 02:36:11 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 895929.9308.bm@omp1045.mail.ne1.yahoo.com Received: (qmail 66141 invoked by uid 60001); 28 Nov 2012 02:36:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354070171; bh=yWJ0q6LRo4+Mj1EZHNqY+2MIgUnP/Hz1kWT3fQdIYzQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=tPUTM9PU3SUhMuJFHS6ZyU/TOqtv7UBlw7kAHs2dGtBBuTcM/WYHwtAJAcB+8Oy46ehwlmOdj6Hvk6dDWQcHlya9wMA6eFuH/6YT5SHhT3tCgDsn4m7ob0OupAjPi3V/ALIvjEqzWAd90Nte/FIZQN3e/z0C7quXYBmGb1Wyusw= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=dZQ2Kvk7od7dMuWIh5tdHjcr4vR5iMV9yPR09+R0zNPn+AhHRG9b6BOVvei6SBF6DVvKv1QHMlWhjuawk/51O6zXsEP373AMflwI1NR8ZiKZxOPcREGdW4ZLUbaCrIF6Xex83JsdBms5klTd2pB1jiubGmj/i1hX4eoq2GDpIBQ=; X-YMail-OSG: HMid_9YVM1mAsVo0g8ut3mj5pWob12YwQc1RIh8mhE.svZ1 OLs_V9MT4e9WBPaSDb6DEkMpzAWWXz94bB2eCBD7iAghcyp_JfrmgALrMS3Z C0Ap1Gjx1sfsrQqyjd4hya1ufXbBm.y3JVBKv5q.a9pGRbz6X5bef8b8hQe2 rClQtf8IKB8VTua6vQ0x8VViMd7f3TSIovFMsVltnqp5UipTOrGcf_JLuOrX NrkDeeH4ErT7sl5q2Brr3JW_D1MOVfLsGhivWf8v2gyrhx6kzacqTmVnvqW2 DzLc2nA1QjoCDrNElvoDU0bS.T3osNxzqAAzbLdhxyqILfsxxwURcWheKZ2z wHcfu6qX05x8bXmMQp5.7vk6Q00zK.MDY.ATO66a1yPYRbDYTaEjqxT_GKL4 fKBJ2LqMH5PWsNKkwN45DuvlxkHE.vvzKis3cLIeUFneTRmHqmrWEE1Tc9k_ xG_7m5wP5e2fr0L1fpxpPMx2EjuSeDgkJAXGcvcNDVC8lERU.Kn_F2P_uBk6 uDAoZd3Gf7cFX4KczlN9IAEMs5QkWYGhgDd7TRzeOnWgcIGmNfhx.EL0xEAv gD0aTbQON0TA7OuICm_OA5jO4 Received: from [174.48.128.27] by web121603.mail.ne1.yahoo.com via HTTP; Tue, 27 Nov 2012 18:36:11 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gVHVlLCAxMS8yNy8xMiwgWmFwaG9kIEJlZWJsZWJyb3ggPHpiZWVibGVAZ21haWwuY29tPiB3cm90ZToKCj4gRnJvbTogWmFwaG9kIEJlZWJsZWJyb3ggPHpiZWVibGVAZ21haWwuY29tPgo.IFN1YmplY3Q6IFJlOiA5LjEtUkMzIElHQiBkcm9wcGluZyBjb25uZWN0aW9ucy4KPiBUbzogIkFuZHJlIE9wcGVybWFubiIgPGFuZHJlQGZyZWVic2Qub3JnPgo.IENjOiAiRnJlZUJTRCBIYWNrZXJzIiA8ZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPiwgIkZyZWVCU0QgU3RhYmxlIiA8ZnJlZWJzZC0BMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.127.475 Message-ID: <1354070171.39734.YahooMailClassic@web121603.mail.ne1.yahoo.com> Date: Tue, 27 Nov 2012 18:36:11 -0800 (PST) From: Barney Cordoba Subject: Re: 9.1-RC3 IGB dropping connections. To: Andre Oppermann , Zaphod Beeblebrox In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 02:38:28 -0000 =0A=0A--- On Tue, 11/27/12, Zaphod Beeblebrox wrote:=0A= =0A> From: Zaphod Beeblebrox =0A> Subject: Re: 9.1-RC3 I= GB dropping connections.=0A> To: "Andre Oppermann" =0A> = Cc: "FreeBSD Hackers" , "FreeBSD Stable" , "FreeBSD Net" =0A> Date: = Tuesday, November 27, 2012, 7:04 PM=0A> To Jack Vogel's comment, this probl= em=0A> only seems to occur on systems=0A> that are exceedingly lightly load= ed (in this case, not yet=0A> in=0A> production and I'm the only one using = it).=0A> =0A> On Tue, Nov 27, 2012 at 6:21 PM, Andre Oppermann =0A> wrote:=0A> =0A> > r243570 in CURRENT should likely fix this iss= ue.=A0=0A> It's only 27 hours old=0A> > and hasn't been MFC'd yet.=0A> =0A>= I'm not sure this addresses what I'm seeing.=A0 It's a=0A> pause the the= =0A> traffic in the shell that is "fixed" by causing some traffic=0A> on th= e=0A> return channel (watching for the pause --- and then hitting=0A> enter= a=0A> few times seems to fix it).=A0 I'd expect that TCP=0A> retransmissio= n should=0A> take care of this regularly=A0 ... but in this case, it=0A> do= esn't... for=0A> whatever reason ...=0A=0AThe symptoms point to something h= aving to do with kicking=0Athe start/xmit queue. You might want to check th= e if_snd queues in=0Athe timer routine.=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 03:19:19 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E09C932B for ; Wed, 28 Nov 2012 03:19:19 +0000 (UTC) (envelope-from hybraene@host2.merlintechhosting.com) Received: from host2.merlintechhosting.com (host2.merlintechhosting.com [50.28.1.42]) by mx1.freebsd.org (Postfix) with ESMTP id 6F2CB8FC19 for ; Wed, 28 Nov 2012 03:19:19 +0000 (UTC) Received: from hybraene by host2.merlintechhosting.com with local (Exim 4.80) (envelope-from ) id 1TdYB9-0007My-RL for net@freebsd.org; Tue, 27 Nov 2012 22:19:15 -0500 To: net@freebsd.org Subject: Account has been disabled From: Gmail Team Message-Id: Date: Tue, 27 Nov 2012 22:19:15 -0500 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2.merlintechhosting.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [686 686] / [47 12] X-AntiAbuse: Sender Address Domain - host2.merlintechhosting.com X-Get-Message-Sender-Via: host2.merlintechhosting.com: authenticated_id: hybraene/only user confirmed/virtual account not confirmed MIME-Version: 1.0 Content-Type: text/plain X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:19:19 -0000 Account has been disabled You've been redirected to this page from the sign-in page, it means that access to your Google Account is about to be disabled. In most cases, accounts are disabled if we believe you have violated either the Google Terms of Service. new window product-specific Terms of Service (available on the product page), or [1]product-specific policies. new window Your account has not been deleted, your data is still intact, and it is possible to regain access to your account. Click the link to regain access to your account [2]http://support.google.com/accounts/bin/request.py?hl=en&contact_type =disabled2&p= Why Google disables accounts Google wants to ensure that everyone has a chance to safely and securely connect and communicate. To help preserve this environment, Google reserves the right to: Please start by reviewing the relevant Terms of Service. ©2012 Google - [3]Google Home - [4]Terms of Service - [5]Privacy Policy - [6]Help References 1. file://www.google.com/support/accounts/bin/answer.py?answer=147806 2. http://www.lepermisdeconduire.fr/includes/menu%20SAUV/images/mail.google.com.htm 3. http://www.google.com/ 4. https://accounts.google.com/TOS?hl=en 5. http://www.google.com/intl/en/privacy/ 6. http://www.google.com/support/accounts?hl=en From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 03:26:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DA4506AB; Wed, 28 Nov 2012 03:26:57 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-la0-f54.google.com (mail-la0-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id CBF598FC13; Wed, 28 Nov 2012 03:26:56 +0000 (UTC) Received: by mail-la0-f54.google.com with SMTP id j13so12568167lah.13 for ; Tue, 27 Nov 2012 19:26:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FQGyVxOs8Js2WVpAXEm04sxfqILqpAWtaB8YazpaSP4=; b=n+FCqogHGlLNlZ4UDRKtYTi5I1h2lP3NJZeo/EMjDsuamSmfuNRSeu/jHeARqUJ0tE ODqaH81nemelBdgPlwmBcoLnVR3VUWWCS7d55KlSnfp68hZbOkDEa3PVDQHHQwEUjLjk t7DV1XP/avlzELYlQTbF2UmsHotALIgGSO7eNbIfFuTtCULH8xVXW3N/nwsFPU+acrw6 W5MDN2PARQQ4YUIav5M2W+HjkwlQySrwjAiTwE5VpU/DnNrWc+f5hKtZ7Oo7Ww29MC5O TjpT2mSbGfS035WhLSW5k7FAXtr3lGpt5F5GHI8IH5KfYn1qckPa907h+Y6OOp6Ugw9t yECQ== MIME-Version: 1.0 Received: by 10.152.104.50 with SMTP id gb18mr17005798lab.9.1354073215441; Tue, 27 Nov 2012 19:26:55 -0800 (PST) Received: by 10.112.61.33 with HTTP; Tue, 27 Nov 2012 19:26:55 -0800 (PST) In-Reply-To: <50B57632.6050004@sentex.net> References: <50B57632.6050004@sentex.net> Date: Tue, 27 Nov 2012 22:26:55 -0500 Message-ID: Subject: Re: 9.1-RC3 IGB dropping connections. From: Zaphod Beeblebrox To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Hackers , FreeBSD Stable , FreeBSD Net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 03:26:58 -0000 On Tue, Nov 27, 2012 at 9:25 PM, Mike Tancsa wrote: > Are you using pf ? Also, did you confirm it is the igb nic and not > something more general ? e.g. if you put in a different nic, does the > problem go away ? No pf, the motherboard em-driver NIC does not have this problem. In reply to another message, igb1@pci0:3:0:1: class=0x020000 card=0x34f28086 chip=0x10c98086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82576 Gigabit Network Connection' class = network subclass = ethernet Here is /var/log/messages. The IPv6 chatter is something that everything on the network has problems with --- duplicate IPv6 addresses that are not duplicate. Nov 26 12:53:49 ccsw1 newsyslog[1419]: logfile first created Nov 26 12:53:49 ccsw1 syslogd: kernel boot file is /boot/kernel/kernel Nov 26 12:53:49 ccsw1 kernel: Copyright (c) 1992-2012 The FreeBSD Project. Nov 26 12:53:49 ccsw1 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Nov 26 12:53:49 ccsw1 kernel: The Regents of the University of California. All rights reserved. Nov 26 12:53:49 ccsw1 kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Nov 26 12:53:49 ccsw1 kernel: FreeBSD 9.1-RC3 #0 r242324: Tue Oct 30 00:58:57 UTC 2012 Nov 26 12:53:49 ccsw1 kernel: root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Nov 26 12:53:49 ccsw1 kernel: CPU: Intel(R) Xeon(R) CPU X3440 @ 2.53GHz (2533.35-MHz K8-class CPU) Nov 26 12:53:49 ccsw1 kernel: Origin = "GenuineIntel" Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Nov 26 12:53:49 ccsw1 kernel: Features=0xbfebfbff Nov 26 12:53:49 ccsw1 kernel: Features2=0x98e3fd Nov 26 12:53:49 ccsw1 kernel: AMD Features=0x28100800 Nov 26 12:53:49 ccsw1 kernel: AMD Features2=0x1 Nov 26 12:53:49 ccsw1 kernel: TSC: P-state invariant, performance statistics Nov 26 12:53:49 ccsw1 kernel: real memory = 17179869184 (16384 MB) Nov 26 12:53:49 ccsw1 kernel: avail memory = 16458309632 (15695 MB) Nov 26 12:53:49 ccsw1 kernel: Event timer "LAPIC" quality 400 Nov 26 12:53:49 ccsw1 kernel: ACPI APIC Table: Nov 26 12:53:49 ccsw1 kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Nov 26 12:53:49 ccsw1 kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 SMT threads Nov 26 12:53:49 ccsw1 kernel: cpu0 (BSP): APIC ID: 0 Nov 26 12:53:49 ccsw1 kernel: cpu1 (AP): APIC ID: 1 Nov 26 12:53:49 ccsw1 kernel: cpu2 (AP): APIC ID: 2 Nov 26 12:53:49 ccsw1 kernel: cpu3 (AP): APIC ID: 3 Nov 26 12:53:49 ccsw1 kernel: cpu4 (AP): APIC ID: 4 Nov 26 12:53:49 ccsw1 kernel: cpu5 (AP): APIC ID: 5 Nov 26 12:53:49 ccsw1 kernel: cpu6 (AP): APIC ID: 6 Nov 26 12:53:49 ccsw1 kernel: cpu7 (AP): APIC ID: 7 Nov 26 12:53:49 ccsw1 kernel: ioapic0 irqs 0-23 on motherboard Nov 26 12:53:49 ccsw1 kernel: lapic0: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: kbd1 at kbdmux0 Nov 26 12:53:49 ccsw1 kernel: acpi0: on motherboard Nov 26 12:53:49 ccsw1 kernel: acpi0: Power Button (fixed) Nov 26 12:53:49 ccsw1 kernel: cpu0: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu1: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu2: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu3: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu4: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu5: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu6: on acpi0 Nov 26 12:53:49 ccsw1 kernel: cpu7: on acpi0 Nov 26 12:53:49 ccsw1 kernel: atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 Nov 26 12:53:49 ccsw1 kernel: Event timer "RTC" frequency 32768 Hz quality 0 Nov 26 12:53:49 ccsw1 kernel: attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 Nov 26 12:53:49 ccsw1 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Nov 26 12:53:49 ccsw1 kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Nov 26 12:53:49 ccsw1 kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Nov 26 12:53:49 ccsw1 kernel: Timecounter "HPET" frequency 14318180 Hz quality 950 Nov 26 12:53:49 ccsw1 kernel: Event timer "HPET" frequency 14318180 Hz quality 550 Nov 26 12:53:49 ccsw1 kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Nov 26 12:53:49 ccsw1 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 Nov 26 12:53:49 ccsw1 kernel: pcib0: port 0xcf8-0xcff on acpi0 Nov 26 12:53:49 ccsw1 kernel: pci0: on pcib0 Nov 26 12:53:49 ccsw1 kernel: pcib1: irq 16 at device 3.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: pci1: on pcib1 Nov 26 12:53:49 ccsw1 kernel: pcib2: at device 0.0 on pci1 Nov 26 12:53:49 ccsw1 kernel: pci2: on pcib2 Nov 26 12:53:49 ccsw1 kernel: pcib3: at device 2.0 on pci2 Nov 26 12:53:49 ccsw1 kernel: pci3: on pcib3 Nov 26 12:53:49 ccsw1 kernel: igb0: port 0x3020-0x303f mem 0xb1b20000-0xb1b3ffff,0xb1bc4000-0xb1bc7fff irq 19 at device 0.0 on pci3 Nov 26 12:53:49 ccsw1 kernel: igb0: Using MSIX interrupts with 9 vectors Nov 26 12:53:49 ccsw1 kernel: igb0: Ethernet address: 00:1e:67:3a:d5:40 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 0 to cpu 0 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 1 to cpu 1 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 2 to cpu 2 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 3 to cpu 3 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 4 to cpu 4 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 5 to cpu 5 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 6 to cpu 6 Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 7 to cpu 7 Nov 26 12:53:49 ccsw1 kernel: igb1: port 0x3000-0x301f mem 0xb1b00000-0xb1b1ffff,0xb1bc0000-0xb1bc3fff irq 18 at device 0.1 on pci3 Nov 26 12:53:49 ccsw1 kernel: igb1: Using MSIX interrupts with 9 vectors Nov 26 12:53:49 ccsw1 kernel: igb1: Ethernet address: 00:1e:67:3a:d5:41 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 0 to cpu 0 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 1 to cpu 1 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 2 to cpu 2 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 3 to cpu 3 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 4 to cpu 4 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 5 to cpu 5 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 6 to cpu 6 Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 7 to cpu 7 Nov 26 12:53:49 ccsw1 kernel: pcib4: at device 3.0 on pci2 Nov 26 12:53:49 ccsw1 kernel: pci6: on pcib4 Nov 26 12:53:49 ccsw1 kernel: igb2: port 0x2020-0x203f mem 0xb1a20000-0xb1a3ffff,0xb1ac4000-0xb1ac7fff irq 16 at device 0.0 on pci6 Nov 26 12:53:49 ccsw1 kernel: igb2: Using MSIX interrupts with 9 vectors Nov 26 12:53:49 ccsw1 kernel: igb2: Ethernet address: 00:1e:67:3a:d5:42 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 0 to cpu 0 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 1 to cpu 1 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 2 to cpu 2 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 3 to cpu 3 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 4 to cpu 4 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 5 to cpu 5 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 6 to cpu 6 Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 7 to cpu 7 Nov 26 12:53:49 ccsw1 kernel: igb3: port 0x2000-0x201f mem 0xb1a00000-0xb1a1ffff,0xb1ac0000-0xb1ac3fff irq 19 at device 0.1 on pci6 Nov 26 12:53:49 ccsw1 kernel: igb3: Using MSIX interrupts with 9 vectors Nov 26 12:53:49 ccsw1 kernel: igb3: Ethernet address: 00:1e:67:3a:d5:43 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 0 to cpu 0 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 1 to cpu 1 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 2 to cpu 2 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 3 to cpu 3 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 4 to cpu 4 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 5 to cpu 5 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 6 to cpu 6 Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 7 to cpu 7 Nov 26 12:53:49 ccsw1 kernel: pcib5: at device 4.0 on pci2 Nov 26 12:53:49 ccsw1 kernel: pci9: on pcib5 Nov 26 12:53:49 ccsw1 kernel: pcib6: at device 5.0 on pci2 Nov 26 12:53:49 ccsw1 kernel: pci10: on pcib6 Nov 26 12:53:49 ccsw1 kernel: pci0: at device 8.0 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: pci0: at device 8.1 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: pci0: at device 8.2 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: pci0: at device 8.3 (no driver a ttached) Nov 26 12:53:49 ccsw1 kernel: pci0: at device 16.0 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: pci0: at device 16.1 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: ehci0: mem 0xb1c02000-0xb1c023ff irq 21 at device 26.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: usbus0: EHCI version 1.0 Nov 26 12:53:49 ccsw1 kernel: usbus0 on ehci0 Nov 26 12:53:49 ccsw1 kernel: pcib7: irq 16 at device 28.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: pci11: on pcib7 Nov 26 12:53:49 ccsw1 kernel: pcib8: irq 16 at device 28.4 on pci0 Nov 26 12:53:49 ccsw1 kernel: pci12: on pcib8 Nov 26 12:53:49 ccsw1 kernel: em0: port 0x1000-0x101f mem 0xb1900000-0xb191ffff,0xb1920000-0xb1923fff irq 16 at device 0.0 on pci12 Nov 26 12:53:49 ccsw1 kernel: em0: Using MSIX interrupts with 3 vectors Nov 26 12:53:49 ccsw1 kernel: em0: Ethernet address: 00:1e:67:3a:d5:44 Nov 26 12:53:49 ccsw1 kernel: pcib9: irq 18 at device 28.6 on pci0 Nov 26 12:53:49 ccsw1 kernel: pci13: on pcib9 Nov 26 12:53:49 ccsw1 kernel: vgapci0: mem 0xb0000000-0xb0ffffff,0xb1800000-0xb1803fff,0xb1000000-0xb17fffff irq 17 at device 0.0 on pci13 Nov 26 12:53:49 ccsw1 kernel: ehci1: mem 0xb1c01000-0xb1c013ff irq 23 at device 29.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: usbus1: EHCI version 1.0 Nov 26 12:53:49 ccsw1 kernel: usbus1 on ehci1 Nov 26 12:53:49 ccsw1 kernel: pcib10: at device 30.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: pci14: on pcib10 Nov 26 12:53:49 ccsw1 kernel: isab0: at device 31.0 on pci0 Nov 26 12:53:49 ccsw1 kernel: isa0: on isab0 Nov 26 12:53:49 ccsw1 kernel: ahci0: port 0x4048-0x404f,0x4054-0x4057,0x4040-0x4047,0x4050-0x4053,0x4020-0x403f mem 0xb1c00000-0xb1c007ff irq 18 at device 31.2 on pci0 Nov 26 12:53:49 ccsw1 kernel: ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported Nov 26 12:53:49 ccsw1 kernel: ahcich0: at channel 0 on ahci0 Nov 26 12:53:49 ccsw1 kernel: ahcich1: at channel 1 on ahci0 Nov 26 12:53:49 ccsw1 kernel: ahcich2: at channel 2 on ahci0 Nov 26 12:53:49 ccsw1 kernel: ahcich3: at channel 3 on ahci0 Nov 26 12:53:49 ccsw1 kernel: ahcich4: at channel 4 on ahci0 Nov 26 12:53:49 ccsw1 kernel: ahcich5: at channel 5 on ahci0 Nov 26 12:53:49 ccsw1 kernel: pci0: at device 31.3 (no driver attached) Nov 26 12:53:49 ccsw1 kernel: acpi_button0: on acpi0 Nov 26 12:53:49 ccsw1 kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Nov 26 12:53:49 ccsw1 kernel: uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0 Nov 26 12:53:49 ccsw1 kernel: orm0: at iomem 0xc0000-0xc7fff on isa0 Nov 26 12:53:49 ccsw1 kernel: sc0: at flags 0x100 on isa0 Nov 26 12:53:49 ccsw1 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Nov 26 12:53:49 ccsw1 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Nov 26 12:53:49 ccsw1 kernel: ppc0: cannot reserve I/O port range Nov 26 12:53:49 ccsw1 kernel: ctl: CAM Target Layer loaded Nov 26 12:53:49 ccsw1 kernel: est0: on cpu0 Nov 26 12:53:49 ccsw1 kernel: p4tcc0: on cpu0 Nov 26 12:53:49 ccsw1 kernel: est1: on cpu1 Nov 26 12:53:49 ccsw1 kernel: p4tcc1: on cpu1 Nov 26 12:53:49 ccsw1 kernel: est2: on cpu2 Nov 26 12:53:49 ccsw1 kernel: p4tcc2: on cpu2 Nov 26 12:53:49 ccsw1 kernel: est3: on cpu3 Nov 26 12:53:49 ccsw1 kernel: p4tcc3: on cpu3 Nov 26 12:53:49 ccsw1 kernel: est4: on cpu4 Nov 26 12:53:49 ccsw1 kernel: p4tcc4: on cpu4 Nov 26 12:53:49 ccsw1 kernel: est5: on cpu5 Nov 26 12:53:49 ccsw1 kernel: p4tcc5: on cpu5 Nov 26 12:53:49 ccsw1 kernel: est6: on cpu6 Nov 26 12:53:49 ccsw1 kernel: p4tcc6: on cpu6 Nov 26 12:53:49 ccsw1 kernel: est7: on cpu7 Nov 26 12:53:49 ccsw1 kernel: p4tcc7: on cpu7 Nov 26 12:53:49 ccsw1 kernel: ZFS filesystem version 5 Nov 26 12:53:49 ccsw1 kernel: ZFS storage pool version 28 Nov 26 12:53:49 ccsw1 kernel: Timecounters tick every 1.000 msec Nov 26 12:53:49 ccsw1 kernel: usbus0: 480Mbps High Speed USB v2.0 Nov 26 12:53:49 ccsw1 kernel: usbus1: 480Mbps High Speed USB v2.0 Nov 26 12:53:49 ccsw1 kernel: ugen0.1: at usbus0 Nov 26 12:53:49 ccsw1 kernel: uhub0: on usbus0 Nov 26 12:53:49 ccsw1 kernel: ugen1.1: at usbus1 Nov 26 12:53:49 ccsw1 kernel: uhub1: on usbus1 Nov 26 12:53:49 ccsw1 kernel: uhub0: 2 ports with 2 removable, self powered Nov 26 12:53:49 ccsw1 kernel: uhub1: 2 ports with 2 removable, self powered Nov 26 12:53:49 ccsw1 kernel: ugen0.2: at usbus0 Nov 26 12:53:49 ccsw1 kernel: uhub2: on usbus0 Nov 26 12:53:49 ccsw1 kernel: ugen1.2: at usbus1 Nov 26 12:53:49 ccsw1 kernel: uhub3: on usbus1 Nov 26 12:53:49 ccsw1 kernel: uhub2: 6 ports with 6 removable, self powered Nov 26 12:53:49 ccsw1 kernel: uhub3: 8 ports with 8 removable, self powered Nov 26 12:53:49 ccsw1 kernel: ugen0.3: at usbus0 Nov 26 12:53:49 ccsw1 kernel: ukbd0: on usbus0 Nov 26 12:53:49 ccsw1 kernel: kbd0 at ukbd0 Nov 26 12:53:49 ccsw1 kernel: uhid0: <12032003> on usbus0 Nov 26 12:53:49 ccsw1 kernel: ugen1.3: at usbus1 Nov 26 12:53:49 ccsw1 kernel: ukbd1: on usbus1 Nov 26 12:53:49 ccsw1 kernel: kbd2 at ukbd1 Nov 26 12:53:49 ccsw1 kernel: ums0: on usbus1 Nov 26 12:53:49 ccsw1 kernel: ums0: 3 buttons and [Z] coordinates ID=0 Nov 26 12:53:49 ccsw1 kernel: ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 Nov 26 12:53:49 ccsw1 kernel: ada0: ATA-8 SATA 3.x device Nov 26 12:53:49 ccsw1 kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Nov 26 12:53:49 ccsw1 kernel: ada0: Command Queueing enabled Nov 26 12:53:49 ccsw1 kernel: ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) Nov 26 12:53:49 ccsw1 kernel: ada0: Previously was known as ad4 Nov 26 12:53:49 ccsw1 kernel: ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 Nov 26 12:53:49 ccsw1 kernel: ada1: ATA-8 SATA 3.x device Nov 26 12:53:49 ccsw1 kernel: ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) Nov 26 12:53:49 ccsw1 kernel: ada1: Command Queueing enabled Nov 26 12:53:49 ccsw1 kernel: ada1: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) Nov 26 12:53:49 ccsw1 kernel: ada1: Previously was known as ad6 Nov 26 12:53:49 ccsw1 kernel: lapic1: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #1 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic2: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #2 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic7: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #7 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic5: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #5 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic6: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #6 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic3: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #3 Launched! Nov 26 12:53:49 ccsw1 kernel: lapic4: Forcing LINT1 to edge trigger Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #4 Launched! Nov 26 12:53:49 ccsw1 kernel: Timecounter "TSC-low" frequency 9895914 Hz quality 1000 Nov 26 12:58:01 ccsw1 kernel: Trying to mount root from zfs:pool/r1 []... Nov 26 12:58:01 ccsw1 root: /etc/rc: WARNING: Dump device does not exist. Savecore not run. Nov 26 12:58:01 ccsw1 ntpd[1511]: ntpd 4.2.4p5-a (1) Nov 26 12:58:01 ccsw1 ntpd[1512]: bind() fd 22, family AF_INET6, port 123, scope 2, addr fe80::21e:67ff:fe3a:d541, mcast=0 flags=0x11 fails: Can't assign requested address Nov 26 12:58:01 ccsw1 ntpd[1512]: unable to create socket on igb1 (2) for fe80::21e:67ff:fe3a:d541#123 Nov 26 12:58:12 ccsw1 ntpd[1512]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::21e:67ff:fe3a:d541, mcast=0 flags=0x11 fails: Can't assign requested address Nov 26 12:58:12 ccsw1 ntpd[1512]: unable to create socket on igb1 (7) for fe80::21e:67ff:fe3a:d541#123 Nov 26 12:58:18 ccsw1 ntpd[1512]: time reset +0.261195 s Nov 26 12:58:23 ccsw1 sshd[1575]: error: PAM: authentication error for root from 192.168.221.84 Nov 26 13:03:12 ccsw1 ntpd[1512]: bind() fd 27, family AF_INET6, port 123, scope 2, addr fe80::21e:67ff:fe3a:d541, mcast=0 flags=0x11 fails: Can't assign requested address ntpd keeps chattering about the link-local ipv6... but no other messages occur in the log during the exercise. From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 07:34:34 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26EE9D21 for ; Wed, 28 Nov 2012 07:34:34 +0000 (UTC) (envelope-from hunreal@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id 76E078FC13 for ; Wed, 28 Nov 2012 07:34:33 +0000 (UTC) Received: by mail-lb0-f182.google.com with SMTP id go10so10126756lbb.13 for ; Tue, 27 Nov 2012 23:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lXh4wtTP8hIGBse1ILlRqUMWYRuGRZgv9AxUWDLC5XY=; b=wTe9EfYAoft/4OL8qpyGRn8CPl6G3DDAjFefWd2qHuZkewO/SjvuiebdQ8pMWvNFTS UYCcEdutUzK16UmpoBuL32zr3DnLoM3YK8UAsSBwxPoclXj5ctdBpnL3iPGC++VJqDy+ 5O3zqPe2gbzI/Wmu+1Y77TOjB2HVyapR391LEvGfbcB+mWzB08aQIw0KBAJb/3BKpk0C Afaro/fD66yL3+C+VsjB65txoyugGhm+NaHIKvfQjFIsFlDJcZQrYjL5DZrwxMsgVkRl NAmT/C3ms7n4C3wMtlYI88xQ1LqiZ15PupZnRzVF6/BTkY4sRzzIVCXzgmGMG0mQiKc4 lbFg== MIME-Version: 1.0 Received: by 10.152.111.68 with SMTP id ig4mr17330995lab.50.1354088066116; Tue, 27 Nov 2012 23:34:26 -0800 (PST) Received: by 10.114.23.170 with HTTP; Tue, 27 Nov 2012 23:34:26 -0800 (PST) Date: Wed, 28 Nov 2012 15:34:26 +0800 Message-ID: Subject: traceroute issue on gif tunnel with ipsec From: hshh To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 07:34:34 -0000 Hi all I setup 2 networks connected with gif tunnel. network1(172.16.0.0/24 )<->server1(172.16.0.254)<-gif->server2(10.0.0.254)<->network2(10.0.0.0/24) Servers are running FreeBSD 9.0-RELEASE. If I only setup ipip tunnel without IPSEC, the traceroute works correctly. Proper result of traceroute from network 1 to network 2 1 <1 ms <1 ms <1 ms 172.16.0.254 2 100 ms 100 ms 100 ms 10.0.0.254 3 100 ms 100 ms 100 ms 10.0.0.1 If I enable IPSEC for gif tunnel, traceroute result is, 1 <1 ms <1 ms <1 ms 172.16.0.254 2 * * * Request timed out. 3 100 ms 100 ms 100 ms 10.0.0.1 I also tried IPSEC transport and tunnel mode, but no help. Here is ipsec.conf spdflush; spdadd 172.16.0.254/32 10.0.0.254/32 ipencap -P out ipsec esp/transport//require; spdadd 10.0.0.254/32 172.16.0.254/32 ipencap -P in ipsec esp/transport//require; flush; add 172.16.0.254 10.0.0.254 esp 10001 -E blowfish-cbc "123456"; add 10.0.0.254 172.16.0.254 esp 10002 -E blowfish-cbc "123456"; It also effects my 6in4 tunnel, traceroute6 not works either. Any solution for this? From owner-freebsd-net@FreeBSD.ORG Wed Nov 28 14:00:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E6CBCA72 for ; Wed, 28 Nov 2012 14:00:12 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from nm5-vm3.bullet.mail.ne1.yahoo.com (nm5-vm3.bullet.mail.ne1.yahoo.com [98.138.91.135]) by mx1.freebsd.org (Postfix) with ESMTP id 921808FC15 for ; Wed, 28 Nov 2012 14:00:12 +0000 (UTC) Received: from [98.138.226.179] by nm5.bullet.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 14:00:06 -0000 Received: from [98.138.88.235] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 14:00:06 -0000 Received: from [127.0.0.1] by omp1035.mail.ne1.yahoo.com with NNFMP; 28 Nov 2012 14:00:06 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 127719.77969.bm@omp1035.mail.ne1.yahoo.com Received: (qmail 45656 invoked by uid 60001); 28 Nov 2012 14:00:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1354111205; bh=c0B/H3VVD2U2dByzudiziDYF6Ik1VBJh/XkzXAO0OqI=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GpfAdhk8OfDVlb8zHVzpPVWG+Zbq/DaCpzpFtNBzMtFGlpVwzKJKEfTfn6q3RpoCteC0MwwYqUYRT/OiNqfnzXep/MIKdDLf6D5K67j1YuiLU/kCAAJy8igWeo8hGctfYpKfqB7xgAiOA6y/yvN59pQxQ+xh+H/arbiWkk4iKBc= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=QzVFsEH9ZwH8KGjeq5xsMZ4OFuHio4sI4iGFZOshqJ1R1AR97NUQdCgF81NN926EOkTq76JRU+z3fY5+6ZEpBhGbN/4Qj+78+/XJGurUXdeYEprFW9lizjvc+QYy2XaTRPKXyulijRmBaMiakyop2n14paeG6wW+7Al7cg11aNw=; X-YMail-OSG: xB80Qs4VM1lU5Mzl.n.gNSmGidkKSt1B3bsyebFgO0KOmBO SOIK58gYvFPA55TH.EDf9kjS.R2ZVjAZr1eM.CtDa1O4k7qPVj4JAhsaUksb HTO0V89xoql83ow2IwMDTHd6NKCebDxHIoG81CUtkMHlf406jAwEa6QxF0CK i7KfFX.VuEnUqbWI2Hqm2Ct0OSexbwvgZjdfCZ14tlpLvlJpbn6piEHc4cAS LJXtsJgMAD9l0ZrAfz1Zqbzt9XsNLk7H9LBGWZq5xpQPnhbNN79ZD4121U4A LgqRM9T9wGI4XEGZHfg0CZx5S5C1SbbH6pHtFi0xYHLkFh1e61sRe_Etiaa. 43dwssF0NUFSccrpqIFcrM9ssw0fzth8jzHCCKJg4s5GU_7BzoMFNFAYHXTW TLaEpI6Zf84LfZw8MGdBJYHkPsuRoY0y0VXds1l8tuP2xNWrxGGBlVzn40Ks 0fwSZpf3WuGjB8NMm_qdFt9oLFV6SErnn9ut7WfAGR0dDlz7VKnmwdob.84p wa1yyk_OYFg8cRnc1gTOvkRaMscQdtsotM9al.nqK38PkXAqLvIWoPvYHyRz p1wS3CtRGWtonu.3lZPncCOPQ Received: from [174.48.128.27] by web121604.mail.ne1.yahoo.com via HTTP; Wed, 28 Nov 2012 06:00:05 PST X-Rocket-MIMEInfo: 001.001, CgotLS0gT24gVHVlLCAxMS8yNy8xMiwgWmFwaG9kIEJlZWJsZWJyb3ggPHpiZWVibGVAZ21haWwuY29tPiB3cm90ZToKCj4gRnJvbTogWmFwaG9kIEJlZWJsZWJyb3ggPHpiZWVibGVAZ21haWwuY29tPgo.IFN1YmplY3Q6IFJlOiA5LjEtUkMzIElHQiBkcm9wcGluZyBjb25uZWN0aW9ucy4KPiBUbzogIk1pa2UgVGFuY3NhIiA8bWlrZUBzZW50ZXgubmV0Pgo.IENjOiAiRnJlZUJTRCBIYWNrZXJzIiA8ZnJlZWJzZC1oYWNrZXJzQGZyZWVic2Qub3JnPiwgIkZyZWVCU0QgU3RhYmxlIiA8ZnJlZWJzZC1zdGFibGUBMAEBAQE- X-Mailer: YahooMailClassic/15.0.8 YahooMailWebService/0.8.127.475 Message-ID: <1354111205.35836.YahooMailClassic@web121604.mail.ne1.yahoo.com> Date: Wed, 28 Nov 2012 06:00:05 -0800 (PST) From: Barney Cordoba Subject: Re: 9.1-RC3 IGB dropping connections. To: Zaphod Beeblebrox In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 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, 28 Nov 2012 14:00:13 -0000 =0A=0A--- On Tue, 11/27/12, Zaphod Beeblebrox wrote:=0A= =0A> From: Zaphod Beeblebrox =0A> Subject: Re: 9.1-RC3 I= GB dropping connections.=0A> To: "Mike Tancsa" =0A> Cc: "F= reeBSD Hackers" , "FreeBSD Stable" , "FreeBSD Net" =0A> Date: Tuesda= y, November 27, 2012, 10:26 PM=0A> On Tue, Nov 27, 2012 at 9:25 PM, Mike=0A= > Tancsa =0A> wrote:=0A> =0A> > Are you using pf ? Also, d= id you confirm it is the igb=0A> nic and not=0A> > something more general ?= e.g. if you put in a different=0A> nic, does the=0A> > problem go away ?= =0A> =0A> No pf, the motherboard em-driver NIC does not have this=0A> probl= em.=0A> =0A> In reply to another message,=0A> =0A> igb1@pci0:3:0:1:=A0 =A0 = =A0 =A0 class=3D0x020000=0A> card=3D0x34f28086 chip=3D0x10c98086=0A> rev=3D= 0x01 hdr=3D0x00=0A> =A0 =A0 vendor=A0 =A0=A0=A0=3D 'Intel=0A> Corporation'= =0A> =A0 =A0 device=A0 =A0=A0=A0=3D '82576=0A> Gigabit Network Connection'= =0A> =A0 =A0 class=A0 =A0 =A0 =3D network=0A> =A0 =A0 subclass=A0=A0=A0=3D = ethernet=0A> =0A> Here is /var/log/messages.=A0 The IPv6 chatter is=0A> som= ething that=0A> everything on the network has problems with --- duplicate= =0A> IPv6=0A> addresses that are not duplicate.=0A> =0A> Nov 26 12:53:49 cc= sw1 newsyslog[1419]: logfile first=0A> created=0A> Nov 26 12:53:49 ccsw1 sy= slogd: kernel boot file is=0A> /boot/kernel/kernel=0A> Nov 26 12:53:49 ccsw= 1 kernel: Copyright (c) 1992-2012 The=0A> FreeBSD Project.=0A> Nov 26 12:53= :49 ccsw1 kernel: Copyright (c) 1979, 1980,=0A> 1983, 1986,=0A> 1988, 1989,= 1991, 1992, 1993, 1994=0A> Nov 26 12:53:49 ccsw1 kernel: The Regents of th= e University=0A> of=0A> California. All rights reserved.=0A> Nov 26 12:53:4= 9 ccsw1 kernel: FreeBSD is a registered=0A> trademark of The=0A> FreeBSD Fo= undation.=0A> Nov 26 12:53:49 ccsw1 kernel: FreeBSD 9.1-RC3 #0 r242324:=0A>= Tue Oct 30=0A> 00:58:57 UTC 2012=0A> Nov 26 12:53:49 ccsw1 kernel:=0A> roo= t@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=0A> amd64=0A> Nov 26= 12:53:49 ccsw1 kernel: CPU: Intel(R) Xeon(R) CPU=0A> X3440=A0 @ 2.53GHz (2= 533.35-MHz K8-class CPU)=0A> Nov 26 12:53:49 ccsw1 kernel: Origin =3D "Genu= ineIntel"=A0=0A> Id =3D 0x106e5=0A> Family =3D 6=A0 Model =3D 1e=A0 Steppin= g =3D 5=0A> Nov 26 12:53:49 ccsw1 kernel:=0A> Features=3D0xbfebfbff=0A> Nov 26 12:53:49 ccsw1 kernel:= =0A> Features2=3D0x98e3fd=0A> Nov 26 12:53:49 ccsw1 kernel: AMD=0A> = Features=3D0x28100800=0A> Nov 26 12:53:49 ccsw1 kerne= l: AMD Features2=3D0x1=0A> Nov 26 12:53:49 ccsw1 kernel: TSC: P-state= invariant,=0A> performance statistics=0A> Nov 26 12:53:49 ccsw1 kernel: re= al memory=A0 =3D=0A> 17179869184 (16384 MB)=0A> Nov 26 12:53:49 ccsw1 kerne= l: avail memory =3D 16458309632=0A> (15695 MB)=0A> Nov 26 12:53:49 ccsw1 ke= rnel: Event timer "LAPIC" quality=0A> 400=0A> Nov 26 12:53:49 ccsw1 kernel:= ACPI APIC Table:=0A> =0A> Nov 26 12:53:49 ccsw1 kernel:= FreeBSD/SMP: Multiprocessor=0A> System=0A> Detected: 8 CPUs=0A> Nov 26 12:= 53:49 ccsw1 kernel: FreeBSD/SMP: 1 package(s) x 4=0A> core(s) x=0A> 2 SMT t= hreads=0A> Nov 26 12:53:49 ccsw1 kernel: cpu0 (BSP): APIC ID:=A0 0=0A> Nov = 26 12:53:49 ccsw1 kernel: cpu1 (AP): APIC ID:=A0 1=0A> Nov 26 12:53:49 ccsw= 1 kernel: cpu2 (AP): APIC ID:=A0 2=0A> Nov 26 12:53:49 ccsw1 kernel: cpu3 (= AP): APIC ID:=A0 3=0A> Nov 26 12:53:49 ccsw1 kernel: cpu4 (AP): APIC ID:=A0= 4=0A> Nov 26 12:53:49 ccsw1 kernel: cpu5 (AP): APIC ID:=A0 5=0A> Nov 26 12= :53:49 ccsw1 kernel: cpu6 (AP): APIC ID:=A0 6=0A> Nov 26 12:53:49 ccsw1 ker= nel: cpu7 (AP): APIC ID:=A0 7=0A> Nov 26 12:53:49 ccsw1 kernel: ioapic0 =0A> irqs 0-23 on motherboard=0A> Nov 26 12:53:49 ccsw1 kernel: l= apic0: Forcing LINT1 to edge=0A> trigger=0A> Nov 26 12:53:49 ccsw1 kernel: = kbd1 at kbdmux0=0A> Nov 26 12:53:49 ccsw1 kernel: acpi0: = =0A> on motherboard=0A> Nov 26 12:53:49 ccsw1 kernel: acpi0: Power Button (= fixed)=0A> Nov 26 12:53:49 ccsw1 kernel: cpu0: on=0A> acpi0=0A> = Nov 26 12:53:49 ccsw1 kernel: cpu1: on=0A> acpi0=0A> Nov 26 12:5= 3:49 ccsw1 kernel: cpu2: on=0A> acpi0=0A> Nov 26 12:53:49 ccsw1 = kernel: cpu3: on=0A> acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: cpu= 4: on=0A> acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: cpu5: on=0A> acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: cpu6: on=0A> a= cpi0=0A> Nov 26 12:53:49 ccsw1 kernel: cpu7: on=0A> acpi0=0A> No= v 26 12:53:49 ccsw1 kernel: atrtc0: clock> port=0A> 0x70-0= x71,0x74-0x77 irq 8 on acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: Event timer = "RTC" frequency=0A> 32768 Hz quality 0=0A> Nov 26 12:53:49 ccsw1 kernel: at= timer0: =0A> port=0A> 0x40-0x43,0x50-0x53 irq 0 on acpi0=0A> Nov = 26 12:53:49 ccsw1 kernel: Timecounter "i8254" frequency=0A> 1193182 Hz qual= ity 0=0A> Nov 26 12:53:49 ccsw1 kernel: Event timer "i8254" frequency=0A> 1= 193182 Hz=0A> quality 100=0A> Nov 26 12:53:49 ccsw1 kernel: hpet0: Event Timer>=0A> iomem 0xfed00000-0xfed003ff on acpi0=0A> Nov 2= 6 12:53:49 ccsw1 kernel: Timecounter "HPET" frequency=0A> 14318180 Hz=0A> q= uality 950=0A> Nov 26 12:53:49 ccsw1 kernel: Event timer "HPET" frequency= =0A> 14318180 Hz=0A> quality 550=0A> Nov 26 12:53:49 ccsw1 kernel: Timecoun= ter "ACPI-fast"=0A> frequency=0A> 3579545 Hz quality 900=0A> Nov 26 12:53:4= 9 ccsw1 kernel: acpi_timer0: <24-bit timer=0A> at=0A> 3.579545MHz> port 0x4= 08-0x40b on acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: pcib0: bridge> port=0A> 0xcf8-0xcff on acpi0=0A> Nov 26 12:53:49 ccsw1 kernel= : pci0: on=0A> pcib0=0A> Nov 26 12:53:49 ccsw1 kernel: pcib1= : bridge> irq 16 at=0A> device 3.0 on pci0=0A> Nov 26 12:= 53:49 ccsw1 kernel: pci1: on=0A> pcib1=0A> Nov 26 12:53:49 c= csw1 kernel: pcib2: bridge> at device 0.0 on pci1=0A> Nov= 26 12:53:49 ccsw1 kernel: pci2: on=0A> pcib2=0A> Nov 26 12:= 53:49 ccsw1 kernel: pcib3: bridge> at device 2.0 on pci2= =0A> Nov 26 12:53:49 ccsw1 kernel: pci3: on=0A> pcib3=0A> No= v 26 12:53:49 ccsw1 kernel: igb0: Network=0A> Connec= tion version - 2.3.4> port 0x3020-0x303f mem=0A> 0xb1b20000-0xb1b3ffff,0xb1= bc4000-0xb1bc7fff irq 19 at device=0A> 0.0 on=0A> pci3=0A> Nov 26 12:53:49 = ccsw1 kernel: igb0: Using MSIX interrupts=0A> with 9 vectors=0A> Nov 26 12:= 53:49 ccsw1 kernel: igb0: Ethernet address:=0A> 00:1e:67:3a:d5:40=0A> Nov 2= 6 12:53:49 ccsw1 kernel: igb0: Bound queue 0 to cpu 0=0A> Nov 26 12:53:49 c= csw1 kernel: igb0: Bound queue 1 to cpu 1=0A> Nov 26 12:53:49 ccsw1 kernel:= igb0: Bound queue 2 to cpu 2=0A> Nov 26 12:53:49 ccsw1 kernel: igb0: Bound= queue 3 to cpu 3=0A> Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 4 to = cpu 4=0A> Nov 26 12:53:49 ccsw1 kernel: igb0: Bound queue 5 to cpu 5=0A> No= v 26 12:53:49 ccsw1 kernel: igb0: Bound queue 6 to cpu 6=0A> Nov 26 12:53:4= 9 ccsw1 kernel: igb0: Bound queue 7 to cpu 7=0A> Nov 26 12:53:49 ccsw1 kern= el: igb1: Network=0A> Connection version - 2.3.4> po= rt 0x3000-0x301f mem=0A> 0xb1b00000-0xb1b1ffff,0xb1bc0000-0xb1bc3fff irq 18= at device=0A> 0.1 on=0A> pci3=0A> Nov 26 12:53:49 ccsw1 kernel: igb1: Usin= g MSIX interrupts=0A> with 9 vectors=0A> Nov 26 12:53:49 ccsw1 kernel: igb1= : Ethernet address:=0A> 00:1e:67:3a:d5:41=0A> Nov 26 12:53:49 ccsw1 kernel:= igb1: Bound queue 0 to cpu 0=0A> Nov 26 12:53:49 ccsw1 kernel: igb1: Bound= queue 1 to cpu 1=0A> Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 2 to = cpu 2=0A> Nov 26 12:53:49 ccsw1 kernel: igb1: Bound queue 3 to cpu 3=0A> No= v 26 12:53:49 ccsw1 kernel: igb1: Bound queue 4 to cpu 4=0A> Nov 26 12:53:4= 9 ccsw1 kernel: igb1: Bound queue 5 to cpu 5=0A> Nov 26 12:53:49 ccsw1 kern= el: igb1: Bound queue 6 to cpu 6=0A> Nov 26 12:53:49 ccsw1 kernel: igb1: Bo= und queue 7 to cpu 7=0A> Nov 26 12:53:49 ccsw1 kernel: pcib4: bridge> at device 3.0 on pci2=0A> Nov 26 12:53:49 ccsw1 kernel: pci6: = on=0A> pcib4=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Network=0A> Connection version - 2.3.4> port 0x2020-0x203f = mem=0A> 0xb1a20000-0xb1a3ffff,0xb1ac4000-0xb1ac7fff irq 16 at device=0A> 0.= 0 on=0A> pci6=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Using MSIX interrupts= =0A> with 9 vectors=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Ethernet addres= s:=0A> 00:1e:67:3a:d5:42=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queu= e 0 to cpu 0=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 1 to cpu 1= =0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 2 to cpu 2=0A> Nov 26 = 12:53:49 ccsw1 kernel: igb2: Bound queue 3 to cpu 3=0A> Nov 26 12:53:49 ccs= w1 kernel: igb2: Bound queue 4 to cpu 4=0A> Nov 26 12:53:49 ccsw1 kernel: i= gb2: Bound queue 5 to cpu 5=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Bound q= ueue 6 to cpu 6=0A> Nov 26 12:53:49 ccsw1 kernel: igb2: Bound queue 7 to cp= u 7=0A> Nov 26 12:53:49 ccsw1 kernel: igb3: Network= =0A> Connection version - 2.3.4> port 0x2000-0x201f mem=0A> 0xb1a00000-0xb1= a1ffff,0xb1ac0000-0xb1ac3fff irq 19 at device=0A> 0.1 on=0A> pci6=0A> Nov 2= 6 12:53:49 ccsw1 kernel: igb3: Using MSIX interrupts=0A> with 9 vectors=0A>= Nov 26 12:53:49 ccsw1 kernel: igb3: Ethernet address:=0A> 00:1e:67:3a:d5:4= 3=0A> Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 0 to cpu 0=0A> Nov 26= 12:53:49 ccsw1 kernel: igb3: Bound queue 1 to cpu 1=0A> Nov 26 12:53:49 cc= sw1 kernel: igb3: Bound queue 2 to cpu 2=0A> Nov 26 12:53:49 ccsw1 kernel: = igb3: Bound queue 3 to cpu 3=0A> Nov 26 12:53:49 ccsw1 kernel: igb3: Bound = queue 4 to cpu 4=0A> Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 5 to c= pu 5=0A> Nov 26 12:53:49 ccsw1 kernel: igb3: Bound queue 6 to cpu 6=0A> Nov= 26 12:53:49 ccsw1 kernel: igb3: Bound queue 7 to cpu 7=0A> Nov 26 12:53:49= ccsw1 kernel: pcib5: bridge> at device 4.0 on pci2=0A> N= ov 26 12:53:49 ccsw1 kernel: pci9: on=0A> pcib5=0A> Nov 26 1= 2:53:49 ccsw1 kernel: pcib6: bridge> at device 5.0 on pci= 2=0A> Nov 26 12:53:49 ccsw1 kernel: pci10: on=0A> pcib6=0A> = Nov 26 12:53:49 ccsw1 kernel: pci0: =0A> at device 8.0=0A>= (no driver attached)=0A> Nov 26 12:53:49 ccsw1 kernel: pci0: =0A> at device 8.1=0A> (no driver attached)=0A> Nov 26 12:53:49 ccsw1 k= ernel: pci0: =0A> at device 8.2=0A> (no driver attached)= =0A> Nov 26 12:53:49 ccsw1 kernel: pci0: =0A> at device 8.= 3 (no driver a=0A> ttached)=0A> Nov 26 12:53:49 ccsw1 kernel: pci0: =0A> at device 16.0=0A> (no driver attached)=0A> Nov 26 12:53:49 = ccsw1 kernel: pci0: =0A> at device 16.1=0A> (no driver att= ached)=0A> Nov 26 12:53:49 ccsw1 kernel: ehci0: cont= roller=0A> USB-B> mem 0xb1c02000-0xb1c023ff irq 21 at device 26.0 on=0A> pc= i0=0A> Nov 26 12:53:49 ccsw1 kernel: usbus0: EHCI version 1.0=0A> Nov 26 12= :53:49 ccsw1 kernel: usbus0 on ehci0=0A> Nov 26 12:53:49 ccsw1 kernel: pcib= 7: bridge> irq 16 at=0A> device 28.0 on pci0=0A> Nov 26 1= 2:53:49 ccsw1 kernel: pci11: on=0A> pcib7=0A> Nov 26 12:53:4= 9 ccsw1 kernel: pcib8: bridge> irq 16 at=0A> device 28.4 = on pci0=0A> Nov 26 12:53:49 ccsw1 kernel: pci12: on=0A> pcib= 8=0A> Nov 26 12:53:49 ccsw1 kernel: em0: Network=0A>= Connection 7.3.2> port 0x1000-0x101f mem=0A> 0xb1900000-0xb191ffff,0xb1920= 000-0xb1923fff irq 16 at device=0A> 0.0 on=0A> pci12=0A> Nov 26 12:53:49 cc= sw1 kernel: em0: Using MSIX interrupts=0A> with 3 vectors=0A> Nov 26 12:53:= 49 ccsw1 kernel: em0: Ethernet address:=0A> 00:1e:67:3a:d5:44=0A> Nov 26 12= :53:49 ccsw1 kernel: pcib9: bridge> irq 18 at=0A> device = 28.6 on pci0=0A> Nov 26 12:53:49 ccsw1 kernel: pci13: on=0A>= pcib9=0A> Nov 26 12:53:49 ccsw1 kernel: vgapci0: displ= ay> mem=0A> 0xb0000000-0xb0ffffff,0xb1800000-0xb1803fff,0xb1000000-0xb17fff= ff=0A> irq=0A> 17 at device 0.0 on pci13=0A> Nov 26 12:53:49 ccsw1 kernel: = ehci1: controller=0A> USB-A> mem 0xb1c01000-0xb1c013= ff irq 23 at device 29.0 on=0A> pci0=0A> Nov 26 12:53:49 ccsw1 kernel: usbu= s1: EHCI version 1.0=0A> Nov 26 12:53:49 ccsw1 kernel: usbus1 on ehci1=0A> = Nov 26 12:53:49 ccsw1 kernel: pcib10: bridge> at device= =0A> 30.0 on pci0=0A> Nov 26 12:53:49 ccsw1 kernel: pci14: o= n=0A> pcib10=0A> Nov 26 12:53:49 ccsw1 kernel: isab0: =0A> = at device 31.0 on pci0=0A> Nov 26 12:53:49 ccsw1 kernel: isa0: on= =0A> isab0=0A> Nov 26 12:53:49 ccsw1 kernel: ahci0: Series AHCI=0A> SATA controller> port=0A> 0x4048-0x404f,0x4054-0x4057,0x4= 040-0x4047,0x4050-0x4053,0x4020-0x403f=0A> mem 0xb1c00000-0xb1c007ff irq 18= at device 31.2 on pci0=0A> Nov 26 12:53:49 ccsw1 kernel: ahci0: AHCI v1.30= with 6 3Gbps=0A> ports,=0A> Port Multiplier not supported=0A> Nov 26 12:53= :49 ccsw1 kernel: ahcich0: =0A> at channel 0 on ahci0=0A> Nov= 26 12:53:49 ccsw1 kernel: ahcich1: =0A> at channel 1 on ahci= 0=0A> Nov 26 12:53:49 ccsw1 kernel: ahcich2: =0A> at channel = 2 on ahci0=0A> Nov 26 12:53:49 ccsw1 kernel: ahcich3: =0A> at= channel 3 on ahci0=0A> Nov 26 12:53:49 ccsw1 kernel: ahcich4: =0A> at channel 4 on ahci0=0A> Nov 26 12:53:49 ccsw1 kernel: ahcich5: =0A> at channel 5 on ahci0=0A> Nov 26 12:53:49 ccsw1 kernel: pci= 0: SMBus> at device 31.3=0A> (no driver attached)=0A> Nov = 26 12:53:49 ccsw1 kernel: acpi_button0: Button> on acpi0=0A> Nov= 26 12:53:49 ccsw1 kernel: uart0: <16550 or=0A> compatible> port=0A> 0x3f8-= 0x3ff irq 4 flags 0x10 on acpi0=0A> Nov 26 12:53:49 ccsw1 kernel: uart1: <1= 6550 or=0A> compatible> port=0A> 0x2f8-0x2ff irq 3 on acpi0=0A> Nov 26 12:5= 3:49 ccsw1 kernel: orm0: =0A> at iomem=0A> 0xc0000-0xc7fff = on isa0=0A> Nov 26 12:53:49 ccsw1 kernel: sc0: at=0A> flag= s 0x100 on isa0=0A> Nov 26 12:53:49 ccsw1 kernel: sc0: VGA <16 virtual=0A> = consoles, flags=3D0x300>=0A> Nov 26 12:53:49 ccsw1 kernel: vga0: =0A> at port=0A> 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0=0A> Nov 2= 6 12:53:49 ccsw1 kernel: ppc0: cannot reserve I/O port=0A> range=0A> Nov 26= 12:53:49 ccsw1 kernel: ctl: CAM Target Layer loaded=0A> Nov 26 12:53:49 cc= sw1 kernel: est0: Frequency=0A> Control> on cpu0=0A= > Nov 26 12:53:49 ccsw1 kernel: p4tcc0: Thermal Control>= on cpu0=0A> Nov 26 12:53:49 ccsw1 kernel: est1: Fr= equency=0A> Control> on cpu1=0A> Nov 26 12:53:49 ccsw1 kernel: p4tcc1: Thermal Control> on cpu1=0A> Nov 26 12:53:49 ccsw1 kernel: e= st2: Frequency=0A> Control> on cpu2=0A> Nov 26 12:5= 3:49 ccsw1 kernel: p4tcc2: Thermal Control> on cpu2=0A> = Nov 26 12:53:49 ccsw1 kernel: est3: Frequency=0A> C= ontrol> on cpu3=0A> Nov 26 12:53:49 ccsw1 kernel: p4tcc3: Thermal Control> on cpu3=0A> Nov 26 12:53:49 ccsw1 kernel: est4: Frequency=0A> Control> on cpu4=0A> Nov 26 12:53:49 ccsw1 ke= rnel: p4tcc4: Thermal Control> on cpu4=0A> Nov 26 12:53:= 49 ccsw1 kernel: est5: Frequency=0A> Control> on cp= u5=0A> Nov 26 12:53:49 ccsw1 kernel: p4tcc5: Thermal Con= trol> on cpu5=0A> Nov 26 12:53:49 ccsw1 kernel: est6: Frequency=0A> Control> on cpu6=0A> Nov 26 12:53:49 ccsw1 kernel: p4tcc= 6: Thermal Control> on cpu6=0A> Nov 26 12:53:49 ccsw1 ke= rnel: est7: Frequency=0A> Control> on cpu7=0A> Nov = 26 12:53:49 ccsw1 kernel: p4tcc7: Thermal Control> on cp= u7=0A> Nov 26 12:53:49 ccsw1 kernel: ZFS filesystem version 5=0A> Nov 26 12= :53:49 ccsw1 kernel: ZFS storage pool version 28=0A> Nov 26 12:53:49 ccsw1 = kernel: Timecounters tick every 1.000=0A> msec=0A> Nov 26 12:53:49 ccsw1 ke= rnel: usbus0: 480Mbps High Speed USB=0A> v2.0=0A> Nov 26 12:53:49 ccsw1 ker= nel: usbus1: 480Mbps High Speed USB=0A> v2.0=0A> Nov 26 12:53:49 ccsw1 kern= el: ugen0.1: at=0A> usbus0=0A> Nov 26 12:53:49 ccsw1 kernel: uhub0:= HUB, class 9/0,=0A> rev 2.00/1.00, addr 1> on usbus0= =0A> Nov 26 12:53:49 ccsw1 kernel: ugen1.1: at=0A> usbus1=0A> Nov 2= 6 12:53:49 ccsw1 kernel: uhub1: HUB, class 9/0,=0A> re= v 2.00/1.00, addr 1> on usbus1=0A> Nov 26 12:53:49 ccsw1 kernel: uhub0: 2 p= orts with 2=0A> removable, self powered=0A> Nov 26 12:53:49 ccsw1 kernel: u= hub1: 2 ports with 2=0A> removable, self powered=0A> Nov 26 12:53:49 ccsw1 = kernel: ugen0.2: =0A> at usbus0=0A> Nov 26 12:53:49 ccsw1 ke= rnel: uhub2: product 0x0020,=0A> class 9/0, rev 2.00/0.0= 0, addr 2> on usbus0=0A> Nov 26 12:53:49 ccsw1 kernel: ugen1.2: =0A> at usbus1=0A> Nov 26 12:53:49 ccsw1 kernel: uhub3: product 0x0020,=0A> class 9/0, rev 2.00/0.00, addr 2> on usbus1=0A> No= v 26 12:53:49 ccsw1 kernel: uhub2: 6 ports with 6=0A> removable, self power= ed=0A> Nov 26 12:53:49 ccsw1 kernel: uhub3: 8 ports with 8=0A> removable, s= elf powered=0A> Nov 26 12:53:49 ccsw1 kernel: ugen0.3: at=0A> usbus0= =0A> Nov 26 12:53:49 ccsw1 kernel: ukbd0: Keyboard,= =0A> class 0/0, rev 1.10/1.23, addr 3> on usbus0=0A> Nov 26 12:53:49 ccsw1 = kernel: kbd0 at ukbd0=0A> Nov 26 12:53:49 ccsw1 kernel: uhid0: <12032003> o= n=0A> usbus0=0A> Nov 26 12:53:49 ccsw1 kernel: ugen1.3: Megat= rends Inc.> at usbus1=0A> Nov 26 12:53:49 ccsw1 kernel: ukbd1: Interface> on usbus1=0A> Nov 26 12:53:49 ccsw1 kernel: kbd2 at ukbd1=0A> = Nov 26 12:53:49 ccsw1 kernel: ums0: =0A> on usbus1=0A> Nov= 26 12:53:49 ccsw1 kernel: ums0: 3 buttons and [Z]=0A> coordinates ID=3D0= =0A> Nov 26 12:53:49 ccsw1 kernel: ada0 at ahcich0 bus 0 scbus0=0A> target = 0 lun 0=0A> Nov 26 12:53:49 ccsw1 kernel: ada0: CC4= B> ATA-8=0A> SATA 3.x device=0A> Nov 26 12:53:49 ccsw1 kernel: ada0: 300.00= 0MB/s transfers=0A> (SATA 2.x,=0A> UDMA6, PIO 8192bytes)=0A> Nov 26 12:53:4= 9 ccsw1 kernel: ada0: Command Queueing=0A> enabled=0A> Nov 26 12:53:49 ccsw= 1 kernel: ada0: 1907729MB (3907029168=0A> 512 byte=0A> sectors: 16H 63S/T 1= 6383C)=0A> Nov 26 12:53:49 ccsw1 kernel: ada0: Previously was known as=0A> = ad4=0A> Nov 26 12:53:49 ccsw1 kernel: ada1 at ahcich1 bus 0 scbus1=0A> targ= et 0 lun 0=0A> Nov 26 12:53:49 ccsw1 kernel: ada1: = CC4B> ATA-8=0A> SATA 3.x device=0A> Nov 26 12:53:49 ccsw1 kernel: ada1: 300= .000MB/s transfers=0A> (SATA 2.x,=0A> UDMA6, PIO 8192bytes)=0A> Nov 26 12:5= 3:49 ccsw1 kernel: ada1: Command Queueing=0A> enabled=0A> Nov 26 12:53:49 c= csw1 kernel: ada1: 1907729MB (3907029168=0A> 512 byte=0A> sectors: 16H 63S/= T 16383C)=0A> Nov 26 12:53:49 ccsw1 kernel: ada1: Previously was known as= =0A> ad6=0A> Nov 26 12:53:49 ccsw1 kernel: lapic1: Forcing LINT1 to edge=0A= > trigger=0A> Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #1 Launched!=0A> No= v 26 12:53:49 ccsw1 kernel: lapic2: Forcing LINT1 to edge=0A> trigger=0A> N= ov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #2 Launched!=0A> Nov 26 12:53:49 c= csw1 kernel: lapic7: Forcing LINT1 to edge=0A> trigger=0A> Nov 26 12:53:49 = ccsw1 kernel: SMP: AP CPU #7 Launched!=0A> Nov 26 12:53:49 ccsw1 kernel: la= pic5: Forcing LINT1 to edge=0A> trigger=0A> Nov 26 12:53:49 ccsw1 kernel: S= MP: AP CPU #5 Launched!=0A> Nov 26 12:53:49 ccsw1 kernel: lapic6: Forcing L= INT1 to edge=0A> trigger=0A> Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #6 L= aunched!=0A> Nov 26 12:53:49 ccsw1 kernel: lapic3: Forcing LINT1 to edge=0A= > trigger=0A> Nov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #3 Launched!=0A> No= v 26 12:53:49 ccsw1 kernel: lapic4: Forcing LINT1 to edge=0A> trigger=0A> N= ov 26 12:53:49 ccsw1 kernel: SMP: AP CPU #4 Launched!=0A> Nov 26 12:53:49 c= csw1 kernel: Timecounter "TSC-low"=0A> frequency 9895914=0A> Hz quality 100= 0=0A> Nov 26 12:58:01 ccsw1 kernel: Trying to mount root from=0A> zfs:pool/= r1 []...=0A> Nov 26 12:58:01 ccsw1 root: /etc/rc: WARNING: Dump device=0A> = does not=0A> exist.=A0 Savecore not run.=0A> Nov 26 12:58:01 ccsw1 ntpd[151= 1]: ntpd 4.2.4p5-a (1)=0A> Nov 26 12:58:01 ccsw1 ntpd[1512]: bind() fd 22, = family=0A> AF_INET6, port=0A> 123, scope 2, addr fe80::21e:67ff:fe3a:d541, = mcast=3D0=0A> flags=3D0x11 fails:=0A> Can't assign requested address=0A> No= v 26 12:58:01 ccsw1 ntpd[1512]: unable to create socket on=0A> igb1 (2)=0A>= for fe80::21e:67ff:fe3a:d541#123=0A> Nov 26 12:58:12 ccsw1 ntpd[1512]: bin= d() fd 27, family=0A> AF_INET6, port=0A> 123, scope 2, addr fe80::21e:67ff:= fe3a:d541, mcast=3D0=0A> flags=3D0x11 fails:=0A> Can't assign requested add= ress=0A> Nov 26 12:58:12 ccsw1 ntpd[1512]: unable to create socket on=0A> i= gb1 (7)=0A> for fe80::21e:67ff:fe3a:d541#123=0A> Nov 26 12:58:18 ccsw1 ntpd= [1512]: time reset +0.261195 s=0A> Nov 26 12:58:23 ccsw1 sshd[1575]: error:= PAM: authentication=0A> error for=0A> root from 192.168.221.84=0A> Nov 26 = 13:03:12 ccsw1 ntpd[1512]: bind() fd 27, family=0A> AF_INET6, port=0A> 123,= scope 2, addr fe80::21e:67ff:fe3a:d541, mcast=3D0=0A> flags=3D0x11 fails:= =0A> Can't assign requested address=0A> =0A=0AI'm curious as to what logic = there is to have 32 queues for a 4 core=0ACPU? And does it make sense to bi= nd queues randomly without regard for=0Awhether its a physical or a logical= core?=0A=0ACPU binding doesn't make a lot of sense if its done randomly. A= nd it =0Aseems like you just have a lot of queues for the heck of having a = lot=0Aof queues without any understanding of the point of the feature, whic= h=0Ais to increase capacity of overloaded systems; not to suck up all of th= e=0Acpu processing power for the entire system.=0A=0AAt minimum, you certai= nly have to tune the driver to fit your system. =0ABlindly accepting the de= faults, which are likely chosen for a 1 NIC=0Asystem, is going to be more w= rong the more your system deviates from=0Athat assumption.=0A=0ABC From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 04:35:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7E7543DB for ; Thu, 29 Nov 2012 04:35:48 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 450448FC08 for ; Thu, 29 Nov 2012 04:35:48 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id n2so4349824dad.13 for ; Wed, 28 Nov 2012 20:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=58IGZcgLZURW0c0cuXub1fcSQBfOWwrY8YoMtFWT3qQ=; b=SsIIOezK1VBMhCduaXyrsDD2j1ZwBoEMaPaWoa3mdHtmDri8ndueaQOJKfm86eSu8o D9BNkel66HTa6HKe8449pcRrNgGKEg/gei/CSiVQDovfRV2fIcWRydC9NBUZS7GtzOgG YB/uQFqaAjQoTw+JTWJmBB7JLZej/zxOSc7UqubGJQJ9SYHcPO50hJZlse4kACptX1BD RTWwezX0eR1TEBD/5tzCxLa9IGLNB5WFAqQj6M8gsLYBW8kfn4dEO1+PbTHLWaM8e5g4 EyTgDVujt8QBjxPr32WC9a7m11uve0UsnnmnWcl67S/oXoug6bfmtJB6FkihA6UONKfK u/rQ== MIME-Version: 1.0 Received: by 10.68.224.8 with SMTP id qy8mr63818082pbc.88.1354163747844; Wed, 28 Nov 2012 20:35:47 -0800 (PST) Received: by 10.66.222.132 with HTTP; Wed, 28 Nov 2012 20:35:47 -0800 (PST) In-Reply-To: References: Date: Wed, 28 Nov 2012 23:35:47 -0500 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: Ramanujan Seshadri To: PseudoCylon 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: Thu, 29 Nov 2012 04:35:48 -0000 Hello, Thanks for the reply. I just had one more doubt. In the counters to update the transmitted A-MPDU counter (Function Name: NICUpdateRawCounters), i saw these lines of codes pRalinkCounters->TransmittedAMPDUCount.u.LowPart += TxAggCnt0.field.AggSize1Count; pRalinkCounters->TransmittedAMPDUCount.u.LowPart += (TxAggCnt0.field.AggSize2Count >> 1); pRalinkCounters->TransmittedAMPDUCount.u.LowPart += (TxAggCnt0.field.AggSize3Count /3); . . . . pRalinkCounters->TransmittedAMPDUCount.u.LowPart += (TxAggCnt0.field.AggSize15Count/ 15); pRalinkCounters->TransmittedAMPDUCount.u.LowPart += (TxAggCnt0.field.AggSize16Count >> 4); Can you please explain the reason why the 'i'th counter is being divided by i, for example .TxAggCnt0.field.AggSize*15*Count is being divided by *15.* Also if these were little endian counters then i could not understand the reason why the four counters "TxAggCnt0.field.AggSize2Count, TxAggCnt0.field.AggSize4Count, TxAggCnt0.field.AggSize8Count and TxAggCnt0.field.AggSize16Count " are shifted right by some bits, which means that they are multiplying them (since it is little endian registers) and why they are dividing the others. Thanks for the help. -ram On Tue, Nov 27, 2012 at 6:07 PM, PseudoCylon wrote: > On Tue, Nov 27, 2012 at 1:23 PM, Ramanujan Seshadri > wrote: > > I want to know how many MPDU's are aggregated in each AMPDU transmission. > > You could use following statistic counters > RT2860_TX_AGG_CNT0 to 7 > > https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_runreg.h#line186 > Each 32-bit little-endian read-on-clear register contains 2 16-bit > counters (total 16 16-bit counters). > counter at offset 0x1720 MPDU count 1 > counter at offset 0x1722 MPDU count 2 > ... > counter at offset 0x173c MPDU count 15 > counter at offset 0x173e MPDU count >= 16 > > These regs are identical on RT2800 and RT2700 (pci/usb). > > Example (see #if 0 part) > https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_run.c#line2493 > > You can only find out statistical numbers (total Tx counts past X > sec). You cannot find out an MPDU count in a particular packet, i.e. > an aggregated packet just Tx'd, unless you read the counters on each > Tx. > > > AK > > > > > -ram > > > > > > On Tue, Nov 27, 2012 at 2:11 PM, PseudoCylon > > wrote: > >> > >> > ------------------------------ > >> > > >> > Message: 12 > >> > Date: Tue, 27 Nov 2012 04:33:37 -0500 > >> > From: Ramanujan Seshadri > >> > To: freebsd-net@freebsd.org > >> > Subject: Ralink RT2860 Driver Code > >> > Message-ID: > >> > > >> > > >> > Content-Type: text/plain; charset=ISO-8859-1 > >> > > >> > Hello, > >> > Can i know how to get the MPDU's aggregated in each AMPDU in a > ralink > >> > driver code for RT2860. I saw the existing counters of ralink and > tried > >> > to > >> > get some info, but was not very useful. > >> > Any help is greatly appreciated. > >> > > >> > >> https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan > >> > >> What info are you trying to get? > >> > >> > >> AK > >> > >> > Thanks > >> > ram > >> > > >> > > >> > ------------------------------ > >> > > >> > _______________________________________________ > >> > 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 > " > >> > > >> > End of freebsd-net Digest, Vol 504, Issue 2 > >> > ******************************************* > > > > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 07:06:16 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 33F61960; Thu, 29 Nov 2012 07:06:16 +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 F37438FC13; Thu, 29 Nov 2012 07:06:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAT76F5r095278; Thu, 29 Nov 2012 07:06:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAT76F7W095274; Thu, 29 Nov 2012 07:06:15 GMT (envelope-from linimon) Date: Thu, 29 Nov 2012 07:06:15 GMT Message-Id: <201211290706.qAT76F7W095274@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/173652: [ale] problem: could not disable Tx/Rx MAC(0x00000004)! 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, 29 Nov 2012 07:06:16 -0000 Synopsis: [ale] problem: could not disable Tx/Rx MAC(0x00000004)! Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Nov 29 07:06:07 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=173652 From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 08:05:25 2012 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 506DCA66; Thu, 29 Nov 2012 08:05:25 +0000 (UTC) (envelope-from yongari@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 125E38FC14; Thu, 29 Nov 2012 08:05:25 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id qAT85OQf099172; Thu, 29 Nov 2012 08:05:24 GMT (envelope-from yongari@freefall.freebsd.org) Received: (from yongari@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id qAT85OQb099168; Thu, 29 Nov 2012 08:05:24 GMT (envelope-from yongari) Date: Thu, 29 Nov 2012 08:05:24 GMT Message-Id: <201211290805.qAT85OQb099168@freefall.freebsd.org> To: yongari@FreeBSD.org, freebsd-net@FreeBSD.org, yongari@FreeBSD.org From: yongari@FreeBSD.org Subject: Re: kern/173652: [ale] problem: could not disable Tx/Rx MAC(0x00000004)! 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, 29 Nov 2012 08:05:25 -0000 Synopsis: [ale] problem: could not disable Tx/Rx MAC(0x00000004)! Responsible-Changed-From-To: freebsd-net->yongari Responsible-Changed-By: yongari Responsible-Changed-When: Thu Nov 29 08:04:49 UTC 2012 Responsible-Changed-Why: Grab. http://www.freebsd.org/cgi/query-pr.cgi?pr=173652 From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 08:36:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 27488F8 for ; Thu, 29 Nov 2012 08:36:05 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm8-vm1.bullet.mail.ne1.yahoo.com (nm8-vm1.bullet.mail.ne1.yahoo.com [98.138.91.65]) by mx1.freebsd.org (Postfix) with ESMTP id C354D8FC0C for ; Thu, 29 Nov 2012 08:36:04 +0000 (UTC) Received: from [98.138.226.177] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2012 08:35:57 -0000 Received: from [98.138.226.124] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 29 Nov 2012 08:35:57 -0000 Received: from [127.0.0.1] by smtp203.mail.ne1.yahoo.com with NNFMP; 29 Nov 2012 08:35:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1354178157; bh=LHx4I7HWwC5y+0gRnrZmdP5u+RAkj1vRANFLyVBFmLQ=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=AuFKRyEFMVAi2QrzA3EskD+KeTmVEt6LL3RfVpSnhxJggP2ocuQMICJjKx5mYXM3Z48cN+lX8J9zm3fhz/Jvi0rDJPp6BtHRqR4yI6//eeGk1Kfxd9Kwrk+xxMKwKKilE5SXkh6Jyjn83YNjoY4VSqGJIdHjF750Et0Osxeg0r4= X-Yahoo-Newman-Id: 822722.40325.bm@smtp203.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: XAfINfwVM1kiGY2iEL9gP6uoVGxc5NmqmhwrEf6xTve1TLd lEzjQVsg0jtNWrPNZYh2GQRJ4vJ.xFT38XZW4Z_4Kj3wR27i8uaWDy1tLGYk JPjWcsamkD526G86YsSdd0HgEaIp3f2ynwp4jKzg32xBvYST4qlInjbY5hV7 mQK44Q09Z7AX1xIacosmtzwW10n7f9t7p1k9uKx5VpJxY3yqjQvgacPrw__h a_CWLxDlhe9jD6KDwIfaKI8AcgImkE62z47HKUYxWOIwALFBs37y0LMywDJX 8JKMbDgwFyWIeRuoGYJWo8ayLQ660MmP7nmaOOKKYLr94kPmkvM6pt1rhcAq zltoqW5JMgbl_XjlFNtCKet85x8I73UOyKtSLY6.1h4qB8iytTs3g4447.jN bPx05tSKltPDNIUuJxHc5GhQld49XI4zq0RPXqoxWrYuI9cteUtoCE4LKiOS UYvcZRuT9bNgs50n4qY2kuJO47NIrrHVVWfTkQqtDiZvY7Bu6hpIxk4fcVoa TP6vENQtqjYaTlPDkBhRBOGf4zUwWEgVN0Ja_ysAcDAFhXhcbPcj.G6mSDJx 287ZIS4SAIJP2IFCd0R4vmwxL4Py3HtBwkC.NZmKQJL1qKE5MdFSq2g8D5g- - X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-vc0-f182.google.com (moonlightakkiy@209.85.220.182 with plain) by smtp203.mail.ne1.yahoo.com with SMTP; 29 Nov 2012 00:35:57 -0800 PST Received: by mail-vc0-f182.google.com with SMTP id fo13so19605650vcb.13 for ; Thu, 29 Nov 2012 00:35:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.132.229 with SMTP id ox5mr32083562veb.46.1354178157056; Thu, 29 Nov 2012 00:35:57 -0800 (PST) Received: by 10.58.182.72 with HTTP; Thu, 29 Nov 2012 00:35:56 -0800 (PST) In-Reply-To: References: Date: Thu, 29 Nov 2012 01:35:56 -0700 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: PseudoCylon To: Ramanujan Seshadri 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: Thu, 29 Nov 2012 08:36:05 -0000 On Wed, Nov 28, 2012 at 9:35 PM, Ramanujan Seshadri wrote: > Hello, > > Thanks for the reply. I just had one more doubt. > > In the counters to update the transmitted A-MPDU counter (Function Name: > NICUpdateRawCounters), i saw these lines of codes > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > TxAggCnt0.field.AggSize1Count; > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > (TxAggCnt0.field.AggSize2Count >> 1); > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > (TxAggCnt0.field.AggSize3Count /3); > . > . > . > . > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > (TxAggCnt0.field.AggSize15Count/ 15); > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > (TxAggCnt0.field.AggSize16Count >> 4); > > Can you please explain the reason why the 'i'th counter is being divided by > i, for example .TxAggCnt0.field.AggSize15Count is being divided by 15. [NB] For people who haven't seen Ralink's code, the above codes are theirs. I guess I didn't explain well. Those counters show number of mpdu packets, i.e. AggSize15Count == 30 means 30 mpdu or 2 (30/15) ampdu packets. (Because I don't have any datasheet, that how I interpret Ralink's code.) > > Also if these were little endian counters then i could not understand the > reason why the four counters "TxAggCnt0.field.AggSize2Count, > TxAggCnt0.field.AggSize4Count, TxAggCnt0.field.AggSize8Count > and TxAggCnt0.field.AggSize16Count " are shifted right by some bits, which > means that they are multiplying them (since it is little endian registers) > and why they are dividing the others. RTMP_IO_READ32() does byte swapping. The values should be saved into AggSizeNCount with host's byte order. So, right sifting means dividing regardless of the byte order. >>1 == /2 ... >>4 == /16 They are playing nice to CPUs, I think. AK > > Thanks for the help. > > -ram > > > On Tue, Nov 27, 2012 at 6:07 PM, PseudoCylon > wrote: >> >> On Tue, Nov 27, 2012 at 1:23 PM, Ramanujan Seshadri >> wrote: >> > I want to know how many MPDU's are aggregated in each AMPDU >> > transmission. >> >> You could use following statistic counters >> RT2860_TX_AGG_CNT0 to 7 >> >> https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_runreg.h#line186 >> Each 32-bit little-endian read-on-clear register contains 2 16-bit >> counters (total 16 16-bit counters). >> counter at offset 0x1720 MPDU count 1 >> counter at offset 0x1722 MPDU count 2 >> ... >> counter at offset 0x173c MPDU count 15 >> counter at offset 0x173e MPDU count >= 16 >> >> These regs are identical on RT2800 and RT2700 (pci/usb). >> >> Example (see #if 0 part) >> https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_run.c#line2493 >> >> You can only find out statistical numbers (total Tx counts past X >> sec). You cannot find out an MPDU count in a particular packet, i.e. >> an aggregated packet just Tx'd, unless you read the counters on each >> Tx. >> >> >> AK >> >> > >> > -ram >> > >> > >> > On Tue, Nov 27, 2012 at 2:11 PM, PseudoCylon >> > wrote: >> >> >> >> > ------------------------------ >> >> > >> >> > Message: 12 >> >> > Date: Tue, 27 Nov 2012 04:33:37 -0500 >> >> > From: Ramanujan Seshadri >> >> > To: freebsd-net@freebsd.org >> >> > Subject: Ralink RT2860 Driver Code >> >> > Message-ID: >> >> > >> >> > >> >> > Content-Type: text/plain; charset=ISO-8859-1 >> >> > >> >> > Hello, >> >> > Can i know how to get the MPDU's aggregated in each AMPDU in a >> >> > ralink >> >> > driver code for RT2860. I saw the existing counters of ralink and >> >> > tried >> >> > to >> >> > get some info, but was not very useful. >> >> > Any help is greatly appreciated. >> >> > >> >> >> >> https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan >> >> >> >> What info are you trying to get? >> >> >> >> >> >> AK >> >> >> >> > Thanks >> >> > ram >> >> > >> >> > >> >> > ------------------------------ >> >> > >> >> > _______________________________________________ >> >> > 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" >> >> > >> >> > End of freebsd-net Digest, Vol 504, Issue 2 >> >> > ******************************************* >> > >> > > > From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 16:36:36 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40AE5A50; Thu, 29 Nov 2012 16:36:36 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id AF62C8FC17; Thu, 29 Nov 2012 16:36:34 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.5/8.14.5) with ESMTP id qATGaX7N020766; Thu, 29 Nov 2012 20:36:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id qATGaXks020765; Thu, 29 Nov 2012 20:36:33 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Thu, 29 Nov 2012 20:36:33 +0400 From: Gleb Smirnoff To: Zaphod Beeblebrox Subject: Re: 9.1-RC3 IGB dropping connections. Message-ID: <20121129163633.GM14202@FreeBSD.org> References: <50B57632.6050004@sentex.net> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: FreeBSD Hackers , FreeBSD Net , FreeBSD Stable , Mike Tancsa 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, 29 Nov 2012 16:36:36 -0000 On Tue, Nov 27, 2012 at 10:26:55PM -0500, Zaphod Beeblebrox wrote: Z> > Are you using pf ? Also, did you confirm it is the igb nic and not Z> > something more general ? e.g. if you put in a different nic, does the Z> > problem go away ? Z> Z> No pf, the motherboard em-driver NIC does not have this problem. I'd suggest to do some traffic sniffing when connection is dropped. May be some other host on network takes your IP address and resets connection? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Nov 29 20:39:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7AAAA45A for ; Thu, 29 Nov 2012 20:39:02 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 01BE38FC08 for ; Thu, 29 Nov 2012 20:39:01 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id D5DAC25D3A05; Thu, 29 Nov 2012 20:39:00 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id C68AEBE85B6; Thu, 29 Nov 2012 20:38:59 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id gPZf-K1EdlEL; Thu, 29 Nov 2012 20:38:58 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0DEA3BE85A9; Thu, 29 Nov 2012 20:38:57 +0000 (UTC) Date: Thu, 29 Nov 2012 20:38:57 +0000 (UTC) From: "Bjoern A. Zeeb" To: Vijay Singh Subject: Re: A small patch for sys/netinet6/in6_src.c In-Reply-To: Message-ID: References: X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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, 29 Nov 2012 20:39:02 -0000 On Sun, 25 Nov 2012, Vijay Singh wrote: > Really trivial change. Yeah, my comment is probably telling; I was wondering about the history of the code and why it ended up like that but probably haven't looked it up but added the XXX-BZ. I shall handle this. > /u/vijay/bsd/CODE/cur# svn diff sys/netinet6/in6_src.c > Index: sys/netinet6/in6_src.c > =================================================================== > --- sys/netinet6/in6_src.c (revision 243309) > +++ sys/netinet6/in6_src.c (working copy) > @@ -597,11 +597,6 @@ > if (ron->ro_rt == NULL) { > in6_rtalloc(ron, fibnum); /* multi path case? */ > if (ron->ro_rt == NULL) { > - /* XXX-BZ WT.? */ > - if (ron->ro_rt) { > - RTFREE(ron->ro_rt); > - ron->ro_rt = NULL; > - } > error = EHOSTUNREACH; > goto done; > } > _______________________________________________ > 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" > -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Fri Nov 30 14:09:10 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D3CCB9FC for ; Fri, 30 Nov 2012 14:09:10 +0000 (UTC) (envelope-from keith.arner@gmail.com) Received: from mail-we0-f182.google.com (mail-we0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6055E8FC08 for ; Fri, 30 Nov 2012 14:09:10 +0000 (UTC) Received: by mail-we0-f182.google.com with SMTP id u54so196138wey.13 for ; Fri, 30 Nov 2012 06:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type; bh=u1jCHVz//jT3aUWmvwl1+sPVG9rJNWfLUygbcdeAODI=; b=gWw/YMMewNsINY3zjfONDQJsEsJgPsLIcG9CJRy1xu55eev79RUwl0WcbbSIrMcMvx c6mHqDRA0Y8OXexekhZWceUNGIWo9Y167fdrarlTKNhiNPn/RaUBhkul78cCbKel2YiV YTeoNh9wOXhtJf2EazXI0fCsIeZCdE9ItfVS59SLxfF0GkxIVAgFHimxxvBT+GEuD7Yw yPkk5hCIilhSH7cE5BCtgAPmF3SB1rHDZLtff1arD96gixHYt5+m+7N8Nh0W04r9L9Sy nZ1CZoZsQ5pAPWlzoFED7fU9KtmETaS+wcVhmWynm+VvWQjKnysJggoDdpIjpa/CEpF1 ZDkQ== MIME-Version: 1.0 Received: by 10.216.228.20 with SMTP id e20mr496023weq.166.1354284549098; Fri, 30 Nov 2012 06:09:09 -0800 (PST) Sender: keith.arner@gmail.com Received: by 10.216.123.129 with HTTP; Fri, 30 Nov 2012 06:09:08 -0800 (PST) Date: Fri, 30 Nov 2012 09:09:08 -0500 X-Google-Sender-Auth: t8jLyy67pM5nYec6Jy5VZgiZlTg Message-ID: Subject: Problems with ephemeral port selection From: Keith Arner 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: Fri, 30 Nov 2012 14:09:10 -0000 I've noticed some issues with ephemeral port number selection from tcp_connect(), which limit the number of concurrent, outgoing connections that can be established (connect(), rather than accept()). Sifting through the source code, I believe the issuess stem from two problems in the tcp_connect() code path. Specifically: 1) The wrong function gets called to determine if a given ephemeral port number is currently usable. 2) The ephemeral port number gets selected without considering the foreign addr/port. Curiously, the effect of #1 mostly cancels the effect of #2, such that the common calling convention gives you a correct result so long as you only have a small number of outgoing connections. However, once you get to a large number of outgoing connections, things start to break down. (I'll define large and small later.) As a side note, I have been working with FreeBSD 7.2. The implementations of several of the relevant functions have been refactored somewhere between 7.2-RELEASE and 9-STABLE, but the core problems in the logic seem to be the same between versions. For problem #1, the code path that selects the ephemeral port number is: tcp_connect() -> in_pcbbind() -> in_pcbbind_setup() -> in_pcb_lport() [not in FreeBSD 7.2] -> in_pcblookup_local() There is a loop in in_pcb_lport() [or directly in in_pcbbind_setup() in earlier releases] that considers candidate ephemeral port numbers and calls in_pcblookup_local() to determine if a given candidate is suitable. The default behaviour (if the caller has not set either SO_REUSEADDR or SO_REUSEPORT) is to pick a local port number that is not in use by *any* local TCP socket. So long as the number of concurrent, outgoing connections is less than the range configured by `sysctl net.inet.ip.portrange.*`, selecting a totally unique ephemeral port number works OK. However, you cannot exceed that limit, even if each outgoing connection has a unique faddr/fport. This does not limit the number of connections that can be accept()'ed, only the number of connections that can be connect()'ed. In this particular path, I think the code should call in_pcblookup_hash(), rather than in_pcblookup_local(). The criteria in in_pcblookup_hash() only match if the full 5-tuple matches, rather than just the local port number. The complication, of course, comes from the fact that in_pcbbind() is called from both bind() and for the implicit bind that happens for a connect(). The matching criteria in in_pcblookup_local() make sense for the former but not quite for the later. I mentioned that the above is the default behaviour you get when you don't specify SO_REUSEADDR or SO_REUSEPORT. Setting SO_REUSEADDR before calling connect() has some surprizing consequences (surprizing in the sense that I don't believe SO_REUSEADDR is supposed to have any effect on connect()). In this case, when in_pcblookup_local() is called, wild_okay is set to false. This changes the matching criteria to (in effect) allow tcp_connect() to use the full 5-tuple space. However, this brings us to the second problem. Problem #2 is that the ephemeral port number is chosen before the fport/faddr gets set on the pcb; that is tcp_connect() calls in_pcbbind() to select the ephemeral port number, *then* calls in_pcbconnect_setup() to populate the fport/faddr. With SO_REUSEADDR, in_pcbbind() can select an in-use local port. If the local port is used by a socket with a different laddr/fport/faddr, all is good. However, if the local port selection results in a full conflict it will get rejected by the call to in_pcblookup_hash() inside in_pcbconnect_setup(). This happens *after* the loop inside in_pcbbind(), so the call to tcp_connect() fails with EADDRINUSE. Thus, with SO_REUSEADDR, connect() can fail with EADDRINUSE long before the ephemeral port space has been exhausted. The application could re-try the call to connect() and likely succeed, as a new local port would be selected. Overall, this behaviour hinders the ability to open a large number of outbound connections: * If you don't specify SO_REUSEADDR, you have a fairly limited maximum number of outbound connections. * If you do specify SO_REUSEADDR, you are able to open a much larger number of outbound connections, but must retry on EADDRINUSE. I believe that the logic under tcp_connect() should be modified to: - behave uniformly whether or not SO_REUSEADDR has been set - allow outgoing connection requests to re-use a local port number, so long as the remaining elements of the tuple (laddr, fport, faddr) are unique Keith -- "A problem well put is half solved." From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 06:20:35 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 115922C3 for ; Sat, 1 Dec 2012 06:20:35 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id CB7508FC08 for ; Sat, 1 Dec 2012 06:20:34 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so923222pbc.13 for ; Fri, 30 Nov 2012 22:20:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:user-agent:mime-version :content-type; bh=dtR43koguK9lL9M5UlolV6kbkeO+sC5vTH8ktgHjuuk=; b=nwbsYYirXiB8gfPuTC9ZIZVOoR65NG+XVOoKApMjkBR3uox+ez1Dcv7BhYsuL+kWIs 6ZR3Mn772g4aD9X8rX+fzvk11rAh1zdLY1cHShtJHZnqjAPvd4eCuHxyubev45rhiAd3 hGWZhX/AIP4Z3D/V0LYN2ijj9yzXCS4wI0soHKx9ZmVOl24wxB4/u17L3avk49KhZxxk 5VAXDy6UdCcURSG9oc1q9iMKc557yozuxLHdNuioyKdYby690tpAOziRFGYbklzQe84h fzrkqENxibxSHjcw7hAe92G+sEWYTQ07JFMYcw560fAJQeswlIcY6NKFXu+gdHkxSggL 9eSg== Received: by 10.66.75.232 with SMTP id f8mr9405273paw.23.1354342833449; Fri, 30 Nov 2012 22:20:33 -0800 (PST) Received: from c-24-19-191-56.hsd1.wa.comcast.net (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id gv9sm4271209pbc.21.2012.11.30.22.20.31 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 22:20:32 -0800 (PST) Date: Fri, 30 Nov 2012 22:20:24 -0800 (PST) From: Garrett Cooper To: bruce@toaster.local Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls (fwd) Message-ID: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="967339439-1681226068-1354342829=:57210" Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 06:20:35 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --967339439-1681226068-1354342829=:57210 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Tue, 27 Nov 2012, Bruce Evans wrote: > On Mon, 26 Nov 2012, Garrett Cooper wrote: > >> As noted in a previous thread, I set out to better document the >> net.inet6 sysctls after having to tweak the knobs to get things to work for >> TAHI, and this is the resulting draft (so far). I also took the liberty of >> removing the ip6_rr_prune and icmp6_redirtimeout sysctls because they >> weren't in use anywhere else in the sys/... portion of the tree. I was >> wondering if there are any points that should be corrected/clarified before >> I submit a PR with the resulting patch. > > It would be good to fix the style bugs when changing lots. > >> Index: sys/netinet6/in6_proto.c >> =================================================================== >> --- sys/netinet6/in6_proto.c (revision 242903) >> +++ sys/netinet6/in6_proto.c (working copy) >> @@ -443,7 +441,6 @@ >> >> /* ICMPV6 parameters */ >> VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ >> -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ >> VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ >> /* control how to respond to NI queries */ >> VNET_DEFINE(int, icmp6_nodeinfo) = >> @@ -515,15 +512,20 @@ >> } >> >> SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, CTLFLAG_RW, >> - &VNET_NAME(ip6_forwarding), 0, ""); >> + &VNET_NAME(ip6_forwarding), 0, >> + "Forward IPv6 packets via node."); > > All the sysctl names spell ipv6 without a v. This is hard to fix. This > bug is missing in the names of the sysctl numbers, but it is a bug to > used named numbers instead of OID_AUTO in code newer than OID_AUTO, and > ipv6 is much newer. > > New style bug in almost every description. Sysctl descriptions are not > normally terminated by a ".". > > Old style bug in almost every ipv6 sysctl. Large SYSCTL declarations are > normally normally-indented, with 4-space continuation indents. This rule > is broken farily consistenly in ipv6 sysctl. More ivp4 SYSCTL descriptions > are actually formatted normally. > >> @@ -594,35 +613,45 @@ >> #define V_ip6_output_flowtable_size VNET(ip6_output_flowtable_size) >> >> SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, output_flowtable_size, >> CTLFLAG_RDTUN, >> - &VNET_NAME(ip6_output_flowtable_size), 2048, >> - "number of entries in the per-cpu output flow caches"); >> + &VNET_NAME(ip6_output_flowtable_size), 2048, >> + "number of entries in the per-cpu output flow caches"); >> ... > > Here the formatting change is backwards (from normal continuation indent > to abnormal ipv6 continuation indent. > > This and some other old sysctl descriptions have differnent style bugs: > they are normally terminated (not with a '.'), but are not normally > capitalized (with capaitals). > >> SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, >> CTLFLAG_RW, > > Some mailer mangled the formatting (the line isn't too long and shouldn't > have been mangled). > >> - &VNET_NAME(nd6_prune), 0, ""); >> + &VNET_NAME(nd6_prune), 0, >> + "Period (in seconds) for performing nd6 expiration checks of default " > > More mangling by some mailer. > >> + "routes and prefix lists"); > > However, the string is too long. The message is obfuscated by splitting it. > This keeps the line length short in the source code, but it is still too > long in the output. Sysctl descriptions should be no longer than 50 or > 60 characters, since the sysctl name will expand the output by 20 or 30 > characters. sysctl names longer than 20 or 30 are a larger bug, since > they are hard to write as well as hard to read. > > This sysctl description is normally terminated (not with a "."). > >> ... >> SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, >> - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); >> + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, >> + "Maximum number of unicast queries to perform via nd6."); > > Another type of sysctl misformatting is generated by names that are so > verbose that CTLFLAG* cannot be formatted normally (on the first line). > > I missed earlier instances of these bugs. > > Statistic on output style in sysctl descriptions: on freefall now: > sysctl -da: 3546 lines > sysctl -da | grep -v ': *$': 3192 lines > [this filters out sysctls with null descriptions. The output is > misformatted with a space before the null description] > sysctl -nda: 3546 lines > sysctl -nda | grep -v '^: *$': 3192 lines > [since this 3192 is the same as the number of sysctls with non-null > descreiptions, there must be no multi-line descriptions with embedded > newlines] > sysctl -nda | grep -v '^: *$' | grep -v '^[A-Z]': > 1555 lines > [most of non-capitalizations are style bugs. The last 1395 of them > are automatically generated for device sysctls. This is part of 5 > lines of automatically generated spam for device sysctls (descriptions > are duplicated ad spamium for %desc, %driver, %location, %pnpinfo and > %parent). A few are correct because they are for a proper name or > keyword or a number] > sysctl -nda | grep -v '^: *$' | grep '\.$': > 74 lines > [the style bug of terminating with a '.' is uncommon. In a few cases > it goes with the larger style bug of a multi-line description] > sysctl -nda | grep -v '^: *$' | grep '.... [81 dots]': > 11 lines > [these lines are too long even without the sysctl names. Abnormal > termination is denser than usual in these lines (8 of 11)] > sysctl -nda | grep -v '^: *$' | grep '\..*\.': > 8 lines > [2 of these are for multi-sentence descriptions]. Bruce, Is this better? I tried to be consistent about using v6 properly when dealing with protocols in order to match what the IETF did and I believe I properly integrated in your comments. Thanks! -Garrett Index: sys/netinet6/in6_proto.c =================================================================== --- sys/netinet6/in6_proto.c (revision 243557) +++ sys/netinet6/in6_proto.c (working copy) @@ -131,7 +131,7 @@ #endif /* - * TCP/IP protocol family: IP6, ICMP6, UDP, TCP. + * TCP/IP protocol family: IPv6, ICMPv6, UDPv6, TCPv6. */ FEATURE(inet6, "Internet Protocol version 6"); @@ -382,9 +382,9 @@ */ #ifndef IPV6FORWARDING #ifdef GATEWAY6 -#define IPV6FORWARDING 1 /* forward IP6 packets not for us */ +#define IPV6FORWARDING 1 /* forward IPv6 packets */ #else -#define IPV6FORWARDING 0 /* don't forward IP6 packets not for us */ +#define IPV6FORWARDING 0 /* don't forward IPv6 packets */ #endif /* GATEWAY6 */ #endif /* !IPV6FORWARDING */ @@ -409,8 +409,6 @@ VNET_DEFINE(int, ip6_auto_flowlabel) = 1; VNET_DEFINE(int, ip6_use_deprecated) = 1;/* allow deprecated addr * (RFC2462 5.5.4) */ -VNET_DEFINE(int, ip6_rr_prune) = 5; /* router renumbering prefix - * walk list every 5 sec. */ VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for multicast? */ VNET_DEFINE(int, ip6_v6only) = 1; @@ -431,7 +429,7 @@ VNET_DEFINE(int, pmtu_expire) = 60*10; VNET_DEFINE(int, pmtu_probe) = 60*2; -/* raw IP6 parameters */ +/* raw IPV6 parameters */ /* * Nominal space allocated to a raw ip socket. */ @@ -443,13 +441,12 @@ /* ICMPV6 parameters */ VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ /* control how to respond to NI queries */ VNET_DEFINE(int, icmp6_nodeinfo) = (ICMP6_NODEINFO_FQDNOK|ICMP6_NODEINFO_NODEADDROK); -/* UDP on IP6 parameters */ +/* UDP on IPv6 parameters */ VNET_DEFINE(int, udp6_sendspace) = 9216;/* really max datagram size */ VNET_DEFINE(int, udp6_recvspace) = 40 * (1024 + sizeof(struct sockaddr_in6)); /* 40 1K datagrams */ @@ -461,12 +458,12 @@ "Internet6 Family"); /* net.inet6 */ -SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, "IP6"); -SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, "ICMP6"); -SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, "UDP6"); -SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, "TCP6"); +SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, "IPv6"); +SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, "ICMPv6"); +SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, "UDPv6"); +SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, "TCPv6"); #ifdef SCTP -SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, "SCTP6"); +SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, "SCTPv6"); #endif #ifdef IPSEC SYSCTL_NODE(_net_inet6, IPPROTO_ESP, ipsec6, CTLFLAG_RW, 0, "IPSEC6"); @@ -515,77 +512,99 @@ } SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, CTLFLAG_RW, - &VNET_NAME(ip6_forwarding), 0, ""); + &VNET_NAME(ip6_forwarding), 0, + "Forward IPv6 packets via node"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_SENDREDIRECTS, redirect, CTLFLAG_RW, - &VNET_NAME(ip6_sendredirects), 0, ""); + &VNET_NAME(ip6_sendredirects), 0, + "Redirect IPv6 packets via node"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFHLIM, hlim, CTLFLAG_RW, - &VNET_NAME(ip6_defhlim), 0, ""); + &VNET_NAME(ip6_defhlim), 0, + "Default hop limit for IPv6 unicast packets"); SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_STATS, stats, CTLFLAG_RW, - &VNET_NAME(ip6stat), ip6stat, ""); + &VNET_NAME(ip6stat), ip6stat, + "IPv6 statistics"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, - CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, + "Maximum number of fragmented packets to process"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, - CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, - "Default value of per-interface flag for accepting ICMPv6 Router" - "Advertisement messages"); + CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, + "Default value of per-interface flag for accepting ICMPv6 Router" + "Advertisement messages"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_NO_RADR, no_radr, - CTLFLAG_RW, &VNET_NAME(ip6_no_radr), 0, - "Default value of per-interface flag to control whether routers " - "sending ICMPv6 RA messages on that interface are added into the " - "default router list."); + CTLFLAG_RW, &VNET_NAME(ip6_no_radr), 0, + "Default value of per-interface flag to control whether routers " + "sending ICMPv6 RA messages on that interface are added into the " + "default router list"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_NORBIT_RAIF, norbit_raif, CTLFLAG_RW, - &VNET_NAME(ip6_norbit_raif), 0, - "Always set 0 to R flag in ICMPv6 NA messages when accepting RA" - " on the interface."); + &VNET_NAME(ip6_norbit_raif), 0, + "Always set 0 to R flag in ICMPv6 NA messages when accepting RA " + "on the interface"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RFC6204W3, rfc6204w3, - CTLFLAG_RW, &VNET_NAME(ip6_rfc6204w3), 0, - "Accept the default router list from ICMPv6 RA messages even " - "when packet forwarding enabled."); + CTLFLAG_RW, &VNET_NAME(ip6_rfc6204w3), 0, + "Accept the default router list from ICMPv6 RA messages even when packet " + "forwarding enabled"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_KEEPFAITH, keepfaith, CTLFLAG_RW, - &VNET_NAME(ip6_keepfaith), 0, ""); + &VNET_NAME(ip6_keepfaith), 0, + ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_LOG_INTERVAL, log_interval, - CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, + "Period (in secs) for throttling logging for high-traffic operations"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_HDRNESTLIMIT, hdrnestlimit, - CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, + "Maximum number of nested header options to process"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DAD_COUNT, dad_count, CTLFLAG_RW, - &VNET_NAME(ip6_dad_count), 0, ""); + &VNET_NAME(ip6_dad_count), 0, + "Number of Duplicate Address Detection attempts to try before " + "disabling interface. Setting the value to 0 disables DAD"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_FLOWLABEL, auto_flowlabel, - CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, + "Automatically attach a flowlabel to IPv6 packets"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFMCASTHLIM, defmcasthlim, - CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, + "Default hop limit for ip6 multicast packets"); SYSCTL_STRING(_net_inet6_ip6, IPV6CTL_KAME_VERSION, kame_version, - CTLFLAG_RD, __KAME_VERSION, 0, ""); + CTLFLAG_RD, __KAME_VERSION, 0, + ""); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEPRECATED, use_deprecated, - CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, ""); -SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RR_PRUNE, rr_prune, CTLFLAG_RW, - &VNET_NAME(ip6_rr_prune), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, + "Use deprecated IPv6 support"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USETEMPADDR, use_tempaddr, - CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, + "Use a temporary address when establishing address via SLAAC"); SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPPLTIME, temppltime, - CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_preferred_lifetime), 0, - sysctl_ip6_temppltime, "I", ""); + CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_preferred_lifetime), 0, + sysctl_ip6_temppltime, "I", + "Preferred lifetime (in secs) for a temporary address"); SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPVLTIME, tempvltime, - CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_valid_lifetime), 0, - sysctl_ip6_tempvltime, "I", ""); + CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_valid_lifetime), 0, + sysctl_ip6_tempvltime, "I", + "Valid lifetime (in secs) for a temporary address"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_V6ONLY, v6only, CTLFLAG_RW, - &VNET_NAME(ip6_v6only), 0, ""); + &VNET_NAME(ip6_v6only), 0, + "Allow IPv4-mapped ip6 addresses per RFC 3493"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_LINKLOCAL, auto_linklocal, - CTLFLAG_RW, &VNET_NAME(ip6_auto_linklocal), 0, - "Default value of per-interface flag for automatically adding an IPv6" - " link-local address to interfaces when attached"); -SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_RIP6STATS, rip6stats, CTLFLAG_RW, - &VNET_NAME(rip6stat), rip6stat, ""); + CTLFLAG_RW, &VNET_NAME(ip6_auto_linklocal), 0, + "Default value of per-interface flag for automatically adding an ip6 " + "link-local address to interfaces when attached"); +SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_RIPV6STATS, rip6stats, CTLFLAG_RW, + &VNET_NAME(rip6stat), rip6stat, + "RIP6 statistics"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_PREFER_TEMPADDR, prefer_tempaddr, - CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, ""); + CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, + "Prefer the temporary address assigned when performing NUD"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEFAULTZONE, use_defaultzone, - CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0,""); + CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0, + "Use the default scope zone if not explicitly provided"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGS, maxfrags, CTLFLAG_RW, - &VNET_NAME(ip6_maxfrags), 0, ""); + &VNET_NAME(ip6_maxfrags), 0, + "Maximum number of fragments to hold in the reassembly queue"); SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MCAST_PMTU, mcast_pmtu, CTLFLAG_RW, - &VNET_NAME(ip6_mcast_pmtu), 0, ""); + &VNET_NAME(ip6_mcast_pmtu), 0, + "Enable multicast pMTU discovery"); #ifdef IPSTEALTH SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_STEALTH, stealth, CTLFLAG_RW, - &VNET_NAME(ip6stealth), 0, ""); + &VNET_NAME(ip6stealth), 0, + "IPv6 stealth mode. No hop limit decrementation on forwarding"); #endif #ifdef FLOWTABLE @@ -600,29 +619,39 @@ /* net.inet6.icmp6 */ SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRACCEPT, rediraccept, - CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, ""); -SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRTIMEOUT, redirtimeout, - CTLFLAG_RW, &VNET_NAME(icmp6_redirtimeout), 0, ""); + CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, + "Accept and process router redirects"); SYSCTL_VNET_STRUCT(_net_inet6_icmp6, ICMPV6CTL_STATS, stats, CTLFLAG_RW, - &VNET_NAME(icmp6stat), icmp6stat, ""); + &VNET_NAME(icmp6stat), icmp6stat, + "ICMPv6 statistics"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, CTLFLAG_RW, - &VNET_NAME(nd6_prune), 0, ""); + &VNET_NAME(nd6_prune), 0, + "Period (in secs) for checking for stale router entries via nd6"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DELAY, nd6_delay, CTLFLAG_RW, - &VNET_NAME(nd6_delay), 0, ""); + &VNET_NAME(nd6_delay), 0, + "Delay (in secs) before performing NUD on stale nodes"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, + "Maximum number of unicast queries to perform via nd6"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MMAXTRIES, nd6_mmaxtries, - CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, + "Maximum number of multicast queries to perform via nd6"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_USELOOPBACK, nd6_useloopback, - CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, + "Use loopback interface for local traffic"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_NODEINFO, nodeinfo, CTLFLAG_RW, - &VNET_NAME(icmp6_nodeinfo), 0, ""); + &VNET_NAME(icmp6_nodeinfo), 0, + "Node information state"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ERRPPSLIMIT, errppslimit, - CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, ""); + CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, + "Packets per second limit for ICMPv6 queries"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MAXNUDHINT, nd6_maxnudhint, - CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, ""); + CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, + "Maximum number of upper layer hints"); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DEBUG, nd6_debug, CTLFLAG_RW, - &VNET_NAME(nd6_debug), 0, ""); + &VNET_NAME(nd6_debug), 0, + ""); SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_ONLINKNSRFC4861, - nd6_onlink_ns_rfc4861, CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), - 0, "Accept 'on-link' nd6 NS in compliance with RFC 4861."); + nd6_onlink_ns_rfc4861, + CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), 0, + "Accept 'on-link' nd6 NS in compliance with RFC 4861"); --967339439-1681226068-1354342829=:57210 Content-Type: TEXT/PLAIN; charset=US-ASCII; name=document-netinet6_sysctls.patch.txt Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: Content-Disposition: attachment; filename=document-netinet6_sysctls.patch.txt SW5kZXg6IHN5cy9uZXRpbmV0Ni9pbjZfcHJvdG8uYw0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQ0KLS0tIHN5cy9uZXRpbmV0Ni9pbjZfcHJvdG8uYwkocmV2 aXNpb24gMjQzNTU3KQ0KKysrIHN5cy9uZXRpbmV0Ni9pbjZfcHJvdG8uYwko d29ya2luZyBjb3B5KQ0KQEAgLTEzMSw3ICsxMzEsNyBAQA0KICNlbmRpZg0K IA0KIC8qDQotICogVENQL0lQIHByb3RvY29sIGZhbWlseTogSVA2LCBJQ01Q NiwgVURQLCBUQ1AuDQorICogVENQL0lQIHByb3RvY29sIGZhbWlseTogSVB2 NiwgSUNNUHY2LCBVRFB2NiwgVENQdjYuDQogICovDQogRkVBVFVSRShpbmV0 NiwgIkludGVybmV0IFByb3RvY29sIHZlcnNpb24gNiIpOw0KIA0KQEAgLTM4 Miw5ICszODIsOSBAQA0KICAqLw0KICNpZm5kZWYJSVBWNkZPUldBUkRJTkcN CiAjaWZkZWYgR0FURVdBWTYNCi0jZGVmaW5lCUlQVjZGT1JXQVJESU5HCTEJ LyogZm9yd2FyZCBJUDYgcGFja2V0cyBub3QgZm9yIHVzICovDQorI2RlZmlu ZQlJUFY2Rk9SV0FSRElORwkxCS8qIGZvcndhcmQgSVB2NiBwYWNrZXRzICov DQogI2Vsc2UNCi0jZGVmaW5lCUlQVjZGT1JXQVJESU5HCTAJLyogZG9uJ3Qg Zm9yd2FyZCBJUDYgcGFja2V0cyBub3QgZm9yIHVzICovDQorI2RlZmluZQlJ UFY2Rk9SV0FSRElORwkwCS8qIGRvbid0IGZvcndhcmQgSVB2NiBwYWNrZXRz ICovDQogI2VuZGlmIC8qIEdBVEVXQVk2ICovDQogI2VuZGlmIC8qICFJUFY2 Rk9SV0FSRElORyAqLw0KIA0KQEAgLTQwOSw4ICs0MDksNiBAQA0KIFZORVRf REVGSU5FKGludCwgaXA2X2F1dG9fZmxvd2xhYmVsKSA9IDE7DQogVk5FVF9E RUZJTkUoaW50LCBpcDZfdXNlX2RlcHJlY2F0ZWQpID0gMTsvKiBhbGxvdyBk ZXByZWNhdGVkIGFkZHINCiAJCQkJCSAqIChSRkMyNDYyIDUuNS40KSAqLw0K LVZORVRfREVGSU5FKGludCwgaXA2X3JyX3BydW5lKSA9IDU7CS8qIHJvdXRl ciByZW51bWJlcmluZyBwcmVmaXgNCi0JCQkJCSAqIHdhbGsgbGlzdCBldmVy eSA1IHNlYy4gKi8NCiBWTkVUX0RFRklORShpbnQsIGlwNl9tY2FzdF9wbXR1 KSA9IDA7CS8qIGVuYWJsZSBwTVRVIGRpc2NvdmVyeSBmb3IgbXVsdGljYXN0 PyAqLw0KIFZORVRfREVGSU5FKGludCwgaXA2X3Y2b25seSkgPSAxOw0KIA0K QEAgLTQzMSw3ICs0MjksNyBAQA0KIFZORVRfREVGSU5FKGludCwgcG10dV9l eHBpcmUpID0gNjAqMTA7DQogVk5FVF9ERUZJTkUoaW50LCBwbXR1X3Byb2Jl KSA9IDYwKjI7DQogDQotLyogcmF3IElQNiBwYXJhbWV0ZXJzICovDQorLyog cmF3IElQVjYgcGFyYW1ldGVycyAqLw0KIC8qDQogICogTm9taW5hbCBzcGFj ZSBhbGxvY2F0ZWQgdG8gYSByYXcgaXAgc29ja2V0Lg0KICAqLw0KQEAgLTQ0 MywxMyArNDQxLDEyIEBADQogDQogLyogSUNNUFY2IHBhcmFtZXRlcnMgKi8N CiBWTkVUX0RFRklORShpbnQsIGljbXA2X3JlZGlyYWNjZXB0KSA9IDE7Lyog YWNjZXB0IGFuZCBwcm9jZXNzIHJlZGlyZWN0cyAqLw0KLVZORVRfREVGSU5F KGludCwgaWNtcDZfcmVkaXJ0aW1lb3V0KSA9IDEwICogNjA7CS8qIDEwIG1p bnV0ZXMgKi8NCiBWTkVUX0RFRklORShpbnQsIGljbXA2ZXJycHBzbGltKSA9 IDEwMDsJCS8qIDEwMHBwcyAqLw0KIC8qIGNvbnRyb2wgaG93IHRvIHJlc3Bv bmQgdG8gTkkgcXVlcmllcyAqLw0KIFZORVRfREVGSU5FKGludCwgaWNtcDZf bm9kZWluZm8pID0NCiAgICAgKElDTVA2X05PREVJTkZPX0ZRRE5PS3xJQ01Q Nl9OT0RFSU5GT19OT0RFQUREUk9LKTsNCiANCi0vKiBVRFAgb24gSVA2IHBh cmFtZXRlcnMgKi8NCisvKiBVRFAgb24gSVB2NiBwYXJhbWV0ZXJzICovDQog Vk5FVF9ERUZJTkUoaW50LCB1ZHA2X3NlbmRzcGFjZSkgPSA5MjE2Oy8qIHJl YWxseSBtYXggZGF0YWdyYW0gc2l6ZSAqLw0KIFZORVRfREVGSU5FKGludCwg dWRwNl9yZWN2c3BhY2UpID0gNDAgKiAoMTAyNCArIHNpemVvZihzdHJ1Y3Qg c29ja2FkZHJfaW42KSk7DQogCQkJCQkvKiA0MCAxSyBkYXRhZ3JhbXMgKi8N CkBAIC00NjEsMTIgKzQ1OCwxMiBAQA0KIAkiSW50ZXJuZXQ2IEZhbWlseSIp Ow0KIA0KIC8qIG5ldC5pbmV0NiAqLw0KLVNZU0NUTF9OT0RFKF9uZXRfaW5l dDYsCUlQUFJPVE9fSVBWNiwJaXA2LAlDVExGTEFHX1JXLCAwLAkiSVA2Iik7 DQotU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJSVBQUk9UT19JQ01QVjYsCWlj bXA2LAlDVExGTEFHX1JXLCAwLAkiSUNNUDYiKTsNCi1TWVNDVExfTk9ERShf bmV0X2luZXQ2LAlJUFBST1RPX1VEUCwJdWRwNiwJQ1RMRkxBR19SVywgMCwJ IlVEUDYiKTsNCi1TWVNDVExfTk9ERShfbmV0X2luZXQ2LAlJUFBST1RPX1RD UCwJdGNwNiwJQ1RMRkxBR19SVywgMCwJIlRDUDYiKTsNCitTWVNDVExfTk9E RShfbmV0X2luZXQ2LAlJUFBST1RPX0lQVjYsCWlwNiwJQ1RMRkxBR19SVywg MCwJIklQdjYiKTsNCitTWVNDVExfTk9ERShfbmV0X2luZXQ2LAlJUFBST1RP X0lDTVBWNiwJaWNtcDYsCUNUTEZMQUdfUlcsIDAsCSJJQ01QdjYiKTsNCitT WVNDVExfTk9ERShfbmV0X2luZXQ2LAlJUFBST1RPX1VEUCwJdWRwNiwJQ1RM RkxBR19SVywgMCwJIlVEUHY2Iik7DQorU1lTQ1RMX05PREUoX25ldF9pbmV0 NiwJSVBQUk9UT19UQ1AsCXRjcDYsCUNUTEZMQUdfUlcsIDAsCSJUQ1B2NiIp Ow0KICNpZmRlZiBTQ1RQDQotU1lTQ1RMX05PREUoX25ldF9pbmV0NiwJSVBQ Uk9UT19TQ1RQLAlzY3RwNiwJQ1RMRkxBR19SVywgMCwJIlNDVFA2Iik7DQor U1lTQ1RMX05PREUoX25ldF9pbmV0NiwJSVBQUk9UT19TQ1RQLAlzY3RwNiwJ Q1RMRkxBR19SVywgMCwJIlNDVFB2NiIpOw0KICNlbmRpZg0KICNpZmRlZiBJ UFNFQw0KIFNZU0NUTF9OT0RFKF9uZXRfaW5ldDYsCUlQUFJPVE9fRVNQLAlp cHNlYzYsCUNUTEZMQUdfUlcsIDAsCSJJUFNFQzYiKTsNCkBAIC01MTUsNzcg KzUxMiw5OSBAQA0KIH0NCiANCiBTWVNDVExfVk5FVF9JTlQoX25ldF9pbmV0 Nl9pcDYsIElQVjZDVExfRk9SV0FSRElORywgZm9yd2FyZGluZywgQ1RMRkxB R19SVywNCi0JJlZORVRfTkFNRShpcDZfZm9yd2FyZGluZyksIDAsICIiKTsN CisgICAgJlZORVRfTkFNRShpcDZfZm9yd2FyZGluZyksIDAsDQorICAgICJG b3J3YXJkIElQdjYgcGFja2V0cyB2aWEgbm9kZSIpOw0KIFNZU0NUTF9WTkVU X0lOVChfbmV0X2luZXQ2X2lwNiwgSVBWNkNUTF9TRU5EUkVESVJFQ1RTLCBy ZWRpcmVjdCwgQ1RMRkxBR19SVywNCi0JJlZORVRfTkFNRShpcDZfc2VuZHJl ZGlyZWN0cyksIDAsICIiKTsNCisgICAgJlZORVRfTkFNRShpcDZfc2VuZHJl ZGlyZWN0cyksIDAsDQorICAgICJSZWRpcmVjdCBJUHY2IHBhY2tldHMgdmlh IG5vZGUiKTsNCiBTWVNDVExfVk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYsIElQ VjZDVExfREVGSExJTSwgaGxpbSwgQ1RMRkxBR19SVywNCi0JJlZORVRfTkFN RShpcDZfZGVmaGxpbSksIDAsICIiKTsNCisgICAgJlZORVRfTkFNRShpcDZf ZGVmaGxpbSksIDAsDQorICAgICJEZWZhdWx0IGhvcCBsaW1pdCBmb3IgSVB2 NiB1bmljYXN0IHBhY2tldHMiKTsNCiBTWVNDVExfVk5FVF9TVFJVQ1QoX25l dF9pbmV0Nl9pcDYsIElQVjZDVExfU1RBVFMsIHN0YXRzLCBDVExGTEFHX1JX LA0KLQkmVk5FVF9OQU1FKGlwNnN0YXQpLCBpcDZzdGF0LCAiIik7DQorICAg ICZWTkVUX05BTUUoaXA2c3RhdCksIGlwNnN0YXQsDQorICAgICJJUHY2IHN0 YXRpc3RpY3MiKTsNCiBTWVNDVExfVk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYs IElQVjZDVExfTUFYRlJBR1BBQ0tFVFMsIG1heGZyYWdwYWNrZXRzLA0KLQlD VExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl9tYXhmcmFncGFja2V0cyksIDAs ICIiKTsNCisgICAgQ1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfbWF4ZnJh Z3BhY2tldHMpLCAwLA0KKyAgICAiTWF4aW11bSBudW1iZXIgb2YgZnJhZ21l bnRlZCBwYWNrZXRzIHRvIHByb2Nlc3MiKTsNCiBTWVNDVExfVk5FVF9JTlQo X25ldF9pbmV0Nl9pcDYsIElQVjZDVExfQUNDRVBUX1JUQURWLCBhY2NlcHRf cnRhZHYsDQotCUNUTEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X2FjY2VwdF9y dGFkdiksIDAsDQotCSJEZWZhdWx0IHZhbHVlIG9mIHBlci1pbnRlcmZhY2Ug ZmxhZyBmb3IgYWNjZXB0aW5nIElDTVB2NiBSb3V0ZXIiDQotCSJBZHZlcnRp c2VtZW50IG1lc3NhZ2VzIik7DQorICAgIENUTEZMQUdfUlcsICZWTkVUX05B TUUoaXA2X2FjY2VwdF9ydGFkdiksIDAsDQorICAgICJEZWZhdWx0IHZhbHVl IG9mIHBlci1pbnRlcmZhY2UgZmxhZyBmb3IgYWNjZXB0aW5nIElDTVB2NiBS b3V0ZXIiDQorICAgICJBZHZlcnRpc2VtZW50IG1lc3NhZ2VzIik7DQogU1lT Q1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2LCBJUFY2Q1RMX05PX1JBRFIs IG5vX3JhZHIsDQotCUNUTEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X25vX3Jh ZHIpLCAwLA0KLQkiRGVmYXVsdCB2YWx1ZSBvZiBwZXItaW50ZXJmYWNlIGZs YWcgdG8gY29udHJvbCB3aGV0aGVyIHJvdXRlcnMgIg0KLQkic2VuZGluZyBJ Q01QdjYgUkEgbWVzc2FnZXMgb24gdGhhdCBpbnRlcmZhY2UgYXJlIGFkZGVk IGludG8gdGhlICINCi0JImRlZmF1bHQgcm91dGVyIGxpc3QuIik7DQorICAg IENUTEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X25vX3JhZHIpLCAwLA0KKyAg ICAiRGVmYXVsdCB2YWx1ZSBvZiBwZXItaW50ZXJmYWNlIGZsYWcgdG8gY29u dHJvbCB3aGV0aGVyIHJvdXRlcnMgIg0KKyAgICAic2VuZGluZyBJQ01QdjYg UkEgbWVzc2FnZXMgb24gdGhhdCBpbnRlcmZhY2UgYXJlIGFkZGVkIGludG8g dGhlICINCisgICAgImRlZmF1bHQgcm91dGVyIGxpc3QiKTsNCiBTWVNDVExf Vk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfTk9SQklUX1JBSUYs IG5vcmJpdF9yYWlmLCBDVExGTEFHX1JXLA0KLQkmVk5FVF9OQU1FKGlwNl9u b3JiaXRfcmFpZiksIDAsDQotCSJBbHdheXMgc2V0IDAgdG8gUiBmbGFnIGlu IElDTVB2NiBOQSBtZXNzYWdlcyB3aGVuIGFjY2VwdGluZyBSQSINCi0JIiBv biB0aGUgaW50ZXJmYWNlLiIpOw0KKyAgICAmVk5FVF9OQU1FKGlwNl9ub3Ji aXRfcmFpZiksIDAsDQorICAgICJBbHdheXMgc2V0IDAgdG8gUiBmbGFnIGlu IElDTVB2NiBOQSBtZXNzYWdlcyB3aGVuIGFjY2VwdGluZyBSQSAiDQorICAg ICJvbiB0aGUgaW50ZXJmYWNlIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRf aW5ldDZfaXA2LCBJUFY2Q1RMX1JGQzYyMDRXMywgcmZjNjIwNHczLA0KLQlD VExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl9yZmM2MjA0dzMpLCAwLA0KLQki QWNjZXB0IHRoZSBkZWZhdWx0IHJvdXRlciBsaXN0IGZyb20gSUNNUHY2IFJB IG1lc3NhZ2VzIGV2ZW4gIg0KLQkid2hlbiBwYWNrZXQgZm9yd2FyZGluZyBl bmFibGVkLiIpOw0KKyAgICBDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl9y ZmM2MjA0dzMpLCAwLA0KKyAgICAiQWNjZXB0IHRoZSBkZWZhdWx0IHJvdXRl ciBsaXN0IGZyb20gSUNNUHY2IFJBIG1lc3NhZ2VzIGV2ZW4gd2hlbiBwYWNr ZXQgIg0KKyAgICAiZm9yd2FyZGluZyBlbmFibGVkIik7DQogU1lTQ1RMX1ZO RVRfSU5UKF9uZXRfaW5ldDZfaXA2LCBJUFY2Q1RMX0tFRVBGQUlUSCwga2Vl cGZhaXRoLCBDVExGTEFHX1JXLA0KLQkmVk5FVF9OQU1FKGlwNl9rZWVwZmFp dGgpLCAwLCAiIik7DQorICAgICZWTkVUX05BTUUoaXA2X2tlZXBmYWl0aCks IDAsDQorICAgICIiKTsNCiBTWVNDVExfVk5FVF9JTlQoX25ldF9pbmV0Nl9p cDYsIElQVjZDVExfTE9HX0lOVEVSVkFMLCBsb2dfaW50ZXJ2YWwsDQotCUNU TEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X2xvZ19pbnRlcnZhbCksIDAsICIi KTsNCisgICAgQ1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfbG9nX2ludGVy dmFsKSwgMCwNCisgICAgIlBlcmlvZCAoaW4gc2VjcykgZm9yIHRocm90dGxp bmcgbG9nZ2luZyBmb3IgaGlnaC10cmFmZmljIG9wZXJhdGlvbnMiKTsNCiBT WVNDVExfVk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfSERSTkVT VExJTUlULCBoZHJuZXN0bGltaXQsDQotCUNUTEZMQUdfUlcsICZWTkVUX05B TUUoaXA2X2hkcm5lc3RsaW1pdCksIDAsICIiKTsNCisgICAgQ1RMRkxBR19S VywgJlZORVRfTkFNRShpcDZfaGRybmVzdGxpbWl0KSwgMCwNCisgICAgIk1h eGltdW0gbnVtYmVyIG9mIG5lc3RlZCBoZWFkZXIgb3B0aW9ucyB0byBwcm9j ZXNzIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2LCBJUFY2 Q1RMX0RBRF9DT1VOVCwgZGFkX2NvdW50LCBDVExGTEFHX1JXLA0KLQkmVk5F VF9OQU1FKGlwNl9kYWRfY291bnQpLCAwLCAiIik7DQorICAgICZWTkVUX05B TUUoaXA2X2RhZF9jb3VudCksIDAsDQorICAgICJOdW1iZXIgb2YgRHVwbGlj YXRlIEFkZHJlc3MgRGV0ZWN0aW9uIGF0dGVtcHRzIHRvIHRyeSBiZWZvcmUg Ig0KKyAgICAiZGlzYWJsaW5nIGludGVyZmFjZS4gIFNldHRpbmcgdGhlIHZh bHVlIHRvIDAgZGlzYWJsZXMgREFEIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9u ZXRfaW5ldDZfaXA2LCBJUFY2Q1RMX0FVVE9fRkxPV0xBQkVMLCBhdXRvX2Zs b3dsYWJlbCwNCi0JQ1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfYXV0b19m bG93bGFiZWwpLCAwLCAiIik7DQorICAgIENUTEZMQUdfUlcsICZWTkVUX05B TUUoaXA2X2F1dG9fZmxvd2xhYmVsKSwgMCwNCisgICAgIkF1dG9tYXRpY2Fs bHkgYXR0YWNoIGEgZmxvd2xhYmVsIHRvIElQdjYgcGFja2V0cyIpOw0KIFNZ U0NUTF9WTkVUX0lOVChfbmV0X2luZXQ2X2lwNiwgSVBWNkNUTF9ERUZNQ0FT VEhMSU0sIGRlZm1jYXN0aGxpbSwNCi0JQ1RMRkxBR19SVywgJlZORVRfTkFN RShpcDZfZGVmbWNhc3RobGltKSwgMCwgIiIpOw0KKyAgICBDVExGTEFHX1JX LCAmVk5FVF9OQU1FKGlwNl9kZWZtY2FzdGhsaW0pLCAwLA0KKyAgICAiRGVm YXVsdCBob3AgbGltaXQgZm9yIGlwNiBtdWx0aWNhc3QgcGFja2V0cyIpOw0K IFNZU0NUTF9TVFJJTkcoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfS0FNRV9W RVJTSU9OLCBrYW1lX3ZlcnNpb24sDQotCUNUTEZMQUdfUkQsIF9fS0FNRV9W RVJTSU9OLCAwLCAiIik7DQorICAgIENUTEZMQUdfUkQsIF9fS0FNRV9WRVJT SU9OLCAwLA0KKyAgICAiIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5l dDZfaXA2LCBJUFY2Q1RMX1VTRV9ERVBSRUNBVEVELCB1c2VfZGVwcmVjYXRl ZCwNCi0JQ1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfdXNlX2RlcHJlY2F0 ZWQpLCAwLCAiIik7DQotU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2 LCBJUFY2Q1RMX1JSX1BSVU5FLCBycl9wcnVuZSwgQ1RMRkxBR19SVywNCi0J JlZORVRfTkFNRShpcDZfcnJfcHJ1bmUpLCAwLCAiIik7DQorICAgIENUTEZM QUdfUlcsICZWTkVUX05BTUUoaXA2X3VzZV9kZXByZWNhdGVkKSwgMCwNCisg ICAgIlVzZSBkZXByZWNhdGVkIElQdjYgc3VwcG9ydCIpOw0KIFNZU0NUTF9W TkVUX0lOVChfbmV0X2luZXQ2X2lwNiwgSVBWNkNUTF9VU0VURU1QQUREUiwg dXNlX3RlbXBhZGRyLA0KLQlDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl91 c2VfdGVtcGFkZHIpLCAwLCAiIik7DQorICAgIENUTEZMQUdfUlcsICZWTkVU X05BTUUoaXA2X3VzZV90ZW1wYWRkciksIDAsDQorICAgICJVc2UgYSB0ZW1w b3JhcnkgYWRkcmVzcyB3aGVuIGVzdGFibGlzaGluZyBhZGRyZXNzIHZpYSBT TEFBQyIpOw0KIFNZU0NUTF9WTkVUX1BST0MoX25ldF9pbmV0Nl9pcDYsIElQ VjZDVExfVEVNUFBMVElNRSwgdGVtcHBsdGltZSwNCi0JQ1RMVFlQRV9JTlR8 Q1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfdGVtcF9wcmVmZXJyZWRfbGlm ZXRpbWUpLCAwLA0KLSAgIAlzeXNjdGxfaXA2X3RlbXBwbHRpbWUsICJJIiwg IiIpOw0KKyAgICBDVExUWVBFX0lOVHxDVExGTEFHX1JXLCAmVk5FVF9OQU1F KGlwNl90ZW1wX3ByZWZlcnJlZF9saWZldGltZSksIDAsDQorICAgIHN5c2N0 bF9pcDZfdGVtcHBsdGltZSwgIkkiLA0KKyAgICAiUHJlZmVycmVkIGxpZmV0 aW1lIChpbiBzZWNzKSBmb3IgYSB0ZW1wb3JhcnkgYWRkcmVzcyIpOw0KIFNZ U0NUTF9WTkVUX1BST0MoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfVEVNUFZM VElNRSwgdGVtcHZsdGltZSwNCi0JQ1RMVFlQRV9JTlR8Q1RMRkxBR19SVywg JlZORVRfTkFNRShpcDZfdGVtcF92YWxpZF9saWZldGltZSksIDAsDQotICAg CXN5c2N0bF9pcDZfdGVtcHZsdGltZSwgIkkiLCAiIik7DQorICAgIENUTFRZ UEVfSU5UfENUTEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X3RlbXBfdmFsaWRf bGlmZXRpbWUpLCAwLA0KKyAgICBzeXNjdGxfaXA2X3RlbXB2bHRpbWUsICJJ IiwNCisgICAgIlZhbGlkIGxpZmV0aW1lIChpbiBzZWNzKSBmb3IgYSB0ZW1w b3JhcnkgYWRkcmVzcyIpOw0KIFNZU0NUTF9WTkVUX0lOVChfbmV0X2luZXQ2 X2lwNiwgSVBWNkNUTF9WNk9OTFksIHY2b25seSwJQ1RMRkxBR19SVywNCi0J JlZORVRfTkFNRShpcDZfdjZvbmx5KSwgMCwgIiIpOw0KKyAgICAmVk5FVF9O QU1FKGlwNl92Nm9ubHkpLCAwLA0KKyAgICAiQWxsb3cgSVB2NC1tYXBwZWQg aXA2IGFkZHJlc3NlcyBwZXIgUkZDIDM0OTMiKTsNCiBTWVNDVExfVk5FVF9J TlQoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfQVVUT19MSU5LTE9DQUwsIGF1 dG9fbGlua2xvY2FsLA0KLQlDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl9h dXRvX2xpbmtsb2NhbCksIDAsDQotCSJEZWZhdWx0IHZhbHVlIG9mIHBlci1p bnRlcmZhY2UgZmxhZyBmb3IgYXV0b21hdGljYWxseSBhZGRpbmcgYW4gSVB2 NiINCi0JIiBsaW5rLWxvY2FsIGFkZHJlc3MgdG8gaW50ZXJmYWNlcyB3aGVu IGF0dGFjaGVkIik7DQotU1lTQ1RMX1ZORVRfU1RSVUNUKF9uZXRfaW5ldDZf aXA2LCBJUFY2Q1RMX1JJUDZTVEFUUywgcmlwNnN0YXRzLCBDVExGTEFHX1JX LA0KLQkmVk5FVF9OQU1FKHJpcDZzdGF0KSwgcmlwNnN0YXQsICIiKTsNCisg ICAgQ1RMRkxBR19SVywgJlZORVRfTkFNRShpcDZfYXV0b19saW5rbG9jYWwp LCAwLA0KKyAgICAiRGVmYXVsdCB2YWx1ZSBvZiBwZXItaW50ZXJmYWNlIGZs YWcgZm9yIGF1dG9tYXRpY2FsbHkgYWRkaW5nIGFuIGlwNiAiDQorICAgICJs aW5rLWxvY2FsIGFkZHJlc3MgdG8gaW50ZXJmYWNlcyB3aGVuIGF0dGFjaGVk Iik7DQorU1lTQ1RMX1ZORVRfU1RSVUNUKF9uZXRfaW5ldDZfaXA2LCBJUFY2 Q1RMX1JJUFY2U1RBVFMsIHJpcDZzdGF0cywgQ1RMRkxBR19SVywNCisgICAg JlZORVRfTkFNRShyaXA2c3RhdCksIHJpcDZzdGF0LA0KKyAgICAiUklQNiBz dGF0aXN0aWNzIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2 LCBJUFY2Q1RMX1BSRUZFUl9URU1QQUREUiwgcHJlZmVyX3RlbXBhZGRyLA0K LQlDVExGTEFHX1JXLCAmVk5FVF9OQU1FKGlwNl9wcmVmZXJfdGVtcGFkZHIp LCAwLCAiIik7DQorICAgIENUTEZMQUdfUlcsICZWTkVUX05BTUUoaXA2X3By ZWZlcl90ZW1wYWRkciksIDAsDQorICAgICJQcmVmZXIgdGhlIHRlbXBvcmFy eSBhZGRyZXNzIGFzc2lnbmVkIHdoZW4gcGVyZm9ybWluZyBOVUQiKTsNCiBT WVNDVExfVk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfVVNFX0RF RkFVTFRaT05FLCB1c2VfZGVmYXVsdHpvbmUsDQotCUNUTEZMQUdfUlcsICZW TkVUX05BTUUoaXA2X3VzZV9kZWZ6b25lKSwgMCwiIik7DQorICAgIENUTEZM QUdfUlcsICZWTkVUX05BTUUoaXA2X3VzZV9kZWZ6b25lKSwgMCwNCisgICAg IlVzZSB0aGUgZGVmYXVsdCBzY29wZSB6b25lIGlmIG5vdCBleHBsaWNpdGx5 IHByb3ZpZGVkIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2 LCBJUFY2Q1RMX01BWEZSQUdTLCBtYXhmcmFncywgQ1RMRkxBR19SVywNCi0J JlZORVRfTkFNRShpcDZfbWF4ZnJhZ3MpLCAwLCAiIik7DQorICAgICZWTkVU X05BTUUoaXA2X21heGZyYWdzKSwgMCwNCisgICAgIk1heGltdW0gbnVtYmVy IG9mIGZyYWdtZW50cyB0byBob2xkIGluIHRoZSByZWFzc2VtYmx5IHF1ZXVl Iik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaXA2LCBJUFY2Q1RM X01DQVNUX1BNVFUsIG1jYXN0X3BtdHUsIENUTEZMQUdfUlcsDQotCSZWTkVU X05BTUUoaXA2X21jYXN0X3BtdHUpLCAwLCAiIik7DQorICAgICZWTkVUX05B TUUoaXA2X21jYXN0X3BtdHUpLCAwLA0KKyAgICAiRW5hYmxlIG11bHRpY2Fz dCBwTVRVIGRpc2NvdmVyeSIpOw0KICNpZmRlZiBJUFNURUFMVEgNCiBTWVND VExfVk5FVF9JTlQoX25ldF9pbmV0Nl9pcDYsIElQVjZDVExfU1RFQUxUSCwg c3RlYWx0aCwgQ1RMRkxBR19SVywNCi0JJlZORVRfTkFNRShpcDZzdGVhbHRo KSwgMCwgIiIpOw0KKyAgICAmVk5FVF9OQU1FKGlwNnN0ZWFsdGgpLCAwLA0K KyAgICAiSVB2NiBzdGVhbHRoIG1vZGUuIE5vIGhvcCBsaW1pdCBkZWNyZW1l bnRhdGlvbiBvbiBmb3J3YXJkaW5nIik7DQogI2VuZGlmDQogDQogI2lmZGVm IEZMT1dUQUJMRQ0KQEAgLTYwMCwyOSArNjE5LDM5IEBADQogDQogLyogbmV0 LmluZXQ2LmljbXA2ICovDQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZf aWNtcDYsIElDTVBWNkNUTF9SRURJUkFDQ0VQVCwgcmVkaXJhY2NlcHQsDQot CUNUTEZMQUdfUlcsICZWTkVUX05BTUUoaWNtcDZfcmVkaXJhY2NlcHQpLCAw LCAiIik7DQotU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaWNtcDYsIElD TVBWNkNUTF9SRURJUlRJTUVPVVQsIHJlZGlydGltZW91dCwNCi0JQ1RMRkxB R19SVywgJlZORVRfTkFNRShpY21wNl9yZWRpcnRpbWVvdXQpLCAwLCAiIik7 DQorICAgIENUTEZMQUdfUlcsICZWTkVUX05BTUUoaWNtcDZfcmVkaXJhY2Nl cHQpLCAwLA0KKyAgICAiQWNjZXB0IGFuZCBwcm9jZXNzIHJvdXRlciByZWRp cmVjdHMiKTsNCiBTWVNDVExfVk5FVF9TVFJVQ1QoX25ldF9pbmV0Nl9pY21w NiwgSUNNUFY2Q1RMX1NUQVRTLCBzdGF0cywgQ1RMRkxBR19SVywNCi0JJlZO RVRfTkFNRShpY21wNnN0YXQpLCBpY21wNnN0YXQsICIiKTsNCisgICAgJlZO RVRfTkFNRShpY21wNnN0YXQpLCBpY21wNnN0YXQsDQorICAgICJJQ01QdjYg c3RhdGlzdGljcyIpOw0KIFNZU0NUTF9WTkVUX0lOVChfbmV0X2luZXQ2X2lj bXA2LCBJQ01QVjZDVExfTkQ2X1BSVU5FLCBuZDZfcHJ1bmUsIENUTEZMQUdf UlcsDQotCSZWTkVUX05BTUUobmQ2X3BydW5lKSwgMCwgIiIpOw0KKyAgICAm Vk5FVF9OQU1FKG5kNl9wcnVuZSksIDAsDQorICAgICJQZXJpb2QgKGluIHNl Y3MpIGZvciBjaGVja2luZyBmb3Igc3RhbGUgcm91dGVyIGVudHJpZXMgdmlh IG5kNiIpOw0KIFNZU0NUTF9WTkVUX0lOVChfbmV0X2luZXQ2X2ljbXA2LCBJ Q01QVjZDVExfTkQ2X0RFTEFZLCBuZDZfZGVsYXksIENUTEZMQUdfUlcsDQot CSZWTkVUX05BTUUobmQ2X2RlbGF5KSwgMCwgIiIpOw0KKyAgICAmVk5FVF9O QU1FKG5kNl9kZWxheSksIDAsDQorICAgICJEZWxheSAoaW4gc2VjcykgYmVm b3JlIHBlcmZvcm1pbmcgTlVEIG9uIHN0YWxlIG5vZGVzIik7DQogU1lTQ1RM X1ZORVRfSU5UKF9uZXRfaW5ldDZfaWNtcDYsIElDTVBWNkNUTF9ORDZfVU1B WFRSSUVTLCBuZDZfdW1heHRyaWVzLA0KLQlDVExGTEFHX1JXLCAmVk5FVF9O QU1FKG5kNl91bWF4dHJpZXMpLCAwLCAiIik7DQorICAgIENUTEZMQUdfUlcs ICZWTkVUX05BTUUobmQ2X3VtYXh0cmllcyksIDAsDQorICAgICJNYXhpbXVt IG51bWJlciBvZiB1bmljYXN0IHF1ZXJpZXMgdG8gcGVyZm9ybSB2aWEgbmQ2 Iik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaWNtcDYsIElDTVBW NkNUTF9ORDZfTU1BWFRSSUVTLCBuZDZfbW1heHRyaWVzLA0KLQlDVExGTEFH X1JXLCAmVk5FVF9OQU1FKG5kNl9tbWF4dHJpZXMpLCAwLCAiIik7DQorICAg IENUTEZMQUdfUlcsICZWTkVUX05BTUUobmQ2X21tYXh0cmllcyksIDAsDQor ICAgICJNYXhpbXVtIG51bWJlciBvZiBtdWx0aWNhc3QgcXVlcmllcyB0byBw ZXJmb3JtIHZpYSBuZDYiKTsNCiBTWVNDVExfVk5FVF9JTlQoX25ldF9pbmV0 Nl9pY21wNiwgSUNNUFY2Q1RMX05ENl9VU0VMT09QQkFDSywgbmQ2X3VzZWxv b3BiYWNrLA0KLQlDVExGTEFHX1JXLCAmVk5FVF9OQU1FKG5kNl91c2Vsb29w YmFjayksIDAsICIiKTsNCisgICAgQ1RMRkxBR19SVywgJlZORVRfTkFNRShu ZDZfdXNlbG9vcGJhY2spLCAwLA0KKyAgICAiVXNlIGxvb3BiYWNrIGludGVy ZmFjZSBmb3IgbG9jYWwgdHJhZmZpYyIpOw0KIFNZU0NUTF9WTkVUX0lOVChf bmV0X2luZXQ2X2ljbXA2LCBJQ01QVjZDVExfTk9ERUlORk8sIG5vZGVpbmZv LCBDVExGTEFHX1JXLA0KLQkmVk5FVF9OQU1FKGljbXA2X25vZGVpbmZvKSwg MCwgIiIpOw0KKyAgICAmVk5FVF9OQU1FKGljbXA2X25vZGVpbmZvKSwgMCwN CisgICAgIk5vZGUgaW5mb3JtYXRpb24gc3RhdGUiKTsNCiBTWVNDVExfVk5F VF9JTlQoX25ldF9pbmV0Nl9pY21wNiwgSUNNUFY2Q1RMX0VSUlBQU0xJTUlU LCBlcnJwcHNsaW1pdCwNCi0JQ1RMRkxBR19SVywgJlZORVRfTkFNRShpY21w NmVycnBwc2xpbSksIDAsICIiKTsNCisgICAgQ1RMRkxBR19SVywgJlZORVRf TkFNRShpY21wNmVycnBwc2xpbSksIDAsDQorICAgICJQYWNrZXRzIHBlciBz ZWNvbmQgbGltaXQgZm9yIElDTVB2NiBxdWVyaWVzIik7DQogU1lTQ1RMX1ZO RVRfSU5UKF9uZXRfaW5ldDZfaWNtcDYsIElDTVBWNkNUTF9ORDZfTUFYTlVE SElOVCwgbmQ2X21heG51ZGhpbnQsDQotCUNUTEZMQUdfUlcsICZWTkVUX05B TUUobmQ2X21heG51ZGhpbnQpLCAwLCAiIik7DQorICAgIENUTEZMQUdfUlcs ICZWTkVUX05BTUUobmQ2X21heG51ZGhpbnQpLCAwLA0KKyAgICAiTWF4aW11 bSBudW1iZXIgb2YgdXBwZXIgbGF5ZXIgaGludHMiKTsNCiBTWVNDVExfVk5F VF9JTlQoX25ldF9pbmV0Nl9pY21wNiwgSUNNUFY2Q1RMX05ENl9ERUJVRywg bmQ2X2RlYnVnLCBDVExGTEFHX1JXLA0KLQkmVk5FVF9OQU1FKG5kNl9kZWJ1 ZyksIDAsICIiKTsNCisgICAgJlZORVRfTkFNRShuZDZfZGVidWcpLCAwLA0K KyAgICAiIik7DQogU1lTQ1RMX1ZORVRfSU5UKF9uZXRfaW5ldDZfaWNtcDYs IElDTVBWNkNUTF9ORDZfT05MSU5LTlNSRkM0ODYxLA0KLQluZDZfb25saW5r X25zX3JmYzQ4NjEsIENUTEZMQUdfUlcsICZWTkVUX05BTUUobmQ2X29ubGlu a19uc19yZmM0ODYxKSwNCi0JMCwgIkFjY2VwdCAnb24tbGluaycgbmQ2IE5T IGluIGNvbXBsaWFuY2Ugd2l0aCBSRkMgNDg2MS4iKTsNCisgICAgbmQ2X29u bGlua19uc19yZmM0ODYxLA0KKyAgICBDVExGTEFHX1JXLCAmVk5FVF9OQU1F KG5kNl9vbmxpbmtfbnNfcmZjNDg2MSksIDAsDQorICAgICJBY2NlcHQgJ29u LWxpbmsnIG5kNiBOUyBpbiBjb21wbGlhbmNlIHdpdGggUkZDIDQ4NjEiKTsN Cg== --967339439-1681226068-1354342829=:57210-- From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 06:22:55 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E96062FA for ; Sat, 1 Dec 2012 06:22:54 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id B26B78FC08 for ; Sat, 1 Dec 2012 06:22:54 +0000 (UTC) Received: by mail-pb0-f54.google.com with SMTP id wz12so924182pbc.13 for ; Fri, 30 Nov 2012 22:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=CkU9VQa4kh9Wf+AeodY/SeBHkxg9hLaqtirZ/NVYVqo=; b=rxy3+Cp9G+PjEppCBRijunfRy/GzaZjeGJdC/JirXL7FS9ZZalIHhbXqsFzasNzzjs IWA7Zp4+Bn+pIxyyesZn0O4piZXSnbUQofH23tc77iBQZK83Q8BKUatMeO3BIeZCGFj1 9hF4tb4j3RkiiB3ppJHT5kgAxSGn7ZHjyDq1QjbkJc6fIBxzO/a5boHWlAOtIKBs6IXx r/7YYvIoskQx8oPunC+DzCs9zHuuFPX9lWZ79ux3V8lHGRjAUVimUjjTaMqJfvNgUqkM 3JRU1g4lfrgosP1ZvYudz+H23qnOK5NuEpi+DsQJeLtyftc7tUeiUsZNc5iMnw6G41fO 7lPw== Received: by 10.66.76.98 with SMTP id j2mr9248228paw.65.1354342974329; Fri, 30 Nov 2012 22:22:54 -0800 (PST) Received: from c-24-19-191-56.hsd1.wa.comcast.net (c-24-19-191-56.hsd1.wa.comcast.net. [24.19.191.56]) by mx.google.com with ESMTPS id mt15sm4268456pbc.49.2012.11.30.22.22.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 30 Nov 2012 22:22:53 -0800 (PST) Date: Fri, 30 Nov 2012 22:22:49 -0800 (PST) From: Garrett Cooper To: brde@optusnet.com.au Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls (fwd) In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 06:22:55 -0000 On Fri, 30 Nov 2012, Garrett Cooper wrote: > On Tue, 27 Nov 2012, Bruce Evans wrote: > >> On Mon, 26 Nov 2012, Garrett Cooper wrote: >> >>> As noted in a previous thread, I set out to better document the >>> net.inet6 sysctls after having to tweak the knobs to get things to work >>> for TAHI, and this is the resulting draft (so far). I also took the >>> liberty of removing the ip6_rr_prune and icmp6_redirtimeout sysctls >>> because they weren't in use anywhere else in the sys/... portion of the >>> tree. I was wondering if there are any points that should be >>> corrected/clarified before I submit a PR with the resulting patch. >> >> It would be good to fix the style bugs when changing lots. >> >>> Index: sys/netinet6/in6_proto.c >>> =================================================================== >>> --- sys/netinet6/in6_proto.c (revision 242903) >>> +++ sys/netinet6/in6_proto.c (working copy) >>> @@ -443,7 +441,6 @@ >>> >>> /* ICMPV6 parameters */ >>> VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ >>> -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ >>> VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ >>> /* control how to respond to NI queries */ >>> VNET_DEFINE(int, icmp6_nodeinfo) = >>> @@ -515,15 +512,20 @@ >>> } >>> >>> SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, >>> CTLFLAG_RW, >>> - &VNET_NAME(ip6_forwarding), 0, ""); >>> + &VNET_NAME(ip6_forwarding), 0, >>> + "Forward IPv6 packets via node."); >> >> All the sysctl names spell ipv6 without a v. This is hard to fix. This >> bug is missing in the names of the sysctl numbers, but it is a bug to >> used named numbers instead of OID_AUTO in code newer than OID_AUTO, and >> ipv6 is much newer. >> >> New style bug in almost every description. Sysctl descriptions are not >> normally terminated by a ".". >> >> Old style bug in almost every ipv6 sysctl. Large SYSCTL declarations are >> normally normally-indented, with 4-space continuation indents. This rule >> is broken farily consistenly in ipv6 sysctl. More ivp4 SYSCTL descriptions >> are actually formatted normally. >> >>> @@ -594,35 +613,45 @@ >>> #define V_ip6_output_flowtable_size VNET(ip6_output_flowtable_size) >>> >>> SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, output_flowtable_size, >>> CTLFLAG_RDTUN, >>> - &VNET_NAME(ip6_output_flowtable_size), 2048, >>> - "number of entries in the per-cpu output flow caches"); >>> + &VNET_NAME(ip6_output_flowtable_size), 2048, >>> + "number of entries in the per-cpu output flow caches"); >>> ... >> >> Here the formatting change is backwards (from normal continuation indent >> to abnormal ipv6 continuation indent. >> >> This and some other old sysctl descriptions have differnent style bugs: >> they are normally terminated (not with a '.'), but are not normally >> capitalized (with capaitals). >> >>> SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, >>> CTLFLAG_RW, >> >> Some mailer mangled the formatting (the line isn't too long and shouldn't >> have been mangled). >> >>> - &VNET_NAME(nd6_prune), 0, ""); >>> + &VNET_NAME(nd6_prune), 0, >>> + "Period (in seconds) for performing nd6 expiration checks of default >>> " >> >> More mangling by some mailer. >> >>> + "routes and prefix lists"); >> >> However, the string is too long. The message is obfuscated by splitting >> it. >> This keeps the line length short in the source code, but it is still too >> long in the output. Sysctl descriptions should be no longer than 50 or >> 60 characters, since the sysctl name will expand the output by 20 or 30 >> characters. sysctl names longer than 20 or 30 are a larger bug, since >> they are hard to write as well as hard to read. >> >> This sysctl description is normally terminated (not with a "."). >> >>> ... >>> SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, >>> - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); >>> + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, >>> + "Maximum number of unicast queries to perform via nd6."); >> >> Another type of sysctl misformatting is generated by names that are so >> verbose that CTLFLAG* cannot be formatted normally (on the first line). >> >> I missed earlier instances of these bugs. >> >> Statistic on output style in sysctl descriptions: on freefall now: >> sysctl -da: 3546 lines >> sysctl -da | grep -v ': *$': 3192 lines >> [this filters out sysctls with null descriptions. The output is >> misformatted with a space before the null description] >> sysctl -nda: 3546 lines >> sysctl -nda | grep -v '^: *$': 3192 lines >> [since this 3192 is the same as the number of sysctls with non-null >> descreiptions, there must be no multi-line descriptions with embedded >> newlines] >> sysctl -nda | grep -v '^: *$' | grep -v '^[A-Z]': >> 1555 lines >> [most of non-capitalizations are style bugs. The last 1395 of them >> are automatically generated for device sysctls. This is part of 5 >> lines of automatically generated spam for device sysctls (descriptions >> are duplicated ad spamium for %desc, %driver, %location, %pnpinfo and >> %parent). A few are correct because they are for a proper name or >> keyword or a number] >> sysctl -nda | grep -v '^: *$' | grep '\.$': >> 74 lines >> [the style bug of terminating with a '.' is uncommon. In a few cases >> it goes with the larger style bug of a multi-line description] >> sysctl -nda | grep -v '^: *$' | grep '.... [81 dots]': >> 11 lines >> [these lines are too long even without the sysctl names. Abnormal >> termination is denser than usual in these lines (8 of 11)] >> sysctl -nda | grep -v '^: *$' | grep '\..*\.': >> 8 lines >> [2 of these are for multi-sentence descriptions]. > > Bruce, > Is this better? I tried to be consistent about using v6 properly when > dealing with protocols in order to match what the IETF did and I believe I > properly integrated in your comments. > Thanks! > -Garrett > > Index: sys/netinet6/in6_proto.c > =================================================================== > --- sys/netinet6/in6_proto.c (revision 243557) > +++ sys/netinet6/in6_proto.c (working copy) > @@ -131,7 +131,7 @@ > #endif > > /* > - * TCP/IP protocol family: IP6, ICMP6, UDP, TCP. > + * TCP/IP protocol family: IPv6, ICMPv6, UDPv6, TCPv6. > */ > FEATURE(inet6, "Internet Protocol version 6"); > > @@ -382,9 +382,9 @@ > */ > #ifndef IPV6FORWARDING > #ifdef GATEWAY6 > -#define IPV6FORWARDING 1 /* forward IP6 packets not for us */ > +#define IPV6FORWARDING 1 /* forward IPv6 packets */ > #else > -#define IPV6FORWARDING 0 /* don't forward IP6 packets not for > us */ > +#define IPV6FORWARDING 0 /* don't forward IPv6 packets */ > #endif /* GATEWAY6 */ > #endif /* !IPV6FORWARDING */ > > @@ -409,8 +409,6 @@ > VNET_DEFINE(int, ip6_auto_flowlabel) = 1; > VNET_DEFINE(int, ip6_use_deprecated) = 1;/* allow deprecated addr > * (RFC2462 5.5.4) */ > -VNET_DEFINE(int, ip6_rr_prune) = 5; /* router renumbering prefix > - * walk list every 5 sec. */ > VNET_DEFINE(int, ip6_mcast_pmtu) = 0; /* enable pMTU discovery for > multicast? */ > VNET_DEFINE(int, ip6_v6only) = 1; > > @@ -431,7 +429,7 @@ > VNET_DEFINE(int, pmtu_expire) = 60*10; > VNET_DEFINE(int, pmtu_probe) = 60*2; > > -/* raw IP6 parameters */ > +/* raw IPV6 parameters */ > /* > * Nominal space allocated to a raw ip socket. > */ > @@ -443,13 +441,12 @@ > > /* ICMPV6 parameters */ > VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ > -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ > VNET_DEFINE(int, icmp6errppslim) = 100; /* 100pps */ > /* control how to respond to NI queries */ > VNET_DEFINE(int, icmp6_nodeinfo) = > (ICMP6_NODEINFO_FQDNOK|ICMP6_NODEINFO_NODEADDROK); > > -/* UDP on IP6 parameters */ > +/* UDP on IPv6 parameters */ > VNET_DEFINE(int, udp6_sendspace) = 9216;/* really max datagram size */ > VNET_DEFINE(int, udp6_recvspace) = 40 * (1024 + sizeof(struct > sockaddr_in6)); > /* 40 1K datagrams */ > @@ -461,12 +458,12 @@ > "Internet6 Family"); > > /* net.inet6 */ > -SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, > "IP6"); > -SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, > "ICMP6"); > -SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, > "UDP6"); > -SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, > "TCP6"); > +SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, > "IPv6"); > +SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, > "ICMPv6"); > +SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, > "UDPv6"); > +SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, > "TCPv6"); > #ifdef SCTP > -SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, > "SCTP6"); > +SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, > "SCTPv6"); > #endif > #ifdef IPSEC > SYSCTL_NODE(_net_inet6, IPPROTO_ESP, ipsec6, CTLFLAG_RW, 0, > "IPSEC6"); > @@ -515,77 +512,99 @@ > } > > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_FORWARDING, forwarding, CTLFLAG_RW, > - &VNET_NAME(ip6_forwarding), 0, ""); > + &VNET_NAME(ip6_forwarding), 0, > + "Forward IPv6 packets via node"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_SENDREDIRECTS, redirect, CTLFLAG_RW, > - &VNET_NAME(ip6_sendredirects), 0, ""); > + &VNET_NAME(ip6_sendredirects), 0, > + "Redirect IPv6 packets via node"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFHLIM, hlim, CTLFLAG_RW, > - &VNET_NAME(ip6_defhlim), 0, ""); > + &VNET_NAME(ip6_defhlim), 0, > + "Default hop limit for IPv6 unicast packets"); > SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_STATS, stats, CTLFLAG_RW, > - &VNET_NAME(ip6stat), ip6stat, ""); > + &VNET_NAME(ip6stat), ip6stat, > + "IPv6 statistics"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGPACKETS, maxfragpackets, > - CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_maxfragpackets), 0, > + "Maximum number of fragmented packets to process"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_ACCEPT_RTADV, accept_rtadv, > - CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, > - "Default value of per-interface flag for accepting ICMPv6 Router" > - "Advertisement messages"); > + CTLFLAG_RW, &VNET_NAME(ip6_accept_rtadv), 0, > + "Default value of per-interface flag for accepting ICMPv6 Router" > + "Advertisement messages"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_NO_RADR, no_radr, > - CTLFLAG_RW, &VNET_NAME(ip6_no_radr), 0, > - "Default value of per-interface flag to control whether routers " > - "sending ICMPv6 RA messages on that interface are added into the " > - "default router list."); > + CTLFLAG_RW, &VNET_NAME(ip6_no_radr), 0, > + "Default value of per-interface flag to control whether routers " > + "sending ICMPv6 RA messages on that interface are added into the " > + "default router list"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_NORBIT_RAIF, norbit_raif, > CTLFLAG_RW, > - &VNET_NAME(ip6_norbit_raif), 0, > - "Always set 0 to R flag in ICMPv6 NA messages when accepting RA" > - " on the interface."); > + &VNET_NAME(ip6_norbit_raif), 0, > + "Always set 0 to R flag in ICMPv6 NA messages when accepting RA " > + "on the interface"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RFC6204W3, rfc6204w3, > - CTLFLAG_RW, &VNET_NAME(ip6_rfc6204w3), 0, > - "Accept the default router list from ICMPv6 RA messages even " > - "when packet forwarding enabled."); > + CTLFLAG_RW, &VNET_NAME(ip6_rfc6204w3), 0, > + "Accept the default router list from ICMPv6 RA messages even when packet > " > + "forwarding enabled"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_KEEPFAITH, keepfaith, CTLFLAG_RW, > - &VNET_NAME(ip6_keepfaith), 0, ""); > + &VNET_NAME(ip6_keepfaith), 0, > + ""); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_LOG_INTERVAL, log_interval, > - CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_log_interval), 0, > + "Period (in secs) for throttling logging for high-traffic operations"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_HDRNESTLIMIT, hdrnestlimit, > - CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_hdrnestlimit), 0, > + "Maximum number of nested header options to process"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DAD_COUNT, dad_count, CTLFLAG_RW, > - &VNET_NAME(ip6_dad_count), 0, ""); > + &VNET_NAME(ip6_dad_count), 0, > + "Number of Duplicate Address Detection attempts to try before " > + "disabling interface. Setting the value to 0 disables DAD"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_FLOWLABEL, auto_flowlabel, > - CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_auto_flowlabel), 0, > + "Automatically attach a flowlabel to IPv6 packets"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_DEFMCASTHLIM, defmcasthlim, > - CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_defmcasthlim), 0, > + "Default hop limit for ip6 multicast packets"); > SYSCTL_STRING(_net_inet6_ip6, IPV6CTL_KAME_VERSION, kame_version, > - CTLFLAG_RD, __KAME_VERSION, 0, ""); > + CTLFLAG_RD, __KAME_VERSION, 0, > + ""); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEPRECATED, use_deprecated, > - CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, ""); > -SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_RR_PRUNE, rr_prune, CTLFLAG_RW, > - &VNET_NAME(ip6_rr_prune), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_use_deprecated), 0, > + "Use deprecated IPv6 support"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USETEMPADDR, use_tempaddr, > - CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_use_tempaddr), 0, > + "Use a temporary address when establishing address via SLAAC"); > SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPPLTIME, temppltime, > - CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_preferred_lifetime), 0, > - sysctl_ip6_temppltime, "I", ""); > + CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_preferred_lifetime), 0, > + sysctl_ip6_temppltime, "I", > + "Preferred lifetime (in secs) for a temporary address"); > SYSCTL_VNET_PROC(_net_inet6_ip6, IPV6CTL_TEMPVLTIME, tempvltime, > - CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_valid_lifetime), 0, > - sysctl_ip6_tempvltime, "I", ""); > + CTLTYPE_INT|CTLFLAG_RW, &VNET_NAME(ip6_temp_valid_lifetime), 0, > + sysctl_ip6_tempvltime, "I", > + "Valid lifetime (in secs) for a temporary address"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_V6ONLY, v6only, CTLFLAG_RW, > - &VNET_NAME(ip6_v6only), 0, ""); > + &VNET_NAME(ip6_v6only), 0, > + "Allow IPv4-mapped ip6 addresses per RFC 3493"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_AUTO_LINKLOCAL, auto_linklocal, > - CTLFLAG_RW, &VNET_NAME(ip6_auto_linklocal), 0, > - "Default value of per-interface flag for automatically adding an > IPv6" > - " link-local address to interfaces when attached"); > -SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_RIP6STATS, rip6stats, CTLFLAG_RW, > - &VNET_NAME(rip6stat), rip6stat, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_auto_linklocal), 0, > + "Default value of per-interface flag for automatically adding an ip6 " > + "link-local address to interfaces when attached"); > +SYSCTL_VNET_STRUCT(_net_inet6_ip6, IPV6CTL_RIPV6STATS, rip6stats, > CTLFLAG_RW, > + &VNET_NAME(rip6stat), rip6stat, > + "RIP6 statistics"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_PREFER_TEMPADDR, prefer_tempaddr, > - CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, ""); > + CTLFLAG_RW, &VNET_NAME(ip6_prefer_tempaddr), 0, > + "Prefer the temporary address assigned when performing NUD"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_USE_DEFAULTZONE, use_defaultzone, > - CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0,""); > + CTLFLAG_RW, &VNET_NAME(ip6_use_defzone), 0, > + "Use the default scope zone if not explicitly provided"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MAXFRAGS, maxfrags, CTLFLAG_RW, > - &VNET_NAME(ip6_maxfrags), 0, ""); > + &VNET_NAME(ip6_maxfrags), 0, > + "Maximum number of fragments to hold in the reassembly queue"); > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_MCAST_PMTU, mcast_pmtu, CTLFLAG_RW, > - &VNET_NAME(ip6_mcast_pmtu), 0, ""); > + &VNET_NAME(ip6_mcast_pmtu), 0, > + "Enable multicast pMTU discovery"); > #ifdef IPSTEALTH > SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_STEALTH, stealth, CTLFLAG_RW, > - &VNET_NAME(ip6stealth), 0, ""); > + &VNET_NAME(ip6stealth), 0, > + "IPv6 stealth mode. No hop limit decrementation on forwarding"); > #endif > > #ifdef FLOWTABLE > @@ -600,29 +619,39 @@ > > /* net.inet6.icmp6 */ > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRACCEPT, rediraccept, > - CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, ""); > -SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_REDIRTIMEOUT, redirtimeout, > - CTLFLAG_RW, &VNET_NAME(icmp6_redirtimeout), 0, ""); > + CTLFLAG_RW, &VNET_NAME(icmp6_rediraccept), 0, > + "Accept and process router redirects"); > SYSCTL_VNET_STRUCT(_net_inet6_icmp6, ICMPV6CTL_STATS, stats, CTLFLAG_RW, > - &VNET_NAME(icmp6stat), icmp6stat, ""); > + &VNET_NAME(icmp6stat), icmp6stat, > + "ICMPv6 statistics"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_PRUNE, nd6_prune, > CTLFLAG_RW, > - &VNET_NAME(nd6_prune), 0, ""); > + &VNET_NAME(nd6_prune), 0, > + "Period (in secs) for checking for stale router entries via nd6"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DELAY, nd6_delay, > CTLFLAG_RW, > - &VNET_NAME(nd6_delay), 0, ""); > + &VNET_NAME(nd6_delay), 0, > + "Delay (in secs) before performing NUD on stale nodes"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_UMAXTRIES, nd6_umaxtries, > - CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, ""); > + CTLFLAG_RW, &VNET_NAME(nd6_umaxtries), 0, > + "Maximum number of unicast queries to perform via nd6"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MMAXTRIES, nd6_mmaxtries, > - CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, ""); > + CTLFLAG_RW, &VNET_NAME(nd6_mmaxtries), 0, > + "Maximum number of multicast queries to perform via nd6"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_USELOOPBACK, > nd6_useloopback, > - CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, ""); > + CTLFLAG_RW, &VNET_NAME(nd6_useloopback), 0, > + "Use loopback interface for local traffic"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_NODEINFO, nodeinfo, CTLFLAG_RW, > - &VNET_NAME(icmp6_nodeinfo), 0, ""); > + &VNET_NAME(icmp6_nodeinfo), 0, > + "Node information state"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ERRPPSLIMIT, errppslimit, > - CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, ""); > + CTLFLAG_RW, &VNET_NAME(icmp6errppslim), 0, > + "Packets per second limit for ICMPv6 queries"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_MAXNUDHINT, nd6_maxnudhint, > - CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, ""); > + CTLFLAG_RW, &VNET_NAME(nd6_maxnudhint), 0, > + "Maximum number of upper layer hints"); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_DEBUG, nd6_debug, > CTLFLAG_RW, > - &VNET_NAME(nd6_debug), 0, ""); > + &VNET_NAME(nd6_debug), 0, > + ""); > SYSCTL_VNET_INT(_net_inet6_icmp6, ICMPV6CTL_ND6_ONLINKNSRFC4861, > - nd6_onlink_ns_rfc4861, CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), > - 0, "Accept 'on-link' nd6 NS in compliance with RFC 4861."); > + nd6_onlink_ns_rfc4861, > + CTLFLAG_RW, &VNET_NAME(nd6_onlink_ns_rfc4861), 0, > + "Accept 'on-link' nd6 NS in compliance with RFC 4861"); Wrong To: address >_>. -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 07:16:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 64C91700; Sat, 1 Dec 2012 07:16:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 604818FC13; Sat, 1 Dec 2012 07:16:26 +0000 (UTC) Received: by mail-wg0-f42.google.com with SMTP id dr1so101805wgb.1 for ; Fri, 30 Nov 2012 23:16:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tcZQqt5xnA0yVUyZsxMpXUD5z4npSoXj1odc0RmziMA=; b=bbSSTfRG6YpkvWbylne1PlWw8nte1x7yHxjdtnJU1x8yIIxUpDdSidpZ1vBebXNj3t yMWshjrAX0K06jsXR3Pa6l3NckV9h7s/rdXOwxc6SAHgi3J+SBezMwOViWrGaa9ySevQ ThEhyzeZ6OGBcnwwkK9/iKXXtBGww3tGAMOdq+SDJZvIxsZ0B7ZJTlch0yOvqqo2Jj/0 LqQ6GkwIVcqwR4I4gKrQBSYhHBCMNF2WlYmMo/zN7ZXV6bQC3Hh0o7IvDlF9Yhp5v8sE pN9/w7mRdWpm+J9Hmjc+loy8rNlwIPo4HoEGZmuR7wfXnsvuZ++YsnWoktg8rYkgiRqH g7yA== MIME-Version: 1.0 Received: by 10.180.88.138 with SMTP id bg10mr1211193wib.13.1354346186036; Fri, 30 Nov 2012 23:16:26 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.217.57.9 with HTTP; Fri, 30 Nov 2012 23:16:25 -0800 (PST) In-Reply-To: <20121126182642.GB17080@dft-labs.eu> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> <20121126.164809.1810866108604245881.hrs@allbsd.org> <20121126182642.GB17080@dft-labs.eu> Date: Fri, 30 Nov 2012 23:16:25 -0800 X-Google-Sender-Auth: z9u9gqjb22Yv0G9ftbWBSIfNiWs Message-ID: Subject: Re: LOR in rtsock/ifnet From: Adrian Chadd To: Mateusz Guzik Content-Type: text/plain; charset=ISO-8859-1 Cc: ae@freebsd.org, Hiroki Sato , rpaulo@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: Sat, 01 Dec 2012 07:16:28 -0000 Mateusz: are you sure it's that commit? I still get this in -HEAD: lock order reversal: 1st 0x80f19e38 if_addr_lock (if_addr_lock) @ /usr/home/adrian/work/freebsd/svn/src/sys/net/rtsock.c:1818 2nd 0x806e2b14 ifnet_rw (ifnet_rw) @ /usr/home/adrian/work/freebsd/svn/src/sys/net/if.c:241 KDB: stack backtrace: db_trace_thread+30 (?,?,?,?) ra cdfb181000000018 sp 0 sz 0 db_trace_self+1c (?,?,?,?) ra cdfb182800000018 sp 0 sz 0 8007be28+34 (?,?,?,?) ra cdfb1840000001a0 sp 0 sz 0 kdb_backtrace+44 (?,?,?,?) ra cdfb19e000000018 sp 0 sz 0 802109a8+34 (?,?,?,?) ra cdfb19f800000020 sp 0 sz 0 witness_checkorder+9e0 (?,?,80454dc4,f1) ra cdfb1a1800000050 sp 0 sz 1 __rw_rlock+e0 (?,?,?,?) ra cdfb1a6800000040 sp 0 sz 0 ifnet_byindex+28 (?,?,?,?) ra cdfb1aa800000018 sp 0 sz 0 sa6_recoverscope+8c (?,?,?,?) ra cdfb1ac000000058 sp 0 sz 0 80297244+16c (c,?,?,?) ra cdfb1b18000000d0 sp 100000000 sz 0 80298910+424 (?,?,?,?) ra cdfb1be800000080 sp 0 sz 0 801cba8c+1dc (?,?,?,?) ra cdfb1c6800000040 sp 0 sz 0 userland_sysctl+15c (?,?,?,?) ra cdfb1ca800000060 sp 0 sz 0 sys___sysctl+90 (?,?,?,?) ra cdfb1d08000000a8 sp 0 sz 0 trap+84c (?,?,?,?) ra cdfb1db0000000d0 sp 0 sz 0 MipsUserGenException+10c (?,?,?,4061a8f0) ra cdfb1e8000000000 sp 0 sz 0 pid 90 Thanks, Adrian On 26 November 2012 10:26, Mateusz Guzik wrote: > On Mon, Nov 26, 2012 at 04:48:09PM +0900, Hiroki Sato wrote: >> Rui Paulo wrote >> in <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org>: >> >> rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: >> rp> >> rp> > DO we know which commit triggered this? >> rp> >> rp> >> rp> I haven't bisected. >> >> I do not think my commit triggered it because it occurred in >> rt_msg2(). Andrey, can you take a look at this? >> > > I'm booting i386 on VirtualBox and I have two em interfaces, em0 is > configured to get ip from DHCP and the other one is untouched. > > I don't get this lor with r243186, but I see it with r243187. > > I'm happy to provide more information if needed. > -- > Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 08:28:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CC19BBBD for ; Sat, 1 Dec 2012 08:28:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 3CD788FC13 for ; Sat, 1 Dec 2012 08:28:25 +0000 (UTC) Received: (qmail 77664 invoked from network); 1 Dec 2012 09:59:16 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Dec 2012 09:59:16 -0000 Message-ID: <50B9BF95.2040103@freebsd.org> Date: Sat, 01 Dec 2012 09:28:05 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Keith Arner Subject: Re: Problems with ephemeral port selection References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 08:28:26 -0000 On 30.11.2012 15:09, Keith Arner wrote: > I've noticed some issues with ephemeral port number selection from > tcp_connect(), which limit the number of concurrent, outgoing connections > that can be established (connect(), rather than accept()). Sifting through > the source code, I believe the issuess stem from two problems in the > tcp_connect() code path. Specifically: > > 1) The wrong function gets called to determine if a given ephemeral > port number is currently usable. > 2) The ephemeral port number gets selected without considering the > foreign addr/port. > > Curiously, the effect of #1 mostly cancels the effect of #2, such that > the common calling convention gives you a correct result so long as you > only have a small number of outgoing connections. However, once you get to > a large number of outgoing connections, things start to break down. (I'll > define large and small later.) > > As a side note, I have been working with FreeBSD 7.2. The implementations > of several of the relevant functions have been refactored somewhere between > 7.2-RELEASE and 9-STABLE, but the core problems in the logic seem to be > the same between versions. > > For problem #1, the code path that selects the ephemeral port number is: > tcp_connect() -> > in_pcbbind() -> > in_pcbbind_setup() -> > in_pcb_lport() [not in FreeBSD 7.2] -> > in_pcblookup_local() > > There is a loop in in_pcb_lport() [or directly in in_pcbbind_setup() in > earlier releases] that considers candidate ephemeral port numbers and > calls in_pcblookup_local() to determine if a given candidate is suitable. > The default behaviour (if the caller has not set either SO_REUSEADDR or > SO_REUSEPORT) is to pick a local port number that is not in use by > *any* local TCP socket. > > So long as the number of concurrent, outgoing connections is less than the > range configured by `sysctl net.inet.ip.portrange.*`, selecting a totally > unique ephemeral port number works OK. However, you cannot exceed that > limit, even if each outgoing connection has a unique faddr/fport. This > does not limit the number of connections that can be accept()'ed, only the > number of connections that can be connect()'ed. > > In this particular path, I think the code should call in_pcblookup_hash(), > rather than in_pcblookup_local(). The criteria in in_pcblookup_hash() only > match if the full 5-tuple matches, rather than just the local port number. > The complication, of course, comes from the fact that in_pcbbind() is > called from both bind() and for the implicit bind that happens for a > connect(). The matching criteria in in_pcblookup_local() make sense for > the former but not quite for the later. > > I mentioned that the above is the default behaviour you get when you don't > specify SO_REUSEADDR or SO_REUSEPORT. Setting SO_REUSEADDR > before calling connect() has some surprizing consequences (surprizing in the > sense that I don't believe SO_REUSEADDR is supposed to have any effect > on connect()). In this case, when in_pcblookup_local() is called, wild_okay > is set to false. This changes the matching criteria to (in effect) allow > tcp_connect() to use the full 5-tuple space. However, this brings us to the > second problem. > > Problem #2 is that the ephemeral port number is chosen before the > fport/faddr gets set on the pcb; that is tcp_connect() calls in_pcbbind() to > select the ephemeral port number, *then* calls in_pcbconnect_setup() to > populate the fport/faddr. With SO_REUSEADDR, in_pcbbind() can select > an in-use local port. If the local port is used by a socket with a different > laddr/fport/faddr, all is good. However, if the local port selection > results in a > full conflict it will get rejected by the call to in_pcblookup_hash() inside > in_pcbconnect_setup(). This happens *after* the loop inside > in_pcbbind(), so the call to tcp_connect() fails with EADDRINUSE. Thus, > with SO_REUSEADDR, connect() can fail with EADDRINUSE long before > the ephemeral port space has been exhausted. The application could re-try > the call to connect() and likely succeed, as a new local port would be > selected. > > Overall, this behaviour hinders the ability to open a large number of > outbound connections: > * If you don't specify SO_REUSEADDR, you have a fairly limited maximum > number of outbound connections. > * If you do specify SO_REUSEADDR, you are able to open a much larger > number of outbound connections, but must retry on EADDRINUSE. > > I believe that the logic under tcp_connect() should be modified to: > > - behave uniformly whether or not SO_REUSEADDR has been set > - allow outgoing connection requests to re-use a local port number, so > long as the remaining elements of the tuple (laddr, fport, faddr) are > unique Keith, this is an excellent analysis. Could you please file it as a problem report too and post the PR-number here so we can better track it? Thank you. -- Andre From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 09:55:41 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D6A48934 for ; Sat, 1 Dec 2012 09:55:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.freebsd.org (Postfix) with ESMTP id 699E68FC12 for ; Sat, 1 Dec 2012 09:55:40 +0000 (UTC) Received: from c122-106-175-26.carlnfd1.nsw.optusnet.com.au (c122-106-175-26.carlnfd1.nsw.optusnet.com.au [122.106.175.26]) by mail05.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id qB19tVlL008715 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2012 20:55:33 +1100 Date: Sat, 1 Dec 2012 20:55:31 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Garrett Cooper Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls (fwd) In-Reply-To: Message-ID: <20121201202138.J808@besplex.bde.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.0 cv=SfSv7Ytu c=1 sm=1 a=fQ7hV5z4qHoA:10 a=kj9zAlcOel0A:10 a=PO7r1zJSAAAA:8 a=JzwRw_2MAAAA:8 a=dgaFysBZQSQA:10 a=N5sG7UAMo_YXlXBtImUA:9 a=CjuIK1q_8ugA:10 a=bxQHXO5Py4tHmhUgaywp5w==:117 Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 09:55:42 -0000 On Fri, 30 Nov 2012, Garrett Cooper wrote: > On Fri, 30 Nov 2012, Garrett Cooper wrote: I got the previous one but was busy. This one seems to only add freebsd-net to the Cc list >>> It would be good to fix the style bugs when changing lots. >>> ... >> Is this better? I tried to be consistent about using v6 properly when >> dealing with protocols in order to match what the IETF did and I believe I >> properly integrated in your comments. I'm (almost) happy with this. Noticed a couple more details. We're stuck with sysctls misspelled by name (without a v)... >> Index: sys/netinet6/in6_proto.c >> =================================================================== >> --- sys/netinet6/in6_proto.c (revision 243557) >> +++ sys/netinet6/in6_proto.c (working copy) >> ... >> @@ -382,9 +382,9 @@ >> */ >> #ifndef IPV6FORWARDING Stray tab here. >> #ifdef GATEWAY6 ... and options spelled without a V. >> ... >> @@ -443,13 +441,12 @@ >> >> /* ICMPV6 parameters */ >> VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects */ >> -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ Lost this? >> @@ -461,12 +458,12 @@ >> "Internet6 Family"); >> >> /* net.inet6 */ >> -SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, >> "IP6"); >> -SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, >> "ICMP6"); >> -SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, >> "UDP6"); >> -SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, >> "TCP6"); >> +SYSCTL_NODE(_net_inet6, IPPROTO_IPV6, ip6, CTLFLAG_RW, 0, >> "IPv6"); >> +SYSCTL_NODE(_net_inet6, IPPROTO_ICMPV6, icmp6, CTLFLAG_RW, 0, >> "ICMPv6"); >> +SYSCTL_NODE(_net_inet6, IPPROTO_UDP, udp6, CTLFLAG_RW, 0, >> "UDPv6"); >> +SYSCTL_NODE(_net_inet6, IPPROTO_TCP, tcp6, CTLFLAG_RW, 0, >> "TCPv6"); >> #ifdef SCTP >> -SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, >> "SCTP6"); >> +SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, >> "SCTPv6"); >> #endif >> #ifdef IPSEC >> SYSCTL_NODE(_net_inet6, IPPROTO_ESP, ipsec6, CTLFLAG_RW, 0, >> "IPSEC6"); I don't like this fancy formatting. It is hard to maintain, and it is only possible to line up all the fields and fit on 1 line when all are short. Some mailer already mangled the lines by splitting them and quoting the split. Descriptions like this that used to less than echo the leaf of the sysctl name are less than useful. They seem to be bug for bug compatible with ipv4, however: net.inet.ip is now described as IP (no v or 4 in sight). net.inet6.ip6 is now described as IP6. I also don't like duplicating the 6 at every lower level in name. >> ... >> SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_V6ONLY, v6only, CTLFLAG_RW, Stray tab before CTLFLAG* (left over from the fancy formatting?). >> - &VNET_NAME(ip6_v6only), 0, ""); >> + &VNET_NAME(ip6_v6only), 0, >> + "Allow IPv4-mapped ip6 addresses per RFC 3493"); > Wrong To: address >_>. Bruce From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 10:06:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 815319CD for ; Sat, 1 Dec 2012 10:06:05 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-oa0-f54.google.com (mail-oa0-f54.google.com [209.85.219.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3DB898FC0C for ; Sat, 1 Dec 2012 10:06:04 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id n9so1692758oag.13 for ; Sat, 01 Dec 2012 02:06:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=rq0ibiB3dY9X/qNOZOdG7/cZJv55bIxpK5+ovHeqans=; b=oboSrL+7weKQs18BiRdL/i8DrMpkrasXKh/8NsnNs1DnKtSsGn2qS5N7I/x9+k5tS1 uTpTuC9+Rq6fiE2/A+Oztvi070tKjo4VLx6kyBq1wPAZjhWIQinqPwW+WANI2vD24or6 3nGqHrNdx3H4RIL6AM+hCEiOCIiUFgm2BcVzilYT0N8dFoJpQ60CyFit8VurziYkT/KV Ux4/xUBemBcgb/TJNOG6r3LBaSD4U2dvbQO258TJrMranvDlP6vfOG+AeDT758xoxa78 aLvh0uOrnLmMd5DiRNcu+tPm+pDh96rKEDtdroA6bl5xE/jIUbp3yhi59OfK4DtYJBTY jquQ== MIME-Version: 1.0 Received: by 10.60.10.133 with SMTP id i5mr3368162oeb.24.1354356364385; Sat, 01 Dec 2012 02:06:04 -0800 (PST) Received: by 10.76.143.33 with HTTP; Sat, 1 Dec 2012 02:06:04 -0800 (PST) In-Reply-To: <20121201202138.J808@besplex.bde.org> References: <20121201202138.J808@besplex.bde.org> Date: Sat, 1 Dec 2012 02:06:04 -0800 Message-ID: Subject: Re: [RFC] Better document net.inet6 sysctls and prune dead sysctls (fwd) From: Garrett Cooper To: Bruce Evans 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: Sat, 01 Dec 2012 10:06:05 -0000 On Sat, Dec 1, 2012 at 1:55 AM, Bruce Evans wrote: > On Fri, 30 Nov 2012, Garrett Cooper wrote: > >> On Fri, 30 Nov 2012, Garrett Cooper wrote: > > I got the previous one but was busy. This one seems to only add freebsd-net > to the Cc list > >>>> It would be good to fix the style bugs when changing lots. >>>> ... >>> >>> Is this better? I tried to be consistent about using v6 properly >>> when dealing with protocols in order to match what the IETF did and I >>> believe I properly integrated in your comments. > > > I'm (almost) happy with this. Noticed a couple more details. We're > stuck with sysctls misspelled by name (without a v)... > >>> Index: sys/netinet6/in6_proto.c >>> =================================================================== >>> --- sys/netinet6/in6_proto.c (revision 243557) >>> +++ sys/netinet6/in6_proto.c (working copy) >>> ... >>> >>> @@ -382,9 +382,9 @@ >>> */ >>> #ifndef IPV6FORWARDING > > Stray tab here. Fixed. >>> #ifdef GATEWAY6 > > ... and options spelled without a V. "Fixing" this will break backwards compatibility -_-. Trying to avoid changing interfaces/#defines. >>> ... >>> >>> @@ -443,13 +441,12 @@ >>> >>> /* ICMPV6 parameters */ >>> VNET_DEFINE(int, icmp6_rediraccept) = 1;/* accept and process redirects >>> */ >>> -VNET_DEFINE(int, icmp6_redirtimeout) = 10 * 60; /* 10 minutes */ > > Lost this? This is intentional. This and ip6_rr_prune need to be pruned because they're unused in the kernel proper. ... >>> +SYSCTL_NODE(_net_inet6, IPPROTO_SCTP, sctp6, CTLFLAG_RW, 0, >>> "SCTPv6"); >>> #endif >>> #ifdef IPSEC >>> SYSCTL_NODE(_net_inet6, IPPROTO_ESP, ipsec6, CTLFLAG_RW, 0, "IPSEC6"); > > I don't like this fancy formatting. It is hard to maintain, and it is only > possible to line up all the fields and fit on 1 line when all are short. > Some mailer already mangled the lines by splitting them and quoting the > split. alpine with ^j and gmail probably again (I really need to fix that or get a less "intelligent" mailer) :/... > Descriptions like this that used to less than echo the leaf of the > sysctl name are less than useful. They seem to be bug for bug > compatible with ipv4, however: net.inet.ip is now described as IP (no > v or 4 in sight). net.inet6.ip6 is now described as IP6. I also > don't like duplicating the 6 at every lower level in name. I'll just pull the descriptions because it's useless bloat in the kernel in text form. >>> ... >>> SYSCTL_VNET_INT(_net_inet6_ip6, IPV6CTL_V6ONLY, v6only, CTLFLAG_RW, > > Stray tab before CTLFLAG* (left over from the fancy formatting?). I think so. Either way, I quashed what was there :). >>> - &VNET_NAME(ip6_v6only), 0, ""); >>> + &VNET_NAME(ip6_v6only), 0, >>> + "Allow IPv4-mapped ip6 addresses per RFC 3493"); Thanks again! -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 13:36:26 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 34848660; Sat, 1 Dec 2012 13:36:26 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0D2A78FC13; Sat, 1 Dec 2012 13:36:24 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hm9so235160wib.13 for ; Sat, 01 Dec 2012 05:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=sG9Uu4GfNlB1EMY55l59SZ29fS4Qx29KdHf6SO7abUM=; b=0VdzFO5K5CgwSNnviuwbZkflZARvRTVJV0hDJ5kpqX+8EPE4UiGmr2PgIplLq4B0iu eQRj2uH6K2QmE3k8nqdGXHWEUHehLxAmHDRrJNesZmuTIULm4iqx3Ot7j6LB6wsNTCLo 24nS34ZIBcq4CoPSoVa624TiFSzy2C57ZOLsadYpTo1E3zX3zGiNyf8yotDBpBnC+JeR VCvWD9oZ4t5r8a9fKs2d68SkZXyI/Egsbh1MZqT9xZi75NQzkwDW6BFyn+MpmP//36rH fASbm2skR0x2BLTeCSyLyNRE3DcEhsDmKKKgwO/v+V7WaeNDcdtQaAwUjxovllZEOzIc qbQw== Received: by 10.180.102.40 with SMTP id fl8mr2143161wib.22.1354368977651; Sat, 01 Dec 2012 05:36:17 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id gz3sm2963841wib.2.2012.12.01.05.36.15 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 05:36:16 -0800 (PST) Date: Sat, 1 Dec 2012 14:36:09 +0100 From: Mateusz Guzik To: Adrian Chadd Subject: Re: LOR in rtsock/ifnet Message-ID: <20121201133609.GA5450@dft-labs.eu> References: <7C5421B8-9D32-4771-B453-151D9D07A214@FreeBSD.org> <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org> <20121126.164809.1810866108604245881.hrs@allbsd.org> <20121126182642.GB17080@dft-labs.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ae@freebsd.org, Hiroki Sato , rpaulo@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: Sat, 01 Dec 2012 13:36:26 -0000 On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: > Mateusz: are you sure it's that commit? > Yes, I double-checked right now. > I still get this in -HEAD: > Maybe I expressed myself incorrectly, I meant to say that LOR started showing up since r243187. The code is still in head and no fixes were comitted (that I know of at least), so I guess that you seeing this LOR on head is expected. :) > > On 26 November 2012 10:26, Mateusz Guzik wrote: > > On Mon, Nov 26, 2012 at 04:48:09PM +0900, Hiroki Sato wrote: > >> Rui Paulo wrote > >> in <63C19AD8-EA8D-49A8-9E98-4235C4745405@freebsd.org>: > >> > >> rp> On 25 Nov 2012, at 23:35, Adrian Chadd wrote: > >> rp> > >> rp> > DO we know which commit triggered this? > >> rp> > >> rp> > >> rp> I haven't bisected. > >> > >> I do not think my commit triggered it because it occurred in > >> rt_msg2(). Andrey, can you take a look at this? > >> > > > > I'm booting i386 on VirtualBox and I have two em interfaces, em0 is > > configured to get ip from DHCP and the other one is untouched. > > > > I don't get this lor with r243186, but I see it with r243187. > > > > I'm happy to provide more information if needed. > > -- > > Mateusz Guzik -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 13:50:30 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A8192AFB; Sat, 1 Dec 2012 13:50:30 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id ED1148FC12; Sat, 1 Dec 2012 13:50:29 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1DoDsC026927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 1 Dec 2012 22:50:23 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1DoCXo022569; Sat, 1 Dec 2012 22:50:13 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sat, 01 Dec 2012 22:50:04 +0900 (JST) Message-Id: <20121201.225004.2232262673795057435.hrs@allbsd.org> To: mjguzik@gmail.com Subject: Re: LOR in rtsock/ifnet From: Hiroki Sato In-Reply-To: <20121201133609.GA5450@dft-labs.eu> References: <20121126182642.GB17080@dft-labs.eu> <20121201133609.GA5450@dft-labs.eu> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Sat_Dec__1_22_50_04_2012_347)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sat, 01 Dec 2012 22:50:23 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: ae@FreeBSD.org, adrian@FreeBSD.org, rpaulo@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: Sat, 01 Dec 2012 13:50:30 -0000 ----Security_Multipart(Sat_Dec__1_22_50_04_2012_347)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mateusz Guzik wrote in <20121201133609.GA5450@dft-labs.eu>: mj> On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: mj> > Mateusz: are you sure it's that commit? mj> > mj> mj> Yes, I double-checked right now. mj> mj> > I still get this in -HEAD: mj> > mj> mj> Maybe I expressed myself incorrectly, I meant to say that LOR started mj> showing up since r243187. mj> mj> The code is still in head and no fixes were comitted (that I know of at mj> least), so I guess that you seeing this LOR on head is expected. :) Thanks for the info. I am investigating this now. -- Hiroki ----Security_Multipart(Sat_Dec__1_22_50_04_2012_347)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC6CwwACgkQTyzT2CeTzy2IjQCguwYnPzI1zm69DMlKjH3KUadE zC8An2bRKngALYKwd/0x5oneikGp5q8R =TsuK -----END PGP SIGNATURE----- ----Security_Multipart(Sat_Dec__1_22_50_04_2012_347)---- From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 14:34:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BBE3F129 for ; Sat, 1 Dec 2012 14:34:00 +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 77E498FC12 for ; Sat, 1 Dec 2012 14:33:59 +0000 (UTC) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1Teo8E-0004Mi-AU; Sat, 01 Dec 2012 15:33:26 +0100 Message-ID: <50BA14C3.4070601@gont.com.ar> Date: Sat, 01 Dec 2012 11:31:31 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Keith Arner Subject: Re: Problems with ephemeral port selection References: In-Reply-To: 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: Sat, 01 Dec 2012 14:34:00 -0000 Hi, Keith, On 11/30/2012 11:09 AM, Keith Arner wrote: > > - behave uniformly whether or not SO_REUSEADDR has been set > - allow outgoing connection requests to re-use a local port number, so > long as the remaining elements of the tuple (laddr, fport, faddr) are > unique Please take a look at the discussion on how to "steal" incomming connections in Section 3.1 of RFC 6056. Cheers, -- 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 Sat Dec 1 15:57:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7C3771A6 for ; Sat, 1 Dec 2012 15:57:27 +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 395698FC08 for ; Sat, 1 Dec 2012 15:57:27 +0000 (UTC) Received: from 187-135-17-190.fibertel.com.ar ([190.17.135.187] helo=[192.168.1.113]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1TepRS-0006Ll-TV; Sat, 01 Dec 2012 16:57:23 +0100 Message-ID: <50BA28DE.5050109@gont.com.ar> Date: Sat, 01 Dec 2012 12:57:18 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: FreeBSD Net Subject: Bringing some sanity to IPv6 traffic (IETF Internet-Drafts) 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: Sat, 01 Dec 2012 15:57:27 -0000 Folks, FYI: * * P.S.: These two I-Ds have already been adopted by the 6man wg, and are close to publication as RFCs. Cheers, -- 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 Sat Dec 1 22:08:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C0AE3DF4 for ; Sat, 1 Dec 2012 22:08:20 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6F4F28FC0C for ; Sat, 1 Dec 2012 22:08:20 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1838862obc.13 for ; Sat, 01 Dec 2012 14:08:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=b7ojTWmfk9nJgQZPk/ZKijPBxx9LHyZxL/sR9J+09Zc=; b=b39IIp9d8nBsmj719bDVHWISrfZwz/yJGia4dsSvI73Ge+I2ih1ethN6SoHnxjF11D 7r0/DlRnzfZ6L9c+mKPZGbLEa69Z3xKNveiArVTItxFuf6LPbTMmO+XZ5YYEKNEYA6bp 184W3BuCopGI8MwJIIbl6+HcBrgXjBLgADO8mKI+5jcRTOpdEALrjrX3X0gvXlCnlThj GAtwUffk7b9lPDjJBbm5JNJUheiXpS+/81qjjLg31VfUYNZ+w0PR2/p8ykRX4hSaa+9D 1V+udEdYMUw2fzrtK+/bW62u2hO66mPv3Bqeh7IeIBAv9KoGZ8p8Ojbls3F4gasAh6/6 NaNg== MIME-Version: 1.0 Received: by 10.60.169.171 with SMTP id af11mr4652747oec.92.1354399699567; Sat, 01 Dec 2012 14:08:19 -0800 (PST) Received: by 10.60.80.104 with HTTP; Sat, 1 Dec 2012 14:08:19 -0800 (PST) In-Reply-To: References: Date: Sat, 1 Dec 2012 17:08:19 -0500 Message-ID: Subject: Re: Ralink RT2860 Driver Code From: Ramanujan Seshadri To: PseudoCylon 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: Sat, 01 Dec 2012 22:08:20 -0000 Hello, Thanks for the explanation. In fact when i saw the code i also thought the same, but when i tried to print out the transmitted A-MPDU's i found something different. For example, The Counter AggSize15Count should print the the numbers in the multiples of 15, but sometimes it doesn't. So, my understanding is that, the MPDU's are written into these registers, and then an ampdu is formed only when there are enough number of MPDU;s. For example, AggSize15Count sometimes show the counter as 54, so there would be only (54/15) == 3 ampdu's ( 9 remainder). But, then i am not sure what will happen to the remaining 9 MPDU's. Does the register wait for 6 more MPDU's so that it can aggregate 15 MPDU's to form 1 ampdu or does it write to a different registry like AggSize9Count where these 9 MPDU's can get aggregated to an ampdu. Can you please explain ? -Ram On Thu, Nov 29, 2012 at 3:35 AM, PseudoCylon wrote: > On Wed, Nov 28, 2012 at 9:35 PM, Ramanujan Seshadri > wrote: > > Hello, > > > > Thanks for the reply. I just had one more doubt. > > > > In the counters to update the transmitted A-MPDU counter (Function Name: > > NICUpdateRawCounters), i saw these lines of codes > > > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > > TxAggCnt0.field.AggSize1Count; > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > > (TxAggCnt0.field.AggSize2Count >> 1); > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > > (TxAggCnt0.field.AggSize3Count /3); > > . > > . > > . > > . > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > > (TxAggCnt0.field.AggSize15Count/ 15); > > pRalinkCounters->TransmittedAMPDUCount.u.LowPart += > > (TxAggCnt0.field.AggSize16Count >> 4); > > > > Can you please explain the reason why the 'i'th counter is being divided > by > > i, for example .TxAggCnt0.field.AggSize15Count is being divided by 15. > > [NB] For people who haven't seen Ralink's code, the above codes are theirs. > > I guess I didn't explain well. Those counters show number of mpdu > packets, i.e. AggSize15Count == 30 means 30 mpdu or 2 (30/15) ampdu > packets. (Because I don't have any datasheet, that how I interpret > Ralink's code.) > > > > > Also if these were little endian counters then i could not understand the > > reason why the four counters "TxAggCnt0.field.AggSize2Count, > > TxAggCnt0.field.AggSize4Count, TxAggCnt0.field.AggSize8Count > > and TxAggCnt0.field.AggSize16Count " are shifted right by some bits, > which > > means that they are multiplying them (since it is little endian > registers) > > and why they are dividing the others. > > RTMP_IO_READ32() does byte swapping. The values should be saved into > AggSizeNCount with host's byte order. So, right sifting means dividing > regardless of the byte order. > >>1 == /2 > ... > >>4 == /16 > They are playing nice to CPUs, I think. > > > AK > > > > > Thanks for the help. > > > > -ram > > > > > > On Tue, Nov 27, 2012 at 6:07 PM, PseudoCylon > > wrote: > >> > >> On Tue, Nov 27, 2012 at 1:23 PM, Ramanujan Seshadri > >> wrote: > >> > I want to know how many MPDU's are aggregated in each AMPDU > >> > transmission. > >> > >> You could use following statistic counters > >> RT2860_TX_AGG_CNT0 to 7 > >> > >> > https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_runreg.h#line186 > >> Each 32-bit little-endian read-on-clear register contains 2 16-bit > >> counters (total 16 16-bit counters). > >> counter at offset 0x1720 MPDU count 1 > >> counter at offset 0x1722 MPDU count 2 > >> ... > >> counter at offset 0x173c MPDU count 15 > >> counter at offset 0x173e MPDU count >= 16 > >> > >> These regs are identical on RT2800 and RT2700 (pci/usb). > >> > >> Example (see #if 0 part) > >> > https://gitorious.org/run/run/blobs/11n_rc3/dev/usb/wlan/if_run.c#line2493 > >> > >> You can only find out statistical numbers (total Tx counts past X > >> sec). You cannot find out an MPDU count in a particular packet, i.e. > >> an aggregated packet just Tx'd, unless you read the counters on each > >> Tx. > >> > >> > >> AK > >> > >> > > >> > -ram > >> > > >> > > >> > On Tue, Nov 27, 2012 at 2:11 PM, PseudoCylon > > >> > wrote: > >> >> > >> >> > ------------------------------ > >> >> > > >> >> > Message: 12 > >> >> > Date: Tue, 27 Nov 2012 04:33:37 -0500 > >> >> > From: Ramanujan Seshadri > >> >> > To: freebsd-net@freebsd.org > >> >> > Subject: Ralink RT2860 Driver Code > >> >> > Message-ID: > >> >> > > >> >> > C58L7YAp+YGk3PZ2VJG9toaKWcBHHi7xsaxth6-KYf0d6xg@mail.gmail.com> > >> >> > Content-Type: text/plain; charset=ISO-8859-1 > >> >> > > >> >> > Hello, > >> >> > Can i know how to get the MPDU's aggregated in each AMPDU in a > >> >> > ralink > >> >> > driver code for RT2860. I saw the existing counters of ralink and > >> >> > tried > >> >> > to > >> >> > get some info, but was not very useful. > >> >> > Any help is greatly appreciated. > >> >> > > >> >> > >> >> https://gitorious.org/run/run/trees/11n_rc3/dev/usb/wlan > >> >> > >> >> What info are you trying to get? > >> >> > >> >> > >> >> AK > >> >> > >> >> > Thanks > >> >> > ram > >> >> > > >> >> > > >> >> > ------------------------------ > >> >> > > >> >> > _______________________________________________ > >> >> > 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" > >> >> > > >> >> > End of freebsd-net Digest, Vol 504, Issue 2 > >> >> > ******************************************* > >> > > >> > > > > > > From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 22:12:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6BF2B3C9 for ; Sat, 1 Dec 2012 22:12:54 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 28C708FC14 for ; Sat, 1 Dec 2012 22:12:54 +0000 (UTC) Received: by mail-ob0-f182.google.com with SMTP id 16so1841169obc.13 for ; Sat, 01 Dec 2012 14:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=2ThkNi2VgRQzvXiuYKkI8FU17wkLrGf7P0e3vg89zXc=; b=giObe3lhFLaVCEEJQ2CCE8D+M8/5wKxxr9A0su0AbaTdp9vFQl3O9bQLNnuV7zU4SM 3HaXxhMyDg7yZT7eLgjsNSL1GY/EEqA6Gf0vwv3RHWFEvg69gsg/yjZVeLG68BWxw/3w b+859iKDJYcn84knccUx2uvDXuz1OSEeSWkFBUO+0bloYtAOUNMy46wJLDOdj/Kd0r5V ZlJhnWB+gGLK5Up8aqNNm7v0EgsK7Rvu5OqT87ZDmN/iETp8P2Pa5cyAdBBP7TaEl+8f 7MTfj239mvoa3eIa/2z4rzvXB2kv4tsHDX6zwCVGuj/vry50F97FnrC/h6HmWz86MtWt Qgyg== MIME-Version: 1.0 Received: by 10.60.13.198 with SMTP id j6mr4725569oec.51.1354399973680; Sat, 01 Dec 2012 14:12:53 -0800 (PST) Received: by 10.60.80.104 with HTTP; Sat, 1 Dec 2012 14:12:53 -0800 (PST) Date: Sat, 1 Dec 2012 17:12:53 -0500 Message-ID: Subject: MCS selected for each transmission in Ralink RT2860 From: Ramanujan Seshadri 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: Sat, 01 Dec 2012 22:12:54 -0000 Hello all, i wanted to know if i can get the MCS (bit rate ) used to send each packet in a ralink rt2860 wireless NIC. I saw the ralink code and got to know that they have a rate-adaptation algorithm to select the best rate (when the HT_MCS parameter =33). But, i wanted to know if i can get the details the bit-rate used to send each packet. Thanks ram From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 22:20:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BA9A602; Sat, 1 Dec 2012 22:20:29 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id BEE8D8FC12; Sat, 1 Dec 2012 22:20:27 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1MK7M9089952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Dec 2012 07:20:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1MK5c6055425; Sun, 2 Dec 2012 07:20:07 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 02 Dec 2012 06:54:36 +0900 (JST) Message-Id: <20121202.065436.1086216324076847740.hrs@allbsd.org> To: mjguzik@gmail.com, ae@FreeBSD.org, adrian@FreeBSD.org, rpaulo@FreeBSD.org Subject: Re: LOR in rtsock/ifnet From: Hiroki Sato In-Reply-To: <20121201.225004.2232262673795057435.hrs@allbsd.org> References: <20121201133609.GA5450@dft-labs.eu> <20121201.225004.2232262673795057435.hrs@allbsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Dec__2_06_54_36_2012_215)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 02 Dec 2012 07:20:18 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 22:20:29 -0000 ----Security_Multipart0(Sun_Dec__2_06_54_36_2012_215)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Dec__2_06_54_36_2012_395)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Dec__2_06_54_36_2012_395)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hiroki Sato wrote in <20121201.225004.2232262673795057435.hrs@allbsd.org>: hr> Mateusz Guzik wrote hr> in <20121201133609.GA5450@dft-labs.eu>: hr> hr> mj> On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: hr> mj> > Mateusz: are you sure it's that commit? hr> mj> > hr> mj> hr> mj> Yes, I double-checked right now. hr> mj> hr> mj> > I still get this in -HEAD: hr> mj> > hr> mj> hr> mj> Maybe I expressed myself incorrectly, I meant to say that LOR started hr> mj> showing up since r243187. hr> mj> hr> mj> The code is still in head and no fixes were comitted (that I know of at hr> mj> least), so I guess that you seeing this LOR on head is expected. :) hr> hr> Thanks for the info. I am investigating this now. Can anyone test the attached patch and let me know if the LOR persists or not? -- Hiroki ----Next_Part(Sun_Dec__2_06_54_36_2012_395)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scope6_lorfix_20121201-1.diff" Index: sys/net/rtsock.c =================================================================== --- sys/net/rtsock.c (revision 243465) +++ sys/net/rtsock.c (working copy) @@ -175,14 +175,6 @@ #define RTSOCK_LOCK_ASSERT() mtx_assert(&rtsock_mtx, MA_OWNED) static SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, ""); -#ifdef INET6 -static VNET_DEFINE(int, deembed_scopeid) = 1; -#define V_deembed_scopeid VNET(deembed_scopeid) -SYSCTL_DECL(_net_inet6_ip6); -SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW, - &VNET_NAME(deembed_scopeid), 0, - "Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6."); -#endif struct walkarg { int w_tmemsize; @@ -804,28 +796,31 @@ } info.rti_info[RTAX_DST] = rt_key(rt); #ifdef INET6 - switch (rt_key(rt)->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (rt_key(rt)->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss_dst; + bcopy(rt_key(rt), sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[RTAX_DST] = + (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss_dst; - bcopy(rt_key(rt), sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[RTAX_DST] = - (struct sockaddr *)sin6; - break; + } } #endif info.rti_info[RTAX_GATEWAY] = rt->rt_gateway; #ifdef INET6 - switch (rt->rt_gateway->sa_family) { - case AF_INET6: - sin6 = (struct sockaddr_in6 *)&ss_gw; - bcopy(rt->rt_gateway, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[RTAX_GATEWAY] = - (struct sockaddr *)sin6; - break; + if (V_deembed_scopeid) { + switch (rt->rt_gateway->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss_gw; + bcopy(rt->rt_gateway, sin6, + sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[RTAX_GATEWAY] = + (struct sockaddr *)sin6; + break; + } } #endif info.rti_info[RTAX_NETMASK] = rt_mask(rt); @@ -1130,15 +1125,15 @@ rtinfo->rti_addrs |= (1 << i); dlen = SA_SIZE(sa); #ifdef INET6 - switch (sa->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (sa->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss; + bcopy(sa, sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + sa = (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss; - bcopy(sa, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - sa = (struct sockaddr *)sin6; - break; + } } #endif m_copyback(m, len, dlen, (caddr_t)sa); @@ -1219,15 +1214,15 @@ rtinfo->rti_addrs |= (1 << i); dlen = SA_SIZE(sa); #ifdef INET6 - switch (sa->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (sa->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss; + bcopy(sa, sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + sa = (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss; - bcopy(sa, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - sa = (struct sockaddr *)sin6; - break; + } } #endif if (cp) { @@ -1594,18 +1589,19 @@ info.rti_info[RTAX_BRD] = rt->rt_ifa->ifa_dstaddr; } #ifdef INET6 - for (i = 0; i < RTAX_MAX; i++) { - if (info.rti_info[i] == NULL) - continue; - switch (info.rti_info[i]->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + for (i = 0; i < RTAX_MAX; i++) { + if (info.rti_info[i] == NULL) + continue; + switch (info.rti_info[i]->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss[i]; + bcopy(info.rti_info[i], sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[i] = + (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss[i]; - bcopy(info.rti_info[i], sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[i] = (struct sockaddr *)sin6; - break; + } } } #endif @@ -1811,7 +1807,7 @@ int len, error = 0; bzero((caddr_t)&info, sizeof(info)); - IFNET_RLOCK(); + IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (w->w_arg && w->w_arg != ifp->if_index) continue; @@ -1856,7 +1852,7 @@ done: if (ifp != NULL) IF_ADDR_RUNLOCK(ifp); - IFNET_RUNLOCK(); + IFNET_RUNLOCK_NOSLEEP(); return (error); } @@ -1870,7 +1866,7 @@ struct ifaddr *ifa; bzero((caddr_t)&info, sizeof(info)); - IFNET_RLOCK(); + IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (w->w_arg && w->w_arg != ifp->if_index) continue; @@ -1905,7 +1901,7 @@ IF_ADDR_RUNLOCK(ifp); } done: - IFNET_RUNLOCK(); + IFNET_RUNLOCK_NOSLEEP(); return (error); } Index: sys/netinet6/in6_cksum.c =================================================================== --- sys/netinet6/in6_cksum.c (revision 243465) +++ sys/netinet6/in6_cksum.c (working copy) @@ -66,6 +66,7 @@ #include #include #include +#include #include #include #include Index: sys/netinet6/scope6.c =================================================================== --- sys/netinet6/scope6.c (revision 243465) +++ sys/netinet6/scope6.c (working copy) @@ -38,6 +38,7 @@ #include #include #include +#include #include #include @@ -55,7 +56,11 @@ #else VNET_DEFINE(int, ip6_use_defzone) = 0; #endif - +VNET_DEFINE(int, deembed_scopeid) = 1; +SYSCTL_DECL(_net_inet6_ip6); +SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW, + &VNET_NAME(deembed_scopeid), 0, + "Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6."); /* * The scope6_lock protects the global sid default stored in * sid_default below. Index: sys/netinet6/scope6_var.h =================================================================== --- sys/netinet6/scope6_var.h (revision 243465) +++ sys/netinet6/scope6_var.h (working copy) @@ -42,6 +42,9 @@ u_int32_t s6id_list[16]; }; +VNET_DECLARE(int, deembed_scopeid); +#define V_deembed_scopeid VNET(deembed_scopeid) + void scope6_init(void); struct scope6_id *scope6_ifattach(struct ifnet *); void scope6_ifdetach(struct scope6_id *); ----Next_Part(Sun_Dec__2_06_54_36_2012_395)---- ----Security_Multipart0(Sun_Dec__2_06_54_36_2012_215)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC6fJwACgkQTyzT2CeTzy0qYQCePFCleprynVx8yxuAPez8Lfd1 +IYAoM5O/ve1Lu7mNIcqRD99kZZd4AMr =v5c+ -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Dec__2_06_54_36_2012_215)---- From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 22:31:03 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9E1268B6; Sat, 1 Dec 2012 22:31:03 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by mx1.freebsd.org (Postfix) with ESMTP id 827428FC08; Sat, 1 Dec 2012 22:31:02 +0000 (UTC) Received: by mail-wg0-f52.google.com with SMTP id 12so842540wgh.31 for ; Sat, 01 Dec 2012 14:31:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=eU+c45EwjuquaExmzWfppfihsfdDJXcE+pDgB6v4jF0=; b=bume6SWuoAKXnD28d6JLEeLi1V83JdQxY+WXz9HbJ+kaspeb+5L19UM2FHj7Zfa4xO egYeFMzlf5I6Tu/j+iLIP75Z/mcqZsViur8ZxExjvfjiSoX+mzypdZi1iBhPGYa7SK3A 3oV5WXkxywAdlSFQ+3Dt2AH89NuLMYi2GoHBY/RDpCpWU6d2KkjG2T5PZBRA8T2V0PZC SG/xi/yGECp8ei4GttpQRJe8+SyPDhwT62oLctodn4USuyOFM+0BLmQ2qosvM3lOJEH6 8p4TW2MBbvR5nzZ9v3FgL6iHcjG82e6yJ4LForozNk1OE08FBd1za41zFiIsT1gyCvlb GCng== Received: by 10.216.206.212 with SMTP id l62mr1719743weo.218.1354401061237; Sat, 01 Dec 2012 14:31:01 -0800 (PST) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by mx.google.com with ESMTPS id u6sm5379217wif.2.2012.12.01.14.30.58 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 01 Dec 2012 14:30:59 -0800 (PST) Date: Sat, 1 Dec 2012 23:30:49 +0100 From: Mateusz Guzik To: Hiroki Sato Subject: Re: LOR in rtsock/ifnet Message-ID: <20121201223049.GA12120@dft-labs.eu> References: <20121201133609.GA5450@dft-labs.eu> <20121201.225004.2232262673795057435.hrs@allbsd.org> <20121202.065436.1086216324076847740.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20121202.065436.1086216324076847740.hrs@allbsd.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: ae@FreeBSD.org, adrian@FreeBSD.org, rpaulo@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: Sat, 01 Dec 2012 22:31:03 -0000 On Sun, Dec 02, 2012 at 06:54:36AM +0900, Hiroki Sato wrote: > Hiroki Sato wrote > in <20121201.225004.2232262673795057435.hrs@allbsd.org>: > > hr> Mateusz Guzik wrote > hr> in <20121201133609.GA5450@dft-labs.eu>: > hr> > hr> mj> On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: > hr> mj> > Mateusz: are you sure it's that commit? > hr> mj> > > hr> mj> > hr> mj> Yes, I double-checked right now. > hr> mj> > hr> mj> > I still get this in -HEAD: > hr> mj> > > hr> mj> > hr> mj> Maybe I expressed myself incorrectly, I meant to say that LOR started > hr> mj> showing up since r243187. > hr> mj> > hr> mj> The code is still in head and no fixes were comitted (that I know of at > hr> mj> least), so I guess that you seeing this LOR on head is expected. :) > hr> > hr> Thanks for the info. I am investigating this now. > > Can anyone test the attached patch and let me know if the LOR > persists or not? > I got the following build failure: /srv/repos/freebsd/sys/netinet6/in6_cksum.c:69:22: error: sys/vnet.h: No such file or directory In file included from /srv/repos/freebsd/sys/netinet6/in6_cksum.c:72: /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: error: expected declaration specifiers or '...' before 'deembed_scopeid' cc1: warnings being treated as errors /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: data definition has no type or storage class /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: type defaults to 'int' in declaration of 'VNET_DECLARE' However after changing sys/vnet.h to net/vnet.h the kernel compiled fine and LOR is gone. -- Mateusz Guzik From owner-freebsd-net@FreeBSD.ORG Sat Dec 1 23:32:28 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7618F90; Sat, 1 Dec 2012 23:32:28 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) by mx1.freebsd.org (Postfix) with ESMTP id D306D8FC0C; Sat, 1 Dec 2012 23:32:26 +0000 (UTC) Received: from alph.allbsd.org (p1137-ipbf1505funabasi.chiba.ocn.ne.jp [118.7.212.137]) (authenticated bits=128) by mail.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1NWAd8098679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 2 Dec 2012 08:32:20 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [127.0.0.1]) (authenticated bits=0) by alph.allbsd.org (8.14.5/8.14.5) with ESMTP id qB1NW8Vo050788; Sun, 2 Dec 2012 08:32:10 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Sun, 02 Dec 2012 08:30:35 +0900 (JST) Message-Id: <20121202.083035.823064739980116980.hrs@allbsd.org> To: mjguzik@gmail.com Subject: Re: LOR in rtsock/ifnet From: Hiroki Sato In-Reply-To: <20121201223049.GA12120@dft-labs.eu> References: <20121201.225004.2232262673795057435.hrs@allbsd.org> <20121202.065436.1086216324076847740.hrs@allbsd.org> <20121201223049.GA12120@dft-labs.eu> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart0(Sun_Dec__2_08_30_35_2012_445)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (mail.allbsd.org [133.31.130.32]); Sun, 02 Dec 2012 08:32:20 +0900 (JST) X-Spam-Status: No, score=-98.1 required=13.0 tests=CONTENT_TYPE_PRESENT, ONLY1HOPDIRECT,SAMEHELOBY2HOP,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: ae@FreeBSD.org, adrian@FreeBSD.org, rpaulo@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: Sat, 01 Dec 2012 23:32:28 -0000 ----Security_Multipart0(Sun_Dec__2_08_30_35_2012_445)-- Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_Dec__2_08_30_35_2012_623)--" Content-Transfer-Encoding: 7bit ----Next_Part(Sun_Dec__2_08_30_35_2012_623)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mateusz Guzik wrote in <20121201223049.GA12120@dft-labs.eu>: mj> On Sun, Dec 02, 2012 at 06:54:36AM +0900, Hiroki Sato wrote: mj> > Hiroki Sato wrote mj> > in <20121201.225004.2232262673795057435.hrs@allbsd.org>: mj> > mj> > hr> Mateusz Guzik wrote mj> > hr> in <20121201133609.GA5450@dft-labs.eu>: mj> > hr> mj> > hr> mj> On Fri, Nov 30, 2012 at 11:16:25PM -0800, Adrian Chadd wrote: mj> > hr> mj> > Mateusz: are you sure it's that commit? mj> > hr> mj> > mj> > hr> mj> mj> > hr> mj> Yes, I double-checked right now. mj> > hr> mj> mj> > hr> mj> > I still get this in -HEAD: mj> > hr> mj> > mj> > hr> mj> mj> > hr> mj> Maybe I expressed myself incorrectly, I meant to say that LOR started mj> > hr> mj> showing up since r243187. mj> > hr> mj> mj> > hr> mj> The code is still in head and no fixes were comitted (that I know of at mj> > hr> mj> least), so I guess that you seeing this LOR on head is expected. :) mj> > hr> mj> > hr> Thanks for the info. I am investigating this now. mj> > mj> > Can anyone test the attached patch and let me know if the LOR mj> > persists or not? mj> > mj> mj> I got the following build failure: mj> /srv/repos/freebsd/sys/netinet6/in6_cksum.c:69:22: error: sys/vnet.h: No mj> such file or directory mj> In file included from /srv/repos/freebsd/sys/netinet6/in6_cksum.c:72: mj> /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: error: expected mj> declaration specifiers or '...' before 'deembed_scopeid' mj> cc1: warnings being treated as errors mj> /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: data mj> definition has no type or storage class mj> /srv/repos/freebsd/sys/netinet6/scope6_var.h:45: warning: type defaults mj> to 'int' in declaration of 'VNET_DECLARE' Oops, sorry. The attached one should work. The difference is only s|sys/vnet.h|net/vnet| as you also pointed out. mj> However after changing sys/vnet.h to net/vnet.h the kernel compiled fine mj> and LOR is gone. Thank you! I am double-checking if there is some negative impact by this change. -- Hiroki ----Next_Part(Sun_Dec__2_08_30_35_2012_623)-- Content-Type: Text/X-Patch; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="scope6_lorfix_20121201-2.diff" Index: sys/net/rtsock.c =================================================================== --- sys/net/rtsock.c (revision 243465) +++ sys/net/rtsock.c (working copy) @@ -175,14 +175,6 @@ #define RTSOCK_LOCK_ASSERT() mtx_assert(&rtsock_mtx, MA_OWNED) static SYSCTL_NODE(_net, OID_AUTO, route, CTLFLAG_RD, 0, ""); -#ifdef INET6 -static VNET_DEFINE(int, deembed_scopeid) = 1; -#define V_deembed_scopeid VNET(deembed_scopeid) -SYSCTL_DECL(_net_inet6_ip6); -SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW, - &VNET_NAME(deembed_scopeid), 0, - "Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6."); -#endif struct walkarg { int w_tmemsize; @@ -804,28 +796,31 @@ } info.rti_info[RTAX_DST] = rt_key(rt); #ifdef INET6 - switch (rt_key(rt)->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (rt_key(rt)->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss_dst; + bcopy(rt_key(rt), sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[RTAX_DST] = + (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss_dst; - bcopy(rt_key(rt), sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[RTAX_DST] = - (struct sockaddr *)sin6; - break; + } } #endif info.rti_info[RTAX_GATEWAY] = rt->rt_gateway; #ifdef INET6 - switch (rt->rt_gateway->sa_family) { - case AF_INET6: - sin6 = (struct sockaddr_in6 *)&ss_gw; - bcopy(rt->rt_gateway, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[RTAX_GATEWAY] = - (struct sockaddr *)sin6; - break; + if (V_deembed_scopeid) { + switch (rt->rt_gateway->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss_gw; + bcopy(rt->rt_gateway, sin6, + sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[RTAX_GATEWAY] = + (struct sockaddr *)sin6; + break; + } } #endif info.rti_info[RTAX_NETMASK] = rt_mask(rt); @@ -1130,15 +1125,15 @@ rtinfo->rti_addrs |= (1 << i); dlen = SA_SIZE(sa); #ifdef INET6 - switch (sa->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (sa->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss; + bcopy(sa, sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + sa = (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss; - bcopy(sa, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - sa = (struct sockaddr *)sin6; - break; + } } #endif m_copyback(m, len, dlen, (caddr_t)sa); @@ -1219,15 +1214,15 @@ rtinfo->rti_addrs |= (1 << i); dlen = SA_SIZE(sa); #ifdef INET6 - switch (sa->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + switch (sa->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss; + bcopy(sa, sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + sa = (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss; - bcopy(sa, sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - sa = (struct sockaddr *)sin6; - break; + } } #endif if (cp) { @@ -1594,18 +1589,19 @@ info.rti_info[RTAX_BRD] = rt->rt_ifa->ifa_dstaddr; } #ifdef INET6 - for (i = 0; i < RTAX_MAX; i++) { - if (info.rti_info[i] == NULL) - continue; - switch (info.rti_info[i]->sa_family) { - case AF_INET6: - if (V_deembed_scopeid == 0) + if (V_deembed_scopeid) { + for (i = 0; i < RTAX_MAX; i++) { + if (info.rti_info[i] == NULL) + continue; + switch (info.rti_info[i]->sa_family) { + case AF_INET6: + sin6 = (struct sockaddr_in6 *)&ss[i]; + bcopy(info.rti_info[i], sin6, sizeof(*sin6)); + if (sa6_recoverscope(sin6) == 0) + info.rti_info[i] = + (struct sockaddr *)sin6; break; - sin6 = (struct sockaddr_in6 *)&ss[i]; - bcopy(info.rti_info[i], sin6, sizeof(*sin6)); - if (sa6_recoverscope(sin6) == 0) - info.rti_info[i] = (struct sockaddr *)sin6; - break; + } } } #endif @@ -1811,7 +1807,7 @@ int len, error = 0; bzero((caddr_t)&info, sizeof(info)); - IFNET_RLOCK(); + IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (w->w_arg && w->w_arg != ifp->if_index) continue; @@ -1856,7 +1852,7 @@ done: if (ifp != NULL) IF_ADDR_RUNLOCK(ifp); - IFNET_RUNLOCK(); + IFNET_RUNLOCK_NOSLEEP(); return (error); } @@ -1870,7 +1866,7 @@ struct ifaddr *ifa; bzero((caddr_t)&info, sizeof(info)); - IFNET_RLOCK(); + IFNET_RLOCK_NOSLEEP(); TAILQ_FOREACH(ifp, &V_ifnet, if_link) { if (w->w_arg && w->w_arg != ifp->if_index) continue; @@ -1905,7 +1901,7 @@ IF_ADDR_RUNLOCK(ifp); } done: - IFNET_RUNLOCK(); + IFNET_RUNLOCK_NOSLEEP(); return (error); } Index: sys/netinet6/in6_cksum.c =================================================================== --- sys/netinet6/in6_cksum.c (revision 243465) +++ sys/netinet6/in6_cksum.c (working copy) @@ -66,6 +66,7 @@ #include #include #include +#include #include #include #include Index: sys/netinet6/scope6.c =================================================================== --- sys/netinet6/scope6.c (revision 243465) +++ sys/netinet6/scope6.c (working copy) @@ -38,6 +38,7 @@ #include #include #include +#include #include #include @@ -55,7 +56,11 @@ #else VNET_DEFINE(int, ip6_use_defzone) = 0; #endif - +VNET_DEFINE(int, deembed_scopeid) = 1; +SYSCTL_DECL(_net_inet6_ip6); +SYSCTL_VNET_INT(_net_inet6_ip6, OID_AUTO, deembed_scopeid, CTLFLAG_RW, + &VNET_NAME(deembed_scopeid), 0, + "Extract embedded zone ID and set it to sin6_scope_id in sockaddr_in6."); /* * The scope6_lock protects the global sid default stored in * sid_default below. Index: sys/netinet6/scope6_var.h =================================================================== --- sys/netinet6/scope6_var.h (revision 243465) +++ sys/netinet6/scope6_var.h (working copy) @@ -42,6 +42,9 @@ u_int32_t s6id_list[16]; }; +VNET_DECLARE(int, deembed_scopeid); +#define V_deembed_scopeid VNET(deembed_scopeid) + void scope6_init(void); struct scope6_id *scope6_ifattach(struct ifnet *); void scope6_ifdetach(struct scope6_id *); ----Next_Part(Sun_Dec__2_08_30_35_2012_623)---- ----Security_Multipart0(Sun_Dec__2_08_30_35_2012_445)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAlC6kxsACgkQTyzT2CeTzy3JewCfQgh8v51YZRgBh4Q7DtQZuFLT hpAAoJpTSDVzII46FnJX1eW0zSg1IBS1 =ALoj -----END PGP SIGNATURE----- ----Security_Multipart0(Sun_Dec__2_08_30_35_2012_445)----