From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 02:29:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2567E1065672 for ; Sun, 19 Feb 2012 02:29:51 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id D9B8E8FC13 for ; Sun, 19 Feb 2012 02:29:50 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by smtp.as41113.net (Postfix) with ESMTPSA id 8655C2280F; Sun, 19 Feb 2012 02:29:49 +0000 (UTC) Message-ID: <4F405E96.9020804@rewt.org.uk> Date: Sun, 19 Feb 2012 02:29:42 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Raymond Wagner References: <4F3F4810.6070501@rewt.org.uk> <4F3F6D95.1000605@wagnerrp.com> <4F3FD501.4060307@rewt.org.uk> <4F3FF6F2.90002@wagnerrp.com> In-Reply-To: <4F3FF6F2.90002@wagnerrp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Panic after vnet/jail destroy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 02:29:51 -0000 On 18/02/2012 19:07, Raymond Wagner wrote: > On 2/18/2012 11:42, Joe Holden wrote: >> On 18/02/2012 09:21, Raymond Wagner wrote: >>> On 2/18/2012 01:41, Joe Holden wrote: >>>> jail_relay_exec_poststop0="ifconfig bridge0 deletem epair0a" >>>> jail_relay_exec_poststop1="ifconfig epair0a destroy" >>>> jail_relay_exec_poststop2="ifconfig bridge1 deletem epair1a" >>>> jail_relay_exec_poststop3="ifconfig epair1a destroy" >>> >>> The kernel panics when you try to destroy an epair. This is a known >>> issue, and not a new issue. I've see the same problem at least as far >>> back as 8.1. The current work around is to simply not destroy them >>> when you bring down your jails. Of course this does mean you will >>> build up a collection of unused epairs. >> Hm really? I haven't seen it when not using the jailv2 stuff, is there a >> pr for this? > > I don't know off hand if there are any open tickets related to this, > but a quick search came up with... > > http://lists.freebsd.org/pipermail/freebsd-virtualization/2011-January/000628.html > aha, thanks! J From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 07:48:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B21781065672 for ; Sun, 19 Feb 2012 07:48:36 +0000 (UTC) (envelope-from lists@rewt.org.uk) Received: from mx.as41113.net (abby.lhr1.as41113.net [91.208.177.20]) by mx1.freebsd.org (Postfix) with ESMTP id 78D518FC0C for ; Sun, 19 Feb 2012 07:48:36 +0000 (UTC) Received: from [172.16.11.44] (unknown [91.208.177.192]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: lists@rewt.org.uk) by smtp.as41113.net (Postfix) with ESMTPSA id 0A54522810 for ; Sun, 19 Feb 2012 07:48:30 +0000 (UTC) Message-ID: <4F40A8D8.2020505@rewt.org.uk> Date: Sun, 19 Feb 2012 07:46:32 +0000 From: Joe Holden User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: VIMAGE and tap/tun/openvpn X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 07:48:36 -0000 Hi guys, I know this is a known problem but is there any plan to fix it or is there something fundamental getting in the way? Looks like it's this: http://www.freebsd.org/cgi/query-pr.cgi?pr=152047 Thanks, J From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 09:45:09 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10157106564A for ; Sun, 19 Feb 2012 09:45:09 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 77B398FC19 for ; Sun, 19 Feb 2012 09:45:08 +0000 (UTC) Received: by lagz14 with SMTP id z14so7790517lag.13 for ; Sun, 19 Feb 2012 01:45:07 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.112.84.233 as permitted sender) client-ip=10.112.84.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.112.84.233 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.112.84.233]) by 10.112.84.233 with SMTP id c9mr4736165lbz.1.1329644707272 (num_hops = 1); Sun, 19 Feb 2012 01:45:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Ou3mkE1SoTrW0kn3RrRqjuGRYmCbelY9lKW87v8UD8A=; b=xFpPYVIujG9mrKjdX+z9z9T8UoicjdatooG45dLY0kBd/AY1k+mNxDSWIIH99/v005 xrG0PcRJmiNtd7aed58izkK+zAwF0/jnah0HawDzXCAnxzaUweFULuVY2rhwpO+xcemN sRNpnDEwa8tXMEmDiaFXKWL4QTDVS0+CVhSr4= MIME-Version: 1.0 Received: by 10.112.84.233 with SMTP id c9mr3951376lbz.1.1329644707208; Sun, 19 Feb 2012 01:45:07 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.112.87.35 with HTTP; Sun, 19 Feb 2012 01:45:07 -0800 (PST) In-Reply-To: References: Date: Sun, 19 Feb 2012 01:45:07 -0800 X-Google-Sender-Auth: 45LzzUCLkmQlouUQ6W6569i-sKg Message-ID: From: Adrian Chadd To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: net80211 - how the heck is M_FRAG (mbuf/net80211 fragments) supposed to work? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 09:45:09 -0000 On 17 February 2012 00:53, Adrian Chadd wrote: > Hi, > > So ray@ pointed out that fragment handling in net80211 is broken. Yes, > 802.11 fragments, not IP fragments. This is specific to ath, but any > driver using IFQ_ENQUEUE/IFQ_DEQUEUE is likely broken. After doing some digging, I stumbled across: r190579 | sam | 2009-03-30 14:53:27 -0700 (Mon, 30 Mar 2009) | 25 lines Hoist 802.11 encapsulation up into net80211: o call ieee80211_encap in ieee80211_start so frames passed down to drivers are already encapsulated o remove ieee80211_encap calls in drivers ... So I wonder if fragment encapsulation was broken at this point? The ath driver would've been able to decapsulate that list of fragment frames and feed them one at a time to the fragment/TX side. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 12:10:04 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43FDE106566B for ; Sun, 19 Feb 2012 12:10:04 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 130198FC18 for ; Sun, 19 Feb 2012 12:10:04 +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 q1JCA3RJ047075 for ; Sun, 19 Feb 2012 12:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1JCA3Bh047074; Sun, 19 Feb 2012 12:10:03 GMT (envelope-from gnats) Date: Sun, 19 Feb 2012 12:10:03 GMT Message-Id: <201202191210.q1JCA3Bh047074@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165032: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 12:10:04 -0000 The following reply was made to PR kern/165032; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165032: commit references a PR Date: Sun, 19 Feb 2012 12:09:30 +0000 (UTC) Author: marius Date: Sun Feb 19 12:09:17 2012 New Revision: 231913 URL: http://svn.freebsd.org/changeset/base/231913 Log: - Probe BCM57780. - In case the parent is bge(4), don't set the Jumbo frame settings unless the MAC actually is Jumbo capable as otherwise the PHY might not have the corresponding registers implemented. This is also in line with what the Linux tg3 driver does. PR: 165032 Submitted by: Alexander Milanov Obtained from: OpenBSD MFC after: 3 days Modified: head/sys/dev/mii/brgphy.c head/sys/dev/mii/miidevs Modified: head/sys/dev/mii/brgphy.c ============================================================================== --- head/sys/dev/mii/brgphy.c Sun Feb 19 10:38:55 2012 (r231912) +++ head/sys/dev/mii/brgphy.c Sun Feb 19 12:09:17 2012 (r231913) @@ -146,6 +146,7 @@ static const struct mii_phydesc brgphys[ MII_PHY_DESC(BROADCOM3, BCM5719C), MII_PHY_DESC(BROADCOM3, BCM5720C), MII_PHY_DESC(BROADCOM3, BCM57765), + MII_PHY_DESC(BROADCOM3, BCM57780), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5906), MII_PHY_END }; @@ -225,7 +226,8 @@ brgphy_attach(device_t dev) sc->mii_flags |= MIIF_HAVEFIBER; } break; - } break; + } + break; case MII_OUI_BROADCOM2: switch (sc->mii_mpd_model) { case MII_MODEL_BROADCOM2_BCM5708S: @@ -942,7 +944,8 @@ brgphy_reset(struct mii_softc *sc) if (bge_sc->bge_phy_flags & BGE_PHY_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if ((bge_sc->bge_phy_flags & BGE_PHY_NO_WIRESPEED) == 0) brgphy_ethernet_wirespeed(sc); Modified: head/sys/dev/mii/miidevs ============================================================================== --- head/sys/dev/mii/miidevs Sun Feb 19 10:38:55 2012 (r231912) +++ head/sys/dev/mii/miidevs Sun Feb 19 12:09:17 2012 (r231913) @@ -179,6 +179,7 @@ model BROADCOM2 BCM5784 0x003a BCM5784 model BROADCOM2 BCM5709C 0x003c BCM5709 10/100/1000baseT PHY model BROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY model BROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY +model BROADCOM3 BCM57780 0x0019 BCM57780 1000BASE-T media interface model BROADCOM3 BCM5717C 0x0020 BCM5717C 1000BASE-T media interface model BROADCOM3 BCM5719C 0x0022 BCM5719C 1000BASE-T media interface model BROADCOM3 BCM57765 0x0024 BCM57765 1000BASE-T media interface _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 13:37:27 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83FB2106566B for ; Sun, 19 Feb 2012 13:37:27 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [IPv6:2a02:6b8:0:602::1]) by mx1.freebsd.org (Postfix) with ESMTP id 9C8D48FC14 for ; Sun, 19 Feb 2012 13:37:26 +0000 (UTC) Received: from smtp3.mail.yandex.net (smtp3.mail.yandex.net [77.88.46.103]) by forward1.mail.yandex.net (Yandex) with ESMTP id 06C7D1241408 for ; Sun, 19 Feb 2012 17:37:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1329658645; bh=7kEQL2LYziDyAbgX9jFPeRH65mC0p0YNCl3JNA5V3a4=; h=Date:From:Reply-To:Message-ID:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=oqzw9IPWxqZMXcw0STvUVHuV5y1xnj+TVB3wpu+DxKuvFBtvtq9Sixk6zg2O8+wwA 5jexTNsIE/q13wO+6ZHBss8HPXcszAf3149Hn5NgVj7sUbdTidBc5+QOVvXlRERACn qjLra005D79O/Aw0cjI5Q4WC2nHXabn7mkDzzxhk= Received: from smtp3.mail.yandex.net (localhost [127.0.0.1]) by smtp3.mail.yandex.net (Yandex) with ESMTP id E09761BA0341 for ; Sun, 19 Feb 2012 17:37:24 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1329658644; bh=7kEQL2LYziDyAbgX9jFPeRH65mC0p0YNCl3JNA5V3a4=; h=Date:From:Reply-To:Message-ID:To:Subject:MIME-Version: Content-Type:Content-Transfer-Encoding; b=oR35zVLxa6ZoLJE2j4KaXSYrPtUEaoV9oIdgFsuLcDM46+JBBJltYaaOVhKozsZld EZTYUciElj8Nd7QMnRnm4avJaS6NxqsGiPH1WQQ48DAtX6+mm7mEjLY9cGKxiFzMEq 6IU8yGJqjye/j0luUe4d22Vev6+92h92ddFwsdRw= Received: from unknown (unknown [77.93.52.20]) by smtp3.mail.yandex.net (nwsmtp/Yandex) with ESMTP id bOQmaVVR-bOQ0FZM4; Sun, 19 Feb 2012 17:37:24 +0400 X-Yandex-Spam: 1 Date: Sun, 19 Feb 2012 15:37:13 +0200 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <47346273.20120219153713@yandex.ru> To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit Subject: freebsd sends arp queries for IP's in not it subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 13:37:27 -0000 # tcpdump -n -i vlan7 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on vlan7, link-type EN10MB (Ethernet), capture size 65535 bytes 15:37:59.202052 ARP, Request who-has 10.12.101.240 tell 10.11.19.147, length 28 15:37:59.258459 ARP, Request who-has 10.83.29.192 tell 10.11.19.147, length 28 15:37:59.400200 ARP, Request who-has 10.7.80.223 tell 10.11.19.147, length 28 15:37:59.409296 ARP, Request who-has 10.4.6.44 tell 10.11.19.147, length 28 15:37:59.850162 ARP, Request who-has 10.0.0.3 tell 10.11.19.147, length 28 15:37:59.920547 ARP, Request who-has 10.7.80.224 tell 10.11.19.147, length 28 15:38:00.093232 ARP, Request who-has 10.192.0.100 tell 10.11.19.147, length 28 15:38:00.164033 ARP, Request who-has 10.199.124.244 tell 10.11.19.147, length 28 15:38:00.312549 ARP, Request who-has 10.168.128.20 tell 10.11.19.147, length 28 15:38:00.384109 ARP, Request who-has 10.13.14.29 tell 10.11.19.147, length 28 15:38:00.410039 ARP, Request who-has 10.7.80.225 tell 10.11.19.147, length 28 15:38:00.511417 ARP, Request who-has 10.242.46.169 tell 10.11.19.147, length 28 15:38:00.897165 ARP, Request who-has 10.49.130.108 tell 10.11.19.147, length 28 15:38:00.912459 ARP, Request who-has 10.7.80.226 tell 10.11.19.147, length 28 15:38:01.269162 ARP, Request who-has 10.83.134.171 tell 10.11.19.147, length 28 15:38:01.411597 ARP, Request who-has 10.7.80.227 tell 10.11.19.147, length 28 15:38:01.567245 ARP, Request who-has 10.11.19.2 tell 10.11.19.147, length 28 15:38:01.574769 ARP, Request who-has 10.35.4.244 tell 10.11.19.147, length 28 15:38:01.778548 ARP, Request who-has 10.20.1.58 tell 10.11.19.147, length 28 15:38:01.909933 ARP, Request who-has 10.7.80.228 tell 10.11.19.147, length 28 15:38:01.996319 ARP, Request who-has 10.199.124.244 tell 10.11.19.147, length 28 15:38:01.998972 ARP, Request who-has 10.20.8.234 tell 10.11.19.147, length 28 15:38:02.091381 ARP, Request who-has 10.0.0.1 tell 10.11.19.147, length 28 15:38:02.411101 ARP, Request who-has 10.7.80.229 tell 10.11.19.147, length 28 15:38:02.413194 ARP, Request who-has 10.4.6.44 tell 10.11.19.147, length 28 15:38:02.580301 ARP, Request who-has 10.11.19.2 tell 10.11.19.147, length 28 15:38:02.876676 ARP, Request who-has 10.49.130.108 tell 10.11.19.147, length 28 15:38:02.918749 ARP, Request who-has 10.7.80.230 tell 10.11.19.147, length 28 15:38:03.312366 ARP, Request who-has 10.0.172.32 tell 10.11.19.147, length 28 15:38:03.376648 ARP, Request who-has 10.68.60.219 tell 10.11.19.147, length 28 15:38:03.406340 ARP, Request who-has 10.7.80.231 tell 10.11.19.147, length 28 15:38:03.573900 ARP, Request who-has 10.35.4.244 tell 10.11.19.147, length 28 15:38:03.590485 ARP, Request who-has 10.11.19.2 tell 10.11.19.147, length 28 15:38:03.803289 ARP, Request who-has 10.0.0.3 tell 10.11.19.147, length 28 15:38:03.912851 ARP, Request who-has 10.7.80.232 tell 10.11.19.147, length 28 15:38:04.104167 ARP, Request who-has 10.199.124.244 tell 10.11.19.147, length 28 15:38:04.414976 ARP, Request who-has 10.7.80.233 tell 10.11.19.147, length 28 15:38:04.507050 ARP, Request who-has 10.242.46.169 tell 10.11.19.147, length 28 15:38:04.577667 ARP, Request who-has 10.67.50.233 tell 10.11.19.147, length 28 15:38:04.888805 ARP, Request who-has 10.49.130.108 tell 10.11.19.147, length 28 15:38:04.919642 ARP, Request who-has 10.7.80.234 tell 10.11.19.147, length 28 15:38:05.143044 ARP, Request who-has 10.13.14.29 tell 10.11.19.147, length 28 15:38:05.410802 ARP, Request who-has 10.7.80.235 tell 10.11.19.147, length 28 15:38:05.646667 ARP, Request who-has 10.3.6.131 tell 10.11.19.147, length 28 15:38:05.906782 ARP, Request who-has 10.7.80.236 tell 10.11.19.147, length 28 ^C 45 packets captured 47 packets received by filter 0 packets dropped by kernel # ifconfig vlan7 vlan7: flags=8843 metric 0 mtu 1500 options=3 ether f4:6d:04:7c:7b:d3 inet 10.11.19.149 netmask 0xfffffff8 broadcast 10.11.19.151 inet6 fe80::f66d:4ff:fe7c:7bd3%vlan7 prefixlen 64 scopeid 0x7 inet 10.11.19.145 netmask 0xfffffff8 broadcast 10.11.19.151 inet 10.11.19.147 netmask 0xfffffff8 broadcast 10.11.19.151 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active vlan: 7 parent interface: re0 Is this a bug? From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 14:16:13 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BC56B1065670; Sun, 19 Feb 2012 14:16:13 +0000 (UTC) (envelope-from auryn@zirakzigil.org) Received: from mx1.giulioferro.ch (mx1.giulioferro.ch [217.150.252.208]) by mx1.freebsd.org (Postfix) with ESMTP id 2D0578FC14; Sun, 19 Feb 2012 14:16:12 +0000 (UTC) Received: from mailscan.giulioferro.ch (unknown [192.168.115.2]) by mx1.giulioferro.ch (Postfix) with ESMTP id C1D763AED7; Sun, 19 Feb 2012 15:16:11 +0100 (CET) X-Virus-Scanned: amavisd-new at example.com Received: from mx1.giulioferro.ch ([192.168.114.4]) by mailscan.giulioferro.ch (mailscan.giulioferro.ch [192.168.115.2]) (amavisd-new, port 10024) with ESMTP id Wv3g4su3EF2n; Sun, 19 Feb 2012 15:16:09 +0100 (CET) Received: from mail.zirakzigil.org (net-93-70-48-129.cust.dsl.vodafone.it [93.70.48.129]) by mx1.giulioferro.ch (Postfix) with ESMTP id 2076E3AEBD; Sun, 19 Feb 2012 15:16:09 +0100 (CET) Received: from ext.zirakzigil.org (unknown [192.168.1.2]) by mail.zirakzigil.org (Postfix) with ESMTP id D8D8F19345B; Sun, 19 Feb 2012 15:16:08 +0100 (CET) X-Virus-Scanned: amavisd-new at zirakzigil.org Received: from mail.zirakzigil.org ([192.168.1.2]) by ext.zirakzigil.org (ext.zirakzigil.org [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 7CqypNtGAT7S; Sun, 19 Feb 2012 15:16:08 +0100 (CET) Received: from [192.168.229.36] (ext [192.168.1.2]) (Authenticated sender: auryn@zirakzigil.org) by mail.zirakzigil.org (Postfix) with ESMTPA id 2D162193456; Sun, 19 Feb 2012 15:16:08 +0100 (CET) Message-ID: <4F410427.6050703@zirakzigil.org> Date: Sun, 19 Feb 2012 15:16:07 +0100 From: Giulio Ferro User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Rick Macklem , freebsd-net@freebsd.org, freebsd-stable@freebsd.org References: <1905075320.1616773.1329616553940.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1905075320.1616773.1329616553940.JavaMail.root@erie.cs.uoguelph.ca> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: kerberized NFS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 14:16:13 -0000 On 02/19/2012 02:55 AM, Rick Macklem wrote: > I just updated the patch: > http://people.freebsd.org/~rmacklem/rpcsec_gss-9.patch > > If you already downloaded it, please do so again, because > it had two arguments reversed in order and would not have > worked. > > I think this one is correct, although I don't currently > have a Kerberos setup to test it with. > > Good luck with it, rick > Thanks a lot. I'm trying next week. From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 18:58:12 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBA441065670 for ; Sun, 19 Feb 2012 18:58:12 +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 8EF858FC13 for ; Sun, 19 Feb 2012 18:58:12 +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 9850125D37C0; Sun, 19 Feb 2012 18:58:11 +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 B4C3DBDBB50; Sun, 19 Feb 2012 18:58:10 +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 SMquvKQqi2XK; Sun, 19 Feb 2012 18:58:09 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AC6E3BDBB4F; Sun, 19 Feb 2012 18:58:09 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4F40A8D8.2020505@rewt.org.uk> Date: Sun, 19 Feb 2012 18:58:08 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <1235C381-6BD9-4FB2-8BE8-E606A56602C2@lists.zabbadoz.net> References: <4F40A8D8.2020505@rewt.org.uk> To: Joe Holden X-Mailer: Apple Mail (2.1084) Cc: "freebsd-net@freebsd.org" Subject: Re: VIMAGE and tap/tun/openvpn X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 18:58:12 -0000 On 19. Feb 2012, at 07:46 , Joe Holden wrote: > Hi guys, >=20 > I know this is a known problem but is there any plan to fix it or is = there something fundamental getting in the way? > Looks like it's this: = http://www.freebsd.org/cgi/query-pr.cgi?pr=3D152047 Can you please move all VIMAGE related discussion to = freebsd-virtualization. Please remember it's still marked experimental so support is = slow/secondary/... /bz --=20 Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 19:35:02 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9193F1065672; Sun, 19 Feb 2012 19:35:02 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 605BB8FC17; Sun, 19 Feb 2012 19:35:02 +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 q1JJZ2G5069484; Sun, 19 Feb 2012 19:35:02 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1JJZ10A069480; Sun, 19 Feb 2012 19:35:01 GMT (envelope-from linimon) Date: Sun, 19 Feb 2012 19:35:01 GMT Message-Id: <201202191935.q1JJZ10A069480@freefall.freebsd.org> To: vlada@devnull.cz, linimon@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/77273: [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 19:35:02 -0000 Synopsis: [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Feb 19 19:34:23 UTC 2012 State-Changed-Why: Unfortunately no one looked at this PR at the time. It has now been obsoleted by the passage of time. http://www.freebsd.org/cgi/query-pr.cgi?pr=77273 From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 19:40:35 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D0E01065672; Sun, 19 Feb 2012 19:40:35 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 2071E8FC1E; Sun, 19 Feb 2012 19:40:35 +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 q1JJeZOE073324; Sun, 19 Feb 2012 19:40:35 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1JJeYJ0073315; Sun, 19 Feb 2012 19:40:34 GMT (envelope-from linimon) Date: Sun, 19 Feb 2012 19:40:34 GMT Message-Id: <201202191940.q1JJeYJ0073315@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-net@FreeBSD.org, freebsd-ipfw@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165190: [ipfw] [lo] loopback interface is not marking ipv6 packets X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 19:40:35 -0000 Old Synopsis: [ipfw] loopback interface is not marking ipv6 packets New Synopsis: [ipfw] [lo] loopback interface is not marking ipv6 packets Responsible-Changed-From-To: freebsd-net->freebsd-ipfw Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 19 19:40:00 UTC 2012 Responsible-Changed-Why: fix assignment. http://www.freebsd.org/cgi/query-pr.cgi?pr=165190 From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 22:19:03 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DCAE3106564A; Sun, 19 Feb 2012 22:19:03 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id AF8EE8FC08; Sun, 19 Feb 2012 22:19:03 +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 q1JMJ340020334; Sun, 19 Feb 2012 22:19:03 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1JMJ3tf020330; Sun, 19 Feb 2012 22:19:03 GMT (envelope-from linimon) Date: Sun, 19 Feb 2012 22:19:03 GMT Message-Id: <201202192219.q1JMJ3tf020330@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165152: [ip6] Does not work through the issue of ipv6 addresses via rtadvd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 22:19:04 -0000 Old Synopsis: Does not work through the issue of ipv6 addresses via rtadvd New Synopsis: [ip6] Does not work through the issue of ipv6 addresses via rtadvd Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 19 22:18:12 UTC 2012 Responsible-Changed-Why: recategorize. http://www.freebsd.org/cgi/query-pr.cgi?pr=165152 From owner-freebsd-net@FreeBSD.ORG Sun Feb 19 22:23:42 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C22DB106564A; Sun, 19 Feb 2012 22:23:42 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 954ED8FC13; Sun, 19 Feb 2012 22:23:42 +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 q1JMNgwk028852; Sun, 19 Feb 2012 22:23:42 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1JMNggD028848; Sun, 19 Feb 2012 22:23:42 GMT (envelope-from linimon) Date: Sun, 19 Feb 2012 22:23:42 GMT Message-Id: <201202192223.q1JMNggD028848@freefall.freebsd.org> To: kes-kes@yandex.ru, linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: bin/164914: interface still accept packets even without IP address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Feb 2012 22:23:42 -0000 Synopsis: interface still accept packets even without IP address State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Feb 19 22:22:31 UTC 2012 State-Changed-Why: Apparently this is by design. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Feb 19 22:22:31 UTC 2012 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=164914 From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 01:54:23 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 19EF9106566C; Mon, 20 Feb 2012 01:54:23 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E178E8FC08; Mon, 20 Feb 2012 01:54:22 +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 q1K1sMHx035366; Mon, 20 Feb 2012 01:54:22 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1K1sMZL035362; Mon, 20 Feb 2012 01:54:22 GMT (envelope-from linimon) Date: Mon, 20 Feb 2012 01:54:22 GMT Message-Id: <201202200154.q1K1sMZL035362@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165296: [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PRI macro X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 01:54:23 -0000 Old Synopsis: Fix EVL_APPLY_VLID, update EVL_APPLY_PRI macro New Synopsis: [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PRI macro Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 20 01:54:04 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165296 From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 01:57:11 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D1CD106566B; Mon, 20 Feb 2012 01:57:11 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 109BF8FC0C; Mon, 20 Feb 2012 01:57:11 +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 q1K1vAig035556; Mon, 20 Feb 2012 01:57:10 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1K1vAvJ035552; Mon, 20 Feb 2012 01:57:10 GMT (envelope-from linimon) Date: Mon, 20 Feb 2012 01:57:10 GMT Message-Id: <201202200157.q1K1vAvJ035552@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/165305: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 01:57:11 -0000 Old Synopsis: Feature parity between IP_TOS and IPV6_TCLASS New Synopsis: [ip6] [request] Feature parity between IP_TOS and IPV6_TCLASS Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 20 01:56:52 UTC 2012 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=165305 From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 02:51:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B8A0106564A for ; Mon, 20 Feb 2012 02:51:17 +0000 (UTC) (envelope-from adam.twardowski@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 40ACD8FC16 for ; Mon, 20 Feb 2012 02:51:16 +0000 (UTC) Received: by iaeo4 with SMTP id o4so9279399iae.13 for ; Sun, 19 Feb 2012 18:51:16 -0800 (PST) Received-SPF: pass (google.com: domain of adam.twardowski@gmail.com designates 10.50.155.170 as permitted sender) client-ip=10.50.155.170; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adam.twardowski@gmail.com designates 10.50.155.170 as permitted sender) smtp.mail=adam.twardowski@gmail.com; dkim=pass header.i=adam.twardowski@gmail.com Received: from mr.google.com ([10.50.155.170]) by 10.50.155.170 with SMTP id vx10mr10046724igb.22.1329706276754 (num_hops = 1); Sun, 19 Feb 2012 18:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=A8WG98ARnJ2nYeX+sUIhXUb2ZUuzisuRZ3N0tvZzm6w=; b=NO3gXLLJBKRlzu1Sh5MSXlnNRHzkZCApOWaWDVb6CuQXRkM6Rsx0NbkgLS1oZDcQnS TNogI+y50kUrf8py7SCFgtfAt3xeRBbuyuOQtIy5xjLzgKJl5ECf2aiXOR8Xe/+U+pO3 BjekvCY+8DxqAeiPsKE94SD+9hePQnVnOunws= MIME-Version: 1.0 Received: by 10.50.155.170 with SMTP id vx10mr8088463igb.22.1329704615488; Sun, 19 Feb 2012 18:23:35 -0800 (PST) Received: by 10.231.101.3 with HTTP; Sun, 19 Feb 2012 18:23:35 -0800 (PST) Date: Sun, 19 Feb 2012 21:23:35 -0500 Message-ID: From: Adam Twardowski To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [urtw] Random wireless crash / kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 02:51:17 -0000 Hello, I submitted a bug report the other day regarding a kernel panic related to the urtw driver. If anyone needs any additional infromation, please let me know. http://www.freebsd.org/cgi/query-pr.cgi?pr=165214 From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 02:59:58 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 620AE106566C; Mon, 20 Feb 2012 02:59:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 117F88FC17; Mon, 20 Feb 2012 02:59:57 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1K2xsO1050766 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 19 Feb 2012 18:59:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F41B789.7050705@freebsd.org> Date: Sun, 19 Feb 2012 19:01:29 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Marcel Moolenaar References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120217135320.GJ55075@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 02:59:58 -0000 On 2/17/12 7:48 AM, Marcel Moolenaar wrote: > On Feb 17, 2012, at 5:53 AM, Gleb Smirnoff wrote: >> M> Thoughts, feedback and suggestion are welcome, >> >> Is it possible to make the structure the driver points to opaque? >> >> Once made, that would allow us to hack on the ifnet (or on its >> successor - iflogical) more aggressively without breaking ABI/API. > Yes, that's the idea. Backward compatibility kinda conflicts > with making struct ifnet entirely abstract, but I don't see > that as a problem without solution. Only as a problem for > which an acceptable solution must be found. > > For example: you can introduce a define that either old or > new drivers use to indicate whether they need full visibility > or whether an abstract type works. This then drives what is > defined/declared and how it's defined/declared. > The trouble is that core debugging is not doable via methods i.e. netstat -i | -I interface [-abdhntW] [-f address_family] [-M core] [-N system] becomes much more difficult to achieve. From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 03:06:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE8B6106566B for ; Mon, 20 Feb 2012 03:06:28 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3896C8FC08 for ; Mon, 20 Feb 2012 03:06:27 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4180057wib.13 for ; Sun, 19 Feb 2012 19:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=DIXwJFNs/SYnLqTZOD5IBkXN2Jf0fBiL70+28aJXRH4=; b=Yb6DJYbbj8QmqkdhpZ1iIe98K5q2/CB0Eav944fLyNd+IbZTsaq2KKMBaSq353Pp4b jfyQFQRBVw7cD/+Q+XePJQa4BvgmwSwJ2R7YnSZgLSJdGrVNL44xQftIrsfPMSER5kkk 1GDWOt9Sna89BPdZxr/PmJLkdg7y44f5FrlUE= MIME-Version: 1.0 Received: by 10.180.96.8 with SMTP id do8mr12166271wib.21.1329707187122; Sun, 19 Feb 2012 19:06:27 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Sun, 19 Feb 2012 19:06:27 -0800 (PST) In-Reply-To: <4F41B789.7050705@freebsd.org> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120217135320.GJ55075@FreeBSD.org> <4F41B789.7050705@freebsd.org> Date: Sun, 19 Feb 2012 19:06:27 -0800 X-Google-Sender-Auth: PKhUEQ_Y8gz9aASE1TulZerWS3o Message-ID: From: Adrian Chadd To: Julian Elischer Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org, Marcel Moolenaar Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 03:06:28 -0000 2012/2/19 Julian Elischer : >> For example: you can introduce a define that either old or >> new drivers use to indicate whether they need full visibility >> or whether an abstract type works. This then drives what is >> defined/declared and how it's defined/declared. >> > The trouble is that core debugging is not doable via methods > > i.e. > =A0 netstat -i | -I interface [-abdhntW] [-f address_family] [-M core] > =A0 =A0 =A0 =A0 =A0 =A0 [-N system] > > becomes much more difficult to achieve. Why? For the default kernel they'd just evaluate to whatever they are right now. There's room for doing extra debugging and logging in the accessor methods, but the accessor methods are still accessing the same underlying structures. You could still inspect the direct data and keep those structures the "FreeBSD Kernel ABI" so tools like netstat can still directly fondle them. This is just for portability and modularity. If a vendor like Juniper wants to override that stuff, let's let them? :) Adrian From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 03:12:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EDFD1065672 for ; Mon, 20 Feb 2012 03:12:58 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id D43C18FC0A for ; Mon, 20 Feb 2012 03:12:57 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1K3CtJA050824 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sun, 19 Feb 2012 19:12:56 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F41BA96.8050707@freebsd.org> Date: Sun, 19 Feb 2012 19:14:30 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: Raymond Wagner References: <4F3F4810.6070501@rewt.org.uk> <4F3F6D95.1000605@wagnerrp.com> In-Reply-To: <4F3F6D95.1000605@wagnerrp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: Panic after vnet/jail destroy X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 03:12:58 -0000 On 2/18/12 1:21 AM, Raymond Wagner wrote: > On 2/18/2012 01:41, Joe Holden wrote: >> jail_relay_exec_poststop0="ifconfig bridge0 deletem epair0a" >> jail_relay_exec_poststop1="ifconfig epair0a destroy" >> jail_relay_exec_poststop2="ifconfig bridge1 deletem epair1a" >> jail_relay_exec_poststop3="ifconfig epair1a destroy" > > The kernel panics when you try to destroy an epair. This is a known > issue, and not a new issue. I've see the same problem at least as > far back as 8.1. The current work around is to simply not destroy > them when you bring down your jails. Of course this does mean you > will build up a collection of unused epairs. or use ng_iface plus ng_bridge instead. > _______________________________________________ > 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 Feb 20 06:39:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09F02106564A for ; Mon, 20 Feb 2012 06:39:15 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 894EF8FC12 for ; Mon, 20 Feb 2012 06:39:14 +0000 (UTC) Received: by wgbgn7 with SMTP id gn7so2846613wgb.1 for ; Sun, 19 Feb 2012 22:39:13 -0800 (PST) Received-SPF: pass (google.com: domain of kob6558@gmail.com designates 10.180.92.229 as permitted sender) client-ip=10.180.92.229; Authentication-Results: mr.google.com; spf=pass (google.com: domain of kob6558@gmail.com designates 10.180.92.229 as permitted sender) smtp.mail=kob6558@gmail.com; dkim=pass header.i=kob6558@gmail.com Received: from mr.google.com ([10.180.92.229]) by 10.180.92.229 with SMTP id cp5mr14316550wib.8.1329719953545 (num_hops = 1); Sun, 19 Feb 2012 22:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=gS99DinDNuj7xeGGpekCbiiY0hah3oo5usWt1/hoWsw=; b=Rcp5wKPfGOcX2XIxuzmSyXsq++aUnNM62rnR1dXvqTXh/iJwdS8I5zinjD6yucmtbX Tw53CBTniTyKkzjAqBqASblPOxeuwa7uJmAKwWU3MTqH/m6rVsPzv/g2BJigX3LlyyPg M0+CHoyb0PwG74SkQzpDtK9qrLKR9A6MseiqU= MIME-Version: 1.0 Received: by 10.180.92.229 with SMTP id cp5mr11946944wib.8.1329719953503; Sun, 19 Feb 2012 22:39:13 -0800 (PST) Received: by 10.223.158.143 with HTTP; Sun, 19 Feb 2012 22:39:13 -0800 (PST) In-Reply-To: <47346273.20120219153713@yandex.ru> References: <47346273.20120219153713@yandex.ru> Date: Sun, 19 Feb 2012 22:39:13 -0800 Message-ID: From: Kevin Oberman To: =?KOI8-R?B?68/O2MvP1yDl18fFzsnK?= Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: freebsd sends arp queries for IP's in not it subnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 06:39:15 -0000 2012/2/19 =EB=CF=CE=D8=CB=CF=D7 =E5=D7=C7=C5=CE=C9=CA : > # tcpdump -n -i vlan7 > tcpdump: verbose output suppressed, use -v or -vv for full protocol decod= e > listening on vlan7, link-type EN10MB (Ethernet), capture size 65535 bytes > 15:37:59.202052 ARP, Request who-has 10.12.101.240 tell 10.11.19.147, len= gth 28 > 15:37:59.258459 ARP, Request who-has 10.83.29.192 tell 10.11.19.147, leng= th 28 [...] > ^C > 45 packets captured > 47 packets received by filter > 0 packets dropped by kernel > # ifconfig vlan7 > vlan7: flags=3D8843 metric 0 mtu = 1500 > =9A =9A =9A =9Aoptions=3D3 > =9A =9A =9A =9Aether f4:6d:04:7c:7b:d3 > =9A =9A =9A =9Ainet 10.11.19.149 netmask 0xfffffff8 broadcast 10.11.19.15= 1 > =9A =9A =9A =9Ainet6 fe80::f66d:4ff:fe7c:7bd3%vlan7 prefixlen 64 scopeid = 0x7 > =9A =9A =9A =9Ainet 10.11.19.145 netmask 0xfffffff8 broadcast 10.11.19.15= 1 > =9A =9A =9A =9Ainet 10.11.19.147 netmask 0xfffffff8 broadcast 10.11.19.15= 1 > =9A =9A =9A =9And6 options=3D29 > =9A =9A =9A =9Amedia: Ethernet autoselect (1000baseT ) > =9A =9A =9A =9Astatus: active > =9A =9A =9A =9Avlan: 7 parent interface: re0 Looks suspicious, but what is the output of 'netstat -rnf inet'? That will say what addresses are in a range that is routed or one that is reached directly using ARP to get the MAC address. --=20 R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 06:56:53 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A702F1065670 for ; Mon, 20 Feb 2012 06:56:53 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6EDCD8FC0C for ; Mon, 20 Feb 2012 06:56:53 +0000 (UTC) Received: by daec6 with SMTP id c6so6133787dae.13 for ; Sun, 19 Feb 2012 22:56:53 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.220.166 as permitted sender) client-ip=10.68.220.166; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.220.166 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.220.166]) by 10.68.220.166 with SMTP id px6mr18607331pbc.103.1329721013085 (num_hops = 1); Sun, 19 Feb 2012 22:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=Rc77t5n+HHeMqzd2rGUJPiP0wVYkoEwd9K/ngGl3raQ=; b=BSSO12kk9jDUEl1sqKDPIJczUF5O4qooNp+pDRZbJHZ8L4L3WLp+03jWqt4zL1MMj+ mC5peo+QUYQYYmqTLpp8hM5rn8cbqiSNTb+9tQ2HSJ2eTp6QN1gdp0KjZQs1SGNchqKw cz31SiZgUqGq336Pmjfn0Ch/FeZbF8+bCYTJQ= Received: by 10.68.220.166 with SMTP id px6mr15965194pbc.103.1329721013049; Sun, 19 Feb 2012 22:56:53 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id a1sm12452134pbj.72.2012.02.19.22.56.49 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 19 Feb 2012 22:56:51 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 20 Feb 2012 15:56:48 -0800 From: YongHyeon PYUN Date: Mon, 20 Feb 2012 15:56:48 -0800 To: Kim Culhan Message-ID: <20120220235648.GA3537@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: msk0: watchdog timeout interface hang X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 06:56:53 -0000 On Thu, Jan 26, 2012 at 05:46:23AM -0500, Kim Culhan wrote: > On Wed, Jan 25, 2012 at 3:26 PM, Kim Culhan wrote: > > Running 10-curent from 01-20-12 > > the msk0 interface hung, on the console: > > > > msk0: watchdog timeout > > msk0: prefetch unit stuck? > > msk0: initialization failed: no memory for Rx buffers > > > > Verbose boot dmesg output attached. > > This additional datapoint found, at boot after the last line in the > verbose dmesg > this line was logged to messages: > > Jan 25 15:21:19 foo kernel: interrupt storm detected on "irq257:"; > throttling interrupt source How about disabling MSI?(hw.msk.msi_disable loader tunable) > > Hope this helps. > > thanks > -kiim From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 07:56:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B83E31065672 for ; Mon, 20 Feb 2012 07:56:59 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 4180A8FC13 for ; Mon, 20 Feb 2012 07:56:58 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so4320202wib.13 for ; Sun, 19 Feb 2012 23:56:58 -0800 (PST) Received-SPF: pass (google.com: domain of adrian.chadd@gmail.com designates 10.216.82.201 as permitted sender) client-ip=10.216.82.201; Authentication-Results: mr.google.com; spf=pass (google.com: domain of adrian.chadd@gmail.com designates 10.216.82.201 as permitted sender) smtp.mail=adrian.chadd@gmail.com; dkim=pass header.i=adrian.chadd@gmail.com Received: from mr.google.com ([10.216.82.201]) by 10.216.82.201 with SMTP id o51mr3884595wee.6.1329724618147 (num_hops = 1); Sun, 19 Feb 2012 23:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=aBwG3BOuhrOaFlHSkX9x8b2QKC3Cgy3ABiZJkm59goI=; b=M0pqTx8gPu84BW8PpoK4ARkcmUttBf2gyUddAjpFd/b23Kp6OwEACTTQwVi4+9YSE+ meYulosD10WlQzFDO87r67/4UKRrgwlua/8WBhaX1PWVTCJbUxBKfRhbZsd+Em2Wk3Jq pMiNbKGL/mmalE0guoBIJOkmKM2N0/UpTEloo= MIME-Version: 1.0 Received: by 10.216.82.201 with SMTP id o51mr3236789wee.6.1329724618085; Sun, 19 Feb 2012 23:56:58 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Sun, 19 Feb 2012 23:56:58 -0800 (PST) In-Reply-To: References: Date: Sun, 19 Feb 2012 23:56:58 -0800 X-Google-Sender-Auth: fovt4KMpxx_wOKd9nh83nalBE5Y Message-ID: From: Adrian Chadd To: Adam Twardowski Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Random wireless crash / kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 07:56:59 -0000 Hi, Do you still have the kernel? On 19 February 2012 18:23, Adam Twardowski wrot= e: > Hello, I submitted a bug report the other day regarding a kernel panic > related to the urtw driver. =A0If anyone needs any additional > infromation, please let me know. It looks like there's no node associated with that particular TX. Change: if (m->m_flags & M_TXCB) { to if ((m->m_flags & M_TXCB) && (data->ni !=3D NULL)) { .. that may fix the crash but it doesn't explain how an mbuf marked M_TXCB has no node.. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 11:07:11 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A2A09106566B for ; Mon, 20 Feb 2012 11:07:11 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9000B8FC14 for ; Mon, 20 Feb 2012 11:07:11 +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 q1KB7BLi090194 for ; Mon, 20 Feb 2012 11:07:11 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1KB7AOb090192 for freebsd-net@FreeBSD.org; Mon, 20 Feb 2012 11:07:10 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 20 Feb 2012 11:07:10 GMT Message-Id: <201202201107.q1KB7AOb090192@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 11:07:11 -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/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/165032 net [mii] [patch] brgphy(4) is not used for BCM57780 o kern/164901 net [regression] [patch] [lagg] igb/lagg poor traffic dist o kern/164569 net [msk] [hang] msk network driver cause freeze in FreeBS 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/164400 net [ipsec] immediate crash after the start of ipsec proce 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/162509 net [re] [panic] Kernel panic may be related to if_re.c (r o kern/162352 net [patch] Enhancement: add SO_PROTO to socket.h 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/161381 net [re] RTL8169SC - re0: PHY write failed 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/160420 net [msk] phy write timeout on HP 5310m 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/159795 net [tcp] excessive duplicate ACKs and TCP session freezes 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/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/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 o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/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 o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o 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 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 o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 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/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 kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/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 s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 391 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 17:03:46 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 39E8D106566B for ; Mon, 20 Feb 2012 17:03:46 +0000 (UTC) (envelope-from adam.twardowski@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02D3A8FC0A for ; Mon, 20 Feb 2012 17:03:45 +0000 (UTC) Received: by iaeo4 with SMTP id o4so10395893iae.13 for ; Mon, 20 Feb 2012 09:03:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=mVVhglIHCPcuESE0svAdpf+Xy4ZyrYlr3HTxCd9WILI=; b=k1Ja2nQDBTjnm0HGZvRuTfhDb/KCFoBIsR1Krek5vx8UszrckjztWdObP/QRXCnwld CnvA0or9aJUwY31LeqTbJr0dUYwUjyfeRlNRPidgB2Yfekpz6JKdii/xueFMp0SfTBBd aYc2sYmgGvynm3pdb3pp8q+DyRcq8Lzo+zVK4= MIME-Version: 1.0 Received: by 10.50.193.195 with SMTP id hq3mr11531581igc.18.1329757425309; Mon, 20 Feb 2012 09:03:45 -0800 (PST) Received: by 10.231.101.3 with HTTP; Mon, 20 Feb 2012 09:03:45 -0800 (PST) Received: by 10.231.101.3 with HTTP; Mon, 20 Feb 2012 09:03:45 -0800 (PST) In-Reply-To: References: Date: Mon, 20 Feb 2012 12:03:45 -0500 Message-ID: From: Adam Twardowski To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: [urtw] Random wireless crash / kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 17:03:46 -0000 I do still have the kernel and the crash dump. I'll try that fix tonight to see how it goes. Unfortunately, the kernel doesn't usually crash, more likely the wifi stops working and I am forced to reboot the machine to get it working again. On Feb 20, 2012 2:56 AM, "Adrian Chadd" wrote: > > Hi, > > Do you still have the kernel? > > > On 19 February 2012 18:23, Adam Twardowski wrote: > > Hello, I submitted a bug report the other day regarding a kernel panic > > related to the urtw driver. If anyone needs any additional > > infromation, please let me know. > > It looks like there's no node associated with that particular TX. > > Change: > > if (m->m_flags & M_TXCB) { > > > to > > if ((m->m_flags & M_TXCB) && (data->ni != NULL)) { > > .. that may fix the crash but it doesn't explain how an mbuf marked > M_TXCB has no node.. > > > > Adrian From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 18:02:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AFEB106564A for ; Mon, 20 Feb 2012 18:02:24 +0000 (UTC) (envelope-from bschmidt@techwires.net) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8AE928FC0A for ; Mon, 20 Feb 2012 18:02:23 +0000 (UTC) Received: by eaan10 with SMTP id n10so2527296eaa.13 for ; Mon, 20 Feb 2012 10:02:22 -0800 (PST) Received-SPF: pass (google.com: domain of bschmidt@techwires.net designates 10.14.95.135 as permitted sender) client-ip=10.14.95.135; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bschmidt@techwires.net designates 10.14.95.135 as permitted sender) smtp.mail=bschmidt@techwires.net Received: from mr.google.com ([10.14.95.135]) by 10.14.95.135 with SMTP id p7mr11032716eef.62.1329760942531 (num_hops = 1); Mon, 20 Feb 2012 10:02:22 -0800 (PST) Received: by 10.14.95.135 with SMTP id p7mr8750153eef.62.1329759119181; Mon, 20 Feb 2012 09:31:59 -0800 (PST) Received: from amy.lab.techwires.net (dslb-088-067-223-031.pools.arcor-ip.net. [88.67.223.31]) by mx.google.com with ESMTPS id w60sm79771547eeb.4.2012.02.20.09.31.57 (version=SSLv3 cipher=OTHER); Mon, 20 Feb 2012 09:31:58 -0800 (PST) Sender: Bernhard Schmidt From: Bernhard Schmidt To: freebsd-net@freebsd.org Date: Mon, 20 Feb 2012 18:32:11 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201202201832.11604.bschmidt@freebsd.org> X-Gm-Message-State: ALoCoQlmnYedZshULkZqLWVamLMPCg1lrw8rLFwlcdzvvD1GCj3Ys1vj1uKpMWoYDjBoc0UJAfnE Cc: Adam Twardowski , Adrian Chadd Subject: Re: [urtw] Random wireless crash / kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 18:02:24 -0000 On Monday 20 February 2012 18:03:45 Adam Twardowski wrote: > I do still have the kernel and the crash dump. I'll try that fix tonight > to see how it goes. Unfortunately, the kernel doesn't usually crash, more > likely the wifi stops working and I am forced to reboot the machine to get > it working again. Building urtw(4) as module here helps a lot, kldunload/kldload is just so much faster than a reboot. :) I have a bunch of asorted fixes [1] for urtw(4) which needs some further testing, though I still wasn't able to fix the issue which made me look into this in the first place.. As a test case I force a disconnection from the AP side a few times, which will eventually result in a device timeout and the requirement to reload the module. I believe that one of those might actually address the panic you're seeing, though, it doesn't fix the device timeout. [1] http://techwires.net/~bschmidt/urtw/ -- Bernhard From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 23:42:54 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F9C31065672 for ; Mon, 20 Feb 2012 23:42:54 +0000 (UTC) (envelope-from brooks@lor.one-eyed-alien.net) Received: from lor.one-eyed-alien.net (lor.one-eyed-alien.net [69.66.77.232]) by mx1.freebsd.org (Postfix) with ESMTP id A81248FC0A for ; Mon, 20 Feb 2012 23:42:52 +0000 (UTC) Received: from lor.one-eyed-alien.net (localhost [127.0.0.1]) by lor.one-eyed-alien.net (8.14.4/8.14.4) with ESMTP id q1KNG27f052133; Mon, 20 Feb 2012 17:16:02 -0600 (CST) (envelope-from brooks@lor.one-eyed-alien.net) Received: (from brooks@localhost) by lor.one-eyed-alien.net (8.14.4/8.14.4/Submit) id q1KNG2he052132; Mon, 20 Feb 2012 17:16:02 -0600 (CST) (envelope-from brooks) Date: Mon, 20 Feb 2012 17:16:02 -0600 From: Brooks Davis To: Marcel Moolenaar Message-ID: <20120220231601.GA51310@lor.one-eyed-alien.net> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:42:54 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2012 at 08:16:22PM -0800, Marcel Moolenaar wrote: > All, >=20 > Juniper is in the final phases of creating a clean separation > between FreeBSD and Junos, so as to make upgrades of FreeBSD > easier. This also allows Juniper to track -current and be more > active FreeBSD contributors. >=20 > To that end, we have a short-term and hopefully short-lived > problem to solve, which is the ability to use FreeBSD's network > drivers against the Junos network stack. As some may know, the > Junos network stack has split up struct ifnet into a physical > and logical component, called ifdev and iflogical. >=20 > We've tried a few approaches to bridge the gap between ifnet > on the one hand and ifdev and iflogical on the other and found > that abstracting ifnet and using accessor functions is the > best way to allow us to use FreeBSD drivers with the Junos > network stack, while retaining the ability to use them with > the FreeBSD stack. >=20 > FreeBSD is also looking at breaking up ifnet and with that in > mind, I was wondering if there would be any resistance to > changing network drivers to use accessor functions or macros > instead of direct pointer dereferences? >=20 > For example, do something like: >=20 > Index: if_fxp.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- if_fxp.c (revision 231178) > +++ if_fxp.c (working copy) > @@ -823,13 +823,14 @@ > } > =20 > if_initname(ifp, device_get_name(dev), device_get_unit(dev)); > - ifp->if_init =3D fxp_init; > - ifp->if_softc =3D sc; > - ifp->if_flags =3D IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; > - ifp->if_ioctl =3D fxp_ioctl; > - ifp->if_start =3D fxp_start; > + if_set_init(ifp, fxp_init); > + if_set_softc(ifp, sc); > + if_set_flags(ifp, IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST, 0); > + if_set_ioctl(ifp, fxp_ioctl); > + if_set_start(ifp, fxp_start); > =20 > - ifp->if_capabilities =3D ifp->if_capenable =3D 0; > + if_set_capabilities(ifp, 0); > + if_set_capenable(ifp, 0); > =20 > /* Enable checksum offload/TSO for 82550 or better chips */ > if (sc->flags & FXP_FLAG_EXT_RFA) { >=20 > Such a scheme, while initially touching a lot of driver, > would make it easier to break up ifnet *and* also make it > easier to hide ABI/API changes from driver vendors (esp. > when the accessor functions are non-inlined functions and > not macros or inlines). This is particularly useful for > Juniper, where we have worked towards network stacks as > (pre-)loadable modules so as to help with migration and > validation. >=20 > Thoughts, feedback and suggestion are welcome, The concept seems fine to me and I like that it might simplify future API changes. Have you verified that if_get_*() accessors don't add significant overhead? I agree with the concern raised by Luigi about intra-branch compatability. My prefered solution to that would be to MFC the adition of the accessors pretty much instantly and to commit the changes to individual drivers seperately to allow them to be merged as needed by driver maintainers. -- Brooks --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iD8DBQFPQtQxXY6L6fI4GtQRAj8IAKDocTqq2HlozpiWThJ6VLrKIOtm4gCgh8K7 JgppnExMIp6BUvNb7fEohxQ= =2t9B -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 20 23:57:52 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 14C51106566B for ; Mon, 20 Feb 2012 23:57:52 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id C45B58FC08 for ; Mon, 20 Feb 2012 23:57:51 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 27F1A7300A; Tue, 21 Feb 2012 01:15:52 +0100 (CET) Date: Tue, 21 Feb 2012 01:15:52 +0100 From: Luigi Rizzo To: Brooks Davis Message-ID: <20120221001552.GA60050@onelab2.iet.unipi.it> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120220231601.GA51310@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i Cc: net@freebsd.org, Marcel Moolenaar Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 23:57:52 -0000 On Mon, Feb 20, 2012 at 05:16:02PM -0600, Brooks Davis wrote: > > The concept seems fine to me and I like that it might simplify future > API changes. Have you verified that if_get_*() accessors don't add > significant overhead? the vast majority of these fields are only accessed in the control path, not on each packet, so there isn't really a performance issue. Besides they can be trivially implemted as macros or inline functions. cheers luigi From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 00:37:31 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 442C7106564A for ; Tue, 21 Feb 2012 00:37:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9EF5D8FC14 for ; Tue, 21 Feb 2012 00:37:30 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5093329wib.13 for ; Mon, 20 Feb 2012 16:37:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lGF5jhgq09csE/w+duUrt5H8o1YCYGV8LaOC3wtchzA=; b=Hzvngo5SEZkcHgYHWL/aLybkfdm57tUuCP2tdDBzy5sIAQ69tF9MsZ8OwbiQoTDCXn hZ7qQAjVDc9/73AUFA2mPOQcV8mooa4+wS05X4S+waQjMbm+8WViujAr5SV/di8S2/mM y3Vld99SVb0xSD15KMzEytutzBiBLQ3uKiouo= MIME-Version: 1.0 Received: by 10.180.93.4 with SMTP id cq4mr17494073wib.21.1329784649530; Mon, 20 Feb 2012 16:37:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Mon, 20 Feb 2012 16:37:29 -0800 (PST) In-Reply-To: <20120221001552.GA60050@onelab2.iet.unipi.it> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> Date: Mon, 20 Feb 2012 16:37:29 -0800 X-Google-Sender-Auth: v9ALCp0XMRFZTgusvIdSqWNQa0c Message-ID: From: Adrian Chadd To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Marcel Moolenaar , Brooks Davis , net@freebsd.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 00:37:31 -0000 On 20 February 2012 16:15, Luigi Rizzo wrote: >> The concept seems fine to me and I like that it might simplify future >> API changes. =A0Have you verified that if_get_*() accessors don't add >> significant overhead? > > the vast majority of these fields are only accessed in the control path, > not on each packet, so there isn't really a performance issue. Besides > they can be trivially implemted as macros or inline functions. I doubt Juniper need _binary_ level compatibility. So we could get away with inline methods. This sort of thing just makes source level compatibility a lot easier. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 02:34:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6ACE6106566C; Tue, 21 Feb 2012 02:34:37 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9A2A98FC08; Tue, 21 Feb 2012 02:34:36 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so5149840wib.13 for ; Mon, 20 Feb 2012 18:34:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=78TlP/oOPs+Ka0eiGptwP/Ifoy2UpEHva9/lZJY3Sz8=; b=AREBx+mvrd3CqSkilsvCQV0QkASg5TS3YIgwVkbwxBOdB6qL5eX+nInpDOjJFStuOS JIiZ8EXnvezOlI9D3x2otPYhjUKC4zLRdX2ctEX2vmV2AMgiAOldgx5dgcCQnMOlKk14 RNpsv3hTlHwuKddwCi4dDA+NzpFLrNUwmVpNI= MIME-Version: 1.0 Received: by 10.180.95.1 with SMTP id dg1mr18009870wib.21.1329791675696; Mon, 20 Feb 2012 18:34:35 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.154.199 with HTTP; Mon, 20 Feb 2012 18:34:35 -0800 (PST) In-Reply-To: References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> Date: Mon, 20 Feb 2012 18:34:35 -0800 X-Google-Sender-Auth: U21Xb_dQEXHgsXmzVgkDb8Zspdc Message-ID: From: Adrian Chadd To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org, Brooks Davis , Luigi Rizzo , Marcel Moolenaar Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:34:37 -0000 On 20 February 2012 18:21, Juli Mallett wrote: > > It's not just about Juniper, though, it's about us, and how much this > buys us. =A0Using inlines buys us some source compatibility and the > ability to add some invariants, but is no different to macros in terms > of KBI within a version of FreeBSD, or between versions. =A0We can't > make ifnet opaque with inlines. =A0Adding a member to ifnet which is > opaque[*] and which has the fields most likely to change in size, > order, existence, etc., and leaving a few that are needed in the fast > path and will be used by macros/inlines is probably where we should > end up. > > *: Obviously ifnet should be a value member of the opaque type, and > the ifnet should include a pointer to the opaque type, or something > like that, since you can't make an opaque struct a value member, which > is probably obvious, but I wanted to be clearish. Is the target though _binary_ compatibility? Just having a blessed method of doing accessor method things will buy more source flexibility. The KBI can stay the same in the default case and IMHO this kind of thing gives developers more power to do smart invariant and debugging things. Being able to say "inform me every time an interface flag changes" would actually be kind of nice when debugging some of the issues i've been facing with ath. I've been half tempted to do this -inside- the ath driver, partially to restore the OS portability it once tried to achieve. Adrian From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 02:42:37 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 374D9106566B; Tue, 21 Feb 2012 02:42:37 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 60C588FC08; Tue, 21 Feb 2012 02:42:35 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so5112957wgb.31 for ; Mon, 20 Feb 2012 18:42:35 -0800 (PST) Received: by 10.180.101.200 with SMTP id fi8mr17989688wib.20.1329792155213; Mon, 20 Feb 2012 18:42:35 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Mon, 20 Feb 2012 18:42:15 -0800 (PST) In-Reply-To: References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> From: Juli Mallett Date: Mon, 20 Feb 2012 18:42:15 -0800 X-Google-Sender-Auth: WEo7rScUTeawExAudPSs_NMW-sw Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkJ5J82eUrB0nl6tjmsz1Gp4oC3U6ZDwkf8r8/YToIIPfwR3IDyayGJIt9p0dztUWA0HABO Cc: net@freebsd.org, Brooks Davis , Luigi Rizzo , Marcel Moolenaar Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:42:37 -0000 On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: > Is the target though _binary_ compatibility? Just having a blessed > method of doing accessor method things will buy more source > flexibility. The KBI can stay the same in the default case and IMHO > this kind of thing gives developers more power to do smart invariant > and debugging things. KBI compatibility requires very little discipline and makes loadable modules for network drivers much less hellish. Inlines, macros and full visibility of ifnet in -current may be useful, but unless there's a performance reason for doing so, retaining KBI compatibility *and* the ability to merge ifnet changes to -stable sounds pretty nice to me. > Being able to say "inform me every time an interface flag changes" > would actually be kind of nice when debugging some of the issues i've > been facing with ath. I've been half tempted to do this -inside- the > ath driver, partially to restore the OS portability it once tried to > achieve. I think that it is rare that this is useful in debugging, and something of a red herring. Even invariants are almost a red herring: really, we shouldn't be using these individual methods to tweak structure fields, either, we should have a way of describing a network driver more semantically, such that the invariants are richer and also not as complicated, and also more comprehensive. Source compatibility is the biggest win, but a little self-discipline to win what measure of binary compatibility we can seems perfectly sensible. (And at some point, we could even replace ifnet with something that's less of a strange grab bag assortment that's awkward to explain to new driver writers, and keep both source and binary compatibility for a reasonable period in doing so. Unlikely to happen in the near term, but wouldn't it be nice? From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 02:45:54 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F610106566B; Tue, 21 Feb 2012 02:45:54 +0000 (UTC) (envelope-from adam.twardowski@gmail.com) Received: from mail-iy0-f182.google.com (mail-iy0-f182.google.com [209.85.210.182]) by mx1.freebsd.org (Postfix) with ESMTP id 09BC98FC13; Tue, 21 Feb 2012 02:45:53 +0000 (UTC) Received: by iaeo4 with SMTP id o4so11165357iae.13 for ; Mon, 20 Feb 2012 18:45:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=W7chaDPZb9p3B5BML093frIdf64MP7JNj9E8zvTSwrg=; b=hfgbFSEVtr2nFBqoxWsndwv5E69dIgtJrUP8BwyXyjLpaD6YjwItkJeTUxpkhcU6M3 SZzXnH9lvqYznUg41zo5I3eOyeKbHeYnNZTb5Fie+afH9vHaoVcrjYO2Ctck2mNVlQaf 3nZa2/PpdZhv19RhwfiyNpuXaMmCMFo2tZhZ8= MIME-Version: 1.0 Received: by 10.50.6.138 with SMTP id b10mr13601407iga.21.1329792353515; Mon, 20 Feb 2012 18:45:53 -0800 (PST) Received: by 10.231.45.202 with HTTP; Mon, 20 Feb 2012 18:45:53 -0800 (PST) In-Reply-To: <201202201832.11604.bschmidt@freebsd.org> References: <201202201832.11604.bschmidt@freebsd.org> Date: Mon, 20 Feb 2012 21:45:53 -0500 Message-ID: From: Adam Twardowski To: Bernhard Schmidt Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, Adrian Chadd Subject: Re: [urtw] Random wireless crash / kernel panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:45:54 -0000 On Mon, Feb 20, 2012 at 12:32 PM, Bernhard Schmidt w= rote: > On Monday 20 February 2012 18:03:45 Adam Twardowski wrote: >> I do still have the kernel and the crash dump. =A0I'll try that fix toni= ght >> to see how it goes. =A0Unfortunately, the kernel doesn't usually crash, = more >> likely the wifi stops working and I am forced to reboot the machine to g= et >> it working again. > > Building urtw(4) as module here helps a lot, kldunload/kldload is just so= much faster than a reboot. :) > > I have a bunch of asorted fixes [1] for urtw(4) which needs some further = testing, though I still wasn't able to fix the issue which made me look int= o this in the first place.. As a test case I force a disconnection from the= AP side a few times, which will eventually result in a device timeout and = the requirement to reload the module. I believe that one of those might act= ually address the panic you're seeing, though, it doesn't fix the device ti= meout. > > [1] http://techwires.net/~bschmidt/urtw/ > > -- > Bernhard Bernhard, I just applied your four patches and rebooted. I also went with a module like you suggested. We will see how it goes. I did not apply Adrians change above, not sure if it was necessary. From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 02:47:51 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51C11106564A for ; Tue, 21 Feb 2012 02:47:51 +0000 (UTC) (envelope-from juli@clockworksquid.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 D055C8FC19 for ; Tue, 21 Feb 2012 02:47:50 +0000 (UTC) Received: by werm13 with SMTP id m13so5666033wer.13 for ; Mon, 20 Feb 2012 18:47:49 -0800 (PST) Received-SPF: pass (google.com: domain of juli@clockworksquid.com designates 10.180.78.233 as permitted sender) client-ip=10.180.78.233; Authentication-Results: mr.google.com; spf=pass (google.com: domain of juli@clockworksquid.com designates 10.180.78.233 as permitted sender) smtp.mail=juli@clockworksquid.com Received: from mr.google.com ([10.180.78.233]) by 10.180.78.233 with SMTP id e9mr22911225wix.0.1329792469913 (num_hops = 1); Mon, 20 Feb 2012 18:47:49 -0800 (PST) Received: by 10.180.78.233 with SMTP id e9mr19087113wix.0.1329790914229; Mon, 20 Feb 2012 18:21:54 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Mon, 20 Feb 2012 18:21:34 -0800 (PST) In-Reply-To: References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> From: Juli Mallett Date: Mon, 20 Feb 2012 18:21:34 -0800 X-Google-Sender-Auth: mNG9R8rR4X28RuTfz6wCFlFHbKE Message-ID: To: Adrian Chadd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkvLR71bGXixVhB/2M4ZzjzTl7JCF27rd4sjV6gE66MJcJJ3jHzr3e/IBTqVLpZP8FyOta3 Cc: net@freebsd.org, Brooks Davis , Luigi Rizzo , Marcel Moolenaar Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 02:47:51 -0000 On Mon, Feb 20, 2012 at 16:37, Adrian Chadd wrote: > On 20 February 2012 16:15, Luigi Rizzo wrote: > >>> The concept seems fine to me and I like that it might simplify future >>> API changes. =C2=A0Have you verified that if_get_*() accessors don't ad= d >>> significant overhead? >> >> the vast majority of these fields are only accessed in the control path, >> not on each packet, so there isn't really a performance issue. Besides >> they can be trivially implemted as macros or inline functions. > > I doubt Juniper need _binary_ level compatibility. So we could get > away with inline methods. > > This sort of thing just makes source level compatibility a lot easier. It's not just about Juniper, though, it's about us, and how much this buys us. Using inlines buys us some source compatibility and the ability to add some invariants, but is no different to macros in terms of KBI within a version of FreeBSD, or between versions. We can't make ifnet opaque with inlines. Adding a member to ifnet which is opaque[*] and which has the fields most likely to change in size, order, existence, etc., and leaving a few that are needed in the fast path and will be used by macros/inlines is probably where we should end up. *: Obviously ifnet should be a value member of the opaque type, and the ifnet should include a pointer to the opaque type, or something like that, since you can't make an opaque struct a value member, which is probably obvious, but I wanted to be clearish. From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 11:08:42 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id ED50C1065676 for ; Tue, 21 Feb 2012 11:08:42 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 0E18814FB9A for ; Tue, 21 Feb 2012 11:08:39 +0000 (UTC) Message-ID: <4F437B36.2090502@FreeBSD.org> Date: Tue, 21 Feb 2012 03:08:38 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F3F9075.20003@mh-sec.de> In-Reply-To: <4F3F9075.20003@mh-sec.de> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <4F3F9075.20003@mh-sec.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Fwd: [ipv6hackers] rfc5722 implementation X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:08:43 -0000 Does anyone who knows more about this topic want to comment? If we're making progress in this area it would be nice to publicize it. Doug -------- Original Message -------- Subject: [ipv6hackers] rfc5722 implementation Date: Sat, 18 Feb 2012 12:50:13 +0100 From: Marc Heuse Reply-To: IPv6 Hackers Mailing List To: IPv6 Hackers Mailing List hi folks, it seems that RFC 5722 (Handling of Overlapping IPv6 Fragments) is started to being implemented. I saw a patch for OpenBSD and it seems that Windows 7 got a silent patch for this. can anybody confirm? and are other OS affected too? greets, marc -- Marc Heuse www.mh-sec.de PGP: FEDD 5B50 C087 F8DF 5CB9 876F 7FDD E533 BF4F 891A _______________________________________________ Ipv6hackers mailing list Ipv6hackers@lists.si6networks.com http://lists.si6networks.com/listinfo/ipv6hackers From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 11:44:29 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E8E24106564A for ; Tue, 21 Feb 2012 11:44:29 +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 5576B8FC13 for ; Tue, 21 Feb 2012 11:44:29 +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 q1LBiOCn001201; Tue, 21 Feb 2012 15:44:24 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q1LBiNeq001200; Tue, 21 Feb 2012 15:44:23 +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, 21 Feb 2012 15:44:23 +0400 From: Gleb Smirnoff To: "Li, Qing" Message-ID: <20120221114423.GJ92625@FreeBSD.org> References: <1329376106.7683.YahooMailNeo@web162203.mail.bf1.yahoo.com> 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-net@freebsd.org" , "M. V." Subject: Re: Assigning multiple IPs in the same network to an interface X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 11:44:30 -0000 On Sat, Feb 18, 2012 at 05:28:22AM +0000, Li, Qing wrote: L> Yes, what you are trying to do is allowed and is supported. In fact several bugs L> were fixed to support such configuration properly. For example, see these commits: L> L> http://svnweb.freebsd.org/base?view=revision&revision=225947 L> L> http://svnweb.freebsd.org/base?view=revision&revision=225223 L> L> I vague remember fixing a bug with this exact description but I am having L> a bit difficult locating the patch. btw, the more I look into the code that does supporting this kind of configuration, the more I think that it should be redesigned. I have an idea of making a chain of 'struct rtentry' which have the same radix key. Only top member of chain is active rtentry. For a normal route, a chain consist of single struct rtentry. If we have several interfaces sharing a prefix, then we just have more members in the chain. Each 'struct ifaddr' references its rtentry, when an ifaddr is being removed, its rtentry is removed too, and in this case another rtentry can be popped to the top of chain. Meanwhile this is also going to fix a problem with installing a prefix when it is already in kernel. Currently, if I run OSPF (quagga) and receive all my local routes, and they are installed into kernel, I can't ifconfig an arbitrary interface to a prefix matching one of my local networks, since this prefix already exist in routing table. With chained rtentries, we can store both OSPF and static route and we can introduce sorting in this chain, according to route origin, or configurable by user. No code yet been written, just thoughts. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 08:19:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 106E5106566C for ; Tue, 21 Feb 2012 08:19:37 +0000 (UTC) (envelope-from saeedeh.motlagh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8A9588FC16 for ; Tue, 21 Feb 2012 08:19:36 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so6960572bkc.13 for ; Tue, 21 Feb 2012 00:19:35 -0800 (PST) Received-SPF: pass (google.com: domain of saeedeh.motlagh@gmail.com designates 10.204.143.145 as permitted sender) client-ip=10.204.143.145; Authentication-Results: mr.google.com; spf=pass (google.com: domain of saeedeh.motlagh@gmail.com designates 10.204.143.145 as permitted sender) smtp.mail=saeedeh.motlagh@gmail.com; dkim=pass header.i=saeedeh.motlagh@gmail.com Received: from mr.google.com ([10.204.143.145]) by 10.204.143.145 with SMTP id v17mr13155326bku.20.1329812375552 (num_hops = 1); Tue, 21 Feb 2012 00:19:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=eerehN9b8O9wArxcwQZzLfb6aJ+g1J/mq/94QTwguoA=; b=jNhVYkV0wA8ps9lg7YEhrNZ++Io+4zEOMrWZO1F7B3GdSqzymryXUf91C76BrmydZ6 E59yt5+jzWeHOS7M/mUMvgEwigVPn4skKQnS6/8cjoX25wZaf3zIQ1AQ/WULL/ipSh68 0zVM8NQL2bnMv/Wq2RaTSaotfDXADENMksCh0= MIME-Version: 1.0 Received: by 10.204.143.145 with SMTP id v17mr10576761bku.20.1329810843881; Mon, 20 Feb 2012 23:54:03 -0800 (PST) Received: by 10.204.201.67 with HTTP; Mon, 20 Feb 2012 23:54:03 -0800 (PST) Date: Tue, 21 Feb 2012 11:24:03 +0330 Message-ID: From: saeedeh motlagh To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Tue, 21 Feb 2012 12:30:22 +0000 Subject: must define username in radius client??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 08:19:37 -0000 hello guys, i wanna have authentication via radius server. in my local network, one system is radius server and the others are clients. the server is running well. when a client login, it sends an access-request to the server. if the user name and password are defined in the server, the server sends back the access-accept to client. if the user name is defined in the client, the login is successful but if this user name is not defined in the client, the login failed and say "login incorrect" although the client receives access-accept from the server. i wanna know if there is any way to have authentication successfully without defining any user name in the client system? yours, From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 12:58:36 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2BE11065678 for ; Tue, 21 Feb 2012 12:58:36 +0000 (UTC) (envelope-from pprocacci@datapipe.com) Received: from EXFESMQ04.datapipe-corp.net (exfesmq04.datapipe.com [64.27.120.68]) by mx1.freebsd.org (Postfix) with ESMTP id 752788FC0C for ; Tue, 21 Feb 2012 12:58:35 +0000 (UTC) Received: from nat.myhome (192.168.128.103) by EXFESMQ04.datapipe-corp.net (192.168.128.29) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 21 Feb 2012 07:58:34 -0500 Date: Tue, 21 Feb 2012 06:58:55 -0600 From: "Paul A. Procacci" To: saeedeh motlagh Message-ID: <20120221125855.GK12291@nat.myhome> References: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Originating-IP: [192.168.128.103] Content-Transfer-Encoding: quoted-printable Cc: freebsd-net Subject: Re: must define username in radius client??? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:58:36 -0000 Assuming ssh (you didn't specify), you only need to setup the shared secret= between machines. The rest is handled by pam/login as normal (ala "auth s= ufficient pam_radius.so") cat /etc/radius.conf #################################### auth 10.5.21.4:1645 "SuperSkret" 3 2 auth 10.5.21.5:1645 "SuperSkret" 3 2 ~Paul On Tue, Feb 21, 2012 at 11:24:03AM +0330, saeedeh motlagh wrote: > hello guys, > i wanna have authentication via radius server. in my local network, > one system is radius server and the others are clients. the server is > running well. when a client login, it sends an access-request to the > server. if the user name and password are defined in the server, the > server sends back the access-accept to client. if the user name is > defined in the client, the login is successful but if this user name > is not defined in the client, the login failed and say "login > incorrect" although the client receives access-accept from the server. > i wanna know if there is any way to have authentication successfully > without defining any user name in the client system? > yours, > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" ________________________________ This message may contain confidential or privileged information. If you are= not the intended recipient, please advise us immediately and delete this m= essage. See http://www.datapipe.com/legal/email_disclaimer/ for further inf= ormation on confidentiality and the risks of non-secure electronic communic= ation. If you cannot access these links, please notify us by reply message = and we will send the contents to you. From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 13:14:28 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A94DB1065679 for ; Tue, 21 Feb 2012 13:14:28 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 1F0818FC18 for ; Tue, 21 Feb 2012 13:14:27 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q1L98PSO054021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 11:08:26 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q1L98MUp057265; Tue, 21 Feb 2012 11:08:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q1L98LSn057264; Tue, 21 Feb 2012 11:08:21 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 21 Feb 2012 11:08:21 +0200 From: Konstantin Belousov To: Juli Mallett Message-ID: <20120221090821.GE55074@deviant.kiev.zoral.com.ua> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4Epv4kl9IRBfg3rk" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: Marcel Moolenaar , Adrian Chadd , Brooks Davis , Luigi Rizzo , net@freebsd.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 13:14:28 -0000 --4Epv4kl9IRBfg3rk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: > On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: > > Is the target though _binary_ compatibility? Just having a blessed > > method of doing accessor method things will buy more source > > flexibility. The KBI can stay the same in the default case and IMHO > > this kind of thing gives developers more power to do smart invariant > > and debugging things. >=20 > KBI compatibility requires very little discipline and makes loadable > modules for network drivers much less hellish. Inlines, macros and > full visibility of ifnet in -current may be useful, but unless there's > a performance reason for doing so, retaining KBI compatibility *and* > the ability to merge ifnet changes to -stable sounds pretty nice to > me. >=20 > > Being able to say "inform me every time an interface flag changes" > > would actually be kind of nice when debugging some of the issues i've > > been facing with ath. I've been half tempted to do this -inside- the > > ath driver, partially to restore the OS portability it once tried to > > achieve. >=20 > I think that it is rare that this is useful in debugging, and > something of a red herring. Even invariants are almost a red herring: > really, we shouldn't be using these individual methods to tweak > structure fields, either, we should have a way of describing a network > driver more semantically, such that the invariants are richer and also > not as complicated, and also more comprehensive. >=20 > Source compatibility is the biggest win, but a little self-discipline > to win what measure of binary compatibility we can seems perfectly > sensible. >=20 > (And at some point, we could even replace ifnet with something that's > less of a strange grab bag assortment that's awkward to explain to new > driver writers, and keep both source and binary compatibility for a > reasonable period in doing so. Unlikely to happen in the near term, > but wouldn't it be nice? You could take a look how mutexes or vm_page_locks are handled, giving inlines for kernel proper and stable KBI for modules. --4Epv4kl9IRBfg3rk Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9DXwUACgkQC3+MBN1Mb4hsFwCgr0yi86G8vk6twSzE8mOuIVNU f4AAoIYmqYiON5SYsi8i4//VuYsrEN37 =xETU -----END PGP SIGNATURE----- --4Epv4kl9IRBfg3rk-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 17:13:31 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEE09106566B; Tue, 21 Feb 2012 17:13:31 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id 79C148FC16; Tue, 21 Feb 2012 17:13:31 +0000 (UTC) Received: from sa-nc-apg-180.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q1LHDNCr028170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 Feb 2012 09:13:29 -0800 (PST) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120221090821.GE55074@deviant.kiev.zoral.com.ua> Date: Tue, 21 Feb 2012 09:13:18 -0800 Content-Transfer-Encoding: 7bit Message-Id: <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net> References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <20120221090821.GE55074@deviant.kiev.zoral.com.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1257) Cc: Juli Mallett , Adrian Chadd , Brooks Davis , Luigi Rizzo , net@freebsd.org Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 17:13:31 -0000 On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote: > On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: >> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: >>> Is the target though _binary_ compatibility? Just having a blessed >>> method of doing accessor method things will buy more source >>> flexibility. The KBI can stay the same in the default case and IMHO >>> this kind of thing gives developers more power to do smart invariant >>> and debugging things. >> >> KBI compatibility requires very little discipline and makes loadable >> modules for network drivers much less hellish. Inlines, macros and >> full visibility of ifnet in -current may be useful, but unless there's >> a performance reason for doing so, retaining KBI compatibility *and* >> the ability to merge ifnet changes to -stable sounds pretty nice to >> me. *snip* > You could take a look how mutexes or vm_page_locks are handled, > giving inlines for kernel proper and stable KBI for modules. A stable KBI is what we'll be aiming for at Juniper. We're working towards a kernel proper without any networking, the FreeBSD network stack as a module, the Juniper network stack as a module and H/W network drivers as modules. The network drivers and how they talk to the network stack is the big piece we still had to flesh out. Dynamic loading and unloading of network stack modules is not a goal, but we do want to be able to pre-load the network stack that we want to use and not have to worry about matching the H/W network drivers with the stack of choice. Inlines for the kernel proper and a stable KBI for modules seems to match everyone's objectives/concerns. We'll definitely take a look at the mutexes and vm_page_locks. FYI, -- Marcel Moolenaar marcel@xcllnt.net From owner-freebsd-net@FreeBSD.ORG Tue Feb 21 20:56:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C6F07106567D; Tue, 21 Feb 2012 20:56:02 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward16.mail.yandex.net (forward16.mail.yandex.net [IPv6:2a02:6b8:0:1402::1]) by mx1.freebsd.org (Postfix) with ESMTP id DF85A8FC1E; Tue, 21 Feb 2012 20:56:01 +0000 (UTC) Received: from smtp19.mail.yandex.net (smtp19.mail.yandex.net [95.108.252.19]) by forward16.mail.yandex.net (Yandex) with ESMTP id 19B7CD22E53; Wed, 22 Feb 2012 00:56:00 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1329857760; bh=/WtycYFbajrDWMxhQHqoyCSz8jQM3dQ6+ODHwG8BlAE=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=HvPM5Vkfi52XaeIp1nbghI2/bVxVYnQGzk77PYRaquNXz1Ce9Srs2oBAVyXf0k827 Kz9meXO59n5RB4zJgLeAeTNxccnx3JJk38U2ph6Ctu5Jxefwh7TScuAHgAWjpLixGw pGxFK9muaatmfoZilbzCKri2umT+IIsXI11XJg9Y= Received: from smtp19.mail.yandex.net (localhost [127.0.0.1]) by smtp19.mail.yandex.net (Yandex) with ESMTP id DA156BE0193; Wed, 22 Feb 2012 00:55:59 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1329857759; bh=/WtycYFbajrDWMxhQHqoyCSz8jQM3dQ6+ODHwG8BlAE=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Ep6Mp+SUVO20wtmqcEQtVp9VM+sW50IiWOm+CaUqBvOBtjRdL6G1a/QcrOhYXUAt4 jvEAuBReuJG57//XY+QKlr0xyJYqXF0AcWeCXs3LIIsPrLzg4oXXNuvlnUKlaTCBlM vMgRRHmK/j0wUmpwLmRN8wpn+9/MPXq6awTPQifg= Received: from unknown (unknown [77.93.52.20]) by smtp19.mail.yandex.net (nwsmtp/Yandex) with ESMTP id txhmDvDJ-txhWZ7qq; Wed, 22 Feb 2012 00:55:59 +0400 X-Yandex-Spam: 1 Date: Tue, 21 Feb 2012 22:55:58 +0200 From: =?koi8-r?B?68/O2MvP1yDl18fFzsnK?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?koi8-r?B?/vAg68/O2MvP1ywgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <323151470.20120221225558@yandex.ru> To: Ivan Ivanyuk In-Reply-To: References: <376001325.20120220220651@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org, freebsd-questions@freebsd.org Subject: Re[2]: deleting an alias from interface cause the static route to be deleted X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?koi8-r?B?68/O2MvP1yDl18fFzsnK?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 20:56:02 -0000 Здравствуйте, Ivan. Вы писали 21 февраля 2012 г., 0:45:33: II> 2012/2/20 Коньков Евгений : >> >> vlan74: flags=8843 metric 0 mtu 1500 >>        options=3 >>        ether f4:6d:04:7c:7b:d3 >>        inet6 fe80::f66d:4ff:fe7c:7bd3%vlan74 prefixlen 64 scopeid 0xd >>        inet 10.1.26.1 netmask 0xfffffe00 broadcast 10.1.27.255 >>        inet 10.1.26.3 netmask 0xfffffe00 broadcast 10.1.27.255 >>        nd6 options=29 >>        media: Ethernet autoselect (1000baseT ) >>        status: active >>        vlan: 74 parent interface: re0 >> >> ifconfig vlan74 delete 10.1.26.1 >> >> will delete these static routes from route table: >> >> 10.3.0.1           10.1.26.2          UGHS        8      367 vlan74 >> 10.1.6.0/23        10.1.26.2          UGS       275   166969 vlan74 >> >> Does this a bug? >> II> See here: II> http://lists.freebsd.org/pipermail/freebsd-net/2012-February/031404.html II> It should be fixed, I asked Andrew and he said it was fixed as well. II> If latest code still has this problem, than yes it's a bug. http://www.freebsd.org/cgi/query-pr.cgi?pr=128954&cat=bin it is repeatable on # uname -a FreeBSD 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #1 r231881: Fri Feb 17 17:20:09 UTC 2012 @:/usr/obj/usr/src/sys/KES_KERN_v8 amd64 # ifconfig vlan7 vlan7: flags=8002 metric 0 mtu 1500 ether 00:00:00:00:00:00 vlan: 0 parent interface: # ifconfig vlan7 vlan 7 vlandev re0 # ifconfig vlan7 vlan7: flags=8842 metric 0 mtu 1500 options=3 ether 14:da:e9:b8:5a:76 media: Ethernet autoselect (100baseTX ) status: active vlan: 7 parent interface: re0 # ifconfig vlan7 add 10.3.0.1/24 # ifconfig vlan7 add 10.3.0.2/24 # route add 10.4.0.0/24 10.3.0.3 add net 10.4.0.0: gateway 10.3.0.3 # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.6.1 UGS 0 0 re0 10.0.0.0/8 10.11.6.1 UGS 1 241 re0 10.3.0.0/24 link#7 U 0 0 vlan7 10.3.0.1 link#7 UHS 0 0 lo0 10.3.0.2 link#7 UHS 0 0 lo0 10.4.0.0/24 10.3.0.3 UGS 0 0 vlan7 10.5.0.18 link#5 UH 0 0 lo0 10.11.6.0/28 link#2 U 0 6161 re0 10.11.6.7 link#2 UHS 0 0 lo0 127.0.0.1 link#5 UH 0 53 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::%lo0/64 link#5 U lo0 fe80::1%lo0 link#5 UHS lo0 ff01::%lo0/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 -------------------------------- # ifconfig vlan7 delete 10.3.0.1 # netstat -nr Routing tables Internet: Destination Gateway Flags Refs Use Netif Expire default 10.11.6.1 UGS 0 0 re0 10.0.0.0/8 10.11.6.1 UGS 0 334 re0 10.3.0.0/24 link#7 U 0 0 vlan7 10.3.0.2 link#7 UHS 0 0 lo0 10.5.0.18 link#5 UH 0 0 lo0 10.11.6.0/28 link#2 U 0 6161 re0 10.11.6.7 link#2 UHS 0 0 lo0 127.0.0.1 link#5 UH 0 53 lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 ::1 UH lo0 ::ffff:0.0.0.0/96 ::1 UGRS lo0 fe80::%lo0/64 link#5 U lo0 fe80::1%lo0 link#5 UHS lo0 ff01::%lo0/32 fe80::1%lo0 U lo0 ff02::%lo0/32 fe80::1%lo0 U lo0 # ifconfig vlan7 vlan7: flags=8843 metric 0 mtu 1500 options=3 ether 14:da:e9:b8:5a:76 inet 10.3.0.2 netmask 0xffffff00 broadcast 10.3.0.255 media: Ethernet autoselect (100baseTX ) status: active vlan: 7 parent interface: re0 NOTICE: that '10.4.0.0/24' is still reachable through 10.3.0.3 via vlan7 but route 10.4.0.0/24 10.3.0.3 UGS 0 0 vlan7 was deleted while deleting IP from vlan -- С уважением, Коньков mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 06:08:11 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C51161065673; Wed, 22 Feb 2012 06:08:11 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 3094E8FC14; Wed, 22 Feb 2012 06:08:11 +0000 (UTC) Received: from julian-mac.elischer.org (adsl-69-105-197-40.dsl.scrm01.pacbell.net [69.105.197.40]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1M687wE062949 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 21 Feb 2012 22:08:09 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F448641.8070403@freebsd.org> Date: Tue, 21 Feb 2012 22:08:01 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Marcel Moolenaar References: <338757D1-6B1E-49CF-983F-5D5851066FD3@xcllnt.net> <20120220231601.GA51310@lor.one-eyed-alien.net> <20120221001552.GA60050@onelab2.iet.unipi.it> <20120221090821.GE55074@deviant.kiev.zoral.com.ua> <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net> In-Reply-To: <1F812CB2-152F-47AF-9952-6AEAC6D95547@xcllnt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , Brooks Davis , Juli Mallett , net@freebsd.org, Konstantin Belousov , Luigi Rizzo Subject: Re: Abstracting struct ifnet X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 06:08:11 -0000 On 2/21/12 9:13 AM, Marcel Moolenaar wrote: > On Feb 21, 2012, at 1:08 AM, Konstantin Belousov wrote: > >> On Mon, Feb 20, 2012 at 06:42:15PM -0800, Juli Mallett wrote: >>> On Mon, Feb 20, 2012 at 18:34, Adrian Chadd wrote: >>>> Is the target though _binary_ compatibility? Just having a blessed >>>> method of doing accessor method things will buy more source >>>> flexibility. The KBI can stay the same in the default case and IMHO >>>> this kind of thing gives developers more power to do smart invariant >>>> and debugging things. >>> KBI compatibility requires very little discipline and makes loadable >>> modules for network drivers much less hellish. Inlines, macros and >>> full visibility of ifnet in -current may be useful, but unless there's >>> a performance reason for doing so, retaining KBI compatibility *and* >>> the ability to merge ifnet changes to -stable sounds pretty nice to >>> me. > *snip* >> You could take a look how mutexes or vm_page_locks are handled, >> giving inlines for kernel proper and stable KBI for modules. > > A stable KBI is what we'll be aiming for at Juniper. We're working > towards a kernel proper without any networking, the FreeBSD network > stack as a module, the Juniper network stack as a module and H/W > network drivers as modules. The network drivers and how they talk > to the network stack is the big piece we still had to flesh out. > > Dynamic loading and unloading of network stack modules is not a goal, > but we do want to be able to pre-load the network stack that we want > to use and not have to worry about matching the H/W network drivers > with the stack of choice. > > Inlines for the kernel proper and a stable KBI for modules seems to > match everyone's objectives/concerns. We'll definitely take a look > at the mutexes and vm_page_locks. I've often wonderd if the vnet changes could be extended to allow not only instances of a single stack, but completely different stacks. > FYI, > From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 18:23:38 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CC801065676; Wed, 22 Feb 2012 18:23:38 +0000 (UTC) (envelope-from kickbsd@yandex.ru) Received: from forward5.mail.yandex.net (forward5.mail.yandex.net [IPv6:2a02:6b8:0:602::5]) by mx1.freebsd.org (Postfix) with ESMTP id CE8E78FC0A; Wed, 22 Feb 2012 18:23:37 +0000 (UTC) Received: from web67.yandex.ru (web67.yandex.ru [77.88.47.168]) by forward5.mail.yandex.net (Yandex) with ESMTP id 211CF1203B6D; Wed, 22 Feb 2012 22:23:36 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1329935016; bh=6tWWJkUE5CtZleq2Xu60IWXs/gARL/Hm0dOAPm+PdMk=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=H38bQR877r3vLjgJwXeX/n+IFviHgnlq+p+RbRaHqZ7pzicxYmE93K4lvas4cEZjc /s63iBiAPvEyVv8HJ2gKBycaMnKrmoJPoSeOP1usC++gdzlcsB3wxGbz5++XIly8kg +AMP5LuNhnkdldVS5aVwXFdVptsgVk4Yk+F9MoDU= Received: from localhost (localhost.localdomain [127.0.0.1]) by web67.yandex.ru (Yandex) with ESMTP id CA912105801C; Wed, 22 Feb 2012 22:23:35 +0400 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.com; s=mail; t=1329935015; bh=6tWWJkUE5CtZleq2Xu60IWXs/gARL/Hm0dOAPm+PdMk=; h=From:To:Cc:In-Reply-To:References:Subject:MIME-Version:Message-Id: Date:Content-Transfer-Encoding:Content-Type; b=fMf7MUtk+CuaxYreRnL/kSRWQP0KkSB6pPDkANBii+HhmYrrgoAGKhRnAgks93dgE ZcFe2IP/ULbHacA1cCAuF9JUugQy3z4B6Be2h3el4P2/hT2e++4Df2+JzPZs9R04R5 E0VwVi8FEf2OVFoqvyDZ+Sm2hhWbNE1QJQccs/ew= X-Yandex-Spam: 1 Received: from modemcable089.150-203-24.mc.videotron.ca (modemcable089.150-203-24.mc.videotron.ca [24.203.150.89]) by web67.yandex.ru with HTTP; Wed, 22 Feb 2012 22:23:35 +0400 From: Darren Baginski Envelope-From: kickbsd@yandex.ru To: Jack Vogel In-Reply-To: References: <167651329324260@web72.yandex.ru> MIME-Version: 1.0 Message-Id: <316881329935015@web67.yandex.ru> Date: Wed, 22 Feb 2012 22:23:35 +0400 X-Mailer: Yamail [ http://yandex.ru ] 5.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain Cc: "freebsd-net@freebsd.org" , Adrian Chadd Subject: Re: IGB freezes after about 2 weeks of uptime X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:23:38 -0000 Same problem on FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22 18:10:53 UTC 2012 root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 16.02.2012, 02:27, "Jack Vogel" : > And assuming its from the release, please upgrade it to HEAD and try again. > > Jack > > On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd wrote: >> are you running the driver from that release, or the -HEAD driver? >> >> adrian >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 18:55:16 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8915F106567B; Wed, 22 Feb 2012 18:55:16 +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 37F548FC14; Wed, 22 Feb 2012 18:55:16 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id q1MItAMr076860; Wed, 22 Feb 2012 13:55:10 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <4F453A06.9060101@sentex.net> Date: Wed, 22 Feb 2012 13:55:02 -0500 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Darren Baginski References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> In-Reply-To: <316881329935015@web67.yandex.ru> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Jack Vogel Subject: Re: IGB freezes after about 2 weeks of uptime X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 18:55:16 -0000 I dont think the driver changes from HEAD were ever MFC'd to 9.x. Only to 8.x ---Mike On 2/22/2012 1:23 PM, Darren Baginski wrote: > Same problem on > FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22 18:10:53 UTC 2012 root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC amd64 > > 16.02.2012, 02:27, "Jack Vogel" : >> And assuming its from the release, please upgrade it to HEAD and try again. >> >> Jack >> >> On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd wrote: >>> are you running the driver from that release, or the -HEAD driver? >>> >>> adrian >>> _______________________________________________ >>> 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" > > -- ------------------- 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 Feb 22 19:46:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E5F8106566C; Wed, 22 Feb 2012 19:46:30 +0000 (UTC) (envelope-from jfvogel@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 EA6738FC14; Wed, 22 Feb 2012 19:46:29 +0000 (UTC) Received: by werm13 with SMTP id m13so420520wer.13 for ; Wed, 22 Feb 2012 11:46:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0KMd9Ufq4ijrsQdQnnLttPlva866fEmLJZV8D++j6Vc=; b=LE8eZtMCgDkc9kzoYuXJBpXdRT8fUeAsJUfq64XxGwRV2FIU9g3O3pREEll5lLGUqK 2DoYZhA9qmchFgkt0ecOJisPya57EvbnW3RLdFORiNfuYTqCGNf/rwe4lI+Wp9xfbHH1 oGuBVaASsjw5qAKhRzZi3U0fT1wUefAeIpl0M= MIME-Version: 1.0 Received: by 10.180.80.226 with SMTP id u2mr36789743wix.0.1329939988909; Wed, 22 Feb 2012 11:46:28 -0800 (PST) Received: by 10.180.102.97 with HTTP; Wed, 22 Feb 2012 11:46:28 -0800 (PST) In-Reply-To: <4F453A06.9060101@sentex.net> References: <167651329324260@web72.yandex.ru> <316881329935015@web67.yandex.ru> <4F453A06.9060101@sentex.net> Date: Wed, 22 Feb 2012 11:46:28 -0800 Message-ID: From: Jack Vogel To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: "freebsd-net@freebsd.org" , Adrian Chadd , Darren Baginski Subject: Re: IGB freezes after about 2 weeks of uptime X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:46:30 -0000 Mike is correct, 8.3 was looming, it is important to a lot of my customers so it has taken priority, 9 stable will be coming... Jack On Wed, Feb 22, 2012 at 10:55 AM, Mike Tancsa wrote: > I dont think the driver changes from HEAD were ever MFC'd to 9.x. Only > to 8.x > > ---Mike > > On 2/22/2012 1:23 PM, Darren Baginski wrote: > > Same problem on > > FreeBSD srv-4-2.lab.local 9.0-STABLE FreeBSD 9.0-STABLE #2: Wed Feb 22 > 18:10:53 UTC 2012 root@srv-4-2.lab.local:/usr/obj/usr/src/sys/GENERIC > amd64 > > > > 16.02.2012, 02:27, "Jack Vogel" : > >> And assuming its from the release, please upgrade it to HEAD and try > again. > >> > >> Jack > >> > >> On Wed, Feb 15, 2012 at 2:14 PM, Adrian Chadd > wrote: > >>> are you running the driver from that release, or the -HEAD driver? > >>> > >>> adrian > >>> _______________________________________________ > >>> 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" > > > > > > > -- > ------------------- > 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 Feb 22 19:56:31 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DBD76106564A for ; Wed, 22 Feb 2012 19:56:31 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 72A2E8FC14 for ; Wed, 22 Feb 2012 19:56:30 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so439759wib.13 for ; Wed, 22 Feb 2012 11:56:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=MNKO8AUKN4XcZzcNgK+huXunvuMsSkOTvgaGzaEb7Pg=; b=E8r5UUGByl9FdIZS8qlSs5C7EVoxJG8LU+vPDytvSxmxvjSk3rfpT6LDyBwm4z7U91 q7XLjpecnMOJ3k6BPxC0HUhxpTHSYhYRiJ5+LAERDLGO1gYV28xQJjnmosxeWeRQ0ogr iamDg00OUe3sOAb3qt8NEX2IbZbNj5fqhzsgo= MIME-Version: 1.0 Received: by 10.180.93.232 with SMTP id cx8mr32890006wib.14.1329940590025; Wed, 22 Feb 2012 11:56:30 -0800 (PST) Received: by 10.180.102.97 with HTTP; Wed, 22 Feb 2012 11:56:29 -0800 (PST) Date: Wed, 22 Feb 2012 11:56:29 -0800 Message-ID: From: Jack Vogel To: FreeBSD Net , FreeBSD stable , re Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 19:56:31 -0000 Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf clusters per MSIX vector, that's how many are in a ring. Either driver will configure 8 queues on a system with that many or more cores, so 8K clusters per port... My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is hardly heavy duty, and yet this exceeds the default mbuf pool on the installed kernel (1024 + maxusers * 64). Now, this can be immediately fixed by a sysadmin after that first boot, but it does result in the second driver that gets started to complain about inadequate buffers. I think the default calculation is dated and should be changed, but am not sure the best way, so are there suggestions/opinions about this, and might we get it fixed before 8.3 is baked? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 20:03:02 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69BD1106566C; Wed, 22 Feb 2012 20:03:02 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CB82F8FC14; Wed, 22 Feb 2012 20:03:01 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so396000wgb.31 for ; Wed, 22 Feb 2012 12:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xeaLOupKGvd8pL1y/XJI4rK9wlhyyJ8aP4SDOUI2akE=; b=pC/vXu0ZIr6X5bFaqbF1GQ1ajU0DsDaRiwydsAoSy6TCgJMTxhHh8FM4JTr3xlsCwq wxPWvWh8AQrWEo04beJq4FvAcxLSvFTIfI4NdZUEIzkC5cdWamVuIBiYye6dbov7Yh4/ H6GuQT95kX0y+Ujey4KNE8alNVK1JVgtGbc9Q= MIME-Version: 1.0 Received: by 10.180.79.229 with SMTP id m5mr31977151wix.6.1329940980264; Wed, 22 Feb 2012 12:03:00 -0800 (PST) Received: by 10.216.158.133 with HTTP; Wed, 22 Feb 2012 12:03:00 -0800 (PST) In-Reply-To: References: Date: Wed, 22 Feb 2012 15:03:00 -0500 Message-ID: From: Arnaud Lacombe To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:03:02 -0000 Hi, On Wed, Feb 22, 2012 at 2:56 PM, Jack Vogel wrote: > Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf > clusters per MSIX vector, > that's how many are in a ring. Either driver will configure 8 queues on a > system with that many or more > cores, so 8K clusters per port... > > My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is > hardly heavy duty, and yet this > exceeds the default mbuf pool on the installed kernel (1024 + maxusers * > 64). > > Now, this can be immediately fixed by a sysadmin after that first boot, but > it does result in the second > driver that gets started to complain about inadequate buffers. > > I think the default calculation is dated and should be changed, but am not > sure the best way, so are > there suggestions/opinions about this, and might we get it fixed before 8.3 > is baked? > get rid of the limit once and for all, it is pointless. - Arnaud From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 20:34:28 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83071106566C; Wed, 22 Feb 2012 20:34:28 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id 3C2D68FC08; Wed, 22 Feb 2012 20:34:28 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 058657300A; Wed, 22 Feb 2012 21:52:32 +0100 (CET) Date: Wed, 22 Feb 2012 21:52:32 +0100 From: Luigi Rizzo To: Jack Vogel Message-ID: <20120222205231.GA81949@onelab2.iet.unipi.it> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 20:34:28 -0000 On Wed, Feb 22, 2012 at 11:56:29AM -0800, Jack Vogel wrote: > Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf > clusters per MSIX vector, > that's how many are in a ring. Either driver will configure 8 queues on a > system with that many or more > cores, so 8K clusters per port... > > My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this is > hardly heavy duty, and yet this > exceeds the default mbuf pool on the installed kernel (1024 + maxusers * > 64). > > Now, this can be immediately fixed by a sysadmin after that first boot, but > it does result in the second > driver that gets started to complain about inadequate buffers. > > I think the default calculation is dated and should be changed, but am not > sure the best way, so are > there suggestions/opinions about this, and might we get it fixed before 8.3 > is baked? I have hit this problem recently, too. Maybe the issue mostly/only exists on 32-bit systems. Here is a possible approach: 1. nmbclusters consume the kernel virtual address space so there must be some upper limit, say VM_LIMIT = 256000 (translates to 512MB of address space) 2. also you don't want the clusters to take up too much of the available memory. This one would only trigger for minimal-memory systems, or virtual machines, but still... MEM_LIMIT = (physical_ram / 2) / 2048 3. one may try to set a suitably large, desirable number of buffers TARGET_CLUSTERS = 128000 4. and finally we could use the current default as the absolute minimum MIN_CLUSTERS = 1024 + maxusers*64 Then at boot the system could say nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) nmbclusters = max(nmbclusters, MIN_CLUSTERS) In turn, i believe interfaces should do their part and by default never try to allocate more than a fraction of the total number of buffers, if necessary reducing the number of active queues. what do people think ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 21:26:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 310E1106564A; Wed, 22 Feb 2012 21:26:30 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id E0CE88FC12; Wed, 22 Feb 2012 21:26:29 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id AB1E27300B; Wed, 22 Feb 2012 22:44:33 +0100 (CET) Date: Wed, 22 Feb 2012 22:44:33 +0100 From: Luigi Rizzo To: Ben Hutchings Message-ID: <20120222214433.GA82582@onelab2.iet.unipi.it> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1329944986.2621.46.camel@bwh-desktop> User-Agent: Mutt/1.4.2.3i Cc: FreeBSD Net , FreeBSD stable , Jack Vogel , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:26:30 -0000 On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: ... > > I have hit this problem recently, too. > > Maybe the issue mostly/only exists on 32-bit systems. > > No, we kept hitting mbuf pool limits on 64-bit systems when we started > working on FreeBSD support. ok never mind then, the mechanism would be the same, though the limits (especially VM_LIMIT) would be different. > > Here is a possible approach: > > > > 1. nmbclusters consume the kernel virtual address space so there > > must be some upper limit, say > > > > VM_LIMIT = 256000 (translates to 512MB of address space) > > > > 2. also you don't want the clusters to take up too much of the available > > memory. This one would only trigger for minimal-memory systems, > > or virtual machines, but still... > > > > MEM_LIMIT = (physical_ram / 2) / 2048 > > > > 3. one may try to set a suitably large, desirable number of buffers > > > > TARGET_CLUSTERS = 128000 > > > > 4. and finally we could use the current default as the absolute minimum > > > > MIN_CLUSTERS = 1024 + maxusers*64 > > > > Then at boot the system could say > > > > nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > > > > nmbclusters = max(nmbclusters, MIN_CLUSTERS) > > > > > > In turn, i believe interfaces should do their part and by default > > never try to allocate more than a fraction of the total number > > of buffers, > > Well what fraction should that be? It surely depends on how many > interfaces are in the system and how many queues the other interfaces > have. > > if necessary reducing the number of active queues. > > So now I have too few queues on my interface even after I increase the > limit. > > There ought to be a standard way to configure numbers of queues and > default queue lengths. Jack raised the problem that there is a poorly chosen default for nmbclusters, causing one interface to consume all the buffers. If the user explicitly overrides the value then the number of cluster should be what the user asks (memory permitting). The next step is on devices: if there are no overrides, the default for a driver is to be lean. I would say that topping the request between 1/4 and 1/8 of the total buffers is surely better than the current situation. Of course if there is an explicit override, then use it whatever happens to the others. cheers luigi From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 21:51:49 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 27449106570A; Wed, 22 Feb 2012 21:51:49 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id 53E4D8FC23; Wed, 22 Feb 2012 21:51:47 +0000 (UTC) Received: by wgbdq11 with SMTP id dq11so474666wgb.31 for ; Wed, 22 Feb 2012 13:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Psq8BF48kHsLS7MmUu4YZ6ReVaw91IXluUKaCJdDWA0=; b=mp4FDt53UNOoU9PP8BRUuCNZDb05v9NIb6zmyiDUw66YAXEPLkeywiD5kj/jOvszHo WcJ5EVshpRGoxjG9bKUcD/xM0T7mmsnHGrW7uQWyh3W8gjVjL4oxUcY7iF/WcYYS3wXT TPPMGn56F2y5SvLuFPBtBrxO0+svUCwq3Kvwk= MIME-Version: 1.0 Received: by 10.180.104.4 with SMTP id ga4mr142392wib.17.1329947506782; Wed, 22 Feb 2012 13:51:46 -0800 (PST) Received: by 10.180.102.97 with HTTP; Wed, 22 Feb 2012 13:51:46 -0800 (PST) In-Reply-To: <20120222214433.GA82582@onelab2.iet.unipi.it> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> Date: Wed, 22 Feb 2012 13:51:46 -0800 Message-ID: From: Jack Vogel To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ben Hutchings , FreeBSD Net , FreeBSD stable , re Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 21:51:49 -0000 On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo wrote: > On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > > On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > ... > > > I have hit this problem recently, too. > > > Maybe the issue mostly/only exists on 32-bit systems. > > > > No, we kept hitting mbuf pool limits on 64-bit systems when we started > > working on FreeBSD support. > > ok never mind then, the mechanism would be the same, though > the limits (especially VM_LIMIT) would be different. > > > > Here is a possible approach: > > > > > > 1. nmbclusters consume the kernel virtual address space so there > > > must be some upper limit, say > > > > > > VM_LIMIT = 256000 (translates to 512MB of address space) > > > > > > 2. also you don't want the clusters to take up too much of the > available > > > memory. This one would only trigger for minimal-memory systems, > > > or virtual machines, but still... > > > > > > MEM_LIMIT = (physical_ram / 2) / 2048 > > > > > > 3. one may try to set a suitably large, desirable number of buffers > > > > > > TARGET_CLUSTERS = 128000 > > > > > > 4. and finally we could use the current default as the absolute minimum > > > > > > MIN_CLUSTERS = 1024 + maxusers*64 > > > > > > Then at boot the system could say > > > > > > nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > > > > > > nmbclusters = max(nmbclusters, MIN_CLUSTERS) > > > > > > > > > In turn, i believe interfaces should do their part and by default > > > never try to allocate more than a fraction of the total number > > > of buffers, > > > > Well what fraction should that be? It surely depends on how many > > interfaces are in the system and how many queues the other interfaces > > have. > > > > if necessary reducing the number of active queues. > > > > So now I have too few queues on my interface even after I increase the > > limit. > > > > There ought to be a standard way to configure numbers of queues and > > default queue lengths. > > Jack raised the problem that there is a poorly chosen default for > nmbclusters, causing one interface to consume all the buffers. > If the user explicitly overrides the value then > the number of cluster should be what the user asks (memory permitting). > The next step is on devices: if there are no overrides, the default > for a driver is to be lean. I would say that topping the request between > 1/4 and 1/8 of the total buffers is surely better than the current > situation. Of course if there is an explicit override, then use > it whatever happens to the others. > > cheers > luigi > Hmmm, well, I could make the default use only 1 queue or something like that, was thinking more of what actual users of the hardware would want. After the installed kernel is booted and the admin would do whatever post install modifications they wish it could be changed, along with nmbclusters. This was why i sought opinions, of the algorithm itself, but also anyone using ixgbe and igb in heavy use, what would you find most convenient? Jack From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 22:10:11 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CCD61065672 for ; Wed, 22 Feb 2012 22:10:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 7C2758FC0C for ; Wed, 22 Feb 2012 22:10:11 +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 q1MMABbF047494 for ; Wed, 22 Feb 2012 22:10:11 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1MMABsY047493; Wed, 22 Feb 2012 22:10:11 GMT (envelope-from gnats) Date: Wed, 22 Feb 2012 22:10:11 GMT Message-Id: <201202222210.q1MMABsY047493@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/164901: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:10:11 -0000 The following reply was made to PR kern/164901; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/164901: commit references a PR Date: Wed, 22 Feb 2012 22:01:45 +0000 (UTC) Author: thompsa Date: Wed Feb 22 22:01:30 2012 New Revision: 232008 URL: http://svn.freebsd.org/changeset/base/232008 Log: Using the flowid in the mbuf assumes the network card is giving a good hash for the traffic flow, this may not be the case giving poor traffic distribution. Add a sysctl which allows us to fall back to our own flow hash code. PR: kern/164901 Submitted by: Eugene Grosbein MFC after: 1 week Modified: head/sys/net/ieee8023ad_lacp.c head/sys/net/if_lagg.c head/sys/net/if_lagg.h Modified: head/sys/net/ieee8023ad_lacp.c ============================================================================== --- head/sys/net/ieee8023ad_lacp.c Wed Feb 22 21:47:50 2012 (r232007) +++ head/sys/net/ieee8023ad_lacp.c Wed Feb 22 22:01:30 2012 (r232008) @@ -812,7 +812,7 @@ lacp_select_tx_port(struct lagg_softc *s return (NULL); } - if (m->m_flags & M_FLOWID) + if (sc->use_flowid && (m->m_flags & M_FLOWID)) hash = m->m_pkthdr.flowid; else hash = lagg_hashmbuf(m, lsc->lsc_hashkey); Modified: head/sys/net/if_lagg.c ============================================================================== --- head/sys/net/if_lagg.c Wed Feb 22 21:47:50 2012 (r232007) +++ head/sys/net/if_lagg.c Wed Feb 22 22:01:30 2012 (r232008) @@ -262,6 +262,8 @@ lagg_clone_create(struct if_clone *ifc, struct ifnet *ifp; int i, error = 0; static const u_char eaddr[6]; /* 00:00:00:00:00:00 */ + struct sysctl_oid *oid; + char num[14]; /* sufficient for 32 bits */ sc = malloc(sizeof(*sc), M_DEVBUF, M_WAITOK|M_ZERO); ifp = sc->sc_ifp = if_alloc(IFT_ETHER); @@ -270,6 +272,15 @@ lagg_clone_create(struct if_clone *ifc, return (ENOSPC); } + sysctl_ctx_init(&sc->ctx); + snprintf(num, sizeof(num), "%u", unit); + sc->use_flowid = 1; + oid = SYSCTL_ADD_NODE(&sc->ctx, &SYSCTL_NODE_CHILDREN(_net_link, lagg), + OID_AUTO, num, CTLFLAG_RD, NULL, ""); + SYSCTL_ADD_INT(&sc->ctx, SYSCTL_CHILDREN(oid), OID_AUTO, + "use_flowid", CTLTYPE_INT|CTLFLAG_RW, &sc->use_flowid, sc->use_flowid, + "Use flow id for load sharing"); + sc->sc_proto = LAGG_PROTO_NONE; for (i = 0; lagg_protos[i].ti_proto != LAGG_PROTO_NONE; i++) { if (lagg_protos[i].ti_proto == LAGG_PROTO_DEFAULT) { @@ -349,6 +360,7 @@ lagg_clone_destroy(struct ifnet *ifp) LAGG_WUNLOCK(sc); + sysctl_ctx_free(&sc->ctx); ifmedia_removeall(&sc->sc_media); ether_ifdetach(ifp); if_free(ifp); @@ -1676,7 +1688,7 @@ lagg_lb_start(struct lagg_softc *sc, str struct lagg_port *lp = NULL; uint32_t p = 0; - if (m->m_flags & M_FLOWID) + if (sc->use_flowid && (m->m_flags & M_FLOWID)) p = m->m_pkthdr.flowid; else p = lagg_hashmbuf(m, lb->lb_key); Modified: head/sys/net/if_lagg.h ============================================================================== --- head/sys/net/if_lagg.h Wed Feb 22 21:47:50 2012 (r232007) +++ head/sys/net/if_lagg.h Wed Feb 22 22:01:30 2012 (r232008) @@ -21,6 +21,8 @@ #ifndef _NET_LAGG_H #define _NET_LAGG_H +#include + /* * Global definitions */ @@ -202,6 +204,8 @@ struct lagg_softc { eventhandler_tag vlan_attach; eventhandler_tag vlan_detach; #endif + struct sysctl_ctx_list ctx; /* sysctl variables */ + int use_flowid; /* use M_FLOWID */ }; struct lagg_port { _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 22:20:17 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 743961065673 for ; Wed, 22 Feb 2012 22:20:17 +0000 (UTC) (envelope-from atmotaruno@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 2B4ED8FC0C for ; Wed, 22 Feb 2012 22:20:16 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so582412vbb.13 for ; Wed, 22 Feb 2012 14:20:16 -0800 (PST) Received-SPF: pass (google.com: domain of atmotaruno@gmail.com designates 10.52.172.202 as permitted sender) client-ip=10.52.172.202; Authentication-Results: mr.google.com; spf=pass (google.com: domain of atmotaruno@gmail.com designates 10.52.172.202 as permitted sender) smtp.mail=atmotaruno@gmail.com; dkim=pass header.i=atmotaruno@gmail.com Received: from mr.google.com ([10.52.172.202]) by 10.52.172.202 with SMTP id be10mr15512095vdc.116.1329949216427 (num_hops = 1); Wed, 22 Feb 2012 14:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=U1B9KiieJeAMJrOrGm8Kq+MOoFwKAMuUbWPEZIWZOXY=; b=XEDMn3Mdq59xutJpMYTm2sD5jzRvc7j8bvVo0RQ7d2WUSeyG0GWMxs99rmuCNUxkvS ewfKivcdH44UvOlVosl+g4hIKZRxdkBWZLrEvsnibkyDRb2Eo/QxgWGrVfPiG3EKmuPz x5vhh859hr17fQBFVdg0oOlq9gVWS1LIyCUNo= MIME-Version: 1.0 Received: by 10.52.172.202 with SMTP id be10mr12656323vdc.116.1329947847814; Wed, 22 Feb 2012 13:57:27 -0800 (PST) Received: by 10.52.65.110 with HTTP; Wed, 22 Feb 2012 13:57:27 -0800 (PST) Date: Thu, 23 Feb 2012 04:57:27 +0700 Message-ID: From: Nugroho Atmotaruno To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:20:17 -0000 Hi all, I'm using FBSD 9.0-RELEASE with TPLink TG-3268 (rl8169) flapping (UP/DOWN every several seconds). [nugroho@xtreme ~]$ uname -a FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan=C2=A0 3 07:46:30 UTC 2012 root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC=C2=A0 amd64 [root@xtreme ~]# tail /var/log/messages Feb 23 04:47:05 xtreme kernel: re0: link state changed to UP Feb 23 04:47:07 xtreme kernel: re0: link state changed to DOWN Feb 23 04:47:10 xtreme kernel: re0: link state changed to UP Feb 23 04:47:16 xtreme kernel: re0: link state changed to DOWN Feb 23 04:47:19 xtreme kernel: re0: link state changed to UP Feb 23 04:47:20 xtreme kernel: re0: link state changed to DOWN Feb 23 04:47:23 xtreme kernel: re0: link state changed to UP Feb 23 04:48:44 xtreme kernel: re0: link state changed to DOWN Feb 23 04:48:47 xtreme kernel: re0: link state changed to UP [root@xtreme ~]# pciconf -lcv re0@pci0:2:5:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec rev=3D= 0x10 hdr=3D0x00 vendor =3D 'Realtek Semiconductor Co., Ltd.' device =3D 'RTL-8169 Gigabit Ethernet' class =3D network subclass =3D ethernet cap 01[dc] =3D powerspec 2 supports D0 D1 D2 D3 current D0 [root@xtreme ~]# devinfo -rv | grep rg rgephy0 pnpinfo oui=3D0xe04c model=3D0x11 rev=3D0x3 at phyn= o=3D1 [root@xtreme ~]# ifconfig re0 re0: flags=3D8843 metric 0 mtu 1500 options=3D389b ether f8:d1:11:04:15:d6 inet 167.205.3.4 netmask 0xffffff80 broadcast 167.205.3.127 inet6 fe80::fad1:11ff:fe04:15d6%re0 prefixlen 64 scopeid 0x7 inet6 2403:8000:1:1880::4 prefixlen 64 nd6 options=3D21 media: Ethernet autoselect (1000baseT ) status: active -- Regards, Nugroho From owner-freebsd-net@FreeBSD.ORG Wed Feb 22 22:37:55 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6D02106564A; Wed, 22 Feb 2012 22:37:55 +0000 (UTC) (envelope-from thompsa@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BDD858FC08; Wed, 22 Feb 2012 22:37:55 +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 q1MMbtZ7076284; Wed, 22 Feb 2012 22:37:55 GMT (envelope-from thompsa@freefall.freebsd.org) Received: (from thompsa@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1MMbt5J076280; Wed, 22 Feb 2012 22:37:55 GMT (envelope-from thompsa) Date: Wed, 22 Feb 2012 22:37:55 GMT Message-Id: <201202222237.q1MMbt5J076280@freefall.freebsd.org> To: eugen@eg.sd.rdtc.ru, thompsa@FreeBSD.org, freebsd-net@FreeBSD.org, thompsa@FreeBSD.org From: thompsa@FreeBSD.org Cc: Subject: Re: kern/164901: [regression] [patch] [lagg] igb/lagg poor traffic distribution X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 22:37:56 -0000 Synopsis: [regression] [patch] [lagg] igb/lagg poor traffic distribution State-Changed-From-To: open->patched State-Changed-By: thompsa State-Changed-When: Wed Feb 22 22:37:24 UTC 2012 State-Changed-Why: Committed to head. Responsible-Changed-From-To: freebsd-net->thompsa Responsible-Changed-By: thompsa Responsible-Changed-When: Wed Feb 22 22:37:24 UTC 2012 Responsible-Changed-Why: Committed to head. http://www.freebsd.org/cgi/query-pr.cgi?pr=164901 From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 01:09:44 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 69E2D106564A for ; Thu, 23 Feb 2012 01:09:44 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id 341608FC0A for ; Thu, 23 Feb 2012 01:09:43 +0000 (UTC) Received: from [127.0.0.1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q1N0wmK4000451 for ; Wed, 22 Feb 2012 16:58:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1329958729; bh=8JpAKX8vqrLHDpksdayzWIETHSiolEUnDAANIdaool0=; h=Subject:From:Reply-To:To:Content-Type:Date:Message-ID: Mime-Version:Content-Transfer-Encoding; b=JDNIYtEl12T76tm/uAn+5btFNcoEFDFmnVFVF33yFgEI9aEA+qzNbbPo8V3Ht3dux XRN8EekjmrVmjhgA0qTOuePDk6qk7qYjsVHgL+5gYmT4f5lwE95rgMdfQesP4/jML2 KFvs+IbGon6H7kf/G3FfoFZSGGNE2j+c8iadPkXo= From: Sean Bruno To: freebsd-net@freebsd.org Content-Type: text/plain; charset="UTF-8" Date: Wed, 22 Feb 2012 16:58:48 -0800 Message-ID: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 01:09:44 -0000 Trying some hackery today in my netboot environment with the Dell 12G R620. I had to disable some bios calls in bios.c after reviewing an email from Doug Ambrisko, and I see a pretty hard failure of bge(4) on stable/7 with yahoo modifications on i386. I've tried disabling msi via: ==== //depot/yahoo/ybsd_7/src/sys/dev/bge/if_bge.c#49 - /home/seanbru/ybsd_7/src/sys/dev/bge/if_bge.c ==== 5633c5633 < sc->bge_msi = 1; --- > sc->bge_msi = 0; This quieted a lot of errors but the interface still appears to be non functional. http://people.freebsd.org/~sbruno/dell_12g_bgesysctl.txt http://people.freebsd.org/~sbruno/dell_12g_pciconf.txt http://people.freebsd.org/~sbruno/dell_12g_dmesg.txt Sean P.S. Not related to the bge(4) failure but might be interesting to others who are trying to get the Dell 12G h/w working in their environment: ==== //depot/yahoo/ybsd_7/src/sys/dev/mpt/mpt_pci.c#21 - /home/seanbru/ybsd_7/src/sys/dev/mpt/mpt_pci.c ==== 235c235,236 < switch ((pci_get_device(dev) & ~1)) { --- > //switch ((pci_get_device(dev) & ~1)) { > switch ((pci_get_device(dev))) { ==== //depot/yahoo/ybsd_7/src/sys/i386/i386/bios.c#5 - /home/seanbru/ybsd_7/src/sys/i386/i386/bios.c ==== 89a90,91 > printf("Ugh, hackery due to modern BIOS implementations\n"); > return; From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 04:33:51 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 95D96106564A for ; Thu, 23 Feb 2012 04:33:51 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6BED28FC08 for ; Thu, 23 Feb 2012 04:33:51 +0000 (UTC) Received: by daec6 with SMTP id c6so887673dae.13 for ; Wed, 22 Feb 2012 20:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4EtPwq9CdpWwpMUYkz2VDo/8OeZ2vkiXMJ7DfaFBE40=; b=IvAmHQaq4fGXZU82vAxQFm4PEZAmqWQ1+IIJFbsIWE15WO2/5cYmkaMEQyFhTpyVKk sJtlSa9677gGqsuPeasX15mSQ8hvw1cHrBX7rf6z1Z1ScqrZiBcU++TihbPqjC6iVe0v 3KDCYRv2Gw3MOaQDwyAmVaRsewtcx2EQZQURw= Received: by 10.68.197.196 with SMTP id iw4mr947254pbc.133.1329971631090; Wed, 22 Feb 2012 20:33:51 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id vy2sm361112pbb.48.2012.02.22.20.33.48 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 22 Feb 2012 20:33:50 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 23 Feb 2012 13:33:44 -0800 From: YongHyeon PYUN Date: Thu, 23 Feb 2012 13:33:44 -0800 To: sbruno@freebsd.org Message-ID: <20120223213344.GC13815@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 04:33:51 -0000 On Wed, Feb 22, 2012 at 04:58:48PM -0800, Sean Bruno wrote: > Trying some hackery today in my netboot environment with the Dell 12G > R620. I had to disable some bios calls in bios.c after reviewing an > email from Doug Ambrisko, and I see a pretty hard failure of bge(4) on > stable/7 with yahoo modifications on i386. > > I've tried disabling msi via: > ==== //depot/yahoo/ybsd_7/src/sys/dev/bge/if_bge.c#49 > - /home/seanbru/ybsd_7/src/sys/dev/bge/if_bge.c ==== > 5633c5633 > < sc->bge_msi = 1; > --- > > sc->bge_msi = 0; > > This quieted a lot of errors but the interface still appears to be non > functional. > > > http://people.freebsd.org/~sbruno/dell_12g_bgesysctl.txt > http://people.freebsd.org/~sbruno/dell_12g_pciconf.txt > http://people.freebsd.org/~sbruno/dell_12g_dmesg.txt > > > Sean As you see ukphy(4) was attached to bge2 so it may cause various issues. Is bge2 ASF/IPMI enabled interface? It seems ASF handling in bge(4) causes more trouble on recent controllers. Unfortunately disabling ASF may also trigger other problems like NMI. I believe bge(4) should always honor ASF/IMPI firmware instead of relying on hw.bge.allow_asf tunable and have to strictly follow firmware handshake sequence. Just ignoring ASF/IMPI firmware seems to confuse firmware. Unfortunately all these information is undocumented and fixing it requires real hardware access. From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 06:54:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 74522106564A; Thu, 23 Feb 2012 06:54:37 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9D4718FC15; Thu, 23 Feb 2012 06:54:36 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1022340bkc.13 for ; Wed, 22 Feb 2012 22:54:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=js53BQ1MdzOwPD4HrTs5EtfOvOMXCud7gkl4qPic+ig=; b=tsMSZPgUrZXzYvV1rfUyxUHFc+8uP6hJZ2Ye8O0Pp001+U94BIg8+L0pic84y7vGaF LTGoJoO/fW8PucqfLGg9bTwAAuBUgHmyCduSCIX4e9JjrNhJO12TLuqGbF1ZOC4ncmlO VYIUwI2E4/CqXTSbfxkcM5/IztoeNKiTePrIU= MIME-Version: 1.0 Received: by 10.204.145.145 with SMTP id d17mr8899bkv.77.1329978449153; Wed, 22 Feb 2012 22:27:29 -0800 (PST) Received: by 10.204.152.86 with HTTP; Wed, 22 Feb 2012 22:27:29 -0800 (PST) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> Date: Thu, 23 Feb 2012 01:27:29 -0500 Message-ID: From: Zaphod Beeblebrox To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 06:54:37 -0000 It could do some good to think of the scale of the problem and maybe the driver can tune to the hardware. First, is 8k packet buffers a reasonable default on a GigE port? Well... on a GigE port, you could have from 100k pps (packets per second) at 1500 bytes to 500k pps at around 300 bytes to truly pathological rates of packets (2M pps at the Ethernet-minimum of 64 bytes). 8k buffers vanish in 1/10th of a second in the 1500 byte case and that doesn't even really speak to the buffers getting emptied by other software. Do you maybe want to have a switch whereby the GigE port is in performance or non-performance mode? Do you want to assume that systems with GigE ports are also not pathologically low in memory? Perhaps in 10 or 100 megabit mode, the driver should make smaller rings? For that matter, if mbufs come in a page's worth at a time, what's the drawback of scaling them up and down with network vs. memory vs. cache pressure? From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 08:37:19 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B648B106564A; Thu, 23 Feb 2012 08:37:19 +0000 (UTC) (envelope-from fabien.thomas@netasq.com) Received: from work.netasq.com (mars.netasq.com [91.212.116.3]) by mx1.freebsd.org (Postfix) with ESMTP id C18E58FC08; Thu, 23 Feb 2012 08:37:18 +0000 (UTC) Received: from [10.2.1.1] (unknown [10.2.1.1]) by work.netasq.com (Postfix) with ESMTPSA id AE232744006; Thu, 23 Feb 2012 09:18:12 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/signed; boundary="Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289"; protocol="application/pkcs7-signature"; micalg=sha1 From: Fabien Thomas In-Reply-To: Date: Thu, 23 Feb 2012 09:19:13 +0100 Message-Id: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> To: Jack Vogel X-Mailer: Apple Mail (2.1257) X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 08:37:19 -0000 --Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Le 22 f=E9vr. 2012 =E0 22:51, Jack Vogel a =E9crit : > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo = wrote: >=20 >> On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: >>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: >> ... >>>> I have hit this problem recently, too. >>>> Maybe the issue mostly/only exists on 32-bit systems. >>>=20 >>> No, we kept hitting mbuf pool limits on 64-bit systems when we = started >>> working on FreeBSD support. >>=20 >> ok never mind then, the mechanism would be the same, though >> the limits (especially VM_LIMIT) would be different. >>=20 >>>> Here is a possible approach: >>>>=20 >>>> 1. nmbclusters consume the kernel virtual address space so there >>>> must be some upper limit, say >>>>=20 >>>> VM_LIMIT =3D 256000 (translates to 512MB of address space) >>>>=20 >>>> 2. also you don't want the clusters to take up too much of the >> available >>>> memory. This one would only trigger for minimal-memory systems, >>>> or virtual machines, but still... >>>>=20 >>>> MEM_LIMIT =3D (physical_ram / 2) / 2048 >>>>=20 >>>> 3. one may try to set a suitably large, desirable number of buffers >>>>=20 >>>> TARGET_CLUSTERS =3D 128000 >>>>=20 >>>> 4. and finally we could use the current default as the absolute = minimum >>>>=20 >>>> MIN_CLUSTERS =3D 1024 + maxusers*64 >>>>=20 >>>> Then at boot the system could say >>>>=20 >>>> nmbclusters =3D min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) >>>>=20 >>>> nmbclusters =3D max(nmbclusters, MIN_CLUSTERS) >>>>=20 >>>>=20 >>>> In turn, i believe interfaces should do their part and by default >>>> never try to allocate more than a fraction of the total number >>>> of buffers, >>>=20 >>> Well what fraction should that be? It surely depends on how many >>> interfaces are in the system and how many queues the other = interfaces >>> have. >>=20 >>>> if necessary reducing the number of active queues. >>>=20 >>> So now I have too few queues on my interface even after I increase = the >>> limit. >>>=20 >>> There ought to be a standard way to configure numbers of queues and >>> default queue lengths. >>=20 >> Jack raised the problem that there is a poorly chosen default for >> nmbclusters, causing one interface to consume all the buffers. >> If the user explicitly overrides the value then >> the number of cluster should be what the user asks (memory = permitting). >> The next step is on devices: if there are no overrides, the default >> for a driver is to be lean. I would say that topping the request = between >> 1/4 and 1/8 of the total buffers is surely better than the current >> situation. Of course if there is an explicit override, then use >> it whatever happens to the others. >>=20 >> cheers >> luigi >>=20 >=20 > Hmmm, well, I could make the default use only 1 queue or something = like > that, > was thinking more of what actual users of the hardware would want. >=20 I think this is more reasonable to setup interface with one queue. Even if the cluster does not hit the max you will end up with unbalanced = setting that let very low mbuf count for other uses. > After the installed kernel is booted and the admin would do whatever = post > install > modifications they wish it could be changed, along with nmbclusters. >=20 > This was why i sought opinions, of the algorithm itself, but also = anyone > using > ixgbe and igb in heavy use, what would you find most convenient? >=20 > Jack > _______________________________________________ > 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" --Apple-Mail=_D789DF06-0C84-453C-AD51-1C13DBE43289-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 09:13:07 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E9A21065670; Thu, 23 Feb 2012 09:13:07 +0000 (UTC) (envelope-from andrnils@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DDE258FC1A; Thu, 23 Feb 2012 09:13:06 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so1107427bkc.13 for ; Thu, 23 Feb 2012 01:13:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2ripg7T6A7DLWtyIpGMKkvqqGEYOLVv49MMSPHikGy4=; b=pZX3t6SaXzZF90EzlP0jK6lCy/9Nn4oqeS+c41F1galOImdLwl+pCBbgb5T8KTOa7Y y8O0h2VL58NW0P5AiH7kjdjobGNAAQ2Gh2B2DS5V4AVJMaRIKkM2SwgrCxFJckr1DeOD WmtvXPS4L6WuX7qWKWJ7j++hypuCg7OGj93qE= MIME-Version: 1.0 Received: by 10.204.157.17 with SMTP id z17mr195468bkw.37.1329986924860; Thu, 23 Feb 2012 00:48:44 -0800 (PST) Received: by 10.204.51.212 with HTTP; Thu, 23 Feb 2012 00:48:44 -0800 (PST) In-Reply-To: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> Date: Thu, 23 Feb 2012 09:48:44 +0100 Message-ID: From: Andreas Nilsson To: Fabien Thomas Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD stable , FreeBSD Net , Jack Vogel , Ben Hutchings , re , Luigi Rizzo Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 09:13:07 -0000 On Thu, Feb 23, 2012 at 9:19 AM, Fabien Thomas wr= ote: > > Le 22 f=E9vr. 2012 =E0 22:51, Jack Vogel a =E9crit : > > > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo wrote= : > > > >> On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: > >>> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > >> ... > >>>> I have hit this problem recently, too. > >>>> Maybe the issue mostly/only exists on 32-bit systems. > >>> > >>> No, we kept hitting mbuf pool limits on 64-bit systems when we starte= d > >>> working on FreeBSD support. > >> > >> ok never mind then, the mechanism would be the same, though > >> the limits (especially VM_LIMIT) would be different. > >> > >>>> Here is a possible approach: > >>>> > >>>> 1. nmbclusters consume the kernel virtual address space so there > >>>> must be some upper limit, say > >>>> > >>>> VM_LIMIT =3D 256000 (translates to 512MB of address space) > >>>> > >>>> 2. also you don't want the clusters to take up too much of the > >> available > >>>> memory. This one would only trigger for minimal-memory systems, > >>>> or virtual machines, but still... > >>>> > >>>> MEM_LIMIT =3D (physical_ram / 2) / 2048 > >>>> > >>>> 3. one may try to set a suitably large, desirable number of buffers > >>>> > >>>> TARGET_CLUSTERS =3D 128000 > >>>> > >>>> 4. and finally we could use the current default as the absolute > minimum > >>>> > >>>> MIN_CLUSTERS =3D 1024 + maxusers*64 > >>>> > >>>> Then at boot the system could say > >>>> > >>>> nmbclusters =3D min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) > >>>> > >>>> nmbclusters =3D max(nmbclusters, MIN_CLUSTERS) > >>>> > >>>> > >>>> In turn, i believe interfaces should do their part and by default > >>>> never try to allocate more than a fraction of the total number > >>>> of buffers, > >>> > >>> Well what fraction should that be? It surely depends on how many > >>> interfaces are in the system and how many queues the other interfaces > >>> have. > >> > >>>> if necessary reducing the number of active queues. > >>> > >>> So now I have too few queues on my interface even after I increase th= e > >>> limit. > >>> > >>> There ought to be a standard way to configure numbers of queues and > >>> default queue lengths. > >> > >> Jack raised the problem that there is a poorly chosen default for > >> nmbclusters, causing one interface to consume all the buffers. > >> If the user explicitly overrides the value then > >> the number of cluster should be what the user asks (memory permitting)= . > >> The next step is on devices: if there are no overrides, the default > >> for a driver is to be lean. I would say that topping the request betwe= en > >> 1/4 and 1/8 of the total buffers is surely better than the current > >> situation. Of course if there is an explicit override, then use > >> it whatever happens to the others. > >> > >> cheers > >> luigi > >> > > > > Hmmm, well, I could make the default use only 1 queue or something like > > that, > > was thinking more of what actual users of the hardware would want. > > > > I think this is more reasonable to setup interface with one queue. > Even if the cluster does not hit the max you will end up with unbalanced > setting that > let very low mbuf count for other uses. > If interfaces have the possibility to use more queues, they should, imo so I'm all for rasing the default size. For those systems with very limited memory it's easily changed. > > > After the installed kernel is booted and the admin would do whatever po= st > > install > > modifications they wish it could be changed, along with nmbclusters. > > > > This was why i sought opinions, of the algorithm itself, but also anyon= e > > using > > ixgbe and igb in heavy use, what would you find most convenient? > > > > Jack > > _______________________________________________ > > 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 Thu Feb 23 10:36:39 2012 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0DE8106566C; Thu, 23 Feb 2012 10:36:39 +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 4F8308FC12; Thu, 23 Feb 2012 10:36:39 +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 q1NAab6h019606; Thu, 23 Feb 2012 14:36:37 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.5/8.14.5/Submit) id q1NAabsc019605; Thu, 23 Feb 2012 14:36:37 +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, 23 Feb 2012 14:36:37 +0400 From: Gleb Smirnoff To: =?koi8-r?B?68/O2MvP1yDl18fFzsnK?= Message-ID: <20120223103637.GS92625@FreeBSD.org> References: <376001325.20120220220651@yandex.ru> <323151470.20120221225558@yandex.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <323151470.20120221225558@yandex.ru> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org, freebsd-questions@FreeBSD.org, Ivan Ivanyuk Subject: Re: deleting an alias from interface cause the static route to be deleted X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 10:36:39 -0000 On Tue, Feb 21, 2012 at 10:55:58PM +0200, Коньков Евгений wrote: К> >> vlan74: flags=8843 metric 0 mtu 1500 К> >>        options=3 К> >>        ether f4:6d:04:7c:7b:d3 К> >>        inet6 fe80::f66d:4ff:fe7c:7bd3%vlan74 prefixlen 64 scopeid 0xd К> >>        inet 10.1.26.1 netmask 0xfffffe00 broadcast 10.1.27.255 К> >>        inet 10.1.26.3 netmask 0xfffffe00 broadcast 10.1.27.255 К> >>        nd6 options=29 К> >>        media: Ethernet autoselect (1000baseT ) К> >>        status: active К> >>        vlan: 74 parent interface: re0 К> >> К> >> ifconfig vlan74 delete 10.1.26.1 К> >> К> >> will delete these static routes from route table: К> >> К> >> 10.3.0.1           10.1.26.2          UGHS        8      367 vlan74 К> >> 10.1.6.0/23        10.1.26.2          UGS       275   166969 vlan74 К> >> К> >> Does this a bug? It is. The problem is that our routing table support only a single route for a prefix (yep, there is RADIX_MPATH, but it serves other needs). Thus, every time we add or delete a prefix we need to do a lot of sanity checking: running through interfaces list, seek for other origin for this prefix, etc. All suggested patches do this, and from my viewpoint these are crutches. I'd prefer to have something like this: http://lists.freebsd.org/pipermail/freebsd-net/2012-February/031468.html -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 11:40:06 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EEA87106564A for ; Thu, 23 Feb 2012 11:40:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id ABF838FC14 for ; Thu, 23 Feb 2012 11:40:06 +0000 (UTC) Received: by daec6 with SMTP id c6so1292116dae.13 for ; Thu, 23 Feb 2012 03:40:06 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.194.230 as permitted sender) client-ip=10.68.194.230; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.194.230 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.194.230]) by 10.68.194.230 with SMTP id hz6mr3182201pbc.24.1329997206425 (num_hops = 1); Thu, 23 Feb 2012 03:40:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=rAxTE/JSFUGlxkk0CDjdzXkjm0IW7lltM9keGIfZWFQ=; b=NXEt8boTP0TSuS1ZtRmLJOdrsOOfJZGTpUW0Bk2riB+Wqwpktwk37d6t1V0XR2ch5H QyPMUnoW3iB5J//nIOYZ7Pf4TfOLwt1QKAUjHNfWSaynJQ6238loUcqDGHBCLNOILBH4 0BOryUM0D6MF8w8aJ5effMnDxe9gzerOXtyac= Received: by 10.68.194.230 with SMTP id hz6mr2679168pbc.24.1329997206366; Thu, 23 Feb 2012 03:40:06 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id w8sm1285666pbo.23.2012.02.23.03.40.03 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 03:40:05 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Thu, 23 Feb 2012 20:40:00 -0800 From: YongHyeon PYUN Date: Thu, 23 Feb 2012 20:40:00 -0800 To: Nugroho Atmotaruno Message-ID: <20120224044000.GF13815@michelle.cdnetworks.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="bCsyhTFzCvuiizWE" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 11:40:07 -0000 --bCsyhTFzCvuiizWE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Feb 23, 2012 at 04:57:27AM +0700, Nugroho Atmotaruno wrote: > Hi all, > > I'm using FBSD 9.0-RELEASE with TPLink TG-3268 (rl8169) flapping > (UP/DOWN every several seconds). > > [nugroho@xtreme ~]$ uname -a > FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue > Jan?? 3 07:46:30 UTC 2012 > root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC?? amd64 > > [root@xtreme ~]# tail /var/log/messages > Feb 23 04:47:05 xtreme kernel: re0: link state changed to UP > Feb 23 04:47:07 xtreme kernel: re0: link state changed to DOWN > Feb 23 04:47:10 xtreme kernel: re0: link state changed to UP > Feb 23 04:47:16 xtreme kernel: re0: link state changed to DOWN > Feb 23 04:47:19 xtreme kernel: re0: link state changed to UP > Feb 23 04:47:20 xtreme kernel: re0: link state changed to DOWN > Feb 23 04:47:23 xtreme kernel: re0: link state changed to UP > Feb 23 04:48:44 xtreme kernel: re0: link state changed to DOWN > Feb 23 04:48:47 xtreme kernel: re0: link state changed to UP > > > [root@xtreme ~]# pciconf -lcv > re0@pci0:2:5:0: class=0x020000 card=0x816910ec chip=0x816910ec rev=0x10 hdr=0x00 > vendor = 'Realtek Semiconductor Co., Ltd.' > device = 'RTL-8169 Gigabit Ethernet' > class = network > subclass = ethernet > cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0 > > [root@xtreme ~]# devinfo -rv | grep rg > rgephy0 pnpinfo oui=0xe04c model=0x11 rev=0x3 at phyno=1 > > [root@xtreme ~]# ifconfig re0 > re0: flags=8843 metric 0 mtu 1500 > options=389b > ether f8:d1:11:04:15:d6 > inet 167.205.3.4 netmask 0xffffff80 broadcast 167.205.3.127 > inet6 fe80::fad1:11ff:fe04:15d6%re0 prefixlen 64 scopeid 0x7 > inet6 2403:8000:1:1880::4 prefixlen 64 > nd6 options=21 > media: Ethernet autoselect (1000baseT ) > status: active > Would you try attached patch? --bCsyhTFzCvuiizWE Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="rgephy.re.diff" Index: sys/dev/mii/rgephy.c =================================================================== --- sys/dev/mii/rgephy.c (revision 232042) +++ sys/dev/mii/rgephy.c (working copy) @@ -110,11 +110,16 @@ rgephy_attach(device_t dev) { struct mii_softc *sc; + struct mii_attach_args *ma; + u_int flags; sc = device_get_softc(dev); + ma = device_get_ivars(dev); + flags = 0; + if (strcmp(ma->mii_data->mii_ifp->if_dname, "re") == 0) + flags |= MIIF_PHYPRIV0; + mii_phy_dev_attach(dev, flags, &rgephy_funcs, 0); - mii_phy_dev_attach(dev, 0, &rgephy_funcs, 0); - /* RTL8169S do not report auto-sense; add manually. */ sc->mii_capabilities = (PHY_READ(sc, MII_BMSR) | BMSR_ANEG) & sc->mii_capmask; @@ -243,7 +248,8 @@ * Check to see if we have link. If we do, we don't * need to restart the autonegotiation process. */ - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && + sc->mii_mpd_rev >= 2) { /* RTL8211B(L) */ reg = PHY_READ(sc, RGEPHY_MII_SSR); if (reg & RGEPHY_SSR_LINK) { @@ -298,7 +304,7 @@ mii->mii_media_status = IFM_AVALID; mii->mii_media_active = IFM_ETHER; - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev >= 2) { ssr = PHY_READ(sc, RGEPHY_MII_SSR); if (ssr & RGEPHY_SSR_LINK) mii->mii_media_status |= IFM_ACTIVE; @@ -328,7 +334,7 @@ } } - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev >= 2) { ssr = PHY_READ(sc, RGEPHY_MII_SSR); switch (ssr & RGEPHY_SSR_SPD_MASK) { case RGEPHY_SSR_S1000: @@ -484,7 +490,7 @@ { uint16_t ssr; - if (sc->mii_mpd_rev == 3) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev == 3) { /* RTL8211C(L) */ ssr = PHY_READ(sc, RGEPHY_MII_SSR); if ((ssr & RGEPHY_SSR_ALDPS) != 0) { --bCsyhTFzCvuiizWE-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 14:09:15 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BE293106566B for ; Thu, 23 Feb 2012 14:09:15 +0000 (UTC) (envelope-from atmotaruno@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 6E41D8FC14 for ; Thu, 23 Feb 2012 14:09:15 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1193383vcm.13 for ; Thu, 23 Feb 2012 06:09:14 -0800 (PST) Received-SPF: pass (google.com: domain of atmotaruno@gmail.com designates 10.220.108.138 as permitted sender) client-ip=10.220.108.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of atmotaruno@gmail.com designates 10.220.108.138 as permitted sender) smtp.mail=atmotaruno@gmail.com; dkim=pass header.i=atmotaruno@gmail.com Received: from mr.google.com ([10.220.108.138]) by 10.220.108.138 with SMTP id f10mr920136vcp.16.1330006154885 (num_hops = 1); Thu, 23 Feb 2012 06:09:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=cXKAUzAX+LAPk1sTNyz+q3UkaBDesbvGozQ3OQNHpBA=; b=YCJNdCJu9B5PXYxLuP3hKjUbaewE/qxHThO+WBjxXpUAxPbjBb2g0l93E9WNumON8D Dv6KKA8jPZbDJ/C0QkGIoNTsmb2DA2FRpQBRAubIPHW/4MVPwGsSjT6nKLaexjXa9Q4k Kb6t8lrazPSKp+y7z3pm6/HgitGwJlRVVv5P4= MIME-Version: 1.0 Received: by 10.220.108.138 with SMTP id f10mr749333vcp.16.1330006154819; Thu, 23 Feb 2012 06:09:14 -0800 (PST) Received: by 10.52.65.110 with HTTP; Thu, 23 Feb 2012 06:09:14 -0800 (PST) In-Reply-To: <20120224044000.GF13815@michelle.cdnetworks.com> References: <20120224044000.GF13815@michelle.cdnetworks.com> Date: Thu, 23 Feb 2012 21:09:14 +0700 Message-ID: From: Nugroho Atmotaruno To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:09:15 -0000 On Fri, Feb 24, 2012 at 11:40 AM, YongHyeon PYUN wrote: > On Thu, Feb 23, 2012 at 04:57:27AM +0700, Nugroho Atmotaruno wrote: >> Hi all, >> >> I'm using FBSD 9.0-RELEASE with TPLink TG-3268 (rl8169) flapping >> (UP/DOWN every several seconds). >> >> [nugroho@xtreme ~]$ uname -a >> FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue >> Jan?? 3 07:46:30 UTC 2012 >> root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC?? amd64 >> >> [root@xtreme ~]# tail /var/log/messages >> Feb 23 04:47:05 xtreme kernel: re0: link state changed to UP >> Feb 23 04:47:07 xtreme kernel: re0: link state changed to DOWN >> Feb 23 04:47:10 xtreme kernel: re0: link state changed to UP >> Feb 23 04:47:16 xtreme kernel: re0: link state changed to DOWN >> Feb 23 04:47:19 xtreme kernel: re0: link state changed to UP >> Feb 23 04:47:20 xtreme kernel: re0: link state changed to DOWN >> Feb 23 04:47:23 xtreme kernel: re0: link state changed to UP >> Feb 23 04:48:44 xtreme kernel: re0: link state changed to DOWN >> Feb 23 04:48:47 xtreme kernel: re0: link state changed to UP >> >> >> [root@xtreme ~]# pciconf -lcv >> re0@pci0:2:5:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec rev= =3D0x10 hdr=3D0x00 >> =C2=A0 =C2=A0 vendor =C2=A0 =C2=A0 =3D 'Realtek Semiconductor Co., Ltd.' >> =C2=A0 =C2=A0 device =C2=A0 =C2=A0 =3D 'RTL-8169 Gigabit Ethernet' >> =C2=A0 =C2=A0 class =C2=A0 =C2=A0 =C2=A0=3D network >> =C2=A0 =C2=A0 subclass =C2=A0 =3D ethernet >> =C2=A0 =C2=A0 cap 01[dc] =3D powerspec 2 =C2=A0supports D0 D1 D2 D3 =C2= =A0current D0 >> >> [root@xtreme ~]# devinfo -rv | grep rg >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rgephy0 pnpinfo = oui=3D0xe04c model=3D0x11 rev=3D0x3 at phyno=3D1 >> >> [root@xtreme ~]# ifconfig re0 >> re0: flags=3D8843 metric 0 mtu 1= 500 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D389b >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ether f8:d1:11:04:15:d6 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 167.205.3.4 netmask 0xffffff80 broadcas= t 167.205.3.127 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 fe80::fad1:11ff:fe04:15d6%re0 prefixle= n 64 scopeid 0x7 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 2403:8000:1:1880::4 prefixlen 64 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21 >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT ) >> =C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active >> > > Would you try attached patch? Thanks for your reply, I'll try it tomorrow. --=20 Regards, Nugroho From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 15:15:30 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D6371065679 for ; Thu, 23 Feb 2012 15:15:30 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 20FA98FC1C for ; Thu, 23 Feb 2012 15:15:29 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S0aOG-00020d-Ho for freebsd-net@freebsd.org; Thu, 23 Feb 2012 16:15:28 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Feb 2012 16:15:28 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Feb 2012 16:15:28 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 23 Feb 2012 16:15:17 +0100 Lines: 47 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8EF65D37CDD7314FAF51F996" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: X-Enigmail-Version: 1.3.5 Cc: freebsd-stable@freebsd.org Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:15:30 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8EF65D37CDD7314FAF51F996 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 22/02/2012 20:56, Jack Vogel wrote: > Using igb and/or ixgbe on a reasonably powered server requires 1K mbuf > clusters per MSIX vector, > that's how many are in a ring. Either driver will configure 8 queues on= a > system with that many or more > cores, so 8K clusters per port... >=20 > My test engineer has a system with 2 igb ports, and 2 10G ixgbe, this i= s > hardly heavy duty, and yet this > exceeds the default mbuf pool on the installed kernel (1024 + maxusers = * > 64). >=20 > Now, this can be immediately fixed by a sysadmin after that first boot,= but > it does result in the second > driver that gets started to complain about inadequate buffers. Does the driver complain loudly enough and does it print out what value it needs? I think that, second to removing the limit somehow, the best option is that the boot process should print out what the manual configuration should be, and possibly why should it be like that. --------------enig8EF65D37CDD7314FAF51F996 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9GWAUACgkQldnAQVacBciLDwCfbvHhAZkIR4jhcXcTJsTuVrWx n8UAn0tEUI3BXCqIBwQ0ZiQ1q2qKHdOu =a5Lz -----END PGP SIGNATURE----- --------------enig8EF65D37CDD7314FAF51F996-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 15:20:05 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0EA3C106566B for ; Thu, 23 Feb 2012 15:20:05 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id AA7F38FC14 for ; Thu, 23 Feb 2012 15:20:04 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S0aSh-00067w-NV for freebsd-net@freebsd.org; Thu, 23 Feb 2012 16:20:03 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Feb 2012 16:20:03 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 23 Feb 2012 16:20:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Date: Thu, 23 Feb 2012 16:19:12 +0100 Lines: 36 Message-ID: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9EFFE8653DC66D2067705633" X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120213 Thunderbird/10.0 In-Reply-To: <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> X-Enigmail-Version: 1.3.5 Cc: freebsd-stable@freebsd.org Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 15:20:05 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9EFFE8653DC66D2067705633 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 23/02/2012 09:19, Fabien Thomas wrote: > I think this is more reasonable to setup interface with one queue. Unfortunately, the moment you do that, two things will happen: 1) users will start complaining again how FreeBSD is slow 2) the setting will be come a "sacred cow" and nobody will change this default for the next 10 years. If it really comes down to enabling only one queue, something needs to complain extremely loudly that this isn't an optimal setting. Only printing it out at boot may not be enough - what's needed is possibly a script in periodic/daily which checks "system sanity" every day and e-mails the operator. --------------enig9EFFE8653DC66D2067705633 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9GWPAACgkQldnAQVacBch8MwCeJ2ae+iyi0z5b7a0BwyHH7fS+ S6UAoJQ4qclF6egfL2K5OU/HOzu4YB4R =pQF+ -----END PGP SIGNATURE----- --------------enig9EFFE8653DC66D2067705633-- From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 16:03:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1CE91065670 for ; Thu, 23 Feb 2012 16:03:23 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 581368FC20 for ; Thu, 23 Feb 2012 16:03:22 +0000 (UTC) Received: by wibhn14 with SMTP id hn14so1315721wib.13 for ; Thu, 23 Feb 2012 08:03:22 -0800 (PST) Received: by 10.180.101.37 with SMTP id fd5mr3996239wib.1.1330013002223; Thu, 23 Feb 2012 08:03:22 -0800 (PST) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.209.78 with HTTP; Thu, 23 Feb 2012 08:03:02 -0800 (PST) In-Reply-To: References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> <134564BB-676B-49BB-8BDA-6B8EB8965969@netasq.com> From: Juli Mallett Date: Thu, 23 Feb 2012 08:03:02 -0800 X-Google-Sender-Auth: Y1jA9RtMAKTklj7ACtaB2RdWag8 Message-ID: To: Ivan Voras Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQkA0ifCt7urr0/Ytd90iacKzkEhmSwQDxOgHD67NFvepTXoHvHjvHtjjLrXPJ4wixZeUe3S Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:03:24 -0000 On Thu, Feb 23, 2012 at 07:19, Ivan Voras wrote: > On 23/02/2012 09:19, Fabien Thomas wrote: >> I think this is more reasonable to setup interface with one queue. > > Unfortunately, the moment you do that, two things will happen: > 1) users will start complaining again how FreeBSD is slow > 2) the setting will be come a "sacred cow" and nobody will change this > default for the next 10 years. Is this any better than making queue-per-core a sacred cow? Even very small systems with comparatively-low memory these days have an increasing number of cores. They also usually have more RAM to go with those cores, but not always. Queue-per-core isn't even optimal for some kinds of workloads, and is harmful to overall performance at higher levels. It also assumes that every core should be utilized for the exciting task of receiving packets. This makes sense on some systems, but not all. Plus more queues doesn't necessarily equal better performance even on systems where you have the memory and cores to spare. On systems with non-uniform memory architectures, routinely processing queues on different physical packages can make networking performance worse. More queues is not a magic wand, it can be roughly the equivalent of go-faster stripes. Queue-per-core has a sort of logic to it, but is not necessarily sensible, like the funroll-all-loops school of system optimization. Which sounds slightly off-topic, except that dedicating loads of mbufs to receive queues that will sit empty on the vast majority of systems and receive a few packets per second in the service of some kind of magical thinking or excitement about multiqueue reception may be a little ill-advised. On my desktop with hardware supporting multiple queues, do I really want to use the maximum number of them just to handle a few thousand packets per second? One core can do that just fine. FreeBSD's great to drop-in on forwarding systems that will have moderate load, but it seems the best justification for this default is so users need fewer reboots to get more queues to spread what is assumed to be an evenly-distributed load over other cores. In practice, isn't the real problem that we have no facility for changing the number of queues at runtime? If the number of queues weren't fixed at boot, users could actually find the number that suits them best with a plausible amount of work, and the point about FreeBSD being "slow" goes away since it's perhaps one more sysctl to set (or one per-interface) or one (or one-per) ifconfig line to run, along with enabling forwarding, etc. The big commitment that multi-queue drivers ask for when they use the maximum number of queues on boot and then demand to fill those queues up with mbufs is unreasonable, even if it can be met on a growing number of systems without much in the way of pain. It's unreasonable, but perhaps it feels good to see all those interrupts bouncing around, all those threads running from time to time in top. Maybe it makes FreeBSD seem more serious, or perhaps it's something that gets people excited. It gives the appearance of doing quite a bit behind the scenes, and perhaps that's beneficial in and of itself, and will keep users from imagining that FreeBSD is slow, to your point. We should be clear, though, whether we are motivated by technical or psychological constraints and benefits. Thanks, Juli. From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 16:13:37 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D2E31065674 for ; Thu, 23 Feb 2012 16:13:37 +0000 (UTC) (envelope-from jpaetzel@freebsd.org) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mx1.freebsd.org (Postfix) with ESMTP id 2DEE18FC1E for ; Thu, 23 Feb 2012 16:13:36 +0000 (UTC) Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 01471210F5 for ; Thu, 23 Feb 2012 10:58:00 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute4.internal (MEProxy); Thu, 23 Feb 2012 10:58:00 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=tFkUZ/ElGuDGrBOZqjoavv 40lsY=; b=DY3oQHs1Cbn4WXkbPATbEl77PlStQWD/qVbZvRL/fUHXmxsnPCszlD QukJqoY0fo5t43cVAyyzZgS/UGbOTMmnbS7i2/wzF68aay9kZnMY3WQBgHmT7BmR oliZraaYxKtaXLjAPIdzGsufDH3Zt6EzsKxfe6IhwqtIsBlLEAOgA= X-Sasl-enc: NgZYrRyPr9ZafP2kPqzyYYMZBtlcYUpodeM+AECAKSBE 1330012680 Received: from roadrash.tcbug.org (drawbridge.ixsystems.com [206.40.55.65]) by mail.messagingengine.com (Postfix) with ESMTPSA id C56DE8E0096; Thu, 23 Feb 2012 10:57:59 -0500 (EST) Message-ID: <4F466206.2000100@freebsd.org> Date: Thu, 23 Feb 2012 07:57:58 -0800 From: Josh Paetzel Organization: FreeBSS User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120209 Thunderbird/10.0 MIME-Version: 1.0 To: Jack Vogel References: <20120222205231.GA81949@onelab2.iet.unipi.it> <1329944986.2621.46.camel@bwh-desktop> <20120222214433.GA82582@onelab2.iet.unipi.it> In-Reply-To: X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Ben Hutchings , FreeBSD Net , Luigi Rizzo , re , FreeBSD stable Subject: Re: nmbclusters: how do we want to fix this for 8.3 ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:13:37 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/22/2012 13:51, Jack Vogel wrote: > > > On Wed, Feb 22, 2012 at 1:44 PM, Luigi Rizzo > wrote: > > On Wed, Feb 22, 2012 at 09:09:46PM +0000, Ben Hutchings wrote: >> On Wed, 2012-02-22 at 21:52 +0100, Luigi Rizzo wrote: > ... >>> I have hit this problem recently, too. Maybe the issue >>> mostly/only exists on 32-bit systems. >> >> No, we kept hitting mbuf pool limits on 64-bit systems when we >> started working on FreeBSD support. > > ok never mind then, the mechanism would be the same, though the > limits (especially VM_LIMIT) would be different. > >>> Here is a possible approach: >>> >>> 1. nmbclusters consume the kernel virtual address space so >>> there must be some upper limit, say >>> >>> VM_LIMIT = 256000 (translates to 512MB of address space) >>> >>> 2. also you don't want the clusters to take up too much of the > available >>> memory. This one would only trigger for minimal-memory >>> systems, or virtual machines, but still... >>> >>> MEM_LIMIT = (physical_ram / 2) / 2048 >>> >>> 3. one may try to set a suitably large, desirable number of >>> buffers >>> >>> TARGET_CLUSTERS = 128000 >>> >>> 4. and finally we could use the current default as the >>> absolute > minimum >>> >>> MIN_CLUSTERS = 1024 + maxusers*64 >>> >>> Then at boot the system could say >>> >>> nmbclusters = min(TARGET_CLUSTERS, VM_LIMIT, MEM_LIMIT) >>> >>> nmbclusters = max(nmbclusters, MIN_CLUSTERS) >>> >>> >>> In turn, i believe interfaces should do their part and by >>> default never try to allocate more than a fraction of the total >>> number of buffers, >> >> Well what fraction should that be? It surely depends on how >> many interfaces are in the system and how many queues the other >> interfaces have. > >>> if necessary reducing the number of active queues. >> >> So now I have too few queues on my interface even after I >> increase the limit. >> >> There ought to be a standard way to configure numbers of queues >> and default queue lengths. > > Jack raised the problem that there is a poorly chosen default for > nmbclusters, causing one interface to consume all the buffers. If > the user explicitly overrides the value then the number of cluster > should be what the user asks (memory permitting). The next step is > on devices: if there are no overrides, the default for a driver is > to be lean. I would say that topping the request between 1/4 and > 1/8 of the total buffers is surely better than the current > situation. Of course if there is an explicit override, then use it > whatever happens to the others. > > cheers luigi > > > Hmmm, well, I could make the default use only 1 queue or something > like that, was thinking more of what actual users of the hardware > would want. > > After the installed kernel is booted and the admin would do > whatever post install modifications they wish it could be changed, > along with nmbclusters. > > This was why i sought opinions, of the algorithm itself, but also > anyone using ixgbe and igb in heavy use, what would you find most > convenient? > > Jack > The default setting is a thorn in our (with my ixsystems servers for freebsd hat on) side. A system with a quad port igb card and two onboard igb NICs won't boot stable/8 or 8.x-R to multiuser. Ditto for a dual port chelsio or ixgbe alongside dual onboard igb interfaces. My vote would be having systems over some minimum threshold of system ram to come up with a higher default for nmbclusters. You don't see too many 10gbe NICs in systems with 2GB of RAM.... - -- Thanks, Josh Paetzel FreeBSD -- The power to serve -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPRmIGAAoJEKFq1/n1feG229gIAIciDDKnc/K6/dgBA2YFGuuV V9cYD6+Zm4bVT9nvFhxJCUj+3CTGQFvNwi2sQx6pVMUWQC7Cpb323CShc8BBNjV3 vCzTmvqVshO+LWhx6J8lq4rqTU+PIKajF3GnwIWt4xmZ6WhrjCUySORYSAINQjKr iXJg/HBA7z/tsPUqOvzU0esZ4moUECapoldEOe0EF2jidARuM4q6MD1+QLMs+JSO JUS5yMPV022NVYS79NsUfvJ1cuwd6/I7CPvsJsW0E+zMMF2BjKZesU89zyFDST80 0WptoEqR9cuyApwu0OfDDzKyL7Z6G9yaAr0zkCAHATxkK0KArMJP/j2eT5uzZkE= =b44v -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 16:28:50 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E6DB61065672; Thu, 23 Feb 2012 16:28:50 +0000 (UTC) (envelope-from remko@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BA5028FC0A; Thu, 23 Feb 2012 16:28:50 +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 q1NGSoO6005181; Thu, 23 Feb 2012 16:28:50 GMT (envelope-from remko@freefall.freebsd.org) Received: (from remko@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1NGSoRu005177; Thu, 23 Feb 2012 16:28:50 GMT (envelope-from remko) Date: Thu, 23 Feb 2012 16:28:50 GMT Message-Id: <201202231628.q1NGSoRu005177@freefall.freebsd.org> To: remko@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: remko@FreeBSD.org Cc: Subject: Re: bin/165413: [netgraph]: ngctl(8) does not work as advertised X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:28:51 -0000 Old Synopsis: ngctl(8) does not work as advertised New Synopsis: [netgraph]: ngctl(8) does not work as advertised Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: remko Responsible-Changed-When: Thu Feb 23 16:28:37 UTC 2012 Responsible-Changed-Why: Reassign to -net team. http://www.freebsd.org/cgi/query-pr.cgi?pr=165413 From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 16:51:24 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE54F1065672 for ; Thu, 23 Feb 2012 16:51:24 +0000 (UTC) (envelope-from rozhuk.im@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 744E38FC18 for ; Thu, 23 Feb 2012 16:51:24 +0000 (UTC) Received: by werm13 with SMTP id m13so1356652wer.13 for ; Thu, 23 Feb 2012 08:51:23 -0800 (PST) Received-SPF: pass (google.com: domain of rozhuk.im@gmail.com designates 10.180.107.67 as permitted sender) client-ip=10.180.107.67; Authentication-Results: mr.google.com; spf=pass (google.com: domain of rozhuk.im@gmail.com designates 10.180.107.67 as permitted sender) smtp.mail=rozhuk.im@gmail.com; dkim=pass header.i=rozhuk.im@gmail.com Received: from mr.google.com ([10.180.107.67]) by 10.180.107.67 with SMTP id ha3mr5148953wib.8.1330015883620 (num_hops = 1); Thu, 23 Feb 2012 08:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:content-language :thread-index; bh=NipKJ/4OFVWePU5WNzM4YKXeJXJcwT83EMDxFSu5Mno=; b=hutunTM7yrHhDlpA3sMsJ53wDB6ayrbVeIxJuZBgobOStkt+DmUubbqGJbSCqA/k+5 GgQR/lmt2Dj4FL7r4NFCJbeEQIy9MBALn8dvcAaFMUtPe+XQrD33STYQ4WYcBlNDSP98 oKcjaUHM4PXL+X3ymfjZtOrHSlMdC4YpR5XAM= Received: by 10.180.107.67 with SMTP id ha3mr4193618wib.8.1330015883578; Thu, 23 Feb 2012 08:51:23 -0800 (PST) Received: from rimwks1w7x64 ([164.215.91.160]) by mx.google.com with ESMTPS id dr5sm9023645wib.0.2012.02.23.08.51.20 (version=SSLv3 cipher=OTHER); Thu, 23 Feb 2012 08:51:21 -0800 (PST) From: rozhuk.im@gmail.com To: Date: Fri, 24 Feb 2012 01:51:15 +0900 Message-ID: <4f466e89.6560b40a.499a.ffffe838@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-Language: ru Thread-Index: AczyS1rtoIKM2+klS3Wa03whgBD4dQ== Cc: Subject: ipfw and DSCP / ECN X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 16:51:25 -0000 Hi! "ip_tos" (ipv4) and "Traffic Class" (ipv6) field in the header of ip packet may contain a DSCP and ECN. "iptos" and "ipprecedence" options in ipfw does not allow to use these fields in the header of packets. May want to add two additional options for working with them in the ipv4 and ipv6 packets: - ipecn: values IPTOS_ECN_NOTECT, IPTOS_ECN_ECT1, IPTOS_ECN_ECT0, IPTOS_ECN_CE (defined in ip.h) - ipdscp: number from 0 to 0x3f I want to hear your opinions about this. Also, the header ipv6 may be more convenient as: struct ip6_hdr { union { struct ip6_hdrctl { u_int32_t ip6_un1_flow; /* 20 bits of flow-ID */ u_int16_t ip6_un1_plen; /* payload length */ u_int8_t ip6_un1_nxt; /* next header */ u_int8_t ip6_un1_hlim; /* hop limit */ } ip6_un1; u_int8_t ip6_un2_vfc; /* 4 bits version, top 4 bits class */ struct ip6_hdrctl2 { u_int32_t ip6_un3_vers:4; /* 4 bits version */ u_int32_t ip6_un3_class:8;/* 8 bits class */ u_int32_t ip6_un3_flow:20;/* 20 bits of flow-ID */ u_int16_t ip6_un3_plen; /* payload length */ u_int8_t ip6_un3_nxt; /* next header */ u_int8_t ip6_un3_hlim; /* hop limit */ } ip6_un3; } ip6_ctlun; struct in6_addr ip6_src; /* source address */ struct in6_addr ip6_dst; /* destination address */ } __packed; PS: http://tools.ietf.org/html/rfc2474#section-3 "A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]." For a full history of the TOS field, see: http://tools.ietf.org/html/rfc3168#section-22 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | DSCP | ECN | RFCs 2474, +-----+-----+-----+-----+-----+-----+-----+-----+ 2780 From owner-freebsd-net@FreeBSD.ORG Thu Feb 23 18:23:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2C5401065679; Thu, 23 Feb 2012 18:23:50 +0000 (UTC) (envelope-from seanbru@yahoo-inc.com) Received: from mrout1-b.corp.bf1.yahoo.com (mrout1-b.corp.bf1.yahoo.com [98.139.253.104]) by mx1.freebsd.org (Postfix) with ESMTP id D4DD68FC0C; Thu, 23 Feb 2012 18:23:48 +0000 (UTC) Received: from [IPv6:::1] (rideseveral.corp.yahoo.com [10.73.160.231]) by mrout1-b.corp.bf1.yahoo.com (8.14.4/8.14.4/y.out) with ESMTP id q1NINNVE018798; Thu, 23 Feb 2012 10:23:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yahoo-inc.com; s=cobra; t=1330021404; bh=/Zr4Vg75EVt9qV0jEBtbC+fXruciB/5PkWcS3MfIVII=; h=Subject:From:To:Cc:In-Reply-To:References:Content-Type:Date: Message-ID:Mime-Version:Content-Transfer-Encoding; b=MytfW5OXovoXzMwt1k3vvPR7daHlqnezJ8pWqWNyHmQX5gU+qDje5+7Ir6yKa6Rw4 fPX/6/GnhhhADOlwuygS0Ijnh5/r9CcZYuZf68N53xbEIo2kX0LbE3NroPOYV13I98 3GgqA6qrfPTwZOvJYy8PA0uM5uM2IgIV4FXjVYFo= From: Sean Bruno To: "pyunyh@gmail.com" In-Reply-To: <20120223213344.GC13815@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> <20120223213344.GC13815@michelle.cdnetworks.com> Content-Type: text/plain; charset="UTF-8" Date: Thu, 23 Feb 2012 10:23:23 -0800 Message-ID: <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 18:23:50 -0000 > As you see ukphy(4) was attached to bge2 so it may cause various > issues. > Is bge2 ASF/IPMI enabled interface? It seems ASF handling in > bge(4) causes more trouble on recent controllers. Unfortunately > disabling ASF may also trigger other problems like NMI. > I believe bge(4) should always honor ASF/IMPI firmware instead of > relying on hw.bge.allow_asf tunable and have to strictly follow > firmware handshake sequence. Just ignoring ASF/IMPI firmware seems > to confuse firmware. > Unfortunately all these information is undocumented and fixing it > requires real hardware access. ASF/IPMI -- I've tried disabling things, but it just fails miserably. I can at least get the host to a login via serial console and poke at things. Do you want me to rig up a test for you on this box? I suspect I can do something temporarily in the freebsd cluster with this box. Sean From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 00:29:20 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 444D3106567D for ; Fri, 24 Feb 2012 00:29:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-197-151.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 5829D16387F for ; Fri, 24 Feb 2012 00:29:07 +0000 (UTC) Message-ID: <4F46D9D2.4060802@FreeBSD.org> Date: Thu, 23 Feb 2012 16:29:06 -0800 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:10.0.2) Gecko/20120218 Thunderbird/10.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4F4548A2.60409@si6networks.com> In-Reply-To: <4F4548A2.60409@si6networks.com> X-Enigmail-Version: 1.3.5 OpenPGP: id=1A1ABC84 X-Forwarded-Message-Id: <4F4548A2.60409@si6networks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Fwd: IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 00:29:20 -0000 Looks like we are making progress here, but are not quite there yet. -------- Original Message -------- Subject: IPv6 NIDS evasion and IPv6 fragmentation/reassembly improvements Date: Wed, 22 Feb 2012 16:57:22 -0300 From: Fernando Gont Organization: SI6 Networks To: ipv6-ops@lists.cluenet.de Folks, FYI, just posted: It contains some test results regarding the implementation of RFC 5722 and draft-ietf-6man-ipv6-atomic-fragments. Thanks, From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 01:07:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AEFE0106566C; Fri, 24 Feb 2012 01:07:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pz0-f54.google.com (mail-pz0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 7BBD88FC16; Fri, 24 Feb 2012 01:07:00 +0000 (UTC) Received: by daec6 with SMTP id c6so2069546dae.13 for ; Thu, 23 Feb 2012 17:07:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=5Db2KrAr5uVt1mTgeeDDcMXKH2cXuQvShRsQVProa6I=; b=kXxtxpQzNzlW/5oNBYAfUBV643gbtUS8dkOke66jZFPakyBxhuGgH2/exp8TYgcQ1V e4jSOqi0duWrvGqdS7m0n8djk+gKFADsEBjp5XHSS9qUeBZCSrolQk8N+wDeG51KDOBS 3c8CpQR7gGc2Hm4CqctUu8ktnoY98SL9BWaDY= Received: by 10.68.212.3 with SMTP id ng3mr805325pbc.135.1330045620106; Thu, 23 Feb 2012 17:07:00 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id x3sm2861512pbg.35.2012.02.23.17.06.57 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 23 Feb 2012 17:06:59 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 24 Feb 2012 10:06:53 -0800 From: YongHyeon PYUN Date: Fri, 24 Feb 2012 10:06:53 -0800 To: Sean Bruno Message-ID: <20120224180653.GA18456@michelle.cdnetworks.com> References: <1329958728.78750.6.camel@powernoodle-l7.corp.yahoo.com> <20120223213344.GC13815@michelle.cdnetworks.com> <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1330021403.3443.11.camel@powernoodle-l7.corp.yahoo.com> User-Agent: Mutt/1.4.2.3i Cc: "freebsd-net@freebsd.org" Subject: Re: bge(4) failure, Dell 12G hardware, BCM5720C X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:07:00 -0000 On Thu, Feb 23, 2012 at 10:23:23AM -0800, Sean Bruno wrote: > > > As you see ukphy(4) was attached to bge2 so it may cause various > > issues. > > Is bge2 ASF/IPMI enabled interface? It seems ASF handling in > > bge(4) causes more trouble on recent controllers. Unfortunately > > disabling ASF may also trigger other problems like NMI. > > I believe bge(4) should always honor ASF/IMPI firmware instead of > > relying on hw.bge.allow_asf tunable and have to strictly follow > > firmware handshake sequence. Just ignoring ASF/IMPI firmware seems > > to confuse firmware. > > Unfortunately all these information is undocumented and fixing it > > requires real hardware access. > > ASF/IPMI -- I've tried disabling things, but it just fails miserably. I > can at least get the host to a login via serial console and poke at > things. > > Do you want me to rig up a test for you on this box? I suspect I can do > something temporarily in the freebsd cluster with this box. > Hmm, I still have to understand what is correct handshake sequence for ASF/IPMI firmware. This handshake may be related with suspend/ resume as well as WOL. I'll let you know when I have experimental patch. > Sean > From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 03:56:45 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9912106566C for ; Fri, 24 Feb 2012 03:56:45 +0000 (UTC) (envelope-from atmotaruno@gmail.com) Received: from mail-vx0-f182.google.com (mail-vx0-f182.google.com [209.85.220.182]) by mx1.freebsd.org (Postfix) with ESMTP id 9F4228FC08 for ; Fri, 24 Feb 2012 03:56:45 +0000 (UTC) Received: by vcmm1 with SMTP id m1so1908678vcm.13 for ; Thu, 23 Feb 2012 19:56:45 -0800 (PST) Received-SPF: pass (google.com: domain of atmotaruno@gmail.com designates 10.220.108.138 as permitted sender) client-ip=10.220.108.138; Authentication-Results: mr.google.com; spf=pass (google.com: domain of atmotaruno@gmail.com designates 10.220.108.138 as permitted sender) smtp.mail=atmotaruno@gmail.com; dkim=pass header.i=atmotaruno@gmail.com Received: from mr.google.com ([10.220.108.138]) by 10.220.108.138 with SMTP id f10mr342830vcp.16.1330055804846 (num_hops = 1); Thu, 23 Feb 2012 19:56:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=ePAF1Z7dOv67ZB8uHxeLo9xTAtLyuj7xB/CueHrF+10=; b=Lbnf/ppxBVKRIP++hFsSuWkbiFiIAwAr5xFk+uIu8UOj5Yzr5cAjdP+ugzEOZKThgb ojdOUe4Xsiod97pxx1cuBTvKnJDgEXiT/uUDnIUPcOSbTMNzQ2WJMt1HdFGFK8qLlHz6 Hyz6ABr71uWe+xW0a8tybwhWsO49VU+js0ou4= MIME-Version: 1.0 Received: by 10.220.108.138 with SMTP id f10mr282771vcp.16.1330055804171; Thu, 23 Feb 2012 19:56:44 -0800 (PST) Received: by 10.52.65.110 with HTTP; Thu, 23 Feb 2012 19:56:44 -0800 (PST) In-Reply-To: References: <20120224044000.GF13815@michelle.cdnetworks.com> Date: Fri, 24 Feb 2012 10:56:44 +0700 Message-ID: From: Nugroho Atmotaruno To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 03:56:46 -0000 On Thu, Feb 23, 2012 at 9:09 PM, Nugroho Atmotaruno wrote: > On Fri, Feb 24, 2012 at 11:40 AM, YongHyeon PYUN wrote= : >> On Thu, Feb 23, 2012 at 04:57:27AM +0700, Nugroho Atmotaruno wrote: >>> Hi all, >>> >>> I'm using FBSD 9.0-RELEASE with TPLink TG-3268 (rl8169) flapping >>> (UP/DOWN every several seconds). >>> >>> [nugroho@xtreme ~]$ uname -a >>> FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue >>> Jan?? 3 07:46:30 UTC 2012 >>> root@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC?? amd64 >>> >>> [root@xtreme ~]# tail /var/log/messages >>> Feb 23 04:47:05 xtreme kernel: re0: link state changed to UP >>> Feb 23 04:47:07 xtreme kernel: re0: link state changed to DOWN >>> Feb 23 04:47:10 xtreme kernel: re0: link state changed to UP >>> Feb 23 04:47:16 xtreme kernel: re0: link state changed to DOWN >>> Feb 23 04:47:19 xtreme kernel: re0: link state changed to UP >>> Feb 23 04:47:20 xtreme kernel: re0: link state changed to DOWN >>> Feb 23 04:47:23 xtreme kernel: re0: link state changed to UP >>> Feb 23 04:48:44 xtreme kernel: re0: link state changed to DOWN >>> Feb 23 04:48:47 xtreme kernel: re0: link state changed to UP >>> >>> >>> [root@xtreme ~]# pciconf -lcv >>> re0@pci0:2:5:0: class=3D0x020000 card=3D0x816910ec chip=3D0x816910ec re= v=3D0x10 hdr=3D0x00 >>> =C2=A0 =C2=A0 vendor =C2=A0 =C2=A0 =3D 'Realtek Semiconductor Co., Ltd.= ' >>> =C2=A0 =C2=A0 device =C2=A0 =C2=A0 =3D 'RTL-8169 Gigabit Ethernet' >>> =C2=A0 =C2=A0 class =C2=A0 =C2=A0 =C2=A0=3D network >>> =C2=A0 =C2=A0 subclass =C2=A0 =3D ethernet >>> =C2=A0 =C2=A0 cap 01[dc] =3D powerspec 2 =C2=A0supports D0 D1 D2 D3 =C2= =A0current D0 >>> >>> [root@xtreme ~]# devinfo -rv | grep rg >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 rgephy0 pnpinfo= oui=3D0xe04c model=3D0x11 rev=3D0x3 at phyno=3D1 >>> >>> [root@xtreme ~]# ifconfig re0 >>> re0: flags=3D8843 metric 0 mtu = 1500 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 options=3D389b >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 ether f8:d1:11:04:15:d6 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet 167.205.3.4 netmask 0xffffff80 broadca= st 167.205.3.127 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 fe80::fad1:11ff:fe04:15d6%re0 prefixl= en 64 scopeid 0x7 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 inet6 2403:8000:1:1880::4 prefixlen 64 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 nd6 options=3D21 >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 media: Ethernet autoselect (1000baseT ) >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 status: active >>> >> >> Would you try attached patch? > > Thanks for your reply, I'll try it tomorrow. > Hi Pyun, I patched my machine last night, but the problem is still there. [nugroho@xtreme ~]$ uname -a FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu Feb 23 21:44:02 WIT 2012 nugroho@xtreme.arc.itb.ac.id:/sys/amd64/compile/GENERIC amd64 [nugroho@xtreme ~]$ tail /var/log/messages Feb 24 10:42:49 xtreme kernel: re0: link state changed to DOWN Feb 24 10:42:52 xtreme kernel: re0: link state changed to UP Feb 24 10:42:53 xtreme kernel: re0: link state changed to DOWN Feb 24 10:42:55 xtreme kernel: re0: link state changed to UP Feb 24 10:42:56 xtreme kernel: re0: link state changed to DOWN Feb 24 10:43:02 xtreme kernel: re0: link state changed to UP Feb 24 10:43:03 xtreme kernel: re0: link state changed to DOWN Feb 24 10:43:06 xtreme kernel: re0: link state changed to UP Feb 24 10:49:16 xtreme kernel: re0: link state changed to DOWN Feb 24 10:49:19 xtreme kernel: re0: link state changed to UP --=20 Regards, Nugroho From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 13:04:25 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E0D62106566B for ; Fri, 24 Feb 2012 13:04:25 +0000 (UTC) (envelope-from atmotaruno@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 88B768FC17 for ; Fri, 24 Feb 2012 13:04:25 +0000 (UTC) Received: by vbbfa15 with SMTP id fa15so2203964vbb.13 for ; Fri, 24 Feb 2012 05:04:24 -0800 (PST) Received-SPF: pass (google.com: domain of atmotaruno@gmail.com designates 10.220.153.10 as permitted sender) client-ip=10.220.153.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of atmotaruno@gmail.com designates 10.220.153.10 as permitted sender) smtp.mail=atmotaruno@gmail.com; dkim=pass header.i=atmotaruno@gmail.com Received: from mr.google.com ([10.220.153.10]) by 10.220.153.10 with SMTP id i10mr1302294vcw.46.1330088664915 (num_hops = 1); Fri, 24 Feb 2012 05:04:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DQtvzGHpkR5xtTfu4g26FuUw4kfAOYNfzdqvk3kPvbI=; b=PKqsHkIg+5O1cYMa49fEjqGzxCnHSUgNDtHxwd4s6wu5+y0P9xn6RvxaICL9Cvoa67 AcGMfy/pqu342ruFb9Inb0IeiwJxdcakY/MwlOQX3UCByAie80fJMZD45ylk047LM4ZB pH51DA0MI6+Qwq0c2WYh4l/mTk279PYEUTntQ= MIME-Version: 1.0 Received: by 10.220.153.10 with SMTP id i10mr1012977vcw.46.1330088664501; Fri, 24 Feb 2012 05:04:24 -0800 (PST) Received: by 10.52.65.110 with HTTP; Fri, 24 Feb 2012 05:04:24 -0800 (PST) In-Reply-To: References: <20120224044000.GF13815@michelle.cdnetworks.com> Date: Fri, 24 Feb 2012 20:04:24 +0700 Message-ID: From: Nugroho Atmotaruno To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:04:26 -0000 On Fri, Feb 24, 2012 at 10:56 AM, Nugroho Atmotaruno wrote: > > Hi Pyun, > > I patched my machine last night, but the problem is still there. > > [nugroho@xtreme ~]$ uname -a > FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu > Feb 23 21:44:02 WIT 2012 > nugroho@xtreme.arc.itb.ac.id:/sys/amd64/compile/GENERIC =C2=A0amd64 > > [nugroho@xtreme ~]$ tail /var/log/messages > Feb 24 10:42:49 xtreme kernel: re0: link state changed to DOWN > Feb 24 10:42:52 xtreme kernel: re0: link state changed to UP > Feb 24 10:42:53 xtreme kernel: re0: link state changed to DOWN > Feb 24 10:42:55 xtreme kernel: re0: link state changed to UP > Feb 24 10:42:56 xtreme kernel: re0: link state changed to DOWN > Feb 24 10:43:02 xtreme kernel: re0: link state changed to UP > Feb 24 10:43:03 xtreme kernel: re0: link state changed to DOWN > Feb 24 10:43:06 xtreme kernel: re0: link state changed to UP > Feb 24 10:49:16 xtreme kernel: re0: link state changed to DOWN > Feb 24 10:49:19 xtreme kernel: re0: link state changed to UP > After repatching, and recompiling my kernel, i got kernel panic. I don't know why but I didn't get kernel crash dump. I took a screenshot here[1]. [1] http://i.imgur.com/8NIwS.jpg --=20 Regards, Nugroho From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 17:14:08 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E39B2106564A; Fri, 24 Feb 2012 17:14:08 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 496A58FC0C; Fri, 24 Feb 2012 17:14:08 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1OHE4W6084081; Sat, 25 Feb 2012 00:14:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F47C55C.8060006@rdtc.ru> Date: Sat, 25 Feb 2012 00:14:04 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" , Alexander Motin , Gleb Smirnoff Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: netisr+lagg+fragments=80% packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 17:14:09 -0000 Hi! I've found that my PPPoE BRAS server gives 80% packet loss for fragmented pings against itself while no packet loss for transit fragmented pings same time. The problem vanishes if I do ONE of following: 1) disable indirect netisr mode, e.g. set back sysctl net.isr.direct=1 AND net.isr.direct_force=1 (net.isr.direct=1 only is not enough to eliminate problem), OR 2) bring down one of two lagg ports, OR 3) decrease ping packets size so they stop get fragmented. More details. There is FreeBSD 8.2-STABLE/amd64 PPPoE server with mpd-5.5 and 4 NICs: em0 and em1 combined to lagg0 (LACP mode) having IP address that carries untagged IP packets; plus, igb0 and igb1 combined to lagg1 (againg, LACP mode) having no IP addresses - instead, there are about 1000 vlan interfaces built on top of lagg1. All vlan interfaces carry PPPoE traffic only. I use another FreeBSD 8.2-STABLE system as PPPoE client (again, mpd-5.5), it connects to BRAS just fine and sends/receives transit traffic just fine. It also pings BRAS with packets up to 1492 (MTU on ng0 interface). But, "ping -s 1472" (1500 bytes at IP layer) gives 80% drops. tcpdump -i ng0 shows that EVERY fragmented outgoing ICMP echo-request gets its echo-reply but only small part of replies get in order: fragment 0 first, fragment 1 next. Most of replies get back out of order: fragment 1 first, fragment 0 second. These produce no lines in ping's output and do increment 'fragments dropped after timeout' counter in "netstat -ss" ouput. However, tcpdump shows they are received at once, no significant delay. This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. And only when lagg1 has both ports up and running. And when I use oversized pings. At the same time, transit oversized pings go through this BRAS just fine, no packet loss at all. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 18:24:51 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DD269106564A; Fri, 24 Feb 2012 18:24:51 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 4276C8FC0C; Fri, 24 Feb 2012 18:24:50 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1OIOldD084415; Sat, 25 Feb 2012 01:24:48 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F47D5EF.7060908@rdtc.ru> Date: Sat, 25 Feb 2012 01:24:47 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "net@freebsd.org" , Alexander Motin , Gleb Smirnoff References: <4F47C55C.8060006@rdtc.ru> In-Reply-To: <4F47C55C.8060006@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Subject: Re: netisr+lagg+fragments=80% packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 18:24:52 -0000 25.02.2012 00:14, Eugene Grosbein пишет: > Hi! > > I've found that my PPPoE BRAS server gives 80% packet loss > for fragmented pings against itself while no packet loss for transit fragmented pings same time. > The problem vanishes if I do ONE of following: > > 1) disable indirect netisr mode, e.g. set back sysctl net.isr.direct=1 AND > net.isr.direct_force=1 (net.isr.direct=1 only is not enough to eliminate problem), OR > 2) bring down one of two lagg ports, OR > 3) decrease ping packets size so they stop get fragmented. > > More details. There is FreeBSD 8.2-STABLE/amd64 PPPoE server with mpd-5.5 > and 4 NICs: em0 and em1 combined to lagg0 (LACP mode) having IP address > that carries untagged IP packets; plus, igb0 and igb1 combined to lagg1 > (againg, LACP mode) having no IP addresses - instead, there are about 1000 > vlan interfaces built on top of lagg1. All vlan interfaces carry PPPoE traffic only. > > I use another FreeBSD 8.2-STABLE system as PPPoE client (again, mpd-5.5), > it connects to BRAS just fine and sends/receives transit traffic just fine. > It also pings BRAS with packets up to 1492 (MTU on ng0 interface). > But, "ping -s 1472" (1500 bytes at IP layer) gives 80% drops. > > tcpdump -i ng0 shows that EVERY fragmented outgoing ICMP echo-request > gets its echo-reply but only small part of replies get in order: > fragment 0 first, fragment 1 next. > > Most of replies get back out of order: fragment 1 first, fragment 0 second. > These produce no lines in ping's output and do increment > 'fragments dropped after timeout' counter in "netstat -ss" ouput. > However, tcpdump shows they are received at once, no significant delay. > > This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. > And only when lagg1 has both ports up and running. And when I use oversized pings. > At the same time, transit oversized pings go through this BRAS just fine, > no packet loss at all. Running two copies of tcpdump for igb0 and igb1 simultaneously, I see that fragments of the same ICMP echo-reply packet encapsulated within PPPoE frame always go out through different ports of lagg1. Even when they arrive to client in order, it seems this depends of switching network in between PPPoE server and client. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Fri Feb 24 19:28:45 2012 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8310E106566B for ; Fri, 24 Feb 2012 19:28:45 +0000 (UTC) (envelope-from andy@fud.org.nz) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D0438FC12 for ; Fri, 24 Feb 2012 19:28:44 +0000 (UTC) Received: by yhgm50 with SMTP id m50so215300yhg.13 for ; Fri, 24 Feb 2012 11:28:44 -0800 (PST) Received-SPF: pass (google.com: domain of andy@fud.org.nz designates 10.50.156.194 as permitted sender) client-ip=10.50.156.194; Authentication-Results: mr.google.com; spf=pass (google.com: domain of andy@fud.org.nz designates 10.50.156.194 as permitted sender) smtp.mail=andy@fud.org.nz Received: from mr.google.com ([10.50.156.194]) by 10.50.156.194 with SMTP id wg2mr5100584igb.18.1330111724214 (num_hops = 1); Fri, 24 Feb 2012 11:28:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.156.194 with SMTP id wg2mr3934075igb.18.1330110038949; Fri, 24 Feb 2012 11:00:38 -0800 (PST) Sender: andy@fud.org.nz Received: by 10.231.207.16 with HTTP; Fri, 24 Feb 2012 11:00:38 -0800 (PST) In-Reply-To: <4F47D5EF.7060908@rdtc.ru> References: <4F47C55C.8060006@rdtc.ru> <4F47D5EF.7060908@rdtc.ru> Date: Sat, 25 Feb 2012 08:00:38 +1300 X-Google-Sender-Auth: AZmkZTS4U8V97otjwYsslnDy9xg Message-ID: From: Andrew Thompson To: Eugene Grosbein Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkkmOG3c8H0OpTbIJsw9Hrc/UNh/4bS3nbeATK5nQ2hwopwcEM5liCfeC1O47MgwTMWUnJS Cc: Alexander Motin , "net@freebsd.org" Subject: Re: netisr+lagg+fragments=80% packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 19:28:45 -0000 2012/2/25 Eugene Grosbein : > 25.02.2012 00:14, Eugene Grosbein =D0=C9=DB=C5=D4: >> This problem occurs only when net.isr.direct=3D0/net.isr.direct_force=3D= 0. >> And only when lagg1 has both ports up and running. And when I use oversi= zed pings. >> At the same time, transit oversized pings go through this BRAS just fine= , >> no packet loss at all. > > Running two copies of tcpdump for igb0 and igb1 simultaneously, > I see that fragments of the same ICMP echo-reply packet encapsulated with= in PPPoE > frame always go out through different ports of lagg1. Even when they arri= ve to client in order, > it seems this depends of switching network in between PPPoE server and cl= ient. > If you are running a recent HEAD then you can try setting net.link.lagg.0.use_flowid to zero. Andrew From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 00:40:13 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0E808106566B for ; Sat, 25 Feb 2012 00:40:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F240D8FC0C for ; Sat, 25 Feb 2012 00:40:12 +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 q1P0eCWt036840 for ; Sat, 25 Feb 2012 00:40:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1P0eCaV036835; Sat, 25 Feb 2012 00:40:12 GMT (envelope-from gnats) Date: Sat, 25 Feb 2012 00:40:12 GMT Message-Id: <201202250040.q1P0eCaV036835@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165032: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:40:13 -0000 The following reply was made to PR kern/165032; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165032: commit references a PR Date: Sat, 25 Feb 2012 00:35:33 +0000 (UTC) Author: marius Date: Sat Feb 25 00:35:19 2012 New Revision: 232134 URL: http://svn.freebsd.org/changeset/base/232134 Log: MFC: r231913 - Probe BCM57780. - In case the parent is bge(4), don't set the Jumbo frame settings unless the MAC actually is Jumbo capable as otherwise the PHY might not have the corresponding registers implemented. This is also in line with what the Linux tg3 driver does. PR: 165032 Submitted by: Alexander Milanov Obtained from: OpenBSD Modified: stable/9/sys/dev/mii/brgphy.c stable/9/sys/dev/mii/miidevs Directory Properties: stable/9/sys/ (props changed) stable/9/sys/amd64/include/xen/ (props changed) stable/9/sys/boot/ (props changed) stable/9/sys/boot/i386/efi/ (props changed) stable/9/sys/boot/ia64/efi/ (props changed) stable/9/sys/boot/ia64/ski/ (props changed) stable/9/sys/boot/powerpc/boot1.chrp/ (props changed) stable/9/sys/boot/powerpc/ofw/ (props changed) stable/9/sys/cddl/contrib/opensolaris/ (props changed) stable/9/sys/conf/ (props changed) stable/9/sys/contrib/dev/acpica/ (props changed) stable/9/sys/contrib/octeon-sdk/ (props changed) stable/9/sys/contrib/pf/ (props changed) stable/9/sys/contrib/x86emu/ (props changed) stable/9/sys/i386/conf/XENHVM (props changed) Modified: stable/9/sys/dev/mii/brgphy.c ============================================================================== --- stable/9/sys/dev/mii/brgphy.c Sat Feb 25 00:16:00 2012 (r232133) +++ stable/9/sys/dev/mii/brgphy.c Sat Feb 25 00:35:19 2012 (r232134) @@ -146,6 +146,7 @@ static const struct mii_phydesc brgphys[ MII_PHY_DESC(BROADCOM3, BCM5719C), MII_PHY_DESC(BROADCOM3, BCM5720C), MII_PHY_DESC(BROADCOM3, BCM57765), + MII_PHY_DESC(BROADCOM3, BCM57780), MII_PHY_DESC(xxBROADCOM_ALT1, BCM5906), MII_PHY_END }; @@ -225,7 +226,8 @@ brgphy_attach(device_t dev) sc->mii_flags |= MIIF_HAVEFIBER; } break; - } break; + } + break; case MII_OUI_BROADCOM2: switch (sc->mii_mpd_model) { case MII_MODEL_BROADCOM2_BCM5708S: @@ -942,7 +944,8 @@ brgphy_reset(struct mii_softc *sc) if (bge_sc->bge_phy_flags & BGE_PHY_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if ((bge_sc->bge_phy_flags & BGE_PHY_NO_WIRESPEED) == 0) brgphy_ethernet_wirespeed(sc); Modified: stable/9/sys/dev/mii/miidevs ============================================================================== --- stable/9/sys/dev/mii/miidevs Sat Feb 25 00:16:00 2012 (r232133) +++ stable/9/sys/dev/mii/miidevs Sat Feb 25 00:35:19 2012 (r232134) @@ -179,6 +179,7 @@ model BROADCOM2 BCM5784 0x003a BCM5784 model BROADCOM2 BCM5709C 0x003c BCM5709 10/100/1000baseT PHY model BROADCOM2 BCM5761 0x003d BCM5761 10/100/1000baseT PHY model BROADCOM2 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY +model BROADCOM3 BCM57780 0x0019 BCM57780 1000BASE-T media interface model BROADCOM3 BCM5717C 0x0020 BCM5717C 1000BASE-T media interface model BROADCOM3 BCM5719C 0x0022 BCM5719C 1000BASE-T media interface model BROADCOM3 BCM57765 0x0024 BCM57765 1000BASE-T media interface _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 00:40:14 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD8D5106564A for ; Sat, 25 Feb 2012 00:40:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B2FB28FC13 for ; Sat, 25 Feb 2012 00:40:14 +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 q1P0eEiv036848 for ; Sat, 25 Feb 2012 00:40:14 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1P0eESf036847; Sat, 25 Feb 2012 00:40:14 GMT (envelope-from gnats) Date: Sat, 25 Feb 2012 00:40:14 GMT Message-Id: <201202250040.q1P0eESf036847@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165032: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:40:15 -0000 The following reply was made to PR kern/165032; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165032: commit references a PR Date: Sat, 25 Feb 2012 00:35:54 +0000 (UTC) Author: marius Date: Sat Feb 25 00:35:28 2012 New Revision: 232135 URL: http://svn.freebsd.org/changeset/base/232135 Log: MFC: r231913 - Probe BCM57780. - In case the parent is bge(4), don't set the Jumbo frame settings unless the MAC actually is Jumbo capable as otherwise the PHY might not have the corresponding registers implemented. This is also in line with what the Linux tg3 driver does. PR: 165032 Submitted by: Alexander Milanov Approved by: re (kib) Obtained from: OpenBSD Modified: stable/8/sys/dev/mii/brgphy.c stable/8/sys/dev/mii/miidevs Directory Properties: stable/8/sys/ (props changed) stable/8/sys/amd64/include/xen/ (props changed) stable/8/sys/boot/ (props changed) stable/8/sys/cddl/contrib/opensolaris/ (props changed) stable/8/sys/contrib/dev/acpica/ (props changed) stable/8/sys/contrib/pf/ (props changed) stable/8/sys/dev/e1000/ (props changed) Modified: stable/8/sys/dev/mii/brgphy.c ============================================================================== --- stable/8/sys/dev/mii/brgphy.c Sat Feb 25 00:35:19 2012 (r232134) +++ stable/8/sys/dev/mii/brgphy.c Sat Feb 25 00:35:28 2012 (r232135) @@ -145,6 +145,7 @@ static const struct mii_phydesc brgphys[ MII_PHY_DESC(xxBROADCOM_ALT2, BCM5719C), MII_PHY_DESC(xxBROADCOM_ALT2, BCM5720C), MII_PHY_DESC(xxBROADCOM_ALT2, BCM57765), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57780), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; @@ -242,7 +243,8 @@ brgphy_attach(device_t dev) sc->mii_flags |= MIIF_HAVEFIBER; } break; - } break; + } + break; case MII_OUI_xxBROADCOM_ALT1: switch (bsc->mii_model) { case MII_MODEL_xxBROADCOM_ALT1_BCM5708S: @@ -964,7 +966,8 @@ brgphy_reset(struct mii_softc *sc) if (bge_sc->bge_phy_flags & BGE_PHY_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if ((bge_sc->bge_phy_flags & BGE_PHY_NO_WIRESPEED) == 0) brgphy_ethernet_wirespeed(sc); Modified: stable/8/sys/dev/mii/miidevs ============================================================================== --- stable/8/sys/dev/mii/miidevs Sat Feb 25 00:35:19 2012 (r232134) +++ stable/8/sys/dev/mii/miidevs Sat Feb 25 00:35:28 2012 (r232135) @@ -157,6 +157,7 @@ model xxBROADCOM_ALT1 BCM5784 0x003a BCM model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY +model xxBROADCOM_ALT2 BCM57780 0x0019 BCM57780 1000BASE-T media interface model xxBROADCOM_ALT2 BCM5717C 0x0020 BCM5717C 10/100/1000baseTX PHY model xxBROADCOM_ALT2 BCM5719C 0x0022 BCM5719C 10/100/1000baseTX PHY model xxBROADCOM_ALT2 BCM57765 0x0024 BCM57765 10/100/1000baseTX PHY _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 00:40:16 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 83E7A1065675 for ; Sat, 25 Feb 2012 00:40:16 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 6984D8FC15 for ; Sat, 25 Feb 2012 00:40:16 +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 q1P0eGcU036853 for ; Sat, 25 Feb 2012 00:40:16 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1P0eGUR036852; Sat, 25 Feb 2012 00:40:16 GMT (envelope-from gnats) Date: Sat, 25 Feb 2012 00:40:16 GMT Message-Id: <201202250040.q1P0eGUR036852@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: dfilter@FreeBSD.ORG (dfilter service) Cc: Subject: Re: kern/165032: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dfilter service List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 00:40:16 -0000 The following reply was made to PR kern/165032; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/165032: commit references a PR Date: Sat, 25 Feb 2012 00:35:59 +0000 (UTC) Author: marius Date: Sat Feb 25 00:35:32 2012 New Revision: 232136 URL: http://svn.freebsd.org/changeset/base/232136 Log: MFC: r231913 - Probe BCM57780. - In case the parent is bge(4), don't set the Jumbo frame settings unless the MAC actually is Jumbo capable as otherwise the PHY might not have the corresponding registers implemented. This is also in line with what the Linux tg3 driver does. PR: 165032 Submitted by: Alexander Milanov Obtained from: OpenBSD Modified: stable/7/sys/dev/mii/brgphy.c stable/7/sys/dev/mii/miidevs Directory Properties: stable/7/sys/ (props changed) stable/7/sys/cddl/contrib/opensolaris/ (props changed) stable/7/sys/contrib/dev/acpica/ (props changed) stable/7/sys/contrib/pf/ (props changed) Modified: stable/7/sys/dev/mii/brgphy.c ============================================================================== --- stable/7/sys/dev/mii/brgphy.c Sat Feb 25 00:35:28 2012 (r232135) +++ stable/7/sys/dev/mii/brgphy.c Sat Feb 25 00:35:32 2012 (r232136) @@ -145,6 +145,7 @@ static const struct mii_phydesc brgphys[ MII_PHY_DESC(xxBROADCOM_ALT2, BCM5719C), MII_PHY_DESC(xxBROADCOM_ALT2, BCM5720C), MII_PHY_DESC(xxBROADCOM_ALT2, BCM57765), + MII_PHY_DESC(xxBROADCOM_ALT2, BCM57780), MII_PHY_DESC(BROADCOM2, BCM5906), MII_PHY_END }; @@ -242,7 +243,8 @@ brgphy_attach(device_t dev) sc->mii_flags |= MIIF_HAVEFIBER; } break; - } break; + } + break; case MII_OUI_xxBROADCOM_ALT1: switch (bsc->mii_model) { case MII_MODEL_xxBROADCOM_ALT1_BCM5708S: @@ -964,7 +966,8 @@ brgphy_reset(struct mii_softc *sc) if (bge_sc->bge_phy_flags & BGE_PHY_JITTER_BUG) brgphy_fixup_jitter_bug(sc); - brgphy_jumbo_settings(sc, ifp->if_mtu); + if (bge_sc->bge_flags & BGE_FLAG_JUMBO) + brgphy_jumbo_settings(sc, ifp->if_mtu); if ((bge_sc->bge_phy_flags & BGE_PHY_NO_WIRESPEED) == 0) brgphy_ethernet_wirespeed(sc); Modified: stable/7/sys/dev/mii/miidevs ============================================================================== --- stable/7/sys/dev/mii/miidevs Sat Feb 25 00:35:28 2012 (r232135) +++ stable/7/sys/dev/mii/miidevs Sat Feb 25 00:35:32 2012 (r232136) @@ -152,6 +152,7 @@ model xxBROADCOM_ALT1 BCM5784 0x003a BCM model xxBROADCOM_ALT1 BCM5709C 0x003c BCM5709C 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5761 0x003d BCM5761 10/100/1000baseTX PHY model xxBROADCOM_ALT1 BCM5709S 0x003f BCM5709S 1000/2500baseSX PHY +model xxBROADCOM_ALT2 BCM57780 0x0019 BCM57780 1000BASE-T media interface model xxBROADCOM_ALT2 BCM5717C 0x0020 BCM5717C 10/100/1000baseTX PHY model xxBROADCOM_ALT2 BCM5719C 0x0022 BCM5719C 10/100/1000baseTX PHY model xxBROADCOM_ALT2 BCM57765 0x0024 BCM57765 10/100/1000baseTX PHY _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 01:23:08 2012 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7575106566C; Sat, 25 Feb 2012 01:23:08 +0000 (UTC) (envelope-from marius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF8FE8FC13; Sat, 25 Feb 2012 01:23:08 +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 q1P1N8kW081130; Sat, 25 Feb 2012 01:23:08 GMT (envelope-from marius@freefall.freebsd.org) Received: (from marius@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q1P1N8tU081126; Sat, 25 Feb 2012 01:23:08 GMT (envelope-from marius) Date: Sat, 25 Feb 2012 01:23:08 GMT Message-Id: <201202250123.q1P1N8tU081126@freefall.freebsd.org> To: a@amilanov.com, marius@FreeBSD.org, freebsd-net@FreeBSD.org From: marius@FreeBSD.org Cc: Subject: Re: kern/165032: [mii] [patch] brgphy(4) is not used for BCM57780 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 01:23:09 -0000 Synopsis: [mii] [patch] brgphy(4) is not used for BCM57780 State-Changed-From-To: open->closed State-Changed-By: marius State-Changed-When: Sat Feb 25 01:22:51 UTC 2012 State-Changed-Why: close http://www.freebsd.org/cgi/query-pr.cgi?pr=165032 From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 04:26:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1D496106564A for ; Sat, 25 Feb 2012 04:26:59 +0000 (UTC) (envelope-from jamesjo@naver.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id ED9818FC13 for ; Sat, 25 Feb 2012 04:26:58 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1S18wB-00070W-Nz for freebsd-net@freebsd.org; Fri, 24 Feb 2012 20:08:47 -0800 Date: Fri, 24 Feb 2012 20:08:47 -0800 (PST) From: jamesjo To: freebsd-net@freebsd.org Message-ID: <1330142927736-5514520.post@n5.nabble.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: Any recommendations for a 10G NIC from Broadcom X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 04:26:59 -0000 Hi, How about myricom's 10g ethernet card? They are supporting a nic driver for freebsd. The Myri10GE FreeBSD driver is named mxge, and has been integrated in FreeBSD since 6.3. If you're running FreeBSD 6.3, 6.4, 7.x, 8.x or 9.x then all you need to do is ifconfig mxge0 inet $ADDRESS up For further installation details, refer to man mxge. http://www.myricom.com/kb/index.php?title=How_do_I_obtain_the_FreeBSD_Myri10GE_driver%3F -james. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Any-recommendations-for-a-10G-NIC-from-Broadcom-tp5118745p5514520.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 05:21:33 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 76B02106566B for ; Sat, 25 Feb 2012 05:21:33 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3D4668FC0C for ; Sat, 25 Feb 2012 05:21:32 +0000 (UTC) Received: by pbcxa7 with SMTP id xa7so3662482pbc.13 for ; Fri, 24 Feb 2012 21:21:32 -0800 (PST) Received-SPF: pass (google.com: domain of pyunyh@gmail.com designates 10.68.240.100 as permitted sender) client-ip=10.68.240.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of pyunyh@gmail.com designates 10.68.240.100 as permitted sender) smtp.mail=pyunyh@gmail.com; dkim=pass header.i=pyunyh@gmail.com Received: from mr.google.com ([10.68.240.100]) by 10.68.240.100 with SMTP id vz4mr15529920pbc.78.1330147292840 (num_hops = 1); Fri, 24 Feb 2012 21:21:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=hrqmzbYqGiPmzk5wpboP9RU0mJ3w2xkEQn6s5sP3ZXQ=; b=lhll3vmCimeUtkBVJpNwJ8QkwMYP82hlwbyzdmUi6PRofiA3ztWpOESeFvEAdaTclP H9PeISn0PC94F8LyOpvO7xCflxLsZdthvmg/AvBbFUCmKBn8XI2wAibf5CtaDGZICDXd TG4RlmsnICxRBdWMSJ7fZWG4zsG/4vA2V5NwM= Received: by 10.68.240.100 with SMTP id vz4mr12827115pbc.78.1330147292764; Fri, 24 Feb 2012 21:21:32 -0800 (PST) Received: from pyunyh@gmail.com ([114.111.62.249]) by mx.google.com with ESMTPS id y9sm6282729pbi.3.2012.02.24.21.21.30 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Feb 2012 21:21:32 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sat, 25 Feb 2012 14:21:26 -0800 From: YongHyeon PYUN Date: Sat, 25 Feb 2012 14:21:26 -0800 To: Nugroho Atmotaruno Message-ID: <20120225222126.GB3718@michelle.cdnetworks.com> References: <20120224044000.GF13815@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="dTy3Mrz/UPE2dbVg" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: re(4) intermittent up/down X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 05:21:33 -0000 --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Fri, Feb 24, 2012 at 08:04:24PM +0700, Nugroho Atmotaruno wrote: > On Fri, Feb 24, 2012 at 10:56 AM, Nugroho Atmotaruno > wrote: > > > > Hi Pyun, > > > > I patched my machine last night, but the problem is still there. > > > > [nugroho@xtreme ~]$ uname -a > > FreeBSD xtreme.arc.itb.ac.id 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Thu > > Feb 23 21:44:02 WIT 2012 > > nugroho@xtreme.arc.itb.ac.id:/sys/amd64/compile/GENERIC ??amd64 > > > > [nugroho@xtreme ~]$ tail /var/log/messages > > Feb 24 10:42:49 xtreme kernel: re0: link state changed to DOWN > > Feb 24 10:42:52 xtreme kernel: re0: link state changed to UP > > Feb 24 10:42:53 xtreme kernel: re0: link state changed to DOWN > > Feb 24 10:42:55 xtreme kernel: re0: link state changed to UP > > Feb 24 10:42:56 xtreme kernel: re0: link state changed to DOWN > > Feb 24 10:43:02 xtreme kernel: re0: link state changed to UP > > Feb 24 10:43:03 xtreme kernel: re0: link state changed to DOWN > > Feb 24 10:43:06 xtreme kernel: re0: link state changed to UP > > Feb 24 10:49:16 xtreme kernel: re0: link state changed to DOWN > > Feb 24 10:49:19 xtreme kernel: re0: link state changed to UP > > > > After repatching, and recompiling my kernel, i got kernel panic. I > don't know why but I didn't get kernel crash dump. I took a screenshot > here[1]. > > [1] http://i.imgur.com/8NIwS.jpg Oops, back out previous patch and try this one. --dTy3Mrz/UPE2dbVg Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rgephy.re.diff2" Index: sys/dev/mii/rgephy.c =================================================================== --- sys/dev/mii/rgephy.c (revision 232144) +++ sys/dev/mii/rgephy.c (working copy) @@ -110,11 +110,16 @@ rgephy_attach(device_t dev) { struct mii_softc *sc; + struct mii_attach_args *ma; + u_int flags; sc = device_get_softc(dev); + ma = device_get_ivars(dev); + flags = 0; + if (strcmp(ma->mii_data->mii_ifp->if_dname, "re") == 0) + flags |= MIIF_PHYPRIV0; + mii_phy_dev_attach(dev, flags, &rgephy_funcs, 0); - mii_phy_dev_attach(dev, 0, &rgephy_funcs, 0); - /* RTL8169S do not report auto-sense; add manually. */ sc->mii_capabilities = (PHY_READ(sc, MII_BMSR) | BMSR_ANEG) & sc->mii_capmask; @@ -243,7 +248,8 @@ * Check to see if we have link. If we do, we don't * need to restart the autonegotiation process. */ - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && + sc->mii_mpd_rev >= 2) { /* RTL8211B(L) */ reg = PHY_READ(sc, RGEPHY_MII_SSR); if (reg & RGEPHY_SSR_LINK) { @@ -298,7 +304,7 @@ mii->mii_media_status = IFM_AVALID; mii->mii_media_active = IFM_ETHER; - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev >= 2) { ssr = PHY_READ(sc, RGEPHY_MII_SSR); if (ssr & RGEPHY_SSR_LINK) mii->mii_media_status |= IFM_ACTIVE; @@ -328,7 +334,7 @@ } } - if (sc->mii_mpd_rev >= 2) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev >= 2) { ssr = PHY_READ(sc, RGEPHY_MII_SSR); switch (ssr & RGEPHY_SSR_SPD_MASK) { case RGEPHY_SSR_S1000: @@ -484,7 +490,7 @@ { uint16_t ssr; - if (sc->mii_mpd_rev == 3) { + if ((sc->mii_flags & MIIF_PHYPRIV0) == 0 && sc->mii_mpd_rev == 3) { /* RTL8211C(L) */ ssr = PHY_READ(sc, RGEPHY_MII_SSR); if ((ssr & RGEPHY_SSR_ALDPS) != 0) { Index: sys/dev/re/if_re.c =================================================================== --- sys/dev/re/if_re.c (revision 232145) +++ sys/dev/re/if_re.c (working copy) @@ -1577,19 +1577,6 @@ re_gmii_writereg(dev, 1, 0x0e, 0); } -#define RE_PHYAD_INTERNAL 0 - - /* Do MII setup. */ - phy = RE_PHYAD_INTERNAL; - if (sc->rl_type == RL_8169) - phy = 1; - error = mii_attach(dev, &sc->rl_miibus, ifp, re_ifmedia_upd, - re_ifmedia_sts, BMSR_DEFCAPMASK, phy, MII_OFFSET_ANY, MIIF_DOPAUSE); - if (error != 0) { - device_printf(dev, "attaching PHYs failed\n"); - goto fail; - } - ifp->if_softc = sc; if_initname(ifp, device_get_name(dev), device_get_unit(dev)); ifp->if_flags = IFF_BROADCAST | IFF_SIMPLEX | IFF_MULTICAST; @@ -1614,6 +1601,19 @@ TASK_INIT(&sc->rl_inttask, 0, re_int_task, sc); +#define RE_PHYAD_INTERNAL 0 + + /* Do MII setup. */ + phy = RE_PHYAD_INTERNAL; + if (sc->rl_type == RL_8169) + phy = 1; + error = mii_attach(dev, &sc->rl_miibus, ifp, re_ifmedia_upd, + re_ifmedia_sts, BMSR_DEFCAPMASK, phy, MII_OFFSET_ANY, MIIF_DOPAUSE); + if (error != 0) { + device_printf(dev, "attaching PHYs failed\n"); + goto fail; + } + /* * Call MI attach routine. */ --dTy3Mrz/UPE2dbVg-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 07:45:00 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3D87B106564A for ; Sat, 25 Feb 2012 07:45:00 +0000 (UTC) (envelope-from bagadeh@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 78A508FC08 for ; Sat, 25 Feb 2012 07:44:59 +0000 (UTC) Received: by bkcjg1 with SMTP id jg1so3481142bkc.13 for ; Fri, 24 Feb 2012 23:44:58 -0800 (PST) Received-SPF: pass (google.com: domain of bagadeh@gmail.com designates 10.204.141.10 as permitted sender) client-ip=10.204.141.10; Authentication-Results: mr.google.com; spf=pass (google.com: domain of bagadeh@gmail.com designates 10.204.141.10 as permitted sender) smtp.mail=bagadeh@gmail.com; dkim=pass header.i=bagadeh@gmail.com Received: from mr.google.com ([10.204.141.10]) by 10.204.141.10 with SMTP id k10mr2668217bku.51.1330155898321 (num_hops = 1); Fri, 24 Feb 2012 23:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=NKe8BgiDoQOXe1L02CIeM5vNqqwr9SbA+QDaTrViENc=; b=FHcSVSr2JzpHQPeI47I/kBHcVcuyJRICNgyrgI4zouShrIXrYbHPDj2IsP3CjWUsxA +8NyVJpJd05s5PyAfFp0y5V5kMiddUXDAJAwlT8axjPCPATMtRDN0EMwnRgPFbpFHmda iP9z8pOTHNDPWU29ddDeEqQ6lL6oXcyfj+4B8= MIME-Version: 1.0 Received: by 10.204.141.10 with SMTP id k10mr2161574bku.51.1330154244144; Fri, 24 Feb 2012 23:17:24 -0800 (PST) Received: by 10.204.167.139 with HTTP; Fri, 24 Feb 2012 23:17:23 -0800 (PST) Date: Sat, 25 Feb 2012 10:47:23 +0330 Message-ID: From: h bagade To: freebsd-net Content-Type: multipart/related; boundary=0015175cac8838003804b9c4ab2d X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: problem with netgraph vlan tagging X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 07:45:00 -0000 --0015175cac8838003804b9c4ab2d Content-Type: text/plain; charset=ISO-8859-1 Hi all, I have designed a topology(illustrated below) using netgraph to add vlan2 tag to the frames coming from eth0 and send it to eth1 to go out of the box. it works fine. [image: Inline image 1] Then I tried to add another interface like eth0 which named eth2 to be tagged vlan2 too. Then I bridged eth0 and eth2 using ifconfig. When traffic comes from eth0(system1) to the destination eth2(system2), all traffic also sent out eth1 which is not suitable! In the mentioned scenario, I don't want the traffic pass to the eth1. Is there any way that eth1 recognize which mac addresses don't belong to this box then sends the traffic out? I mean I want to send taraffic out of eth1 when the destination is not accessible via FreeBSD box so it should be sent out to be find out. Any comments or hints are really appreciated p.s. I use netgraph on freebsd 8.2 box. --0015175cac8838003804b9c4ab2d-- From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 07:47:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EA2E5106564A for ; Sat, 25 Feb 2012 07:47:48 +0000 (UTC) (envelope-from iwc2010005@gmail.com) Received: from mail-lpp01m010-f54.google.com (mail-lpp01m010-f54.google.com [209.85.215.54]) by mx1.freebsd.org (Postfix) with ESMTP id 685318FC18 for ; Sat, 25 Feb 2012 07:47:48 +0000 (UTC) Received: by lagz14 with SMTP id z14so5206286lag.13 for ; Fri, 24 Feb 2012 23:47:47 -0800 (PST) Received-SPF: pass (google.com: domain of iwc2010005@gmail.com designates 10.152.130.167 as permitted sender) client-ip=10.152.130.167; Authentication-Results: mr.google.com; spf=pass (google.com: domain of iwc2010005@gmail.com designates 10.152.130.167 as permitted sender) smtp.mail=iwc2010005@gmail.com; dkim=pass header.i=iwc2010005@gmail.com Received: from mr.google.com ([10.152.130.167]) by 10.152.130.167 with SMTP id of7mr4383754lab.36.1330156067236 (num_hops = 1); Fri, 24 Feb 2012 23:47:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=CfVBlvNQCQ+MoygpQAZTW0vSrAt5g/Sa4+I4o46XTt8=; b=opv1gIkXUV2oG1qXjNATa6VC4iKNpxm2AECySR15/+qSvhnFk16hnbEwssB/7GReRY m70gAUZiPYCr0rpA2AlBd7RCX5kpwm5MlbSntp0fe+WWxRxCnzugy6joYew/loX9cAmf UE9N+AFeEjdYA0I7VO4IPSly6iRwWmiss8eQY= MIME-Version: 1.0 Received: by 10.152.130.167 with SMTP id of7mr3569115lab.36.1330154450350; Fri, 24 Feb 2012 23:20:50 -0800 (PST) Received: by 10.112.66.43 with HTTP; Fri, 24 Feb 2012 23:20:50 -0800 (PST) Date: Sat, 25 Feb 2012 12:50:50 +0530 Message-ID: From: Rajneesh Kumar To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ARP module interaction X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 07:47:49 -0000 Hi, I am working on ARP module of FreeBSD and want to modify it to suit my needs. I am trying to prevent ARP cache poisoning by a false reply reply packet. For the same I referred "Rechard Steven's TCP/IP Illustrated vol.-2" to understand how the modules interact and the purpose served by every function. But the reference given in the book is very old and new kernel does differ a lot. So I am in a soup now. I want to understand the working of arpresolve() function in latest kernel. Precisely in the old kernel arpresolve() used to call arplookup() and arpwhohas(), but there is no such function called arplookup() or arpwhohas() in the new kernel. So how those tasks are achieved now?? Any reference from where I can read would be appreciated. Regards, Rajneesh From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 12:17:19 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C8CCF106564A; Sat, 25 Feb 2012 12:17:19 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 2E3F98FC08; Sat, 25 Feb 2012 12:17:18 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1PCHEL3089735; Sat, 25 Feb 2012 19:17:14 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F48D14A.7090003@rdtc.ru> Date: Sat, 25 Feb 2012 19:17:14 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: Andrew Thompson References: <4F47C55C.8060006@rdtc.ru> <4F47D5EF.7060908@rdtc.ru> In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Alexander Motin , Gleb Smirnoff , "net@freebsd.org" Subject: Re: netisr+lagg+fragments=80% packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 12:17:19 -0000 25.02.2012 02:00, Andrew Thompson пишет: > 2012/2/25 Eugene Grosbein : >> 25.02.2012 00:14, Eugene Grosbein пишет: >>> This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. >>> And only when lagg1 has both ports up and running. And when I use oversized pings. >>> At the same time, transit oversized pings go through this BRAS just fine, >>> no packet loss at all. >> >> Running two copies of tcpdump for igb0 and igb1 simultaneously, >> I see that fragments of the same ICMP echo-reply packet encapsulated within PPPoE >> frame always go out through different ports of lagg1. Even when they arrive to client in order, >> it seems this depends of switching network in between PPPoE server and client. >> > > If you are running a recent HEAD then you can try setting > net.link.lagg.0.use_flowid to zero. It helps to set net.link.lagg.1.use_flowid=1, yes (but I use 8.2-STABLE with this sysctl added). Perhaps, ip_fragment() does not keep flowid for fragments it creates. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 12:51:29 2012 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B759A1065670; Sat, 25 Feb 2012 12:51:29 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 01E648FC12; Sat, 25 Feb 2012 12:51:28 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id q1PCpRl8089843; Sat, 25 Feb 2012 19:51:27 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4F48D94F.6030803@rdtc.ru> Date: Sat, 25 Feb 2012 19:51:27 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 References: <4F47C55C.8060006@rdtc.ru> <4F47D5EF.7060908@rdtc.ru> <4F48D14A.7090003@rdtc.ru> In-Reply-To: <4F48D14A.7090003@rdtc.ru> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Alexander Motin , Gleb Smirnoff , Andrew Thompson , "net@freebsd.org" Subject: Re: netisr+lagg+fragments=80% packet loss X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 12:51:29 -0000 25.02.2012 19:17, Eugene Grosbein пишет: > 25.02.2012 02:00, Andrew Thompson пишет: >> 2012/2/25 Eugene Grosbein : >>> 25.02.2012 00:14, Eugene Grosbein пишет: >>>> This problem occurs only when net.isr.direct=0/net.isr.direct_force=0. >>>> And only when lagg1 has both ports up and running. And when I use oversized pings. >>>> At the same time, transit oversized pings go through this BRAS just fine, >>>> no packet loss at all. >>> >>> Running two copies of tcpdump for igb0 and igb1 simultaneously, >>> I see that fragments of the same ICMP echo-reply packet encapsulated within PPPoE >>> frame always go out through different ports of lagg1. Even when they arrive to client in order, >>> it seems this depends of switching network in between PPPoE server and client. >>> >> >> If you are running a recent HEAD then you can try setting >> net.link.lagg.0.use_flowid to zero. > > It helps to set net.link.lagg.1.use_flowid=1, yes (but I use 8.2-STABLE with this sysctl added). > Perhaps, ip_fragment() does not keep flowid for fragments it creates. The following patch (by Alexander Chernikov) solves the problem by preserving flowid for fragments: --- sys/netinet/ip_output.c.orig 2012-02-25 19:19:15.000000000 +0700 +++ sys/netinet/ip_output.c 2012-02-25 19:32:00.000000000 +0700 @@ -825,6 +825,10 @@ } m->m_pkthdr.len = mhlen + len; m->m_pkthdr.rcvif = NULL; + if (m0->m_flags & M_FLOWID) { + m->m_pkthdr.flowid = m0->m_pkthdr.flowid; + m->m_flags |= M_FLOWID; + } #ifdef MAC mac_netinet_fragment(m0, m); #endif From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 18:35:59 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E442A106564A for ; Sat, 25 Feb 2012 18:35:59 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 669C88FC15 for ; Sat, 25 Feb 2012 18:35:59 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so151445bkc.13 for ; Sat, 25 Feb 2012 10:35:58 -0800 (PST) Received-SPF: pass (google.com: domain of subbsd@gmail.com designates 10.204.129.196 as permitted sender) client-ip=10.204.129.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of subbsd@gmail.com designates 10.204.129.196 as permitted sender) smtp.mail=subbsd@gmail.com; dkim=pass header.i=subbsd@gmail.com Received: from mr.google.com ([10.204.129.196]) by 10.204.129.196 with SMTP id p4mr972029bks.21.1330194958287 (num_hops = 1); Sat, 25 Feb 2012 10:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:mime-version:content-type :content-transfer-encoding:message-id; bh=mKWh8dTv/iq+VoOKoO8BNST8GRpm9Gr3Dsv+m0NinIc=; b=tQYRHrJ/emr6g1dO9h3kZtkklpGHDsFmoMd0YWec+iSEm2NoHlNL49mZLLJrTUQE4p V0JJurT9eaHil/XB54u+6sMm+hdJf1ra1vXxK7r9cWVDX/RYI0WcgTqt7IJNpEPC7ihE 9auaOJkDT5XbGw6QsQ2913mhMRaTQ/0vo6KD0= Received: by 10.204.129.196 with SMTP id p4mr768143bks.21.1330193614820; Sat, 25 Feb 2012 10:13:34 -0800 (PST) Received: from gizmo.my.domain (nat140-249-205-109.tvoe.tv. [109.205.249.140]) by mx.google.com with ESMTPS id ey8sm15102453bkb.1.2012.02.25.10.13.32 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Feb 2012 10:13:33 -0800 (PST) From: Mr Dandy To: freebsd-net@freebsd.org Date: Sat, 25 Feb 2012 22:13:50 +0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202252213.50760.subbsd@gmail.com> Subject: ipv6 host inaccessible via route -inteface without ndp pairs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 18:36:00 -0000 Hi I play with IPv6 on the Hezner hosting. According to http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en information my rc.conf have (FreeBSD 9.0-RELEASE/amd64): --- ipv6_activate_all_interfaces="YES" ipv6_static_routes="hetzner" ipv6_route_hetzner="2a01:4f8:61:50c0::/59 -iface re0" ifconfig_re0_ipv6="inet6 2a01:4f8:61:50c2::13/64" ipv6_defaultrouter="2a01:4f8:61:50c0::1" ipv6_gateway_enable="YES" -- Pictures after boot: # ifconfig re0 inet6 re0: flags=8843 metric 0 mtu 1500 options=389b inet6 2a01:4f8:61:50c2::13 prefixlen 64 inet6 fe80::224:21ff:fe2c:6943%re0 prefixlen 64 scopeid 0x1 nd6 options=21 # route get -inet6 2a01:4f8:61:50c0::1 route to: 2a01:4f8:61:50c0::1 destination: 2a01:4f8:61:50c0:: mask: ffff:ffff:ffff:ffe0:: interface: re0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 # route get -inet6 default route: writing to routing socket: No such process # ping6 -c1 2a01:4f8:61:50c0::1 PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 ping6: sendmsg: Operation not permitted ping6: wrote 2a01:4f8:61:50c0::1 16 chars, ret=-1 --- 2a01:4f8:61:50c0::1 ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss - is inaccessible. This situation changes when ip/mac pairs already presents in NDP list (by ndp -s pairs or static_ndp_pairs in /etc/rc.conf) # ndp -s 2a01:4f8:61:50c0::1 00:26:88:75:ed:06 ( I took MAC by registered the my ip in /59 network and touching 2a01:4f8:61:50c0::1 by ping6 ) # route add -inet6 -host 2a01:4f8:61:50c0::/59 -iface re0 add net 2a01:4f8:61:50c0::/59: gateway re0 # ping6 -c1 2a01:4f8:61:50c0::1 PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 16 bytes from 2a01:4f8:61:50c0::1, icmp_seq=0 hlim=64 time=2.341 ms --- 2a01:4f8:61:50c0::1 ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 2.341/2.341/2.341/0.000 ms # route add -inet6 default 2a01:4f8:61:50c0::1 add net default: gateway 2a01:4f8:61:50c0::1 # ping6 -c1 www.freebsd.org PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2001:4f8:fff6::22 16 bytes from 2001:4f8:fff6::22, icmp_seq=0 hlim=54 time=163.879 ms --- red.freebsd.org ping6 statistics --- 1 packets transmitted, 1 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = 163.879/163.879/163.879/0.000 ms All fine while ndp have cache: # ndp -a Neighbor Linklayer Address Netif Expire S Flags fe80::226:88ff:fe75:ed06%re0 00:26:88:75:ed:06 re0 23h52m6s S R 2a01:4f8:61:50c0::1 00:26:88:75:ed:06 re0 23h59m58s S R 00:24:21:2c:69:43 re0 permanent R fe80::224:21ff:fe2c:6943%re0 00:24:21:2c:69:43 re0 permanent R # ndp -d 2a01:4f8:61:50c0::1 2a01:4f8:61:50c0::1 (2a01:4f8:61:50c0::1) deleted # ping6 -c1 2a01:4f8:61:50c0::1 PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 ping6: sendmsg: Operation not permitted ping6: wrote 2a01:4f8:61:50c0::1 16 chars, ret=-1 ^C --- 2a01:4f8:61:50c0::1 ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 19:15:29 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ADC3B106564A for ; Sat, 25 Feb 2012 19:15:29 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 362D38FC08 for ; Sat, 25 Feb 2012 19:15:28 +0000 (UTC) Received: by eekd17 with SMTP id d17so785252eek.13 for ; Sat, 25 Feb 2012 11:15:28 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.14.99.1 as permitted sender) client-ip=10.14.99.1; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.14.99.1 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.14.99.1]) by 10.14.99.1 with SMTP id w1mr4398851eef.49.1330197328096 (num_hops = 1); Sat, 25 Feb 2012 11:15:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=FL96WquT8QqOSSOWWBj7jmiSkwEnX6MdsprbveyadNQ=; b=ceRzYeOfPUTMwER2VfBfP2QOpBTR0vxwk3lAoy0FCKokRsrGFsF17oIq3Sr01i659A 8/d/CUtj9Sbnde6mVKiuu+H6QV6kRKAM4X3COAbQioUZpNN7NGLfZJqr0fRvKyoN9Ku4 NUczOAjZL/41RoRhCBdYqdYzoLObz/Vp7wQa8= Received: by 10.14.99.1 with SMTP id w1mr3261990eef.49.1330195676272; Sat, 25 Feb 2012 10:47:56 -0800 (PST) Received: from LesPaul.local ([82.76.253.74]) by mx.google.com with ESMTPS id u11sm27451133eeb.1.2012.02.25.10.47.53 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Feb 2012 10:47:55 -0800 (PST) Date: Sat, 25 Feb 2012 18:47:50 +0000 From: Vlad Galu To: Mr Dandy Message-ID: <371110A7FCE442FA8189BEDF90DF6451@dudu.ro> In-Reply-To: <201202252213.50760.subbsd@gmail.com> References: <201202252213.50760.subbsd@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQkTDx/IXyCj32+ZSRi6bUVxMy3R+vWjatpJ3Vkys2Z1n5DAHQiLXZwiE9GuluBrTOPSRygG Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host inaccessible via route -inteface without ndp pairs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 19:15:29 -0000 -- Good, fast and cheap: pick any two. On Saturday, February 25, 2012 at 6:13 PM, Mr Dandy wrote: > Hi > > I play with IPv6 on the Hezner hosting. According to > http://wiki.hetzner.de/index.php/Zusaetzliche_IP-Adressen/en information my > rc.conf have (FreeBSD 9.0-RELEASE/amd64): > --- > ipv6_activate_all_interfaces="YES" > ipv6_static_routes="hetzner" > ipv6_route_hetzner="2a01:4f8:61:50c0::/59 -iface re0" > ifconfig_re0_ipv6="inet6 2a01:4f8:61:50c2::13/64" > ipv6_defaultrouter="2a01:4f8:61:50c0::1" > ipv6_gateway_enable="YES" > -- > > Pictures after boot: > > # ifconfig re0 inet6 > re0: flags=8843 metric 0 mtu 1500 > options=389b > inet6 2a01:4f8:61:50c2::13 prefixlen 64 > inet6 fe80::224:21ff:fe2c:6943%re0 prefixlen 64 scopeid 0x1 > nd6 options=21 > > # route get -inet6 2a01:4f8:61:50c0::1 > route to: 2a01:4f8:61:50c0::1 > destination: 2a01:4f8:61:50c0:: > mask: ffff:ffff:ffff:ffe0:: > interface: re0 > flags: > recvpipe sendpipe ssthresh rtt,msec mtu weight expire > 0 0 0 0 1500 1 0 > > # route get -inet6 default > route: writing to routing socket: No such process > > # ping6 -c1 2a01:4f8:61:50c0::1 > PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 > ping6: sendmsg: Operation not permitted > ping6: wrote 2a01:4f8:61:50c0::1 16 chars, ret=-1 > > --- 2a01:4f8:61:50c0::1 ping6 statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss > > - is inaccessible. > > This situation changes when ip/mac pairs already presents in NDP list (by ndp > -s pairs or static_ndp_pairs in /etc/rc.conf) > > # ndp -s 2a01:4f8:61:50c0::1 00:26:88:75:ed:06 > > ( I took MAC by registered the my ip in /59 network and touching > 2a01:4f8:61:50c0::1 by ping6 ) > > # route add -inet6 -host 2a01:4f8:61:50c0::/59 -iface re0 > add net 2a01:4f8:61:50c0::/59: gateway re0 > > # ping6 -c1 2a01:4f8:61:50c0::1 > PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 > 16 bytes from 2a01:4f8:61:50c0::1, icmp_seq=0 hlim=64 time=2.341 ms > > --- 2a01:4f8:61:50c0::1 ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 2.341/2.341/2.341/0.000 ms > > # route add -inet6 default 2a01:4f8:61:50c0::1 > add net default: gateway 2a01:4f8:61:50c0::1 > > # ping6 -c1 www.freebsd.org (http://www.freebsd.org) > PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2001:4f8:fff6::22 > 16 bytes from 2001:4f8:fff6::22, icmp_seq=0 hlim=54 time=163.879 ms > > --- red.freebsd.org (http://red.freebsd.org) ping6 statistics --- > 1 packets transmitted, 1 packets received, 0.0% packet loss > round-trip min/avg/max/std-dev = 163.879/163.879/163.879/0.000 ms > > All fine while ndp have cache: > > # ndp -a > Neighbor Linklayer Address Netif Expire S > Flags > fe80::226:88ff:fe75:ed06%re0 00:26:88:75:ed:06 re0 23h52m6s S R > 2a01:4f8:61:50c0::1 00:26:88:75:ed:06 re0 23h59m58s S R > 00:24:21:2c:69:43 re0 permanent R > fe80::224:21ff:fe2c:6943%re0 00:24:21:2c:69:43 re0 permanent R > > # ndp -d 2a01:4f8:61:50c0::1 > 2a01:4f8:61:50c0::1 (2a01:4f8:61:50c0::1) deleted > > # ping6 -c1 2a01:4f8:61:50c0::1 > PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 > ping6: sendmsg: Operation not permitted > ping6: wrote 2a01:4f8:61:50c0::1 16 chars, ret=-1 > ^C > --- 2a01:4f8:61:50c0::1 ping6 statistics --- > 1 packets transmitted, 0 packets received, 100.0% packet loss You might need to add ipv6_default_interface="re0" to /etc/rc.conf. After you do that, it will have ACCEPT_RTADV and DEFAULTIF set. Also, see http://social.bitmand.com/post/1168584251/hetzner-freebsd-and-ipv6. From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 19:33:21 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4337106566C for ; Sat, 25 Feb 2012 19:33:21 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 4B79E8FC20 for ; Sat, 25 Feb 2012 19:33:20 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so171503bkc.13 for ; Sat, 25 Feb 2012 11:33:20 -0800 (PST) Received-SPF: pass (google.com: domain of subbsd@gmail.com designates 10.204.129.220 as permitted sender) client-ip=10.204.129.220; Authentication-Results: mr.google.com; spf=pass (google.com: domain of subbsd@gmail.com designates 10.204.129.220 as permitted sender) smtp.mail=subbsd@gmail.com; dkim=pass header.i=subbsd@gmail.com Received: from mr.google.com ([10.204.129.220]) by 10.204.129.220 with SMTP id p28mr3602939bks.8.1330198400118 (num_hops = 1); Sat, 25 Feb 2012 11:33:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=4x3VXkqRsdPVn7VHQk5YwYf8hKdePjUSyXn6gG0IAgk=; b=kOEVz20Cy5V6vyxR+nL12uXQwpQ6F4rWkmQerd1Ym9zR39DAO7YXRq30SS7/BCN0Fn OuIhVhoihNErcawu2Bh44rkUrXPsdzQ0H/dkLZhSyN8isnhfcnGMBG7E/yezd/zGG+V5 M+NgTmIOz8oPRCPQOdhezoydfSJB7Q9iwjRIc= Received: by 10.204.129.220 with SMTP id p28mr2972921bks.8.1330198399997; Sat, 25 Feb 2012 11:33:19 -0800 (PST) Received: from gizmo.my.domain (nat140-249-205-109.tvoe.tv. [109.205.249.140]) by mx.google.com with ESMTPS id jc4sm15364489bkc.7.2012.02.25.11.33.18 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Feb 2012 11:33:19 -0800 (PST) From: Mr Dandy To: Vlad Galu Date: Sat, 25 Feb 2012 23:33:36 +0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201202252213.50760.subbsd@gmail.com> <371110A7FCE442FA8189BEDF90DF6451@dudu.ro> In-Reply-To: <371110A7FCE442FA8189BEDF90DF6451@dudu.ro> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202252333.36403.subbsd@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host inaccessible via route -inteface without ndp pairs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 19:33:22 -0000 On Saturday 25 February 2012 22:47:50 Vlad Galu wrote: > > Hi > > > > You might need to add ipv6_default_interface="re0" to /etc/rc.conf. After > you do that, it will have ACCEPT_RTADV and DEFAULTIF set. Thanks for informations. Ok - looks like FreeBSD still not have rc.conf variable for controlling net.inet6.ip6.accept_rtadv (ipv6_default_interface="re0") = ndp -I re0 But that in my case I have seen on netstat correct information about default gw for ipv6 - I should in /etc/rc.d/routing change string from ipv6_static_routes="default ${ipv6_static_routes}" to ipv6_static_routes="${ipv6_static_routes} default" And however I all the same can't achieve working configuration IPv6 from the boot. At present i have /etc/rc.conf related to ipv6: ipv6_activate_all_interfaces="YES" ipv6_static_routes="hetzner" ipv6_route_hetzner="2a01:4f8:61:50c0::/59 -iface re0" ipv6_default_interface="re0" ifconfig_re0_ipv6="inet6 2a01:4f8:61:50c2::13/64" ipv6_defaultrouter="2a01:4f8:61:50c0::1" rtadvd_enable="YES" rtadvd_interfaces="re0" /etc/sysct.conf: net.inet6.ip6.accept_rtadv=1 After reboot what i get: # sysctl -n net.inet6.ip6.accept_rtadv 1 # ndp -I ND default interface = re0 # route get -inet6 default route to: :: destination: :: mask: default gateway: 2a01:4f8:61:50c0::1 interface: re0 flags: recvpipe sendpipe ssthresh rtt,msec mtu weight expire 0 0 0 0 1500 1 0 # ping6 2a01:4f8:61:50c0::1 PING6(56=40+8+8 bytes) 2a01:4f8:61:50c2::13 --> 2a01:4f8:61:50c0::1 ping6: sendmsg: Operation not permitted ping6: wrote 2a01:4f8:61:50c0::1 16 chars, ret=-1 ^C --- 2a01:4f8:61:50c0::1 ping6 statistics --- 1 packets transmitted, 0 packets received, 100.0% packet loss ? It seems not a problem of configuration rc-scripts, something isn't perfectly in order with route table for -iface? From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 19:55:47 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8423F1065679 for ; Sat, 25 Feb 2012 19:55:47 +0000 (UTC) (envelope-from dudu@dudu.ro) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id C05238FC0C for ; Sat, 25 Feb 2012 19:55:44 +0000 (UTC) Received: by eekd17 with SMTP id d17so794373eek.13 for ; Sat, 25 Feb 2012 11:55:44 -0800 (PST) Received-SPF: pass (google.com: domain of dudu@dudu.ro designates 10.213.10.196 as permitted sender) client-ip=10.213.10.196; Authentication-Results: mr.google.com; spf=pass (google.com: domain of dudu@dudu.ro designates 10.213.10.196 as permitted sender) smtp.mail=dudu@dudu.ro; dkim=pass header.i=dudu@dudu.ro Received: from mr.google.com ([10.213.10.196]) by 10.213.10.196 with SMTP id q4mr2160315ebq.82.1330199744204 (num_hops = 1); Sat, 25 Feb 2012 11:55:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dudu.ro; s=google; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition; bh=oXAHnmF0ARuU+NJchhkb1XhpyVNwCCKw3tnAW6thK54=; b=APJKhRwkMEg3H8YkFvBFsBlXAisZFYSz7hFqDcJQELG4YRW6r0hU/nWF3nTG9hWzHh DratI548b+rH9WZZaY27VRxWBUkhA3e/mN6T9KqmQE4q2POfTjIFv55HYtBzDuxRIzn2 ErX3OpYCjOYhbeGJJEHFYlYqJhxxCBXsQvtoo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=date:from:to:cc:message-id:in-reply-to:references:subject:x-mailer :mime-version:content-type:content-transfer-encoding :content-disposition:x-gm-message-state; bh=oXAHnmF0ARuU+NJchhkb1XhpyVNwCCKw3tnAW6thK54=; b=xNn8hiMe6KaqOi+6LAU+fT7jCyJ78+lH9XjRb1YVu9zDyDp+NFv3vC8ppePt1Rg5Sy cnYIAmgQtVmdKock2lzw2JcC8fDOnLdFZdW7dN3x1fUfpFItPVoTsI0ypUKNplCj9jYX KiTS0G4YZQdE9kwtr/m6XxvRXO8dcOfX9BcJc= Received: by 10.213.10.196 with SMTP id q4mr1601803ebq.82.1330199743825; Sat, 25 Feb 2012 11:55:43 -0800 (PST) Received: from LesPaul.local ([82.76.253.74]) by mx.google.com with ESMTPS id v51sm35465403eef.2.2012.02.25.11.55.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Feb 2012 11:55:42 -0800 (PST) Date: Sat, 25 Feb 2012 19:55:38 +0000 From: Vlad Galu To: Mr Dandy Message-ID: In-Reply-To: <201202252333.36403.subbsd@gmail.com> References: <201202252213.50760.subbsd@gmail.com> <371110A7FCE442FA8189BEDF90DF6451@dudu.ro> <201202252333.36403.subbsd@gmail.com> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Gm-Message-State: ALoCoQmhAJNfnB1JVriwlOWwOIMv0du0ScbQ4UW1MrWOtnJwNEWm5KOItyzjvubXXL8O9TBIihyB Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host inaccessible via route -inteface without ndp pairs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 19:55:47 -0000 On Saturday, February 25, 2012 at 7:33 PM, Mr Dandy wrote: > On Saturday 25 February 2012 22:47:50 Vlad Galu wrote: > > > Hi > > > > > > > > You might need to add ipv6_default_interface="re0" to /etc/rc.conf. After > > you do that, it will have ACCEPT_RTADV and DEFAULTIF set. > > > > Thanks for informations. > > Ok - looks like FreeBSD still not have rc.conf variable for controlling > net.inet6.ip6.accept_rtadv > Why don't you add that to /etc/sysctl.conf? > > (ipv6_default_interface="re0") = ndp -I re0 > > But that in my case I have seen on netstat correct information about default > gw for ipv6 - I should in /etc/rc.d/routing change string from > > ipv6_static_routes="default ${ipv6_static_routes}" > to > ipv6_static_routes="${ipv6_static_routes} default" > > And however I all the same can't achieve working configuration IPv6 from the > boot. At present i have /etc/rc.conf related to ipv6: > > ipv6_activate_all_interfaces="YES" > ipv6_static_routes="hetzner" > ipv6_route_hetzner="2a01:4f8:61:50c0::/59 -iface re0" > ipv6_default_interface="re0" > ifconfig_re0_ipv6="inet6 2a01:4f8:61:50c2::13/64" > ipv6_defaultrouter="2a01:4f8:61:50c0::1" > rtadvd_enable="YES" > rtadvd_interfaces="re0" You don't need to run rtadvd. The following configuration should work (although I use RELENG_9, rc.conf variable naming is slightly different, but not by much): ipv6_enable="YES" ipv6_default_interface="re0" ipv6_static_routes="hetzner" ipv6_route_hetzner="2a01:4f8:61:50c0:: -prefixlen 59 -iface re0" ipv6_ifconfig_re0="2a01:4f8:61:50c2::13" ipv6_defaultrouter="2a01:4f8:61:50c0::1" Maybe you have some conflicting firewall rules? From owner-freebsd-net@FreeBSD.ORG Sat Feb 25 20:48:58 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A1E51065673 for ; Sat, 25 Feb 2012 20:48:58 +0000 (UTC) (envelope-from subbsd@gmail.com) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id B92CC8FC08 for ; Sat, 25 Feb 2012 20:48:57 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so195859bkc.13 for ; Sat, 25 Feb 2012 12:48:56 -0800 (PST) Received-SPF: pass (google.com: domain of subbsd@gmail.com designates 10.205.130.12 as permitted sender) client-ip=10.205.130.12; Authentication-Results: mr.google.com; spf=pass (google.com: domain of subbsd@gmail.com designates 10.205.130.12 as permitted sender) smtp.mail=subbsd@gmail.com; dkim=pass header.i=subbsd@gmail.com Received: from mr.google.com ([10.205.130.12]) by 10.205.130.12 with SMTP id hk12mr365492bkc.76.1330202936637 (num_hops = 1); Sat, 25 Feb 2012 12:48:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=YDXyHrC83oZu5oH0IHghl+JC+c7GMxSt2TpT605b7VQ=; b=Io6HsmnNBbA8kdvxHuSf/h3mBbc7XbcS8P1QDWiD1zqqESNCuPLTMyVPMv2Oeyl4An Oi6KkG94CiXrFQEkRjjKT8jtLGKz+wE/zwxEy8ROPUNr1A6Svhh20r2A8EcrKHpv/w+C qzSHaXBERVAJvkTCXyF+9VsHxROLVVhh3DnwU= Received: by 10.205.130.12 with SMTP id hk12mr291823bkc.76.1330202936538; Sat, 25 Feb 2012 12:48:56 -0800 (PST) Received: from gizmo.my.domain (nat140-249-205-109.tvoe.tv. [109.205.249.140]) by mx.google.com with ESMTPS id x20sm15623505bka.9.2012.02.25.12.48.55 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 25 Feb 2012 12:48:55 -0800 (PST) From: Mr Dandy To: Vlad Galu Date: Sun, 26 Feb 2012 00:49:13 +0400 User-Agent: KMail/1.13.7 (FreeBSD/9.0-STABLE; KDE/4.7.4; amd64; ; ) References: <201202252213.50760.subbsd@gmail.com> <201202252333.36403.subbsd@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201202260049.13208.subbsd@gmail.com> Cc: freebsd-net@freebsd.org Subject: Re: ipv6 host inaccessible via route -inteface without ndp pairs X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2012 20:48:58 -0000 On Saturday 25 February 2012 23:55:38 you wrote: > The following configuration should work (although I use RELENG_9, rc.conf variable naming is slightly different, but not by much): ( i just change variable from old declaration (ipv6_ifconfig_IF form) to new style - ifconfig_IF_ipv6 according to /etc/network.subr ) > > ipv6_enable="YES" > ipv6_default_interface="re0" > ipv6_static_routes="hetzner" > ipv6_route_hetzner="2a01:4f8:61:50c0:: -prefixlen 59 -iface re0" > ipv6_ifconfig_re0="2a01:4f8:61:50c2::13" > > ipv6_defaultrouter="2a01:4f8:61:50c0::1" No luck (in this sample forgotten /prefix for ipv6 addr) > > Maybe you have some conflicting firewall rules? No, ipfw is clean, something another influences here, but on ktrace ( http://pastebin.com/Y20FNTTK ) I haven't understood what exactly 2621 ping6 STRU struct sockaddr { AF_INET6, [2a01:4f8:61:50c0::1]:0 } .. ( guru meditation ;) 2621 ping6 RET sendmsg -1 errno 1 Operation not permitted