From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 11:17:05 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 3021E172; Sun, 27 Jan 2013 11:17:05 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 26DB3B33; Sun, 27 Jan 2013 11:17:03 +0000 (UTC) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA19106; Sun, 27 Jan 2013 13:16:55 +0200 (EET) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1TzQEJ-000JA7-CB; Sun, 27 Jan 2013 13:16:55 +0200 Message-ID: <51050CA5.8030805@FreeBSD.org> Date: Sun, 27 Jan 2013 13:16:53 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130121 Thunderbird/17.0.2 MIME-Version: 1.0 To: Nikolay Denev , =?ISO-8859-1?Q?Ermal_Lu=E7i?= , "Alexander V. Chernikov" Subject: Re: ng_ether naming References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> <50CB5B8A.8030703@FreeBSD.org> <75277A1B-B434-4220-A800-9004C29DA92A@gmail.com> In-Reply-To: <75277A1B-B434-4220-A800-9004C29DA92A@gmail.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 11:17:05 -0000 Guys, based on your suggestions and submissions I've produced the following patch: http://people.freebsd.org/~avg/ng_ether-renaming.diff It's only compile-tested at the moment :) but I'd like to get your opinion about the direction of the change(s). I am going to really test the change very soon. Thank you. -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 12:22:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3588FEDE; Sun, 27 Jan 2013 12:22:48 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mx1.freebsd.org (Postfix) with ESMTP id ADB1BDD0; Sun, 27 Jan 2013 12:22:47 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id hy16so486172qab.7 for ; Sun, 27 Jan 2013 04:22:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tXpA3/n0DTwi3IpikR0cJ8/o1adHSVlYkoqlq8tMg0A=; b=lM0NskQNLI8n3Dy7AtPX/UFRyWNtsrip8HcPa1ush6X61rsYlGRcw0MY+0Hx5VRNVn 2LnqPtp4Kj4+bW2PqEvmQyu2GX/slR/ie7j9luFzs1enwtaV4JilGXtGbuTw5MnGUFTx NGU/KOnuTQpO0bOKhQ5lHfTZU37oNcOJjDd2BRIj2Z4WbztmqSk9yGwouJ5R4NUahvBq Lz1XrTExkIa/21y6YaM0ZBL8NDMwA/9DmULcd4UWLzri5yq54LlbMfgWbIVgRKIM0RYd MibiwAuKqbTpDBmFK57K0wm3DAgJn9kT/ceVQohQiY++e8Zqh0CiM1XArzfwFH+xh4Wh kkeQ== MIME-Version: 1.0 X-Received: by 10.49.24.135 with SMTP id u7mr14520412qef.4.1359289359005; Sun, 27 Jan 2013 04:22:39 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.27.197 with HTTP; Sun, 27 Jan 2013 04:22:38 -0800 (PST) In-Reply-To: <51050CA5.8030805@FreeBSD.org> References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> <50CB5B8A.8030703@FreeBSD.org> <75277A1B-B434-4220-A800-9004C29DA92A@gmail.com> <51050CA5.8030805@FreeBSD.org> Date: Sun, 27 Jan 2013 13:22:38 +0100 X-Google-Sender-Auth: uBUzwUL2rogoiQN2-8IxxRmtU_o Message-ID: Subject: Re: ng_ether naming From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Andriy Gapon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Nikolay Denev , "Alexander V. Chernikov" , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 12:22:48 -0000 Hello, it looks good, for just interface renaming scope. The problem of it is that you need to check if the ifnet pointer needs updated as well. For coming and going interfaces like vlans you would have to update some pointers as well at least the ifnet one. The complete patch would rather include moving detach/attach(?) code from if_ethersubr.c to ng_ether based on interface events. On Sun, Jan 27, 2013 at 12:16 PM, Andriy Gapon wrote: > > Guys, > > based on your suggestions and submissions I've produced the following > patch: > http://people.freebsd.org/~avg/ng_ether-renaming.diff > > It's only compile-tested at the moment :) > but I'd like to get your opinion about the direction of the change(s). > I am going to really test the change very soon. > > Thank you. > > -- > Andriy Gapon > -- Ermal From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 13:15:59 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 735112FA; Sun, 27 Jan 2013 13:15:59 +0000 (UTC) (envelope-from kubito@gmail.com) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 9D3FBF98; Sun, 27 Jan 2013 13:15:58 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so377912lab.5 for ; Sun, 27 Jan 2013 05:15:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=++7Xpyxj8tNbcGs239nt3wu02rGOzh2sINwXkTXIFcY=; b=jYlv3DU3RcMkcugyhBv1gnLeHd2AamRd/PV9SN3GEBJEPvU0wHagBAdDJSExRlFHMK NXmBeuGvs5twPHY1P9LH70pOFsUMSBd51+/Uq27x4H1SEp8c3hV5uY1UW5dg9hTlucMO aCjlaSjorkZJsZBnvHj8e0HPhQsGw7UlePxTRM7Sp9Nd/YWR06qSz39DxPPoJD44kXa2 y+jGYwXnf4U9B3aE1s0VQhC9eZ2tY+B6oEDE19rCG3F64h/WCi/W6aCEf4c07Rzx4Ubq qbIATlOSP3oT/hfBmFlcNsDbwST9M4QRRYnl23nIdJWBcY8UD5F50ldjgthkbU2gw598 UpNA== X-Received: by 10.152.133.67 with SMTP id pa3mr10124834lab.44.1359292557651; Sun, 27 Jan 2013 05:15:57 -0800 (PST) Received: from gibbon.gmail.com (a91-154-115-217.elisa-laajakaista.fi. [91.154.115.217]) by mx.google.com with ESMTPS id gi3sm2350225lab.7.2013.01.27.05.15.55 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 05:15:56 -0800 (PST) Sender: Raphael Kubo da Costa From: Raphael Kubo da Costa To: hselasky@FreeBSD.org Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> <83wqv8nod7.fsf@FreeBSD.org> <20130120104526.GI14114@glebius.int.ru> Date: Sun, 27 Jan 2013 15:15:53 +0200 In-Reply-To: <20130120104526.GI14114@glebius.int.ru> (Gleb Smirnoff's message of "Sun, 20 Jan 2013 14:45:26 +0400") Message-ID: <87k3qyojg6.fsf@FreeBSD.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-net@FreeBSD.org, bug-followup@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 13:15:59 -0000 Gleb Smirnoff writes: > On Sun, Jan 20, 2013 at 08:24:36AM -0200, Raphael Kubo da Costa wrote: > R> glebius@FreeBSD.org writes: > R> > R> > Synopsis: [ng_ubt] [patch] Add vendor IDs for Broadcom USB > R> > dongles (BCM20702) > R> > > R> > Responsible-Changed-From-To: glebius->rakuco > R> > Responsible-Changed-By: glebius > R> > Responsible-Changed-When: Sun Jan 20 07:33:56 UTC 2013 > R> > Responsible-Changed-Why: > R> > Let Raphael handle the MFC. > R> > R> hselasky@ has already MFC'ed this to 9 a while ago. Do you think it is > R> safe enough to MFC to 8 and 7? > > You and Hans decide. > > The PR can be closed since fix already reached a stable branch. Hans, do you think it makes sense to MFC this to the other stable branches? I don't have 7 and 8 systems at hand to test this patch, so I'd like your feedback on the issue. Thanks. From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 16:14:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9421C695; Sun, 27 Jan 2013 16:14:33 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.c2i.net [212.247.154.130]) by mx1.freebsd.org (Postfix) with ESMTP id A557D935; Sun, 27 Jan 2013 16:14:32 +0000 (UTC) X-T2-Spam-Status: No, hits=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe05.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 367582444; Sun, 27 Jan 2013 17:09:23 +0100 From: Hans Petter Selasky To: Raphael Kubo da Costa Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) Date: Sun, 27 Jan 2013 17:10:37 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> <20130120104526.GI14114@glebius.int.ru> <87k3qyojg6.fsf@FreeBSD.org> In-Reply-To: <87k3qyojg6.fsf@FreeBSD.org> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 16:14:33 -0000 On Sunday 27 January 2013 14:15:53 Raphael Kubo da Costa wrote: > Gleb Smirnoff writes: > > On Sun, Jan 20, 2013 at 08:24:36AM -0200, Raphael Kubo da Costa wrote: > > R> glebius@FreeBSD.org writes: > > R> > > R> > Synopsis: [ng_ubt] [patch] Add vendor IDs for Broadcom USB > > R> > dongles (BCM20702) > > R> > > > R> > Responsible-Changed-From-To: glebius->rakuco > > R> > Responsible-Changed-By: glebius > > R> > Responsible-Changed-When: Sun Jan 20 07:33:56 UTC 2013 > > R> > Responsible-Changed-Why: > > R> > Let Raphael handle the MFC. > > R> > > R> hselasky@ has already MFC'ed this to 9 a while ago. Do you think it is > > R> safe enough to MFC to 8 and 7? > > > > You and Hans decide. > > > > The PR can be closed since fix already reached a stable branch. > > Hans, do you think it makes sense to MFC this to the other stable > branches? I don't have 7 and 8 systems at hand to test this patch, so > I'd like your feedback on the issue. Yes, 8 at least. Could try 7 too, but then you need to translate the patch into the old USB stack. --HPS From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 18:29:57 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 84B2437B; Sun, 27 Jan 2013 18:29:57 +0000 (UTC) (envelope-from kubito@gmail.com) Received: from mail-lb0-f169.google.com (mail-lb0-f169.google.com [209.85.217.169]) by mx1.freebsd.org (Postfix) with ESMTP id A6A51F74; Sun, 27 Jan 2013 18:29:56 +0000 (UTC) Received: by mail-lb0-f169.google.com with SMTP id m4so3018671lbo.0 for ; Sun, 27 Jan 2013 10:29:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=OAC0EtpqUFxQERLFssSnWCJPaCR77SCk0m+swOy30Y0=; b=cyjiQSvqWQ0o8sHIB4jSYWHEjRorcYxpeDgMn/oaJZu4Vp8hQXGYj020ejAYMT/xdX sUW0S9qLRPuCTm7JeFApi0Jh+DFG+5hhwl1JWNNXdgjW0PIcCxSoG1Cn5RhWmfl1z4ae g8wGboErzo9K7t2ZaOsaFYSvF0p+0SLKkAVCWFOSGzcqDRM5lKD/cbNlEgHYS4K1PclY 37d5DTveM7RHEhVJ41MXaXGaKHFsheHnts9iSqPrO4qE2WxWfQy4Rxib5eJO1WzQIq3N duyFEpHEV1PweSE76mDqomBkXEtPO1/h5PV32JrZ/yqc6J5X8TVaY8OT7MKRQ2DrQ9aT nV1w== X-Received: by 10.152.112.36 with SMTP id in4mr10892289lab.35.1359311395288; Sun, 27 Jan 2013 10:29:55 -0800 (PST) Received: from gibbon.gmail.com (a91-154-115-217.elisa-laajakaista.fi. [91.154.115.217]) by mx.google.com with ESMTPS id a5sm2652538lbl.1.2013.01.27.10.29.52 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 10:29:54 -0800 (PST) Sender: Raphael Kubo da Costa From: Raphael Kubo da Costa To: Hans Petter Selasky Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> <20130120104526.GI14114@glebius.int.ru> <87k3qyojg6.fsf@FreeBSD.org> <201301271710.38023.hselasky@c2i.net> Date: Sun, 27 Jan 2013 20:29:48 +0200 In-Reply-To: <201301271710.38023.hselasky@c2i.net> (Hans Petter Selasky's message of "Sun, 27 Jan 2013 17:10:37 +0100") Message-ID: <87bocao4wz.fsf@FreeBSD.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 18:29:57 -0000 Hans Petter Selasky writes: >> Hans, do you think it makes sense to MFC this to the other stable >> branches? I don't have 7 and 8 systems at hand to test this patch, so >> I'd like your feedback on the issue. > > Yes, 8 at least. Could try 7 too, but then you need to translate the patch > into the old USB stack. Right, I guess it's OK to leave 7 out. Are you willing to perform the MFC or would you like me to take care of it? From owner-freebsd-net@FreeBSD.ORG Sun Jan 27 19:07:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E2976BB5; Sun, 27 Jan 2013 19:07:13 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.c2i.net [212.247.154.98]) by mx1.freebsd.org (Postfix) with ESMTP id E99DD11A; Sun, 27 Jan 2013 19:07:12 +0000 (UTC) X-T2-Spam-Status: No, hits=-1.0 required=5.0 tests=ALL_TRUSTED Received: from [176.74.213.204] (account mc467741@c2i.net HELO laptop015.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.4.4) with ESMTPA id 370745577; Sun, 27 Jan 2013 20:07:09 +0100 From: Hans Petter Selasky To: Raphael Kubo da Costa Subject: Re: kern/174707: [ng_ubt] [patch] Add vendor IDs for Broadcom USB dongles (BCM20702) Date: Sun, 27 Jan 2013 20:08:24 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301200734.r0K7YH4w027535@freefall.freebsd.org> <201301271710.38023.hselasky@c2i.net> <87bocao4wz.fsf@FreeBSD.org> In-Reply-To: <87bocao4wz.fsf@FreeBSD.org> X-Face: ?p&W)c(+80hU; '{.$5K+zq{oC6y| /D'an*6mw>j'f:eBsex\Gi, Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 19:07:14 -0000 On Sunday 27 January 2013 19:29:48 Raphael Kubo da Costa wrote: > Hans Petter Selasky writes: > >> Hans, do you think it makes sense to MFC this to the other stable > >> branches? I don't have 7 and 8 systems at hand to test this patch, so > >> I'd like your feedback on the issue. > > > > Yes, 8 at least. Could try 7 too, but then you need to translate the > > patch into the old USB stack. > > Right, I guess it's OK to leave 7 out. Are you willing to perform the > MFC or would you like me to take care of it? Please do the MFC! I'm quite busy and might forget to do such stuff :-) --HPS From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 06:35:45 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C902ED8C; Mon, 28 Jan 2013 06:35:45 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by mx1.freebsd.org (Postfix) with ESMTP id 6E955BF2; Mon, 28 Jan 2013 06:35:45 +0000 (UTC) Received: by mail-pb0-f47.google.com with SMTP id rp8so514298pbb.34 for ; Sun, 27 Jan 2013 22:35:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:date:to:cc:subject:message-id:reply-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=2RacGay4nKiXjswap+LYj/1R3BklExGECrJVUYi2YcE=; b=jfDdnNRfagARNXe8mlBcGP6m59yqAXmAUhck8r3GUBB9aKYCz/AS2sLDQBQLPyTFAi RR2Ha8pOTsd4haaQKclcY/u/eIv/r99tR6CS5Dn4jNx3VKS/LM8U3cd9Q/5CKEVGptQ2 qqQCNGXBz2bcpn408+9hpu7F8CJRK5Ls97wwK7XYofCyTJjQbOhlI59q7udckpA7SmIn ktvckWbbowjY7eqpI7NoE7RcOgTPRuZna7igRLmHQVk7qR2L8SuVSMBduKg233e7JuDz ihjvOEv7Yu1n0INf2iNCcKKp65xNmO6MGZR2CmWNS3KwUFdJlofE/KOqGVVhL/6L+LDA pMBg== X-Received: by 10.66.84.195 with SMTP id b3mr33785573paz.30.1359354939703; Sun, 27 Jan 2013 22:35:39 -0800 (PST) Received: from pyunyh@gmail.com (lpe4.p59-icn.cdngp.net. [114.111.62.249]) by mx.google.com with ESMTPS id x6sm6157347paw.0.2013.01.27.22.35.35 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sun, 27 Jan 2013 22:35:38 -0800 (PST) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 28 Jan 2013 15:35:31 +0900 From: YongHyeon PYUN Date: Mon, 28 Jan 2013 15:35:31 +0900 To: Christian Gusenbauer Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Message-ID: <20130128063531.GC1447@michelle.cdnetworks.com> References: <201301241805.57623.c47g@gmx.at> <20130125043043.GA1429@michelle.cdnetworks.com> <20130125045048.GB1429@michelle.cdnetworks.com> <201301251809.50929.c47g@gmx.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201301251809.50929.c47g@gmx.at> User-Agent: Mutt/1.4.2.3i Cc: freebsd-fs@freebsd.org, Konstantin Belousov , net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 06:35:45 -0000 On Fri, Jan 25, 2013 at 06:09:50PM +0100, Christian Gusenbauer wrote: > On Friday 25 January 2013 05:50:48 YongHyeon PYUN wrote: > > On Fri, Jan 25, 2013 at 01:30:43PM +0900, YongHyeon PYUN wrote: > > > On Thu, Jan 24, 2013 at 05:21:50PM -0500, John Baldwin wrote: > > > > On Thursday, January 24, 2013 4:22:12 pm Konstantin Belousov wrote: > > > > > On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > > > > > > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > > > > > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian Gusenbauer > wrote: > > > > > > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > > > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin Belousov > wrote: > > > > > > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian > Gusenbauer wrote: > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get the > > > > > > > > > > > panic below if I execute the following commands (as > > > > > > > > > > > single user): > > > > > > > > > > > > > > > > > > > > > > # swapon -a > > > > > > > > > > > # dumpon /dev/ada0s3b > > > > > > > > > > > # mount -u / > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > > > > > > > > > > > > > then the system panics almost immediately. I'll attach > > > > > > > > > > > the stack trace. > > > > > > > > > > > > > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a 1Gbit > > > > > > > > > > > network, maybe that's the cause for the panic, because > > > > > > > > > > > the bcopy (see stack frame #15) fails. > > > > > > > > > > > > > > > > > > > > > > Any clues? > > > > > > > > > > > > > > > > > > > > I tried a similar operation with the nfs mount of > > > > > > > > > > rsize=32768 and mtu 6144, but the machine runs HEAD and em > > > > > > > > > > instead of age. I was unable to reproduce the panic on the > > > > > > > > > > copy of the 5GB file from nfs mount. > > > > > > > > > > > > > > > > Hmmm, I did a quick test. If I do not change the MTU, so just > > > > > > > > configuring age0 with > > > > > > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 up > > > > > > > > > > > > > > > > then I can copy all files from the mounted directory without > > > > > > > > any problems, too. So it's probably age0 related? > > > > > > > > > > > > > > From your backtrace and the buffer printout, I see somewhat > > > > > > > strange thing. The buffer data address is 0xffffff8171418000, > > > > > > > while kernel faulted at the attempt to write at > > > > > > > 0xffffff8171413000, which is is lower then the buffer data > > > > > > > pointer, at the attempt to bcopy to the buffer. > > > > > > > > > > > > > > The other data suggests that there were no overflow of the data > > > > > > > from the server response. So it might be that mbuf_len(mp) > > > > > > > returned negative number ? I am not sure is it possible at all. > > > > > > > > > > > > > > Try this debugging patch, please. You need to add INVARIANTS etc > > > > > > > to the kernel config. > > > > > > > > > > > > > > diff --git a/sys/fs/nfs/nfs_commonsubs.c > > > > > > > b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 > > > > > > > --- a/sys/fs/nfs/nfs_commonsubs.c > > > > > > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > > > > > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > > struct uio *uiop, int siz) } > > > > > > > > > > > > > > mbufcp = NFSMTOD(mp, caddr_t); > > > > > > > len = mbuf_len(mp); > > > > > > > > > > > > > > + KASSERT(len > 0, ("len %d", len)); > > > > > > > > > > > > > > } > > > > > > > xfer = (left > len) ? len : left; > > > > > > > > > > > > > > #ifdef notdef > > > > > > > > > > > > > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > > struct uio *uiop, int siz) uiop->uio_resid -= xfer; > > > > > > > > > > > > > > } > > > > > > > if (uiop->uio_iov->iov_len <= siz) { > > > > > > > > > > > > > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > > > > > > + uiop->uio_iovcnt)); > > > > > > > > > > > > > > uiop->uio_iovcnt--; > > > > > > > uiop->uio_iov++; > > > > > > > > > > > > > > } else { > > > > > > > > > > > > > > I thought that server have returned too long response, but it > > > > > > > seems to be not the case from your data. Still, I think the > > > > > > > patch below might be due. > > > > > > > > > > > > > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 100644 > > > > > > > --- a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio > > > > > > > *uiop, struct ucred *cred, NFSM_DISSECT(tl, u_int32_t *, > > > > > > > NFSX_UNSIGNED); > > > > > > > > > > > > > > eof = fxdr_unsigned(int, *tl); > > > > > > > > > > > > > > } > > > > > > > > > > > > > > - NFSM_STRSIZ(retlen, rsize); > > > > > > > + NFSM_STRSIZ(retlen, len); > > > > > > > > > > > > > > error = nfsm_mbufuio(nd, uiop, retlen); > > > > > > > if (error) > > > > > > > > > > > > > > goto nfsmout; > > > > > > > > > > > > I applied your patches and now I get a > > > > > > > > > > > > panic: len -4 > > > > > > cpuid = 1 > > > > > > KDB: enter: panic > > > > > > Dumping 377 out of 6116 > > > > > > MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% > > > > > > > > > > This means that the age driver either produced corrupted mbuf chain, > > > > > or filled wrong negative value into the mbuf len field. I am quite > > > > > certain that the issue is in the driver. > > > > > > > > > > I added the net@ to Cc:, hopefully you could get help there. > > > > > > > > And I've cc'd Pyun who has written most of this driver and is likely > > > > the one most familiar with its handling of jumbo frames. > > > > > > Try attached one and let me know how it goes. > > > Note, I don't have age(4) anymore so it wasn't tested at all. > > > > Sorry, ignore previous patch and use this one(age.diff2) instead. > > Thanks for the patch! I ignored the first and applied only the second one, but > unfortunately that did not change anything. I still get the "panic: len -4" > :-(. Ok, I contacted QAC and got a hint for its descriptor usage and I realized the controller does not work as I initially expected! When I wrote age(4) for the controller, the hardware was available only for a couple of weeks so I may have not enough time to test it. Sorry about that. I'll let you know when experimental patch is available. Due to lack of hardware, it would take more time than it used to be. Thanks for reporting! > > Ciao, > Christian. From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 06:40:01 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 24D94F0E for ; Mon, 28 Jan 2013 06:40:01 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ea0-f179.google.com (mail-ea0-f179.google.com [209.85.215.179]) by mx1.freebsd.org (Postfix) with ESMTP id B9C7FC26 for ; Mon, 28 Jan 2013 06:40:00 +0000 (UTC) Received: by mail-ea0-f179.google.com with SMTP id d12so977916eaa.10 for ; Sun, 27 Jan 2013 22:39:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=B1cCkKu23zkJPj3s4Wm30Ip50pF4/A8/XtdVS5EOyFo=; b=UszN9pETnSbaI1/mclHLoxiavii/rFVwJ1nPnX3R+/wJh8wbqVH1NBTVd1sOCmYOnV 6MaFrihfPCshDsHF1OBuZcR3osZWSuQUzfN15aLkFhNex2ca6SBO33NahetJHmRMwEnN SY5Jg4v6BkCijBve1ETtiTBDeRLkTjcg8W2oaCapTz2qBqsNLu5Xh77zeoiSSv9N4r5Q boUGM6ykSv/nw/cD4vzA2lKd7RHgtP697u9RjMgOY8D1m1JnEnlMRpbdsyFBJFcYo9Tr i9g5X6cs39FYAMZ6Ajt4k0yFzeH+4yu+MSxRYt3CbmKCW2iA+VU6OTmk7xtjGOpK4bzx 2uUA== MIME-Version: 1.0 X-Received: by 10.14.173.196 with SMTP id v44mr44217748eel.29.1359355193480; Sun, 27 Jan 2013 22:39:53 -0800 (PST) Received: by 10.223.161.80 with HTTP; Sun, 27 Jan 2013 22:39:53 -0800 (PST) Date: Sun, 27 Jan 2013 22:39:53 -0800 Message-ID: Subject: ixgbe & msi/x From: Vijay Singh To: net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 06:40:01 -0000 I am investigating an issue where the ixgbe (82599) device is hung and I think I have traced it to the driver not getting interrupts. I have MSI/X enabled, with 2 rx/tx queues. I am trying to understand this bit of code in the MSI/X setup: if (ixgbe_enable_msix) { ixgbe_configure_ivars(adapter); /* Set up auto-mask */ <<== THIS BIT if (hw->mac.type == ixgbe_mac_82598EB) IXGBE_WRITE_REG(hw, IXGBE_EIAM, IXGBE_EICS_RTX_QUEUE); else { IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(0), 0xFFFFFFFF); IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(1), 0xFFFFFFFF); } } Does this mean that ixgbe_disable_queue() is not needed in the msi/x interrupt handler - ixgbe_msix_que()? -vijay From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 07:05:01 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C8023C9 for ; Mon, 28 Jan 2013 07:05:01 +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 04429D67 for ; Mon, 28 Jan 2013 07:05:00 +0000 (UTC) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id 3C76B7300A; Mon, 28 Jan 2013 08:04:39 +0100 (CET) Date: Mon, 28 Jan 2013 08:04:39 +0100 From: Luigi Rizzo To: Vijay Singh Subject: Re: ixgbe & msi/x Message-ID: <20130128070439.GB85353@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: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 07:05:01 -0000 On Sun, Jan 27, 2013 at 10:39:53PM -0800, Vijay Singh wrote: > I am investigating an issue where the ixgbe (82599) device is hung and > I think I have traced it to the driver not getting interrupts. I have > MSI/X enabled, with 2 rx/tx queues. just curious, is this happening under behyve or also native, and is it always occurring or it is occasional ? I am asking because with netmap when i tried to exploit interrupt mitigation (strictly processing incoming traffic only on rx interrupts) i noticed packet drops even at relatively low rates, which made me suspect that interrupts were either lost or heavily delayed. I did not pursue the problem and implemented a workaround (peek at the ring before blocking -- there is a netmap sysctl that controls that), but in light of your comment it might be interesting to investigate the problem again. It could be also worthwhile to compare netmap behaviour under FreeBSD and linux to see if the problem appears only on one platform (hence pointing out a driver issue) or on both (in which case no conclusion can be drawn). cheers luigi > I am trying to understand this bit of code in the MSI/X setup: > > if (ixgbe_enable_msix) { > ixgbe_configure_ivars(adapter); > /* Set up auto-mask */ <<== THIS BIT > if (hw->mac.type == ixgbe_mac_82598EB) > IXGBE_WRITE_REG(hw, IXGBE_EIAM, IXGBE_EICS_RTX_QUEUE); > else { > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(0), 0xFFFFFFFF); > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(1), 0xFFFFFFFF); > } > } > > Does this mean that ixgbe_disable_queue() is not needed in the msi/x > interrupt handler - ixgbe_msix_que()? > > -vijay > _______________________________________________ > 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 Jan 28 11:06:47 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DACD295E for ; Mon, 28 Jan 2013 11:06:47 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CC456CDD for ; Mon, 28 Jan 2013 11:06:47 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0SB6loi034630 for ; Mon, 28 Jan 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0SB6l7T034628 for freebsd-net@FreeBSD.org; Mon, 28 Jan 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 28 Jan 2013 11:06:47 GMT Message-Id: <201301281106.r0SB6l7T034628@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:06:47 -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/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171728 net [arp] arp issue o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 440 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 11:10:21 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0B70E22A; Mon, 28 Jan 2013 11:10:21 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 8AC57EBE; Mon, 28 Jan 2013 11:10:20 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r0SBAD2v074620; Mon, 28 Jan 2013 15:10:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r0SBADNn074619; Mon, 28 Jan 2013 15:10:13 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Mon, 28 Jan 2013 15:10:13 +0400 From: Gleb Smirnoff To: Andriy Gapon Subject: Re: ng_ether naming Message-ID: <20130128111013.GI53596@FreeBSD.org> References: <50C9C012.8020306@FreeBSD.org> <50C9C55A.5090900@ipfw.ru> <50CA0161.1060000@FreeBSD.org> <50CB5B8A.8030703@FreeBSD.org> <75277A1B-B434-4220-A800-9004C29DA92A@gmail.com> <51050CA5.8030805@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <51050CA5.8030805@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: Ermal Lu?i , Nikolay Denev , "Alexander V. Chernikov" , freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 11:10:21 -0000 On Sun, Jan 27, 2013 at 01:16:53PM +0200, Andriy Gapon wrote: A> based on your suggestions and submissions I've produced the following patch: A> http://people.freebsd.org/~avg/ng_ether-renaming.diff A> A> It's only compile-tested at the moment :) A> but I'd like to get your opinion about the direction of the change(s). A> I am going to really test the change very soon. Patch is okay. If you wan't to close all related PRs, you also need to patch ppp(8), so that it does same sanitation of interface names when running PPPoE. And probably drop a note to Dmitry, who maintains mpd5. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 15:44:56 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DAF709B4 for ; Mon, 28 Jan 2013 15:44:56 +0000 (UTC) (envelope-from c47g@gmx.at) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by mx1.freebsd.org (Postfix) with ESMTP id 866E167E for ; Mon, 28 Jan 2013 15:44:56 +0000 (UTC) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LwkgY-1V5zEF2dcu-016LOi for ; Mon, 28 Jan 2013 16:44:55 +0100 Received: (qmail invoked by alias); 28 Jan 2013 15:44:55 -0000 Received: from cm56-168-232.liwest.at (EHLO bones.gusis.at) [86.56.168.232] by mail.gmx.net (mp012) with SMTP; 28 Jan 2013 16:44:55 +0100 X-Authenticated: #9978462 X-Provags-ID: V01U2FsdGVkX1+RNOEagoaR8Aj+CRm8gJ6VegtnFdM0y+SAncGTcB 2AVQOib+LqwOIQ From: Christian Gusenbauer To: pyunyh@gmail.com Subject: Re: 9.1-stable crashes while copying data from a NFS mounted directory Date: Mon, 28 Jan 2013 16:46:43 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) References: <201301241805.57623.c47g@gmx.at> <201301251809.50929.c47g@gmx.at> <20130128063531.GC1447@michelle.cdnetworks.com> In-Reply-To: <20130128063531.GC1447@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301281646.43551.c47g@gmx.at> X-Y-GMX-Trusted: 0 Cc: freebsd-fs@freebsd.org, Konstantin Belousov , net@freebsd.org, John Baldwin , yongari@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:44:56 -0000 On Monday 28 January 2013 07:35:31 YongHyeon PYUN wrote: > On Fri, Jan 25, 2013 at 06:09:50PM +0100, Christian Gusenbauer wrote: > > On Friday 25 January 2013 05:50:48 YongHyeon PYUN wrote: > > > On Fri, Jan 25, 2013 at 01:30:43PM +0900, YongHyeon PYUN wrote: > > > > On Thu, Jan 24, 2013 at 05:21:50PM -0500, John Baldwin wrote: > > > > > On Thursday, January 24, 2013 4:22:12 pm Konstantin Belousov wrote: > > > > > > On Thu, Jan 24, 2013 at 09:50:52PM +0100, Christian Gusenbauer wrote: > > > > > > > On Thursday 24 January 2013 20:37:09 Konstantin Belousov wrote: > > > > > > > > On Thu, Jan 24, 2013 at 07:50:49PM +0100, Christian > > > > > > > > Gusenbauer > > > > wrote: > > > > > > > > > On Thursday 24 January 2013 19:07:23 Konstantin Belousov wrote: > > > > > > > > > > On Thu, Jan 24, 2013 at 08:03:59PM +0200, Konstantin > > > > > > > > > > Belousov > > > > wrote: > > > > > > > > > > > On Thu, Jan 24, 2013 at 06:05:57PM +0100, Christian > > > > Gusenbauer wrote: > > > > > > > > > > > > Hi! > > > > > > > > > > > > > > > > > > > > > > > > I'm using 9.1 stable svn revision 245605 and I get > > > > > > > > > > > > the panic below if I execute the following commands > > > > > > > > > > > > (as single user): > > > > > > > > > > > > > > > > > > > > > > > > # swapon -a > > > > > > > > > > > > # dumpon /dev/ada0s3b > > > > > > > > > > > > # mount -u / > > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 mtu 6144 up > > > > > > > > > > > > # mount -t nfs -o rsize=32768 data:/multimedia /mnt > > > > > > > > > > > > # cp /mnt/Movies/test/a.m2ts /tmp > > > > > > > > > > > > > > > > > > > > > > > > then the system panics almost immediately. I'll > > > > > > > > > > > > attach the stack trace. > > > > > > > > > > > > > > > > > > > > > > > > Note, that I'm using jumbo frames (6144 byte) on a > > > > > > > > > > > > 1Gbit network, maybe that's the cause for the panic, > > > > > > > > > > > > because the bcopy (see stack frame #15) fails. > > > > > > > > > > > > > > > > > > > > > > > > Any clues? > > > > > > > > > > > > > > > > > > > > > > I tried a similar operation with the nfs mount of > > > > > > > > > > > rsize=32768 and mtu 6144, but the machine runs HEAD and > > > > > > > > > > > em instead of age. I was unable to reproduce the panic > > > > > > > > > > > on the copy of the 5GB file from nfs mount. > > > > > > > > > > > > > > > > > > Hmmm, I did a quick test. If I do not change the MTU, so > > > > > > > > > just configuring age0 with > > > > > > > > > > > > > > > > > > # ifconfig age0 inet 192.168.2.2 up > > > > > > > > > > > > > > > > > > then I can copy all files from the mounted directory > > > > > > > > > without any problems, too. So it's probably age0 related? > > > > > > > > > > > > > > > > From your backtrace and the buffer printout, I see somewhat > > > > > > > > strange thing. The buffer data address is 0xffffff8171418000, > > > > > > > > while kernel faulted at the attempt to write at > > > > > > > > 0xffffff8171413000, which is is lower then the buffer data > > > > > > > > pointer, at the attempt to bcopy to the buffer. > > > > > > > > > > > > > > > > The other data suggests that there were no overflow of the > > > > > > > > data from the server response. So it might be that > > > > > > > > mbuf_len(mp) returned negative number ? I am not sure is it > > > > > > > > possible at all. > > > > > > > > > > > > > > > > Try this debugging patch, please. You need to add INVARIANTS > > > > > > > > etc to the kernel config. > > > > > > > > > > > > > > > > diff --git a/sys/fs/nfs/nfs_commonsubs.c > > > > > > > > b/sys/fs/nfs/nfs_commonsubs.c index efc0786..9a6bda5 100644 > > > > > > > > --- a/sys/fs/nfs/nfs_commonsubs.c > > > > > > > > +++ b/sys/fs/nfs/nfs_commonsubs.c > > > > > > > > @@ -218,6 +218,7 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > > > struct uio *uiop, int siz) } > > > > > > > > > > > > > > > > mbufcp = NFSMTOD(mp, caddr_t); > > > > > > > > len = mbuf_len(mp); > > > > > > > > > > > > > > > > + KASSERT(len > 0, ("len %d", len)); > > > > > > > > > > > > > > > > } > > > > > > > > xfer = (left > len) ? len : left; > > > > > > > > > > > > > > > > #ifdef notdef > > > > > > > > > > > > > > > > @@ -239,6 +240,8 @@ nfsm_mbufuio(struct nfsrv_descript *nd, > > > > > > > > struct uio *uiop, int siz) uiop->uio_resid -= xfer; > > > > > > > > > > > > > > > > } > > > > > > > > if (uiop->uio_iov->iov_len <= siz) { > > > > > > > > > > > > > > > > + KASSERT(uiop->uio_iovcnt > 1, ("uio_iovcnt %d", > > > > > > > > + uiop->uio_iovcnt)); > > > > > > > > > > > > > > > > uiop->uio_iovcnt--; > > > > > > > > uiop->uio_iov++; > > > > > > > > > > > > > > > > } else { > > > > > > > > > > > > > > > > I thought that server have returned too long response, but it > > > > > > > > seems to be not the case from your data. Still, I think the > > > > > > > > patch below might be due. > > > > > > > > > > > > > > > > diff --git a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > > b/sys/fs/nfsclient/nfs_clrpcops.c index be0476a..a89b907 > > > > > > > > 100644 --- a/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > > +++ b/sys/fs/nfsclient/nfs_clrpcops.c > > > > > > > > @@ -1444,7 +1444,7 @@ nfsrpc_readrpc(vnode_t vp, struct uio > > > > > > > > *uiop, struct ucred *cred, NFSM_DISSECT(tl, u_int32_t *, > > > > > > > > NFSX_UNSIGNED); > > > > > > > > > > > > > > > > eof = fxdr_unsigned(int, *tl); > > > > > > > > > > > > > > > > } > > > > > > > > > > > > > > > > - NFSM_STRSIZ(retlen, rsize); > > > > > > > > + NFSM_STRSIZ(retlen, len); > > > > > > > > > > > > > > > > error = nfsm_mbufuio(nd, uiop, retlen); > > > > > > > > if (error) > > > > > > > > > > > > > > > > goto nfsmout; > > > > > > > > > > > > > > I applied your patches and now I get a > > > > > > > > > > > > > > panic: len -4 > > > > > > > cpuid = 1 > > > > > > > KDB: enter: panic > > > > > > > Dumping 377 out of 6116 > > > > > > > MB:..5%..13%..22%..34%..43%..51%..64%..73%..81%..94% > > > > > > > > > > > > This means that the age driver either produced corrupted mbuf > > > > > > chain, or filled wrong negative value into the mbuf len field. I > > > > > > am quite certain that the issue is in the driver. > > > > > > > > > > > > I added the net@ to Cc:, hopefully you could get help there. > > > > > > > > > > And I've cc'd Pyun who has written most of this driver and is > > > > > likely the one most familiar with its handling of jumbo frames. > > > > > > > > Try attached one and let me know how it goes. > > > > Note, I don't have age(4) anymore so it wasn't tested at all. > > > > > > Sorry, ignore previous patch and use this one(age.diff2) instead. > > > > Thanks for the patch! I ignored the first and applied only the second > > one, but unfortunately that did not change anything. I still get the > > "panic: len -4" > > > > :-(. > > Ok, I contacted QAC and got a hint for its descriptor usage and I > realized the controller does not work as I initially expected! > When I wrote age(4) for the controller, the hardware was available > only for a couple of weeks so I may have not enough time to test > it. Sorry about that. > I'll let you know when experimental patch is available. Due to lack > of hardware, it would take more time than it used to be. > > Thanks for reporting! Thanks for investing your time! I'm looking forward to test your next patch(es) :-)! Ciao, Christian. From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 17:15:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7BB5DAF5 for ; Mon, 28 Jan 2013 17:15:21 +0000 (UTC) (envelope-from pkeusem@visi.com) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by mx1.freebsd.org (Postfix) with ESMTP id 012BBD4E for ; Mon, 28 Jan 2013 17:15:20 +0000 (UTC) Received: from [173.17.248.27] (account pkeusem@visi.com HELO [172.16.175.217]) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPSA id 95477685; Mon, 28 Jan 2013 11:15:13 -0600 Message-ID: <5106B21F.4060609@visi.com> Date: Mon, 28 Jan 2013 11:15:11 -0600 From: Paul Keusemann User-Agent: Mozilla/5.0 (X11; SunOS sun4u; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marius Strobl Subject: Re: Cas driver fails to load first time after boot. References: <50FEFAB8.1070006@visi.com> <20130124150904.GA27559@alchemy.franken.de> <51017FF0.5080001@visi.com> <20130124215017.GS85306@alchemy.franken.de> <5101F264.7030206@visi.com> <20130125161916.GV85306@alchemy.franken.de> <5102D9AB.9010405@visi.com> <20130125233409.GZ85306@alchemy.franken.de> In-Reply-To: <20130125233409.GZ85306@alchemy.franken.de> X-Is-From-Me: yes Content-Type: multipart/mixed; boundary="------------090706020109010001000202" Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:15:21 -0000 This is a multi-part message in MIME format. --------------090706020109010001000202 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 01/25/13 17:34, Marius Strobl wrote: > On Fri, Jan 25, 2013 at 01:14:51PM -0600, Paul Keusemann wrote: >> On 01/25/13 10:19, Marius Strobl wrote: >>> On Thu, Jan 24, 2013 at 08:48:04PM -0600, Paul Keusemann wrote: >>>> On 01/24/13 15:50, Marius Strobl wrote: >>>>> On Thu, Jan 24, 2013 at 12:39:44PM -0600, Paul Keusemann wrote: >>>>>> On 01/24/13 09:09, Marius Strobl wrote: >>>>>>> On Tue, Jan 22, 2013 at 02:46:48PM -0600, Paul Keusemann wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've got a Dell R200 which I'm trying to build into a gateway with a Sun >>>>>>>> QGE (501-6738-10). The cas driver fails to load the first time I try to >>>>>>>> load it but succeeds the second time. Is this a problem with the card, >>>>>>>> the driver, my karma? >>>>>>> Wrong phase of the moon, apparently :) >>>>>>> The MII setup of these chips is a bit tricky and I'm not sure whether >>>>>>> I've hit all code paths during development of the driver. I certainly >>>>>>> didn't test with a 501-6738, these have been reported as working before, >>>>>>> though. It also doesn't make much sense that attaching the devices >>>>>>> succeeds on the second attempt. Could you please use a if_cas.ko built >>>>>>> with the attached patch and report the debug output for one of the >>>>>>> interfaces in both the working and the non-working case? >>>>>> I would love to give you output from the working and non-working case >>>>>> but apparently the phase of the moon has changed, I can't get it to fail >>>>>> now. The messages output from the working case is attached. >>>>>> >>>>> Thanks but unfortunately this doesn't make any sense either. In general, >>>>> printf()s cause deays which can be relevant. In the locations I've put >>>>> them they hardly can make such a difference though. >>>>> If you haven't already done so, could you please power off the machine >>>>> before doing the test with the patched module? Is the problem still gone >>>>> if you revert to the original module? >>>> OK, power-cycling makes a difference. The driver fails to attach all of >>>> the devices after power-cycling most of the time if not all of the >>>> time. The number of devices attached varies, the attached message file >>>> fragment is from my last test. Three of the devices were attached on >>>> the first load attempt and all four of them on the second attempt. >>> Okay, so we now at least have a way to reproduce the problem. >>> Unfortunately, it's still unclear what's the exact cause of it. At >>> least the problem is not what I suspected and hoped it most likely is. >>> Could you please test how things behave after a power-cycle with the >>> attached patche (after reverting the previous one). >> The patched driver fails to compile with the following error message: >> > <...> > >> I found the following defintion of nitems in the iwn and usb/wlan drivers: >> >> #define nitems(_a) (sizeof((_a)) / sizeof((_a)[0])) >> >> so I added it to if_cas.c and rebuilt without errors. >> > Sorry, I didn't think of 8.3 not having nitems(), yet. Actually, > this part of the patch is orthogonal to your problem and just a > change I had in that tree. > >> This looks like like it fixed the problem. I ran three tests from >> power-up to loading the driver and the driver loaded successfully all >> three times. I then added if_cas_load="YES" to /boot/loader.conf and >> did two more successful reboots from power-up. > Great! Thanks a lot for testing! > >> Will this driver work on FreeBSD 9.1? >> > Yes, the patch should also solve the problem in 9.1. I suspect the > hang you are seeing there isn't specific to cas(4) but rather a > general regression that came in with the VIMAGE changes. Now, if > a network device driver fails to attach during boot and tries to > clean up by detaching and freeing the interface part at that stage > again this causes problems. I already talked to bz@ about this and > what I remember from his reply this is an ordering issue that is at > least very hard to fix. OK. I've successfully upgraded from 8.3-Release to 9.1-Release. I stupidly powered-down the machine after the upgrade, so I had to remove the QGE card to get it to boot 9.1 and build a custom kernel. The patch applied cleanly, the kernel built without errors and boots from power-up without problems. I've attached the most recent messages file, dmesg, kldstat and ifconfig output if you're interested. The only odd thing I noticed was that cas0 and cas3 log messages: "cannot disable RX MAC" but cas1 and cas2 do not. I haven't actually tried any of the interfaces yet but I assume they'll work as expected. Let me know if there's anything further testing you'd like me to do. Thanks so much for your help with this, it is much appreciated. Paul > > Marius > > -- Paul Keusemann pkeusem@visi.com 4266 Joppa Court (952) 894-7805 Savage, MN 55378 --------------090706020109010001000202 Content-Type: text/plain; charset=us-ascii; name="dmesg.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dmesg.out" Copyright (c) 1992-2012 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.1-RELEASE #4: Mon Jan 28 09:02:45 CST 2013 toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.45-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Features=0xbfebfbff Features2=0xe3bd AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 4092600320 (3903 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0: Changing APIC ID to 4 ioapic1: Changing APIC ID to 5 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 32-55 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: Power Button (fixed) cpu0: on acpi0 cpu1: on acpi0 cpu2: on acpi0 cpu3: on acpi0 atrtc0: port 0x70-0x7f irq 8 on acpi0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: port 0x40-0x5f irq 0 on acpi0 Timecounter "i8254" frequency 1193182 Hz quality 0 Event timer "i8254" frequency 1193182 Hz quality 100 hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 950 Event timer "HPET" frequency 14318180 Hz quality 450 Event timer "HPET1" frequency 14318180 Hz quality 440 Event timer "HPET2" frequency 14318180 Hz quality 440 Event timer "HPET3" frequency 14318180 Hz quality 440 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 pcib2: irq 16 at device 28.0 on pci0 pci2: on pcib2 pcib3: at device 0.0 on pci2 pci3: on pcib3 pcib4: at device 2.0 on pci3 pci4: on pcib4 cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 cas0: cannot disable RX MAC miibus0: on cas0 nsgphy0: PHY 1 on miibus0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas0: 16kB RX FIFO, 9kB TX FIFO cas0: Ethernet address: 00:14:4f:25:ca:10 cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 miibus1: on cas1 nsgphy1: PHY 1 on miibus1 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas1: 16kB RX FIFO, 9kB TX FIFO cas1: Ethernet address: 00:14:4f:25:ca:11 cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 miibus2: on cas2 nsgphy2: PHY 1 on miibus2 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas2: 16kB RX FIFO, 9kB TX FIFO cas2: Ethernet address: 00:14:4f:25:ca:12 cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 cas3: cannot disable RX MAC miibus3: on cas3 nsgphy3: PHY 1 on miibus3 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow cas3: 16kB RX FIFO, 9kB TX FIFO cas3: Ethernet address: 00:14:4f:25:ca:13 pcib5: irq 16 at device 28.4 on pci0 pci5: on pcib5 bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus4: on bge0 brgphy0: PHY 1 on miibus4 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:19:b9:fa:82:51 pcib6: irq 17 at device 28.5 on pci0 pci6: on pcib6 bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E miibus5: on bge1 brgphy1: PHY 1 on miibus5 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:19:b9:fa:82:52 uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 usbus0 on uhci0 uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 usbus1 on uhci1 uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 usbus2 on uhci2 ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 usbus3: EHCI version 1.0 usbus3 on ehci0 pcib7: at device 30.0 on pci0 pci7: on pcib7 vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 ata2: at channel 0 on atapci0 ata3: at channel 1 on atapci0 fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: does not respond device_attach: fdc0 attach returned 6 uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 fdc0: No FDOUT register! ppc0: cannot reserve I/O port range ctl: CAM Target Layer loaded est0: on cpu0 p4tcc0: on cpu0 est1: on cpu1 p4tcc1: on cpu1 est2: on cpu2 p4tcc2: on cpu2 est3: on cpu3 p4tcc3: on cpu3 Timecounters tick every 1.000 msec usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 480Mbps High Speed USB v2.0 ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 uhub0: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub3: 6 ports with 6 removable, self powered ada0 at ata2 bus 0 scbus0 target 0 lun 0 ada0: ATA-7 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) ada0: 76293MB (156250000 512 byte sectors: 16H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! cd0 at ata2 bus 0 scbus0 target 1 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, SMP: AP CPU #2 Launched! PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Timecounter "TSC-low" frequency 16667601 Hz quality 1000 Root mount waiting for: usbus3 ugen3.2: at usbus3 uhub4: on usbus3 uhub4: MTT enabled uhub4: 4 ports with 4 removable, self powered Trying to mount root from ufs:/dev/ad4s1a [rw]... bge0: link state changed to UP --------------090706020109010001000202 Content-Type: text/plain; charset=us-ascii; name="ifconfig.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ifconfig.out" cas0: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:10 nd6 options=29 media: Ethernet autoselect cas1: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:11 nd6 options=29 media: Ethernet autoselect cas2: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:12 nd6 options=29 media: Ethernet autoselect cas3: flags=8802 metric 0 mtu 1500 options=b ether 00:14:4f:25:ca:13 nd6 options=29 media: Ethernet autoselect bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:19:b9:fa:82:51 inet 172.16.175.221 netmask 0xffffff00 broadcast 172.16.175.255 inet6 fe80::219:b9ff:fefa:8251%bge0 prefixlen 64 scopeid 0x5 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active bge1: flags=8802 metric 0 mtu 1500 options=8009b ether 00:19:b9:fa:82:52 nd6 options=29 media: Ethernet autoselect (none) status: no carrier lo0: flags=8049 metric 0 mtu 16384 options=600003 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0xb inet 127.0.0.1 netmask 0xff000000 nd6 options=21 --------------090706020109010001000202 Content-Type: text/plain; charset=us-ascii; name="kldstat.out" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="kldstat.out" Id Refs Address Size Name 1 1 0xffffffff80200000 1323488 kernel (/boot/kernel/kernel) Contains modules: Id Name 412 newreno 401 if_lo 389 elf64 455 elf32 390 shell 364 pseudofs 402 if_tun 321 uether 400 if_gif 403 if_vlan 398 if_faith 413 mld 411 igmp 394 sysvmsg 395 sysvsem 396 sysvshm 415 nfssvc 359 nfscommon 362 nfsd 420 krpc 416 nfslockd 357 devfs 363 procfs 421 ufs 388 cd9660 360 nfs 358 msdosfs 361 nfscl 9 cbb 10 cbr 1 cam 63 ata 15 ses 8 ada 373 g_part_mbr 372 g_part_gpt 371 g_part_ebr 370 g_part_bsd 317 uhub/rue 14 sa 13 pass 5 probe 137 pci/fxp 7 ch 4 pmp 12 da 6 cd 2 xpt 11 ctl 110 pci/dc 355 pci/xl 3 aprobe 79 pci/ata_intel 266 pci/snd_hda 78 pci/ata_highpoint 477 root/nexus 476 nexus/ram 475 isa/sysresource 265 hdacc/snd_hda 264 hdaa/snd_hda_pcm 263 pci/snd_via8233 262 pci/snd_ich 261 pci/snd_es137x 260 emu10kx/snd_emu10kx_midi 259 emu10kx/snd_emu10kx_pcm 474 pci/ioapic 473 nexus/apic 258 pci/snd_emu10kx 257 csa/snd_csapcm 472 nexus/qpi 471 qpi/pcib 256 pci/snd_csa 470 legacy/pcib 469 isa/pcibus_pnp 468 isa/orm 467 isa/atdma 466 acpi/atdma 465 legacy/isa 255 pci/snd_cmi 464 isa/attimer 463 acpi/attimer 462 isa/atrtc 461 acpi/atrtc 460 cpu/p4tcc 459 cpu/hwpstate 77 pci/ata_cyrix 254 pccard/sn 458 cpu/est 457 cpu/powernow 253 isa/sn 121 pci/lem 252 pci/skc 251 skc/sk 250 sk/miibus 249 pci/sis 248 sis/miibus 76 pci/ata_cypress 247 pci/siis 246 siis/siisch 245 pci/sge 244 sge/miibus 243 pci/sf 242 sf/miibus 75 pci/ata_cenatek 35 acpi/acpi_smbat 74 pci/ata_ati 454 isa/vga 453 vgapci/vgapm 452 isa/sc 73 pci/ata_amd 451 pci/isci 450 scrndr-vga 449 scterm-scteken 241 pci/re 240 re/miibus 72 pci/ata_adaptec 448 pci/nfe 447 nfe/miibus 446 pci/hptrr 445 pci/hptmv 444 pccard/fdc 443 isa/fdc 442 acpi/fdc 441 fdc/fd 440 io 391 cpu/cpufreq 439 vesa 239 random 438 isa/ed 238 pci/ral 237 pci/puc 437 atkbdc/psm 436 isa/psmcpnp 435 acpi/psmcpnp 236 pccard/puc 434 isa/atkbdc 433 acpi/atkbdc 432 atkbdc/atkbd 431 pci/arcmsr 430 hostb/agp_via 429 hostb/agp_intel 428 vgapci/agp_i810 427 hostb/agp_amd64 71 pci/ata_ali 235 pty 234 puc/ppc 233 pci/ppc 232 isa/ppc 231 acpi/ppc 230 ppbus/ppi 70 pci/ata_acard 229 ppc/ppbus 228 ppbus/lpt 69 pci/ata_ahci 426 nexus/legacy 425 legacy/cpu 424 acpi/fpupnp 227 ppbus/plip 226 pci/pcn 225 pcn/miibus 68 atapci/ata_ahci_ata 387 isab/isa 423 root/nexus_acpi 386 eisab/isa 224 pci/vgapci 223 pci/pcib 222 pcib/pci 120 pci/em 34 acpi/acpi_sysresource 67 pci/atapci 66 atapci/ata 65 isa/ata 64 pccard/ata 23 acpi/acpi_cmbat 22 acpi/acpi_button 221 pci/isab 220 pci/ignore_pci 219 pci/hostb 218 pci/fixup_pci 217 pci/cbb 16 aac/aacp 33 cpu/acpi_perf 216 isa/cbb 62 pci/an 61 pccard/an 119 pci/ed 118 pccard/ed 117 ed/miibus 116 pci/dpt 215 pcic/pccard 214 cbb/pccard 213 null 212 pci/nge 211 nge/miibus 210 pci/mwl 115 pci/de 114 dcons 60 isa/an 113 firewire/dcons_crom 112 miibus/pnphy 111 miibus/dcphy 209 pci/mvs 109 dc/miibus 208 mvs/mvsch 207 sata/mvsch 108 pccard/cs 107 isa/cs 21 acpi/acpi_acad 206 pci/mskc 205 mskc/msk 204 msk/miibus 59 pci/amr 106 cpu/ichss 58 amr/amrd 201 pci/mpt 105 pci/ciss 32 pci/acpi_pcib 31 acpi/acpi_pcib 25 acpi/acpi_ec 57 pci/ale 198 pci/mps 104 pci/cas 197 pci/mly 196 pci/mlx 195 mlx/mlxd 194 miibus/xmphy 193 miibus/ukphy 192 miibus/truephy 191 miibus/tlphy 419 pci/rl 418 cardbus/rl 417 rl/miibus 190 miibus/tdkphy 189 miibus/smcphy 188 miibus/rlphy 187 miibus/rgephy 186 miibus/rdcphy 414 nfslock 185 miibus/qsphy 184 miibus/pnaphy 183 miibus/nsphyter 182 miibus/nsphy 181 miibus/nsgphy 180 miibus/mlphy 179 miibus/lxtphy 178 miibus/jmphy 177 miibus/ip1000phy 176 miibus/icsphy 175 miibus/gentbi 174 miibus/e1000phy 173 miibus/ciphy 172 miibus/brgphy 171 miibus/bmtphy 170 miibus/axphy 169 miibus/atphy 168 miibus/amphy 167 miibus/acphy 166 mfi/mfisyspd 165 mfi/mfid 164 pci/mfi 103 cas/miibus 56 ale/miibus 19 pci/aac 102 cbb/cardbus 101 pci/bxe 18 pci/aacch 163 mem 55 pci/alc 54 alc/miibus 53 ahc 52 ahd 161 pci/malo 51 pci/ahd 50 pci/ahc_pci 49 isa/ahc_isa 100 pci/bt 99 isa/bt 160 pci/lge 159 lge/miibus 98 pci/bge 356 miibus/xlphy 354 xl/miibus 353 pccard/xe 352 pci/wpi 351 pci/wi 350 pccard/wi 349 pci/wb 348 wb/miibus 347 watchdog 346 pci/vx 345 pci/vr 344 vr/miibus 158 pci/le 343 pci/vge 342 vge/miibus 97 bge/miibus 341 uhub/ums 157 kbdmux 48 pccard/aic 340 uhub/ukbd 339 uhub/uhid 96 pci/bfe 156 pci/jme 155 jme/miibus 154 pci/ixv 338 uhub/uvscom 337 uhub/uvisor 336 uhub/uslcom 335 uhub/uplcom 334 uhub/ulpt 333 uhub/uipaq 332 uhub/uftdi 331 uhub/ubsa 330 uhub/uark 329 uhub/u3g 328 uhub/zyd 95 bfe/miibus 327 uhub/urtw 326 uhub/ural 325 uhub/if_upgt 94 pci/bce 324 uhub/uath 323 uhub/run 322 uhub/rum 320 miibus/ruephy 319 uhub/udav 318 udav/miibus 316 rue/miibus 315 uhub/kue 314 uhub/cue 313 uhub/cdce 312 uhub/axe 311 axe/miibus 310 uhub/aue 309 aue/miibus 93 bce/miibus 30 acpi/acpi_pci_link 24 acpi/cpu 308 usbus/uhub 307 uhub/uhub 47 pci/ahci 153 pci/ixgbe 46 atapci/ahci 45 ahci/ahcich 29 pcib/acpi_pci 20 nexus/acpi 28 acpi/acpi_lid 44 pci/age 43 age/miibus 42 pci/ae 306 uhub/usb_linux 305 uhub/urio 152 pci/iwn 304 uhub/umass 151 pci/iwi 150 pci/isp 149 pci/ipw 303 ohci/usbus 302 uhci/usbus 301 ehci/usbus 300 xhci/usbus 299 at91_udp/usbus 298 musbotg/usbus 297 uss820/usbus 296 pci/xhci 148 pci/ips 295 pci/uhci 147 ips/ipsd 41 ae/miibus 294 pci/ohci 146 pci/iir 293 pci/ehci 27 acpi/acpi_isab 145 pci/ida 144 ida/idad 143 pci/hptiop 142 pci/hme 292 puc/uart 291 pci/uart 290 pccard/uart 289 isa/uart 288 acpi/uart 141 hme/miibus 287 pci/txp 286 pci/tx 285 tx/miibus 140 pci/gem 139 gem/miibus 138 miibus/inphy 284 pci/tws 136 fxp/miibus 40 pci/adw 283 pci/twe 282 twe/twed 39 pci/adv 135 firewire/fwip 281 pci/twa 280 pci/trm 279 pci/tl 278 tl/miibus 277 pci/ti 38 acpi/acpi_timer 37 cpu/acpi_throttle 276 pci/sym 275 pci/stge 274 stge/miibus 273 pci/ste 272 ste/miibus 36 acpi/acpi_tz 271 midi 270 uaudio/ua_pcm 17 aac/aacd 134 firewire/fwe 133 pci/fwohci 269 uhub/uaudio 92 pci/ath_pci 91 pci/ata_via 90 pci/ata_sis 268 sound 89 pci/ata_sii 132 fwohci/firewire 131 pccard/fe 130 exca 129 pccard/ex 128 isa/ex 127 pci/esp 126 pccard/ep 125 isa/ep 88 pci/ata_serverworks 124 pci/et 123 et/miibus 87 pci/ata_promise 26 acpi/hpet 86 pci/ata_nvidia 85 pci/ata_netcell 122 pci/igb 84 pci/ata_national 83 pci/ata_micron 82 pci/ata_marvell 81 pci/ata_jmicron 80 pci/ata_ite 267 hdac/snd_hda 202 mpt_raid 374 g_raid 378 g_raid_md_nvidia 203 mpt_user 380 g_raid_md_sii 377 g_raid_md_jmicron 375 g_raid_md_ddf 379 g_raid_md_promise 200 mpt_cam 376 g_raid_md_intel 393 firmware 381 g_raid_tr_concat 408 wlan 407 wlan_wep 406 wlan_tkip 405 wlan_ccmp 199 mpt_core 404 wlan_amrr 422 g_class 384 g_raid_tr_raid1e 369 g_part 368 g_label 392 rootbus 367 g_vfs 162 g_md 383 g_raid_tr_raid1 366 g_disk 385 g_raid_tr_raid5 410 wlan_sta 365 g_dev 409 wlan_ratectl_none 382 g_raid_tr_raid0 399 if_firewire 397 ether 456 x86bios --------------090706020109010001000202 Content-Type: text/plain; charset=us-ascii; name="messages" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="messages" Jan 28 11:04:05 lucid kernel: Copyright (c) 1992-2012 The FreeBSD Project. Jan 28 11:04:05 lucid kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 28 11:04:05 lucid kernel: The Regents of the University of California. All rights reserved. Jan 28 11:04:05 lucid kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 28 11:04:05 lucid kernel: FreeBSD 9.1-RELEASE #4: Mon Jan 28 09:02:45 CST 2013 Jan 28 11:04:05 lucid kernel: toor@lucid:/usr/obj/usr/src/sys/LUCID amd64 Jan 28 11:04:05 lucid kernel: CPU: Intel(R) Xeon(R) CPU X3210 @ 2.13GHz (2133.45-MHz K8-class CPU) Jan 28 11:04:05 lucid kernel: Origin = "GenuineIntel" Id = 0x6fb Family = 6 Model = f Stepping = 11 Jan 28 11:04:05 lucid kernel: Features=0xbfebfbff Jan 28 11:04:05 lucid kernel: Features2=0xe3bd Jan 28 11:04:05 lucid kernel: AMD Features=0x20100800 Jan 28 11:04:05 lucid kernel: AMD Features2=0x1 Jan 28 11:04:05 lucid kernel: TSC: P-state invariant, performance statistics Jan 28 11:04:05 lucid kernel: real memory = 4294967296 (4096 MB) Jan 28 11:04:05 lucid kernel: avail memory = 4092600320 (3903 MB) Jan 28 11:04:05 lucid kernel: Event timer "LAPIC" quality 400 Jan 28 11:04:05 lucid kernel: ACPI APIC Table: Jan 28 11:04:05 lucid kernel: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs Jan 28 11:04:05 lucid kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) Jan 28 11:04:05 lucid kernel: cpu0 (BSP): APIC ID: 0 Jan 28 11:04:05 lucid kernel: cpu1 (AP): APIC ID: 1 Jan 28 11:04:05 lucid kernel: cpu2 (AP): APIC ID: 2 Jan 28 11:04:05 lucid kernel: cpu3 (AP): APIC ID: 3 Jan 28 11:04:05 lucid kernel: ioapic0: Changing APIC ID to 4 Jan 28 11:04:05 lucid kernel: ioapic1: Changing APIC ID to 5 Jan 28 11:04:05 lucid kernel: ioapic0 irqs 0-23 on motherboard Jan 28 11:04:05 lucid kernel: ioapic1 irqs 32-55 on motherboard Jan 28 11:04:05 lucid kernel: kbd1 at kbdmux0 Jan 28 11:04:05 lucid kernel: acpi0: on motherboard Jan 28 11:04:05 lucid kernel: acpi0: Power Button (fixed) Jan 28 11:04:05 lucid kernel: cpu0: on acpi0 Jan 28 11:04:05 lucid kernel: cpu1: on acpi0 Jan 28 11:04:05 lucid kernel: cpu2: on acpi0 Jan 28 11:04:05 lucid kernel: cpu3: on acpi0 Jan 28 11:04:05 lucid kernel: atrtc0: port 0x70-0x7f irq 8 on acpi0 Jan 28 11:04:05 lucid kernel: Event timer "RTC" frequency 32768 Hz quality 0 Jan 28 11:04:05 lucid kernel: attimer0: port 0x40-0x5f irq 0 on acpi0 Jan 28 11:04:05 lucid kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jan 28 11:04:05 lucid kernel: Event timer "i8254" frequency 1193182 Hz quality 100 Jan 28 11:04:05 lucid kernel: hpet0: iomem 0xfed00000-0xfed003ff on acpi0 Jan 28 11:04:05 lucid kernel: Timecounter "HPET" frequency 14318180 Hz quality 950 Jan 28 11:04:05 lucid kernel: Event timer "HPET" frequency 14318180 Hz quality 450 Jan 28 11:04:05 lucid kernel: Event timer "HPET1" frequency 14318180 Hz quality 440 Jan 28 11:04:05 lucid kernel: Event timer "HPET2" frequency 14318180 Hz quality 440 Jan 28 11:04:05 lucid kernel: Event timer "HPET3" frequency 14318180 Hz quality 440 Jan 28 11:04:05 lucid kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 Jan 28 11:04:05 lucid kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 Jan 28 11:04:05 lucid kernel: pcib0: port 0xcf8-0xcff on acpi0 Jan 28 11:04:05 lucid kernel: pci0: on pcib0 Jan 28 11:04:05 lucid kernel: pcib1: irq 16 at device 1.0 on pci0 Jan 28 11:04:05 lucid kernel: pci1: on pcib1 Jan 28 11:04:05 lucid kernel: pcib2: irq 16 at device 28.0 on pci0 Jan 28 11:04:05 lucid kernel: pci2: on pcib2 Jan 28 11:04:05 lucid kernel: pcib3: at device 0.0 on pci2 Jan 28 11:04:05 lucid kernel: pci3: on pcib3 Jan 28 11:04:05 lucid kernel: pcib4: at device 2.0 on pci3 Jan 28 11:04:05 lucid kernel: pci4: on pcib4 Jan 28 11:04:05 lucid kernel: cas0: mem 0xdf800000-0xdf9fffff irq 35 at device 0.0 on pci4 Jan 28 11:04:05 lucid kernel: cas0: cannot disable RX MAC Jan 28 11:04:05 lucid kernel: miibus0: on cas0 Jan 28 11:04:05 lucid kernel: nsgphy0: PHY 1 on miibus0 Jan 28 11:04:05 lucid kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: cas0: 16kB RX FIFO, 9kB TX FIFO Jan 28 11:04:05 lucid kernel: cas0: Ethernet address: 00:14:4f:25:ca:10 Jan 28 11:04:05 lucid kernel: cas1: mem 0xdfa00000-0xdfbfffff irq 34 at device 1.0 on pci4 Jan 28 11:04:05 lucid kernel: miibus1: on cas1 Jan 28 11:04:05 lucid kernel: nsgphy1: PHY 1 on miibus1 Jan 28 11:04:05 lucid kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: cas1: 16kB RX FIFO, 9kB TX FIFO Jan 28 11:04:05 lucid kernel: cas1: Ethernet address: 00:14:4f:25:ca:11 Jan 28 11:04:05 lucid kernel: cas2: mem 0xdfc00000-0xdfdfffff irq 33 at device 2.0 on pci4 Jan 28 11:04:05 lucid kernel: miibus2: on cas2 Jan 28 11:04:05 lucid kernel: nsgphy2: PHY 1 on miibus2 Jan 28 11:04:05 lucid kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: cas2: 16kB RX FIFO, 9kB TX FIFO Jan 28 11:04:05 lucid kernel: cas2: Ethernet address: 00:14:4f:25:ca:12 Jan 28 11:04:05 lucid kernel: cas3: mem 0xdfe00000-0xdfffffff irq 32 at device 3.0 on pci4 Jan 28 11:04:05 lucid kernel: cas3: cannot disable RX MAC Jan 28 11:04:05 lucid kernel: miibus3: on cas3 Jan 28 11:04:05 lucid kernel: nsgphy3: PHY 1 on miibus3 Jan 28 11:04:05 lucid kernel: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: cas3: 16kB RX FIFO, 9kB TX FIFO Jan 28 11:04:05 lucid kernel: cas3: Ethernet address: 00:14:4f:25:ca:13 Jan 28 11:04:05 lucid kernel: pcib5: irq 16 at device 28.4 on pci0 Jan 28 11:04:05 lucid kernel: pci5: on pcib5 Jan 28 11:04:05 lucid kernel: bge0: mem 0xdf3f0000-0xdf3fffff irq 16 at device 0.0 on pci5 Jan 28 11:04:05 lucid kernel: bge0: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 28 11:04:05 lucid kernel: miibus4: on bge0 Jan 28 11:04:05 lucid kernel: brgphy0: PHY 1 on miibus4 Jan 28 11:04:05 lucid kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: bge0: Ethernet address: 00:19:b9:fa:82:51 Jan 28 11:04:05 lucid kernel: pcib6: irq 17 at device 28.5 on pci0 Jan 28 11:04:05 lucid kernel: pci6: on pcib6 Jan 28 11:04:05 lucid kernel: bge1: mem 0xdf4f0000-0xdf4fffff irq 17 at device 0.0 on pci6 Jan 28 11:04:05 lucid kernel: bge1: CHIP ID 0x00004201; ASIC REV 0x04; CHIP REV 0x42; PCI-E Jan 28 11:04:05 lucid kernel: miibus5: on bge1 Jan 28 11:04:05 lucid kernel: brgphy1: PHY 1 on miibus5 Jan 28 11:04:05 lucid kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow Jan 28 11:04:05 lucid kernel: bge1: Ethernet address: 00:19:b9:fa:82:52 Jan 28 11:04:05 lucid kernel: uhci0: port 0xdc60-0xdc7f irq 21 at device 29.0 on pci0 Jan 28 11:04:05 lucid kernel: usbus0 on uhci0 Jan 28 11:04:05 lucid kernel: uhci1: port 0xdc80-0xdc9f irq 20 at device 29.1 on pci0 Jan 28 11:04:05 lucid kernel: usbus1 on uhci1 Jan 28 11:04:05 lucid kernel: uhci2: port 0xdca0-0xdcbf irq 21 at device 29.2 on pci0 Jan 28 11:04:05 lucid kernel: usbus2 on uhci2 Jan 28 11:04:05 lucid kernel: ehci0: mem 0xdf2ffc00-0xdf2fffff irq 21 at device 29.7 on pci0 Jan 28 11:04:05 lucid kernel: usbus3: EHCI version 1.0 Jan 28 11:04:05 lucid kernel: usbus3 on ehci0 Jan 28 11:04:05 lucid kernel: pcib7: at device 30.0 on pci0 Jan 28 11:04:05 lucid kernel: pci7: on pcib7 Jan 28 11:04:05 lucid kernel: vgapci0: port 0xec00-0xecff mem 0xd0000000-0xd7ffffff,0xdf5f0000-0xdf5fffff irq 19 at device 5.0 on pci7 Jan 28 11:04:05 lucid kernel: isab0: at device 31.0 on pci0 Jan 28 11:04:05 lucid kernel: isa0: on isab0 Jan 28 11:04:05 lucid kernel: atapci0: port 0xdc30-0xdc37,0xdc28-0xdc2b,0xdc38-0xdc3f,0xdc2c-0xdc2f,0xdc40-0xdc4f,0xdc50-0xdc5f irq 23 at device 31.2 on pci0 Jan 28 11:04:05 lucid kernel: ata2: at channel 0 on atapci0 Jan 28 11:04:05 lucid kernel: ata3: at channel 1 on atapci0 Jan 28 11:04:05 lucid kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jan 28 11:04:05 lucid kernel: fdc0: does not respond Jan 28 11:04:05 lucid kernel: device_attach: fdc0 attach returned 6 Jan 28 11:04:05 lucid kernel: uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 Jan 28 11:04:05 lucid kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jan 28 11:04:05 lucid kernel: atkbd0: irq 1 on atkbdc0 Jan 28 11:04:05 lucid kernel: kbd0 at atkbd0 Jan 28 11:04:05 lucid kernel: atkbd0: [GIANT-LOCKED] Jan 28 11:04:05 lucid kernel: psm0: irq 12 on atkbdc0 Jan 28 11:04:05 lucid kernel: psm0: [GIANT-LOCKED] Jan 28 11:04:05 lucid kernel: psm0: model IntelliMouse, device ID 3 Jan 28 11:04:05 lucid kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000-0xc9fff,0xca000-0xcb7ff,0xec000-0xeffff on isa0 Jan 28 11:04:05 lucid kernel: sc0: at flags 0x100 on isa0 Jan 28 11:04:05 lucid kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jan 28 11:04:05 lucid kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jan 28 11:04:05 lucid kernel: fdc0: No FDOUT register! Jan 28 11:04:05 lucid kernel: ppc0: cannot reserve I/O port range Jan 28 11:04:05 lucid kernel: ctl: CAM Target Layer loaded Jan 28 11:04:05 lucid kernel: est0: on cpu0 Jan 28 11:04:05 lucid kernel: p4tcc0: on cpu0 Jan 28 11:04:05 lucid kernel: est1: on cpu1 Jan 28 11:04:05 lucid kernel: p4tcc1: on cpu1 Jan 28 11:04:05 lucid kernel: est2: on cpu2 Jan 28 11:04:05 lucid kernel: p4tcc2: on cpu2 Jan 28 11:04:05 lucid kernel: est3: on cpu3 Jan 28 11:04:05 lucid kernel: p4tcc3: on cpu3 Jan 28 11:04:05 lucid kernel: Timecounters tick every 1.000 msec Jan 28 11:04:05 lucid kernel: usbus0: 12Mbps Full Speed USB v1.0 Jan 28 11:04:05 lucid kernel: usbus1: 12Mbps Full Speed USB v1.0 Jan 28 11:04:05 lucid kernel: usbus2: 12Mbps Full Speed USB v1.0 Jan 28 11:04:05 lucid kernel: usbus3: 480Mbps High Speed USB v2.0 Jan 28 11:04:05 lucid kernel: ugen0.1: at usbus0 Jan 28 11:04:05 lucid kernel: uhub0: on usbus0 Jan 28 11:04:05 lucid kernel: ugen1.1: at usbus1 Jan 28 11:04:05 lucid kernel: uhub1: on usbus1 Jan 28 11:04:05 lucid kernel: ugen2.1: at usbus2 Jan 28 11:04:05 lucid kernel: uhub2: on usbus2 Jan 28 11:04:05 lucid kernel: ugen3.1: at usbus3 Jan 28 11:04:05 lucid kernel: uhub3: on usbus3 Jan 28 11:04:05 lucid kernel: uhub0: 2 ports with 2 removable, self powered Jan 28 11:04:05 lucid kernel: uhub1: 2 ports with 2 removable, self powered Jan 28 11:04:05 lucid kernel: uhub2: 2 ports with 2 removable, self powered Jan 28 11:04:05 lucid kernel: uhub3: 6 ports with 6 removable, self powered Jan 28 11:04:05 lucid kernel: ada0 at ata2 bus 0 scbus0 target 0 lun 0 Jan 28 11:04:05 lucid kernel: ada0: ATA-7 SATA 2.x device Jan 28 11:04:05 lucid kernel: ada0: 300.000MB/s transfers (SATA 2.x, UDMA5, PIO 8192bytes) Jan 28 11:04:05 lucid kernel: ada0: 76293MB (156250000 512 byte sectors: 16H 63S/T 16383C) Jan 28 11:04:05 lucid kernel: ada0: Previously was known as ad4 Jan 28 11:04:05 lucid kernel: SMP: AP CPU #3 Launched! Jan 28 11:04:05 lucid kernel: SMP: AP CPU #1 Launched! Jan 28 11:04:05 lucid kernel: cd0 at ata2 bus 0 scbus0 target 1 lun 0 Jan 28 11:04:05 lucid kernel: cd0: Removable CD-ROM SCSI-0 device Jan 28 11:04:05 lucid kernel: cd0: 150.000MB/s transfers (SATA 1.x, UDMA2, ATAPI 12bytes, SMP: AP CPU #2 Launched! Jan 28 11:04:05 lucid kernel: PIO 8192bytes) Jan 28 11:04:05 lucid kernel: cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed Jan 28 11:04:05 lucid kernel: Timecounter "TSC-low" frequency 16667601 Hz quality 1000 Jan 28 11:04:05 lucid kernel: Root mount waiting for: usbus3 Jan 28 11:04:05 lucid kernel: ugen3.2: at usbus3 Jan 28 11:04:05 lucid kernel: uhub4: on usbus3 Jan 28 11:04:05 lucid kernel: uhub4: MTT enabled Jan 28 11:04:05 lucid kernel: uhub4: 4 ports with 4 removable, self powered Jan 28 11:04:05 lucid kernel: Trying to mount root from ufs:/dev/ad4s1a [rw]... Jan 28 11:04:06 lucid kernel: bge0: link state changed to UP --------------090706020109010001000202-- From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 17:15:53 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B1D71B8B for ; Mon, 28 Jan 2013 17:15:53 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f41.google.com (mail-ee0-f41.google.com [74.125.83.41]) by mx1.freebsd.org (Postfix) with ESMTP id 5340FD5D for ; Mon, 28 Jan 2013 17:15:53 +0000 (UTC) Received: by mail-ee0-f41.google.com with SMTP id c13so1461336eek.28 for ; Mon, 28 Jan 2013 09:15:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=PUzE1KzMclt6XBX3ZIqb6acsJR43l1bjylXZtAVXCwQ=; b=ackw17UDOGupNTbPy1nqWdTRo6z7L6gmZ61VepMniwDj6iDrYzuBJZAsEQZDxTxfUK oDRoQEyAarSTcSNgB2KVrRtcst03h5tLP8wY9kyMPnL50Y22Dbu6pa+gDu312TQyOAWs a4XDYGbw2leMr+xAqobhJX+gaePhS+Bd7lTxAK+GfStNSnY6iSe2vZNGZLm/VpwbL09p XXunjkT2rWEjoOdtDfWRZPshcbpyOVFtAN+CEmysJ8Ji/EeKNB3UnTNRvtIbywEqoMMF 1jIGVngkJoJIWJB5NmCeoV0DVokzgfP9KnepKolvMLPXWfUQXfHr86RjGnVpIb4N9uCL IMjA== MIME-Version: 1.0 X-Received: by 10.14.209.198 with SMTP id s46mr28173574eeo.19.1359393346507; Mon, 28 Jan 2013 09:15:46 -0800 (PST) Received: by 10.223.161.80 with HTTP; Mon, 28 Jan 2013 09:15:46 -0800 (PST) In-Reply-To: <20130128070439.GB85353@onelab2.iet.unipi.it> References: <20130128070439.GB85353@onelab2.iet.unipi.it> Date: Mon, 28 Jan 2013 09:15:46 -0800 Message-ID: Subject: Re: ixgbe & msi/x From: Vijay Singh To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:15:53 -0000 > just curious, is this happening under behyve or also native, > and is it always occurring or it is occasional ? Native, and it happens when the pps rate is high, even if the aggregate bandwidth is low. > I am asking because with netmap when i tried to exploit interrupt > mitigation (strictly processing incoming traffic only on rx > interrupts) i noticed packet drops even at relatively low rates, > which made me suspect that interrupts were either lost or heavily > delayed. I am running whatever is in the driver (version 2.4.5) by default. Since msi/x isnt enabled by default, I have enabled that. The same test, sustains a *much* higher pps load with legacy interrupts, so I think that the msi/x interrupt setup is missing something. -vijay From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 18:58:25 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 11C0C379; Mon, 28 Jan 2013 18:58:25 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E5753263; Mon, 28 Jan 2013 18:58:24 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 18FFAB9A0; Mon, 28 Jan 2013 13:58:24 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: ixgbe & msi/x Date: Mon, 28 Jan 2013 11:14:09 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301281114.09933.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 13:58:24 -0500 (EST) Cc: net@freebsd.org, Vijay Singh X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:58:25 -0000 On Monday, January 28, 2013 1:39:53 am Vijay Singh wrote: > I am investigating an issue where the ixgbe (82599) device is hung and > I think I have traced it to the driver not getting interrupts. I have > MSI/X enabled, with 2 rx/tx queues. > > I am trying to understand this bit of code in the MSI/X setup: > > if (ixgbe_enable_msix) { > ixgbe_configure_ivars(adapter); > /* Set up auto-mask */ <<== THIS BIT > if (hw->mac.type == ixgbe_mac_82598EB) > IXGBE_WRITE_REG(hw, IXGBE_EIAM, IXGBE_EICS_RTX_QUEUE); > else { > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(0), 0xFFFFFFFF); > IXGBE_WRITE_REG(hw, IXGBE_EIAM_EX(1), 0xFFFFFFFF); > } > } > > Does this mean that ixgbe_disable_queue() is not needed in the msi/x > interrupt handler - ixgbe_msix_que()? You are really going to need the datasheet for this adapter to tell. From my recent reading of the datasheet for igb(4) (which is likely similar), it appears that MSI interrupts on that device are configured to auto-clear bits in the interrupt cause registers (ICR and EICR) when an MSI interrupt is posted so that the interrupt handler doesn't have to do a read of these registers to clear their status bits (one of the points of MSI interrupts is that you can just access in-memory descriptor rings when the handler fires without needing to do a read of the PCI device to force any posted memory writes by the device to flush). If I had to wager a guess, I'd say that ixgbe was following the same model. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 19:32:55 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3679E962 for ; Mon, 28 Jan 2013 19:32:55 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-lb0-f181.google.com (mail-lb0-f181.google.com [209.85.217.181]) by mx1.freebsd.org (Postfix) with ESMTP id A07C86FA for ; Mon, 28 Jan 2013 19:32:54 +0000 (UTC) Received: by mail-lb0-f181.google.com with SMTP id gm6so4305947lbb.26 for ; Mon, 28 Jan 2013 11:32:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=30hziINk/UrpewsOIYHDDkETlDaBRJDmB6+SkGDpdiA=; b=0PnssKTsa/jgrGjKnFZTyW1LTaKl1DsPdfSXw2ZByQJ1PYo9yVhONRWAEpEX81HNn4 4w8dkS86rshaepE8A2TRsGgbMZb5YdY+SXPlyDKioprKLMNv8cUdlMf1ocW0cgCUGJYx NoIvHjQHl6ORC5OBDKCgt/TJRewyTfhmmw75pV8lEVdv3X3aoBXzr6nyvDtp86/RY23z 3AwItHPBx7U60u4h3JakUTFG9OeiVEB+gCIR8Uwf4Weuh7c42QDijnbxd3nAhtwlLEp4 iUthlvKZd1nfSkG2i1TwZSH8PAi2F+Sld9GrBTsHRTLenFbKae2h4PivWOVsiAW4jJAf wweA== MIME-Version: 1.0 X-Received: by 10.152.123.34 with SMTP id lx2mr14217626lab.52.1359401573116; Mon, 28 Jan 2013 11:32:53 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.114.93.200 with HTTP; Mon, 28 Jan 2013 11:32:52 -0800 (PST) In-Reply-To: References: <20130128070439.GB85353@onelab2.iet.unipi.it> Date: Mon, 28 Jan 2013 11:32:52 -0800 X-Google-Sender-Auth: k6o7qNOO21y6EbfW5QrIQncwOAw Message-ID: Subject: Re: ixgbe & msi/x From: Luigi Rizzo To: Vijay Singh Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:32:55 -0000 On Mon, Jan 28, 2013 at 9:15 AM, Vijay Singh wrote: > > just curious, is this happening under behyve or also native, > > and is it always occurring or it is occasional ? > > Native, and it happens when the pps rate is high, even if the > aggregate bandwidth is low. > > that was my case too. I have not gone too far into my investigation but should note that not _all_ interrupts were lost; my symptoms were queue overflows under netmap even at a low 2 Mpps, which with 2k entries in the rx ring means that the interrupt was delayed for more than 1ms, well above the moderation delay. With these symptoms I would normally blame the os scheduler, but in this case it seems a bit hard given that the machine has 4 cores at 2.8 GHz and no other processes running. So just to clarify, which one of these symptoms did you see 1) no rx interrupts at all at any rx rate 2) occasional missing interrupts/drops as the rx pps increase 3) complete loss of rx interrupts above some pps threshold ? cheers luigi From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 19:55:52 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 97DC7DEC for ; Mon, 28 Jan 2013 19:55:52 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id 0C4E67E5 for ; Mon, 28 Jan 2013 19:55:51 +0000 (UTC) Received: by mail-ee0-f44.google.com with SMTP id l10so1541926eei.3 for ; Mon, 28 Jan 2013 11:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=8ag6GqB/7lN5FVSbTOjPk3RkUfQidxD6ucye6GqWrb0=; b=zP0EuDoL4Bx1fwCz4AWK52+VCG0gEpTay/AtZOjbgRB7A2eCx5S0CzNJjCO8oDWmgm +QkRNlJQKdtWwssNm66jO775uS2NcUpvgYGMngPmZXeRL1YnC1mTmkoTKuySsr9EDCeC Txvr1Z8BxBTvXlXFNT/JAJHo18jP5cM4vihubn4ReAlpJlreh+pZcetTcKHA2DgJUBRY 8HdiLOKvEN3rPrGfVq0FtKPckheKHkMyIbe0q1nAxZztdQyFvDrQlTS+rpn9HO/nMlgB g60gU+1T7xcVQpaiC9XUBVsvYnXCOvBIwz5w4s6yvrgc1B7ARykc6dERUEHtawyF8zmw 46HQ== MIME-Version: 1.0 X-Received: by 10.14.173.196 with SMTP id v44mr50622147eel.29.1359402945049; Mon, 28 Jan 2013 11:55:45 -0800 (PST) Received: by 10.223.161.80 with HTTP; Mon, 28 Jan 2013 11:55:44 -0800 (PST) In-Reply-To: References: <20130128070439.GB85353@onelab2.iet.unipi.it> Date: Mon, 28 Jan 2013 11:55:44 -0800 Message-ID: Subject: Re: ixgbe & msi/x From: Vijay Singh To: Luigi Rizzo Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 19:55:52 -0000 > that was my case too. I have not gone too far into my investigation but > should > note that not _all_ interrupts were lost; my symptoms were queue overflows > under netmap even at a low 2 Mpps, which with 2k entries in the rx ring > means > that the interrupt was delayed for more than 1ms, well above the moderation > delay. This would be consistent with what I am seeing. I saw that vmstat -i reported some interrupt rate for the rx rings but even a simple ping at that point would lead to input errors - queue overflows. > So just to clarify, which one of these symptoms did you see > 1) no rx interrupts at all at any rx rate > 2) occasional missing interrupts/drops as the rx pps increase > 3) complete loss of rx interrupts above some pps threshold ? I think it would be closest to 3. The same HW runs fine when I disable msi/x and use legacy interrupts. -vijay From owner-freebsd-net@FreeBSD.ORG Mon Jan 28 21:27:30 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DD7088DB for ; Mon, 28 Jan 2013 21:27:30 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 94106D2C for ; Mon, 28 Jan 2013 21:27:30 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id B5713B946; Mon, 28 Jan 2013 16:27:29 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: two problems in dev/e1000/if_lem.c::lem_handle_rxtx() Date: Mon, 28 Jan 2013 16:25:15 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301281625.16157.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Mon, 28 Jan 2013 16:27:29 -0500 (EST) Cc: Luigi Rizzo , Jack Vogel , head@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 21:27:30 -0000 On Tuesday, January 15, 2013 8:23:24 pm Luigi Rizzo wrote: > Hi, > i found a couple of problems in > dev/e1000/if_lem.c::lem_handle_rxtx() , > (compare with dev/e1000/if_em.c::em_handle_que() for better understanding): > > 1. in if_em.c::em_handle_que(), when em_rxeof() exceeds the > rx_process_limit, the task is rescheduled so it can complete the work. > Conversely, in if_lem.c::lem_handle_rxtx() the lem_rxeof() is > only run once, and if there are more pending packets the only > chance to drain them is to receive (many) more interrupts. > > This is a relatively serious problem, because the receiver has > a hard time recovering. > > I'd like to commit a fix to this same as it is done in e1000. This seems sensible. > 2. in if_em.c::em_handle_que(), interrupts are reenabled unconditionally, > whereas lem_handle_rxtx() only enables them if IFF_DRV_RUNNING is set. > > I cannot really tell what is the correct way here, so I'd like > to put a comment there unless there is a good suggestion on > what to do. > > Accesses to the intr register are race-prone anyways > (disabled in fastintr, enabled in the rxtx task without > holding any lock, and generally accessed under EM_CORE_LOCK > in other places), and presumably enabling/disabling the > interrupts around activations of the taks is just an > optimization (and on a VM, it is actually a pessimization > due to the huge cost of VM exits). Actually, this is quite important. The reason being that you don't want the interrupt handler and the task both running at the same time (ever). If you do they will both process RX packets and deliver them in different order to the stack wreaking havoc on TCP. In the case of what lem is doing, it is not racy (except with ifconfig up/down which is handled by checking for IFF_DRV_RUNNING changing after reacquiring the RX lock) as the algorith, is that once the fast interrupt handler masks the interrupt, that code path cannot run again until either the threaded handler or the task re-enables interrupts. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 04:14:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4316F668; Tue, 29 Jan 2013 04:14:03 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ia0-x22c.google.com (ia-in-x022c.1e100.net [IPv6:2607:f8b0:4001:c02::22c]) by mx1.freebsd.org (Postfix) with ESMTP id F1D1F670; Tue, 29 Jan 2013 04:14:02 +0000 (UTC) Received: by mail-ia0-f172.google.com with SMTP id u8so17313iag.31 for ; Mon, 28 Jan 2013 20:14:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oh1Tppcsix2D/Uc02JkMxGM+RGBJSdLw0YLLB6ja0Vk=; b=uTI6xsXTNvXRDwjHkfFNUtST2MmCs4FzQKz7GCgaFq5A5EZjVzdHmKTxcMAj5nKyuy ll+yZlxGway7GjHR3UuwGN5yaooQUmQpU9z4OOaiRwA5LS4PfxI51uZfJEZ7WBZ7r//V LfWQTHcZEUmaGZBDPNd75LfbpsFxnwqzZy6mqXsaXeRomEapeDPmnC2nIEDPAED/LkY/ E4iAw7SftnYUatOrcicRlLlWpdCpKrSzr5UY8Sv4byHGvecahZQED+HpiEkaMdQ+VuiT xBVhOLtBdf8t+EyaMxAwkLTv4WB6ziyuOY3KPFVjg0roXOlQ83aI7gUwLuTAdBd5Da/S NA4Q== MIME-Version: 1.0 X-Received: by 10.43.17.199 with SMTP id qd7mr59093icb.52.1359432842518; Mon, 28 Jan 2013 20:14:02 -0800 (PST) Received: by 10.43.112.194 with HTTP; Mon, 28 Jan 2013 20:14:02 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 20:14:02 -0800 Message-ID: Subject: Re: e1000 serdes link flap From: Neel Natu To: Jack F Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net , Ryan Stone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 04:14:03 -0000 Hi Jack, On Wed, Jan 23, 2013 at 2:58 PM, Ryan Stone wrote: > On Wed, Jan 23, 2013 at 2:13 AM, Neel Natu wrote: >> >> Hi, >> >> I am running into a problem in head with the e1000 link state >> detection logic attached to a 82571EB serdes controller. >> >> The symptom is that the link state keeps flapping between "up" and "down". >> >> After I enabled the debug output in >> 'e1000_check_for_serdes_link_82571()' this is what I see: >> >> e1000_check_for_serdes_link_82571 >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 >> FORCED_UP -> AN_PROG >> em6: link state changed to DOWN >> e1000_check_for_serdes_link_82571 >> ctrl = 0x4c0201, status = 0x803a4, rxcw = 0x44000000 >> AN_PROG -> FORCED_UP >> em6: link state changed to UP >> e1000_check_for_serdes_link_82571 >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 >> FORCED_UP -> AN_PROG >> em6: link state changed to DOWN >> >> >> The problem goes away if I apply the following patch to bring the link >> state detection logic in line with the e1000e driver in Linux: >> >> Index: e1000_82571.c >> =================================================================== >> --- e1000_82571.c (revision 245766) >> +++ e1000_82571.c (working copy) >> @@ -1712,10 +1712,8 @@ >> * auto-negotiation in the TXCW register and >> disable >> * forced link in the Device Control register in >> an >> * attempt to auto-negotiate with our link >> partner. >> - * If the partner code word is null, stop forcing >> - * and restart auto negotiation. >> */ >> - if ((rxcw & E1000_RXCW_C) || !(rxcw & >> E1000_RXCW_CW)) { >> + if ((rxcw & E1000_RXCW_C) != 0) { >> /* Enable autoneg, and unforce link up */ >> E1000_WRITE_REG(hw, E1000_TXCW, >> mac->txcw); >> E1000_WRITE_REG(hw, E1000_CTRL, >> >> I am not sure why the !(rxcw & E1000_RXCW_CW) check was added and the >> e1000 SDM does not have any more information. >> >> Jack, can you take a look at the patch and commit if it looks alright? > > > I have this change applied internally. I thought that it was something > funny in my environment, so I never tried to push it upstream. Sorry for > costing you time in having to debug this. :( Are you planning to commit this patch? I am happy to get you more information from my system if it helps you get to the bottom of this quicker. best Neel From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 07:53:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EB59530A for ; Tue, 29 Jan 2013 07:53:44 +0000 (UTC) (envelope-from unixnotes@qq.com) Received: from sam.nabble.com (sam.nabble.com [216.139.236.26]) by mx1.freebsd.org (Postfix) with ESMTP id D085CE20 for ; Tue, 29 Jan 2013 07:53:44 +0000 (UTC) Received: from [192.168.236.26] (helo=sam.nabble.com) by sam.nabble.com with esmtp (Exim 4.72) (envelope-from ) id 1U060m-0004De-8O for freebsd-net@freebsd.org; Mon, 28 Jan 2013 23:53:44 -0800 Date: Mon, 28 Jan 2013 23:53:44 -0800 (PST) From: unixnotes To: freebsd-net@freebsd.org Message-ID: <1359446024251-5781938.post@n5.nabble.com> Subject: openntp server prompts dispatch_imsg in main: pipe closed error MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 07:53:45 -0000 My system is freebsd 8.2, openntp server prompts dispatch_imsg in main: pip= e closed error=EF=BC=8CWho can help me?Thanks! ----- FreeBSD http://www.unixnotes.net=20 -- View this message in context: http://freebsd.1045724.n5.nabble.com/openntp-= server-prompts-dispatch-imsg-in-main-pipe-closed-error-tp5781938.html Sent from the freebsd-net mailing list archive at Nabble.com. From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 17:05:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 630C42EF for ; Tue, 29 Jan 2013 17:05:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 43C1B97C for ; Tue, 29 Jan 2013 17:05:43 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 71CC8B9AE for ; Tue, 29 Jan 2013 12:05:42 -0500 (EST) From: John Baldwin To: net@freebsd.org Subject: [PATCH] Allow tcpdrop to use non-space separators Date: Tue, 29 Jan 2013 12:05:41 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301291205.41301.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 29 Jan 2013 12:05:42 -0500 (EST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 17:05:43 -0000 A common use case I have at work is to find a busted connection using netstat -n or sockstat and then want to tcpdrop it. However, tcpdrop requires spaces between the address and port so I can't simply cut and paste from one terminal window into another to generate the tcpdrop command. This patch adds support for having a decimal (netstat output) or colon (sockstat output) between the address and port instead of a space. It is careful to look for the last of these tokens to avoid parsing part of the address as the port. Index: tcpdrop.8 =================================================================== --- tcpdrop.8 (revision 246073) +++ tcpdrop.8 (working copy) @@ -62,6 +62,9 @@ .Pp Addresses and ports may be specified by name or numeric value. Both IPv4 and IPv6 address formats are supported. +.Pp +The addresses and ports may be separated by periods or colons +instead of spaces. .Sh EXIT STATUS .Ex -std .Sh EXAMPLES Index: tcpdrop.c =================================================================== --- tcpdrop.c (revision 246073) +++ tcpdrop.c (working copy) @@ -50,6 +50,7 @@ static bool tcpdrop_list_commands = false; +static char *findport(const char *); static struct xinpgen *getxpcblist(const char *); static void sockinfo(const struct sockaddr *, struct host_service *); static bool tcpdrop(const struct sockaddr *, const struct sockaddr *); @@ -65,6 +66,7 @@ int main(int argc, char *argv[]) { + char *lport, *fport; bool dropall; int ch; @@ -93,15 +95,43 @@ exit(0); } - if (argc != 4 || tcpdrop_list_commands) + if ((argc != 2 && argc != 4) || tcpdrop_list_commands) usage(); - if (!tcpdropbyname(argv[0], argv[1], argv[2], argv[3])) + if (argc == 2) { + lport = findport(argv[0]); + fport = findport(argv[1]); + if (lport == NULL || lport[1] == '\0' || rport == NULL || + rport[1] == '\0') + usage(); + *lport++ = '\0'; + *fport++ = '\0'; + if (!tcpdropbyname(argv[0], lport, argv[1], fport)) + exit(1); + } else if (!tcpdropbyname(argv[0], argv[1], argv[2], argv[3])) exit(1); exit(0); } +static char * +findport(const char *arg) +{ + char *dot, *colon; + + /* A strrspn() or strrpbrk() would be nice. */ + dot = strrchr(arg, '.'); + colon = strrchr(arg, ':'); + if (dot == NULL) + return (colon); + if (colon == NULL) + return (dot); + if (dot < colon) + return (colon); + else + return (dot); +} + static struct xinpgen * getxpcblist(const char *name) { @@ -237,7 +267,7 @@ error = getaddrinfo(fhost, fport, &hints, &foreign); if (error != 0) { freeaddrinfo(local); /* XXX gratuitous */ - errx(1, "getaddrinfo: %s port %s: %s", lhost, lport, + errx(1, "getaddrinfo: %s port %s: %s", fhost, fport, gai_strerror(error)); } @@ -318,6 +348,8 @@ { fprintf(stderr, "usage: tcpdrop local-address local-port foreign-address foreign-port\n" +" tcpdrop local-address:local-port foreign-address:foreign-port\n" +" tcpdrop local-address.local-port foreign-address.foreign-port\n" " tcpdrop [-l] -a\n"); exit(1); } -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 18:50:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CB7C7C7D; Tue, 29 Jan 2013 18:50:43 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id A489AFB9; Tue, 29 Jan 2013 18:50:43 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 20E58B97D; Tue, 29 Jan 2013 13:50:43 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Tue, 29 Jan 2013 13:50:39 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> <5100EAD3.2090006@networx.ch> <201301241114.40734.jhb@freebsd.org> In-Reply-To: <201301241114.40734.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301291350.39931.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 29 Jan 2013 13:50:43 -0500 (EST) Cc: Sepherosa Ziehau , Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 18:50:43 -0000 On Thursday, January 24, 2013 11:14:40 am John Baldwin wrote: > > > Agree, per-socket option could be useful than global sysctls under > > > certain situation. However, in addition to the per-socket option, > > > could global sysctl nodes to disable idle_restart/idle_cwv help too? > > > > No. This is far too dangerous once it makes it into some tuning guide. > > The threat of congestion breakdown is real. The Internet, or any packet > > network, can only survive in the long term if almost all follow the rules > > and self-constrain to remain fair to the others. What would happen if > > nobody would respect the traffic lights anymore? > > The problem with this argument is Linux has already had this as a tunable > option for years and the Internet hasn't melted as a result. > > > Since this seems to be a burning issue I'll come up with a patch in the > > next days to add a decaying restartCWND that'll be fair and allow a very > > quick ramp up if no loss occurs. > > I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option > is useful both with and without a decaying restartCWND? *ping* Andre, do you object to adding the new socket option? -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 19:23:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 12F04615 for ; Tue, 29 Jan 2013 19:23:45 +0000 (UTC) (envelope-from Mark.Martinec+freebsd@ijs.si) Received: from mail.ijs.si (amavis-proxy-ori.ijs.si [193.2.4.66]) by mx1.freebsd.org (Postfix) with ESMTP id C1BB9184 for ; Tue, 29 Jan 2013 19:23:44 +0000 (UTC) Received: from amavis-proxy-ori.ijs.si (localhost [IPv6:::1]) by mail.ijs.si (Postfix) with ESMTP id 3YwcsM3RQlzGN2s for ; Tue, 29 Jan 2013 20:17:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ijs.si; h= message-id:content-transfer-encoding:content-type:content-type :mime-version:user-agent:date:date:subject:subject:organization :from:from:received:received:received:vbr-info; s=jakla2; t= 1359487026; x=1362079027; bh=PnCKl/IeLVlS5Bai45d+fVNIcpAGcEAp5xS u/RNfHSQ=; b=UgGyPFT6xGhVVD11C/Ye5D0DUDAIH6zwFWTe2OUR/jP9HC1fAgr F3DyCxCneGaS5xQfW7LxxRIsDm3w5oYZYesCTQNtFRB0V4WJT/xs1Sh0yRuVAxZ/ njssCNlWATBRpK7Nv1aWu1rtdMrtnb7d0WuTcmbDo23ttK1WPXsPK+60= VBR-Info: md=ijs.si; mc=all; mv=dwl.spamhaus.org; X-Virus-Scanned: amavisd-new at ijs.si Received: from mail.ijs.si ([IPv6:::1]) by amavis-proxy-ori.ijs.si (mail.ijs.si [IPv6:::1]) (amavisd-new, port 10012) with ESMTP id 6fiVSFIYcZQl for ; Tue, 29 Jan 2013 20:17:06 +0100 (CET) Received: from mildred.ijs.si (mailbox.ijs.si [IPv6:2001:1470:ff80::143:1]) by mail.ijs.si (Postfix) with ESMTP for ; Tue, 29 Jan 2013 20:17:06 +0100 (CET) Received: from neli.ijs.si (neli.ijs.si [IPv6:2001:1470:ff80:88:21c:c0ff:feb1:8c91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mildred.ijs.si (Postfix) with ESMTPSA id 8A741130 for ; Tue, 29 Jan 2013 20:17:06 +0100 (CET) From: Mark Martinec Organization: J. Stefan Institute To: freebsd-net@freebsd.org Subject: ALTQ on EPAIR interface? Date: Tue, 29 Jan 2013 20:17:04 +0100 User-Agent: KMail/1.13.7 (FreeBSD/9.1-STABLE; KDE/4.8.4; amd64; ; ) MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201301292017.05016.Mark.Martinec+freebsd@ijs.si> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:23:45 -0000 The ALTQ(4) man page (FreeBSD 9.1-STABLE) claims that altq is supported on the epair(4) interface, yet when such interface is specified in the 'altq on' directive in pf.conf, the pf complains: # service pf start Enabling pfpfctl: epair0a: driver does not support altq So, does it, or does it not support the altq? Background: the intention is to provide some QoS on the inner side of a tunnel carrying both IPv4 and IPv6 traffic to a remote site. Apparently the GIF interface also does not support altq, so the idea was to put epair in the mix. Applying altq to an outer ethernet interface does not allow classifying on the inner contents of the tunnel afict, so it doesn't look line an option. Mark From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 23:07:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 526AA9BC for ; Tue, 29 Jan 2013 23:07:33 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C6DDAE27 for ; Tue, 29 Jan 2013 23:07:32 +0000 (UTC) Received: (qmail 85357 invoked from network); 30 Jan 2013 00:27:32 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Jan 2013 00:27:32 -0000 Message-ID: <5108562A.1040603@freebsd.org> Date: Wed, 30 Jan 2013 00:07:22 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <5100EAD3.2090006@networx.ch> <201301241114.40734.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> In-Reply-To: <201301291350.39931.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 23:07:33 -0000 On 29.01.2013 19:50, John Baldwin wrote: > On Thursday, January 24, 2013 11:14:40 am John Baldwin wrote: >>>> Agree, per-socket option could be useful than global sysctls under >>>> certain situation. However, in addition to the per-socket option, >>>> could global sysctl nodes to disable idle_restart/idle_cwv help too? >>> >>> No. This is far too dangerous once it makes it into some tuning guide. >>> The threat of congestion breakdown is real. The Internet, or any packet >>> network, can only survive in the long term if almost all follow the rules >>> and self-constrain to remain fair to the others. What would happen if >>> nobody would respect the traffic lights anymore? >> >> The problem with this argument is Linux has already had this as a tunable >> option for years and the Internet hasn't melted as a result. >> >>> Since this seems to be a burning issue I'll come up with a patch in the >>> next days to add a decaying restartCWND that'll be fair and allow a very >>> quick ramp up if no loss occurs. >> >> I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option >> is useful both with and without a decaying restartCWND? > > *ping* > > Andre, do you object to adding the new socket option? Yes, unfortunately I do object. This option, combined with the inflated CWND at the end of a burst, effectively removes much, if not all, of the congestion control mechanisms originally put in place to allow multiple [TCP] streams co-exist on the same pipe. Not having any decay or timeout makes it even worse by doing this burst after an arbitrary amount of time when network conditions and the congestion situation have certainly changed. The primary principle of TCP is be cooperative with competing streams and fairly share bandwidth on a given link. Whenever the ACK clock came to a halt for some time we must re-probe (slowstart from a restartCWND) the link to compensate for our lack of knowledge of the current link and congestion situation. Doing that with a decay function and floor equaling the IW (10 segments nowadays) gives a rapid ramp up especially on LAN RTTs while avoiding a blind burst and subsequent loss cycle. If you absolutely know that you're the only one on that network and you want pure wirespeed then a TCP cc_null module doing away with all congestion control may be the right answer. The infrastructure is in place and it can be selected per socket. Plus it can be loaded as a module and thus doesn't have to be part of the base system. I'm currently re-emerging finishing up from the startup and auto-scaling rabbit- hole and will post patches for review shortly. After that I'm looking after the restartCWND issue. A first quick patch (untested) to update the restartCWND to the IW is below. -- Andre $ svn diff netinet/cc/cc_newreno.c Index: netinet/cc/cc_newreno.c =================================================================== --- netinet/cc/cc_newreno.c (revision 246082) +++ netinet/cc/cc_newreno.c (working copy) @@ -166,12 +166,21 @@ * * See RFC5681 Section 4.1. "Restarting Idle Connections". */ - if (V_tcp_do_rfc3390) + if (V_tcp_do_initcwnd10) + rw = min(10 * CCV(ccv, t_maxseg), + max(2 * CCV(ccv, t_maxseg), 14600)); + else if (V_tcp_do_rfc3390) rw = min(4 * CCV(ccv, t_maxseg), max(2 * CCV(ccv, t_maxseg), 4380)); - else - rw = CCV(ccv, t_maxseg) * 2; - + else { + /* Per RFC5681 Section 3.1 */ + if (CCV(ccv, t_maxseg) > 2190) + rw = 2 * CCV(ccv, t_maxseg); + else if (CCV(ccv, t_maxseg) > 1095) + rw = 3 * CCV(ccv, t_maxseg); + else + rw = 4 * CCV(ccv, t_maxseg); + } CCV(ccv, snd_cwnd) = min(rw, CCV(ccv, snd_cwnd)); } From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 23:11:44 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 98BD2A85 for ; Tue, 29 Jan 2013 23:11:44 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 19716E54 for ; Tue, 29 Jan 2013 23:11:43 +0000 (UTC) Received: (qmail 85389 invoked from network); 30 Jan 2013 00:31:50 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Jan 2013 00:31:50 -0000 Message-ID: <5108572D.1090905@freebsd.org> Date: Wed, 30 Jan 2013 00:11:41 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Allow tcpdrop to use non-space separators References: <201301291205.41301.jhb@freebsd.org> In-Reply-To: <201301291205.41301.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 23:11:44 -0000 On 29.01.2013 18:05, John Baldwin wrote: > A common use case I have at work is to find a busted connection using netstat > -n or sockstat and then want to tcpdrop it. However, tcpdrop requires spaces > between the address and port so I can't simply cut and paste from one terminal > window into another to generate the tcpdrop command. This patch adds support > for having a decimal (netstat output) or colon (sockstat output) between the > address and port instead of a space. It is careful to look for the last of > these tokens to avoid parsing part of the address as the port. Excellent. Can netstat be changed from decimal to colon output as well? The decimal output is completely outdated and probably from a time when not even dinosaurs were [created|evolved] yet. Colon output for port numbers is *the* standard all around. -- Andre > Index: tcpdrop.8 > =================================================================== > --- tcpdrop.8 (revision 246073) > +++ tcpdrop.8 (working copy) > @@ -62,6 +62,9 @@ > .Pp > Addresses and ports may be specified by name or numeric value. > Both IPv4 and IPv6 address formats are supported. > +.Pp > +The addresses and ports may be separated by periods or colons > +instead of spaces. > .Sh EXIT STATUS > .Ex -std > .Sh EXAMPLES > Index: tcpdrop.c > =================================================================== > --- tcpdrop.c (revision 246073) > +++ tcpdrop.c (working copy) > @@ -50,6 +50,7 @@ > > static bool tcpdrop_list_commands = false; > > +static char *findport(const char *); > static struct xinpgen *getxpcblist(const char *); > static void sockinfo(const struct sockaddr *, struct host_service *); > static bool tcpdrop(const struct sockaddr *, const struct sockaddr *); > @@ -65,6 +66,7 @@ > int > main(int argc, char *argv[]) > { > + char *lport, *fport; > bool dropall; > int ch; > > @@ -93,15 +95,43 @@ > exit(0); > } > > - if (argc != 4 || tcpdrop_list_commands) > + if ((argc != 2 && argc != 4) || tcpdrop_list_commands) > usage(); > > - if (!tcpdropbyname(argv[0], argv[1], argv[2], argv[3])) > + if (argc == 2) { > + lport = findport(argv[0]); > + fport = findport(argv[1]); > + if (lport == NULL || lport[1] == '\0' || rport == NULL || > + rport[1] == '\0') > + usage(); > + *lport++ = '\0'; > + *fport++ = '\0'; > + if (!tcpdropbyname(argv[0], lport, argv[1], fport)) > + exit(1); > + } else if (!tcpdropbyname(argv[0], argv[1], argv[2], argv[3])) > exit(1); > > exit(0); > } > > +static char * > +findport(const char *arg) > +{ > + char *dot, *colon; > + > + /* A strrspn() or strrpbrk() would be nice. */ > + dot = strrchr(arg, '.'); > + colon = strrchr(arg, ':'); > + if (dot == NULL) > + return (colon); > + if (colon == NULL) > + return (dot); > + if (dot < colon) > + return (colon); > + else > + return (dot); > +} > + > static struct xinpgen * > getxpcblist(const char *name) > { > @@ -237,7 +267,7 @@ > error = getaddrinfo(fhost, fport, &hints, &foreign); > if (error != 0) { > freeaddrinfo(local); /* XXX gratuitous */ > - errx(1, "getaddrinfo: %s port %s: %s", lhost, lport, > + errx(1, "getaddrinfo: %s port %s: %s", fhost, fport, > gai_strerror(error)); > } > > @@ -318,6 +348,8 @@ > { > fprintf(stderr, > "usage: tcpdrop local-address local-port foreign-address foreign-port\n" > +" tcpdrop local-address:local-port foreign-address:foreign-port\n" > +" tcpdrop local-address.local-port foreign-address.foreign-port\n" > " tcpdrop [-l] -a\n"); > exit(1); > } > From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 23:17:06 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 18794B73; Tue, 29 Jan 2013 23:17:06 +0000 (UTC) (envelope-from rizzo.unipi@gmail.com) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by mx1.freebsd.org (Postfix) with ESMTP id 34FD4E8E; Tue, 29 Jan 2013 23:17:04 +0000 (UTC) Received: by mail-wi0-f180.google.com with SMTP id hj13so986052wib.13 for ; Tue, 29 Jan 2013 15:17:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=FBa61QuaNXq1cxWD+G3Uw7dDhqqcPLXBP7xMDSYFHqM=; b=UYXnAFgQAemm9BsubGOUYk82ZZnanzZEVjilNhJHtvdf35EvkTU3krPRx/nbi4mn+a AIS688o6/nfsHdNGIduMTPNSoA0hqHlmxtpVbTGiO+OClkaNfCTeD4iL8PDHhekW6h7W TaonMDCJ2xmMy+h0d3OO4El/f1E++nWG9s12sR1quBNkF3lQBP+5+HavwA2R8lA4aWMf IBoglxc3rWhAiEcx3c0DYfMLUdLjmTHewfy/N7RxN42wbCuVueahmJmP6HESm0riRU37 77PeA/c6WRi5744r0LAIyk4lR7ttHATpfUucuXU/7BU7c+U9OvQwl7IyoLHxwjuS/Wyk Nuig== MIME-Version: 1.0 X-Received: by 10.180.24.9 with SMTP id q9mr5366290wif.14.1359501423709; Tue, 29 Jan 2013 15:17:03 -0800 (PST) Sender: rizzo.unipi@gmail.com Received: by 10.194.47.236 with HTTP; Tue, 29 Jan 2013 15:17:03 -0800 (PST) In-Reply-To: <5108572D.1090905@freebsd.org> References: <201301291205.41301.jhb@freebsd.org> <5108572D.1090905@freebsd.org> Date: Tue, 29 Jan 2013 15:17:03 -0800 X-Google-Sender-Auth: 9ksglsMJoDJdyT24D98g1WD-778 Message-ID: Subject: Re: [PATCH] Allow tcpdrop to use non-space separators From: Luigi Rizzo To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: John Baldwin , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 23:17:06 -0000 On Tue, Jan 29, 2013 at 3:11 PM, Andre Oppermann wrote: > On 29.01.2013 18:05, John Baldwin wrote: > >> A common use case I have at work is to find a busted connection using >> netstat >> -n or sockstat and then want to tcpdrop it. However, tcpdrop requires >> spaces >> between the address and port so I can't simply cut and paste from one >> terminal >> window into another to generate the tcpdrop command. This patch adds >> support >> for having a decimal (netstat output) or colon (sockstat output) between >> the >> address and port instead of a space. It is careful to look for the last >> of >> these tokens to avoid parsing part of the address as the port. >> > > Excellent. Can netstat be changed from decimal to colon output as well? > The decimal output is completely outdated and probably from a time when > not even dinosaurs were [created|evolved] yet. Colon output for port > numbers is *the* standard all around. i was going to say i'd really love to have the parsing code in some kind of library function. I find myself writing this code again and again (and presumably i am not the only one) each time with new bugs and features... i know that non-standard library functions are a pain when porting software (see humanize_* stuff) but better than duplication. cheers luigi > >> From owner-freebsd-net@FreeBSD.ORG Tue Jan 29 23:17:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6AC5BC05 for ; Tue, 29 Jan 2013 23:17:24 +0000 (UTC) (envelope-from markd-freebsd-net@bushwire.net) Received: from smtp1.bushwire.net (f5.bushwire.net [199.48.133.46]) by mx1.freebsd.org (Postfix) with SMTP id 204FDE96 for ; Tue, 29 Jan 2013 23:17:23 +0000 (UTC) Received: (qmail 52630 invoked by uid 1001); 29 Jan 2013 23:10:42 -0000 Delivered-To: qmda-intercept-freebsd-net@freebsd.org DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=2004; d=bushwire.net; b=Q5CaabxSi4mu60j3JxQJk6ptknc35QmrJxEMqRjxpI18gKOGF8MR7FyB2F4IJGRx; Comments: DomainKeys? See http://en.wikipedia.org/wiki/DomainKeys DomainKey-Trace-MD: h=12; b=14; l=C18R71D32M65F52T27S62R48M17C39C27I49; Comments: QMDA 0.3 Received: (qmail 52623 invoked by uid 1001); 29 Jan 2013 23:10:42 -0000 Date: 29 Jan 2013 23:10:42 +0000 Message-ID: <20130129231042.52622.qmail@f5-external.bushwire.net> From: "Mark Delany" To: freebsd-net@freebsd.org Subject: Re: [PATCH] Allow tcpdrop to use non-space separators References: <201301291205.41301.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <201301291205.41301.jhb@freebsd.org> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 23:17:24 -0000 On 29Jan13, John Baldwin allegedly wrote: > A common use case I have at work is to find a busted connection using netstat > -n or sockstat and then want to tcpdrop it. However, tcpdrop requires spaces > between the address and port so I can't simply cut and paste from one terminal > window into another to generate the tcpdrop command. This patch adds support > for having a decimal (netstat output) or colon (sockstat output) Any thoughts on including '#' as a valid port delimiter? this is mentioned in http://tools.ietf.org/html/rfc5952 Section 6 as an (albeit lowly) option and it does have the benefit of avoiding both of the ip4v/v6 delimiters. Mark. From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 09:25:47 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C71A1EFF for ; Wed, 30 Jan 2013 09:25:47 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 01B6F9DA for ; Wed, 30 Jan 2013 09:25:46 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r0U9Pic2085156 for ; Wed, 30 Jan 2013 13:25:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r0U9Pik7085155 for net@FreeBSD.org; Wed, 30 Jan 2013 13:25:44 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 30 Jan 2013 13:25:44 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Subject: [patch] good bye sockaddr_inarp Message-ID: <20130130092544.GA84981@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="8t9RHnE3ZwKMSgU+" Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 09:25:47 -0000 --8t9RHnE3ZwKMSgU+ Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Hello! It looks to me that the only thing the sockaddr_inarp was ever used for is to carry the SIN_PROXY flag. The SIN_PROXY flag in its turn, meant install a "proxy only" ARP entry. Such entry behaves as any "published" entry, but doesn't modify the routing table of the host. Please correct me, if I am wrong in the above ^^. Now, once ARP and routing are somewhat divorced, the meaning of "proxy only" is lost, because any entry doesn't affect routing table. This allows us to cleanup usage of SIN_PROXY and after that it appears that we don't need sockaddr_inarp at all. Attached patch does that. I didn't notice any functionality regressions, and I'd be grateful if anyone points me at a test case, that would. P.S. More reading on the history can be found here: http://www.freebsd.org/cgi/query-pr.cgi?pr=12357 -- Totus tuus, Glebius. --8t9RHnE3ZwKMSgU+ Content-Type: text/x-diff; charset=koi8-r Content-Disposition: attachment; filename="sockaddr_inarp.diff" Index: usr.sbin/ndp/ndp.c =================================================================== --- usr.sbin/ndp/ndp.c (revision 246095) +++ usr.sbin/ndp/ndp.c (working copy) @@ -436,9 +436,6 @@ goto overwrite; } } - /* - * IPv4 arp command retries with sin_other = SIN_PROXY here. - */ fprintf(stderr, "set: cannot configure a new entry\n"); return 1; } @@ -523,9 +520,6 @@ !(rtm->rtm_flags & RTF_GATEWAY)) { goto delete; } - /* - * IPv4 arp command retries with sin_other = SIN_PROXY here. - */ fprintf(stderr, "delete: cannot delete non-NDP entry\n"); return 1; } Index: usr.sbin/ppp/arp.c =================================================================== --- usr.sbin/ppp/arp.c (revision 246095) +++ usr.sbin/ppp/arp.c (working copy) @@ -91,7 +91,7 @@ */ static struct { struct rt_msghdr hdr; - struct sockaddr_inarp dst; + struct sockaddr_in dst; struct sockaddr_dl hwa; char extra[128]; } arpmsg; @@ -124,10 +124,9 @@ arpmsg.hdr.rtm_seq = ++bundle->routing_seq; arpmsg.hdr.rtm_addrs = RTA_DST | RTA_GATEWAY; arpmsg.hdr.rtm_inits = RTV_EXPIRE; - arpmsg.dst.sin_len = sizeof(struct sockaddr_inarp); + arpmsg.dst.sin_len = sizeof(struct sockaddr_in); arpmsg.dst.sin_family = AF_INET; arpmsg.dst.sin_addr.s_addr = addr.s_addr; - arpmsg.dst.sin_other = SIN_PROXY; arpmsg.hdr.rtm_msglen = (char *) &arpmsg.hwa - (char *) &arpmsg + arpmsg.hwa.sdl_len; Index: usr.sbin/arp/arp.c =================================================================== --- usr.sbin/arp/arp.c (revision 246095) +++ usr.sbin/arp/arp.c (working copy) @@ -81,28 +81,28 @@ #include typedef void (action_fn)(struct sockaddr_dl *sdl, - struct sockaddr_inarp *s_in, struct rt_msghdr *rtm); + struct sockaddr_in *s_in, struct rt_msghdr *rtm); static int search(u_long addr, action_fn *action); static action_fn print_entry; static action_fn nuke_entry; -static int delete(char *host, int do_proxy); +static int delete(char *host); static void usage(void); static int set(int argc, char **argv); static int get(char *host); static int file(char *name); static struct rt_msghdr *rtmsg(int cmd, - struct sockaddr_inarp *dst, struct sockaddr_dl *sdl); + struct sockaddr_in *dst, struct sockaddr_dl *sdl); static int get_ether_addr(in_addr_t ipaddr, struct ether_addr *hwaddr); -static struct sockaddr_inarp *getaddr(char *host); +static struct sockaddr_in *getaddr(char *host); static int valid_type(int type); static int nflag; /* no reverse dns lookups */ static char *rifname; static time_t expire_time; -static int flags, doing_proxy, proxy_only; +static int flags, doing_proxy; /* which function we're supposed to do */ #define F_GET 1 @@ -179,7 +179,7 @@ if (argc < 2 || argc > 6) usage(); if (func == F_REPLACE) - (void)delete(argv[0], 0); + delete(argv[0]); rtn = set(argc, argv) ? 1 : 0; break; case F_DELETE: @@ -187,15 +187,8 @@ if (argc != 0) usage(); search(0, nuke_entry); - } else { - if (argc == 2 && strncmp(argv[1], "pub", 3) == 0) - ch = SIN_PROXY; - else if (argc == 1) - ch = 0; - else - usage(); - rtn = delete(argv[0], ch); - } + } else + rtn = delete(argv[0]); break; case F_FILESET: if (argc != 1) @@ -246,15 +239,15 @@ } /* - * Given a hostname, fills up a (static) struct sockaddr_inarp with + * Given a hostname, fills up a (static) struct sockaddr_in with * the address of the host and returns a pointer to the * structure. */ -static struct sockaddr_inarp * +static struct sockaddr_in * getaddr(char *host) { struct hostent *hp; - static struct sockaddr_inarp reply; + static struct sockaddr_in reply; bzero(&reply, sizeof(reply)); reply.sin_len = sizeof(reply); @@ -298,8 +291,8 @@ static int set(int argc, char **argv) { - struct sockaddr_inarp *addr; - struct sockaddr_inarp *dst; /* what are we looking for */ + struct sockaddr_in *addr; + struct sockaddr_in *dst; /* what are we looking for */ struct sockaddr_dl *sdl; struct rt_msghdr *rtm; struct ether_addr *ea; @@ -316,7 +309,7 @@ dst = getaddr(host); if (dst == NULL) return (1); - doing_proxy = flags = proxy_only = expire_time = 0; + doing_proxy = flags = expire_time = 0; while (argc-- > 0) { if (strncmp(argv[0], "temp", 4) == 0) { struct timespec tp; @@ -332,7 +325,12 @@ flags |= RTF_ANNOUNCE; doing_proxy = 1; if (argc && strncmp(argv[1], "only", 3) == 0) { - proxy_only = 1; + /* + * Compatibility: in pre FreeBSD 8 times + * the "only" keyword used to mean that + * an ARP entry should be announced, but + * not installed into routing table. + */ argc--; argv++; } } else if (strncmp(argv[0], "blackhole", 9) == 0) { @@ -385,7 +383,7 @@ warn("%s", host); return (1); } - addr = (struct sockaddr_inarp *)(rtm + 1); + addr = (struct sockaddr_in *)(rtm + 1); sdl = (struct sockaddr_dl *)(SA_SIZE(addr) + (char *)addr); if ((sdl->sdl_family != AF_LINK) || @@ -405,7 +403,7 @@ static int get(char *host) { - struct sockaddr_inarp *addr; + struct sockaddr_in *addr; addr = getaddr(host); if (addr == NULL) @@ -425,9 +423,9 @@ * Delete an arp entry */ static int -delete(char *host, int do_proxy) +delete(char *host) { - struct sockaddr_inarp *addr, *dst; + struct sockaddr_in *addr, *dst; struct rt_msghdr *rtm; struct sockaddr_dl *sdl; struct sockaddr_dl sdl_m; @@ -456,7 +454,7 @@ warn("%s", host); return (1); } - addr = (struct sockaddr_inarp *)(rtm + 1); + addr = (struct sockaddr_in *)(rtm + 1); sdl = (struct sockaddr_dl *)(SA_SIZE(addr) + (char *)addr); /* @@ -504,7 +502,7 @@ size_t needed; char *lim, *buf, *next; struct rt_msghdr *rtm; - struct sockaddr_inarp *sin2; + struct sockaddr_in *sin2; struct sockaddr_dl *sdl; char ifname[IF_NAMESIZE]; int st, found_entry = 0; @@ -538,7 +536,7 @@ lim = buf + needed; for (next = buf; next < lim; next += rtm->rtm_msglen) { rtm = (struct rt_msghdr *)next; - sin2 = (struct sockaddr_inarp *)(rtm + 1); + sin2 = (struct sockaddr_in *)(rtm + 1); sdl = (struct sockaddr_dl *)((char *)sin2 + SA_SIZE(sin2)); if (rifname && if_indextoname(sdl->sdl_index, ifname) && strcmp(ifname, rifname)) @@ -562,7 +560,7 @@ static void print_entry(struct sockaddr_dl *sdl, - struct sockaddr_inarp *addr, struct rt_msghdr *rtm) + struct sockaddr_in *addr, struct rt_msghdr *rtm) { const char *host; struct hostent *hp; @@ -612,8 +610,6 @@ else printf(" expired"); } - if (addr->sin_other & SIN_PROXY) - printf(" published (proxy only)"); if (rtm->rtm_flags & RTF_ANNOUNCE) printf(" published"); switch(sdl->sdl_type) { @@ -659,12 +655,12 @@ */ static void nuke_entry(struct sockaddr_dl *sdl __unused, - struct sockaddr_inarp *addr, struct rt_msghdr *rtm __unused) + struct sockaddr_in *addr, struct rt_msghdr *rtm __unused) { char ip[20]; snprintf(ip, sizeof(ip), "%s", inet_ntoa(addr->sin_addr)); - (void)delete(ip, 0); + delete(ip); } static void @@ -682,7 +678,7 @@ } static struct rt_msghdr * -rtmsg(int cmd, struct sockaddr_inarp *dst, struct sockaddr_dl *sdl) +rtmsg(int cmd, struct sockaddr_in *dst, struct sockaddr_dl *sdl) { static int seq; int rlen; @@ -728,14 +724,9 @@ rtm->rtm_rmx.rmx_expire = expire_time; rtm->rtm_inits = RTV_EXPIRE; rtm->rtm_flags |= (RTF_HOST | RTF_STATIC | RTF_LLDATA); - dst->sin_other = 0; if (doing_proxy) { - if (proxy_only) - dst->sin_other = SIN_PROXY; - else { - rtm->rtm_addrs |= RTA_NETMASK; - rtm->rtm_flags &= ~RTF_HOST; - } + rtm->rtm_addrs |= RTA_NETMASK; + rtm->rtm_flags &= ~RTF_HOST; } /* FALLTHROUGH */ case RTM_GET: Index: usr.sbin/rarpd/rarpd.c =================================================================== --- usr.sbin/rarpd/rarpd.c (revision 246095) +++ usr.sbin/rarpd/rarpd.c (working copy) @@ -692,11 +692,10 @@ * host (i.e. the guy running rarpd), won't try to ARP for the hardware * address of the guy being booted (he cannot answer the ARP). */ -struct sockaddr_inarp sin_inarp = { - sizeof(struct sockaddr_inarp), AF_INET, 0, +struct sockaddr_in sin_inarp = { + sizeof(struct sockaddr_in), AF_INET, 0, {0}, {0}, - 0, 0 }; struct sockaddr_dl sin_dl = { sizeof(struct sockaddr_dl), AF_LINK, 0, IFT_ETHER, 0, 6, @@ -712,7 +711,7 @@ { struct timespec tp; int cc; - struct sockaddr_inarp *ar, *ar2; + struct sockaddr_in *ar, *ar2; struct sockaddr_dl *ll, *ll2; struct rt_msghdr *rt; int xtype, xindex; @@ -740,7 +739,7 @@ rt->rtm_addrs = RTA_DST; rt->rtm_type = RTM_GET; rt->rtm_seq = ++seq; - ar2 = (struct sockaddr_inarp *)rtmsg.rtspace; + ar2 = (struct sockaddr_in *)rtmsg.rtspace; bcopy(ar, ar2, sizeof(*ar)); rt->rtm_msglen = sizeof(*rt) + sizeof(*ar); errno = 0; Index: sbin/route/route.c =================================================================== --- sbin/route/route.c (revision 246095) +++ sbin/route/route.c (working copy) @@ -86,7 +86,6 @@ #endif struct sockaddr_at sat; struct sockaddr_dl sdl; - struct sockaddr_inarp sinarp; struct sockaddr_storage ss; /* added to avoid memory overrun */ } so_dst, so_gate, so_mask, so_genmask, so_ifa, so_ifp; @@ -923,10 +922,8 @@ flags |= RTF_HOST; if ((nrflags & F_INTERFACE) == 0) flags |= RTF_GATEWAY; - if (nrflags & F_PROXY) { - so_dst.sinarp.sin_other = SIN_PROXY; + if (nrflags & F_PROXY) flags |= RTF_ANNOUNCE; - } if (dest == NULL) dest = ""; if (gateway == NULL) Index: contrib/ipfilter/ipsend/44arp.c =================================================================== --- contrib/ipfilter/ipsend/44arp.c (revision 246095) +++ contrib/ipfilter/ipsend/44arp.c (working copy) @@ -72,7 +72,7 @@ size_t needed; char *lim, *buf, *next; struct rt_msghdr *rtm; - struct sockaddr_inarp *sin; + struct sockaddr_in *sin; struct sockaddr_dl *sdl; #ifdef IPSEND @@ -113,7 +113,7 @@ for (next = buf; next < lim; next += rtm->rtm_msglen) { rtm = (struct rt_msghdr *)next; - sin = (struct sockaddr_inarp *)(rtm + 1); + sin = (struct sockaddr_in *)(rtm + 1); sdl = (struct sockaddr_dl *)(sin + 1); if (!bcmp(addr, (char *)&sin->sin_addr, sizeof(struct in_addr))) Index: libexec/bootpd/rtmsg.c =================================================================== --- libexec/bootpd/rtmsg.c (revision 246095) +++ libexec/bootpd/rtmsg.c (working copy) @@ -106,9 +106,9 @@ } static struct sockaddr_in so_mask = {8, 0, 0, { 0xffffffff}}; -static struct sockaddr_inarp blank_sin = {sizeof(blank_sin), AF_INET }, sin_m; +static struct sockaddr_in blank_sin = {sizeof(blank_sin), AF_INET }, sin_m; static struct sockaddr_dl blank_sdl = {sizeof(blank_sdl), AF_LINK }, sdl_m; -static int expire_time, flags, export_only, doing_proxy; +static int expire_time, flags, doing_proxy; static struct { struct rt_msghdr m_rtm; char m_space[512]; @@ -122,7 +122,7 @@ char *eaddr; int len; { - register struct sockaddr_inarp *sin = &sin_m; + register struct sockaddr_in *sin = &sin_m; register struct sockaddr_dl *sdl; register struct rt_msghdr *rtm = &(m_rtmsg.m_rtm); u_char *ea; @@ -137,7 +137,7 @@ ea = (u_char *)LLADDR(&sdl_m); bcopy(eaddr, ea, len); sdl_m.sdl_alen = len; - doing_proxy = flags = export_only = expire_time = 0; + doing_proxy = flags = expire_time = 0; /* make arp entry temporary */ clock_gettime(CLOCK_MONOTONIC, &tp); @@ -148,7 +148,7 @@ report(LOG_WARNING, "rtmget: %s", strerror(errno)); return (1); } - sin = (struct sockaddr_inarp *)(rtm + 1); + sin = (struct sockaddr_in *)(rtm + 1); sdl = (struct sockaddr_dl *)(sin->sin_len + (char *)sin); if (sin->sin_addr.s_addr == sin_m.sin_addr.s_addr) { if (sdl->sdl_family == AF_LINK && @@ -163,13 +163,6 @@ inet_ntoa(sin->sin_addr)); return (1); } - if (sin_m.sin_other & SIN_PROXY) { - report(LOG_WARNING, - "set: proxy entry exists for non 802 device\n"); - return(1); - } - sin_m.sin_other = SIN_PROXY; - export_only = 1; goto tryagain; } overwrite: @@ -209,14 +202,9 @@ rtm->rtm_rmx.rmx_expire = expire_time; rtm->rtm_inits = RTV_EXPIRE; rtm->rtm_flags |= (RTF_HOST | RTF_STATIC | RTF_LLDATA); - sin_m.sin_other = 0; if (doing_proxy) { - if (export_only) - sin_m.sin_other = SIN_PROXY; - else { - rtm->rtm_addrs |= RTA_NETMASK; - rtm->rtm_flags &= ~RTF_HOST; - } + rtm->rtm_addrs |= RTA_NETMASK; + rtm->rtm_flags &= ~RTF_HOST; } /* FALLTHROUGH */ case RTM_GET: Index: sys/netinet/in.c =================================================================== --- sys/netinet/in.c (revision 246095) +++ sys/netinet/in.c (working copy) @@ -1494,7 +1494,7 @@ /* XXX stack use */ struct { struct rt_msghdr rtm; - struct sockaddr_inarp sin; + struct sockaddr_in sin; struct sockaddr_dl sdl; } arpc; int error, i; @@ -1515,7 +1515,7 @@ /* * produce a msg made of: * struct rt_msghdr; - * struct sockaddr_inarp; (IPv4) + * struct sockaddr_in; (IPv4) * struct sockaddr_dl; */ bzero(&arpc, sizeof(arpc)); @@ -1529,12 +1529,8 @@ arpc.sin.sin_addr.s_addr = SIN(lle)->sin_addr.s_addr; /* publish */ - if (lle->la_flags & LLE_PUB) { + if (lle->la_flags & LLE_PUB) arpc.rtm.rtm_flags |= RTF_ANNOUNCE; - /* proxy only */ - if (lle->la_flags & LLE_PROXY) - arpc.sin.sin_other = SIN_PROXY; - } sdl = &arpc.sdl; sdl->sdl_family = AF_LINK; Index: sys/netinet/if_ether.h =================================================================== --- sys/netinet/if_ether.h (revision 246095) +++ sys/netinet/if_ether.h (working copy) @@ -89,16 +89,6 @@ #define arp_pln ea_hdr.ar_pln #define arp_op ea_hdr.ar_op -struct sockaddr_inarp { - u_char sin_len; - u_char sin_family; - u_short sin_port; - struct in_addr sin_addr; - struct in_addr sin_srcaddr; - u_short sin_tos; - u_short sin_other; -#define SIN_PROXY 1 -}; /* * IP and ethernet specific routing flags */ Index: sys/net/if_llatbl.c =================================================================== --- sys/net/if_llatbl.c (revision 246095) +++ sys/net/if_llatbl.c (working copy) @@ -285,28 +285,8 @@ switch (rtm->rtm_type) { case RTM_ADD: - if (rtm->rtm_flags & RTF_ANNOUNCE) { + if (rtm->rtm_flags & RTF_ANNOUNCE) flags |= LLE_PUB; -#ifdef INET - if (dst->sa_family == AF_INET && - ((struct sockaddr_inarp *)dst)->sin_other != 0) { - struct rtentry *rt; - ((struct sockaddr_inarp *)dst)->sin_other = 0; - rt = rtalloc1(dst, 0, 0); - if (rt == NULL || !(rt->rt_flags & RTF_HOST)) { - log(LOG_INFO, "%s: RTM_ADD publish " - "(proxy only) is invalid\n", - __func__); - if (rt) - RTFREE_LOCKED(rt); - return EINVAL; - } - RTFREE_LOCKED(rt); - - flags |= LLE_PROXY; - } -#endif - } flags |= LLE_CREATE; break; @@ -345,7 +325,7 @@ * LLE_DELETED flag, and reset the expiration timer */ bcopy(LLADDR(dl), &lle->ll_addr, ifp->if_addrlen); - lle->la_flags |= (flags & (LLE_PUB | LLE_PROXY)); + lle->la_flags |= (flags & LLE_PUB); lle->la_flags |= LLE_VALID; lle->la_flags &= ~LLE_DELETED; #ifdef INET6 @@ -367,15 +347,12 @@ laflags = lle->la_flags; LLE_WUNLOCK(lle); #ifdef INET - /* gratuitous ARP */ - if ((laflags & LLE_PUB) && dst->sa_family == AF_INET) { + /* gratuitous ARP */ + if ((laflags & LLE_PUB) && dst->sa_family == AF_INET) arprequest(ifp, &((struct sockaddr_in *)dst)->sin_addr, &((struct sockaddr_in *)dst)->sin_addr, - ((laflags & LLE_PROXY) ? - (u_char *)IF_LLADDR(ifp) : - (u_char *)LLADDR(dl))); - } + (u_char *)LLADDR(dl)); #endif } else { if (flags & LLE_EXCLUSIVE) Index: sys/net/if_llatbl.h =================================================================== --- sys/net/if_llatbl.h (revision 246095) +++ sys/net/if_llatbl.h (working copy) @@ -172,7 +172,6 @@ #define LLE_STATIC 0x0002 /* entry is static */ #define LLE_IFADDR 0x0004 /* entry is interface addr */ #define LLE_VALID 0x0008 /* ll_addr is valid */ -#define LLE_PROXY 0x0010 /* proxy entry ??? */ #define LLE_PUB 0x0020 /* publish entry ??? */ #define LLE_LINKED 0x0040 /* linked to lookup structure */ #define LLE_EXCLUSIVE 0x2000 /* return lle xlocked */ --8t9RHnE3ZwKMSgU+-- From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 11:45:36 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2FC9D459 for ; Wed, 30 Jan 2013 11:45:36 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 98AAA1EE for ; Wed, 30 Jan 2013 11:45:35 +0000 (UTC) Received: (qmail 87987 invoked from network); 30 Jan 2013 13:05:36 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Jan 2013 13:05:36 -0000 Message-ID: <510907DC.3040900@networx.ch> Date: Wed, 30 Jan 2013 12:45:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: [patch] good bye sockaddr_inarp References: <20130130092544.GA84981@FreeBSD.org> In-Reply-To: <20130130092544.GA84981@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:45:36 -0000 On 30.01.2013 10:25, Gleb Smirnoff wrote: > Hello! > > It looks to me that the only thing the sockaddr_inarp was > ever used for is to carry the SIN_PROXY flag. > > The SIN_PROXY flag in its turn, meant install a "proxy only" > ARP entry. Such entry behaves as any "published" entry, but > doesn't modify the routing table of the host. > > Please correct me, if I am wrong in the above ^^. Proxy arp is used for ppp for example when the remote end is given an IP address from a locally connected network. Usually the IP address was obtained via DHCP. The ppp server then installs a proxy ARP entry for this IP address to receive all packets for it and forward them over the PPP link. > Now, once ARP and routing are somewhat divorced, the meaning > of "proxy only" is lost, because any entry doesn't affect routing > table. We still need the proxy ARP functionality and semantics. The routing table however isn't involved anymore as you've observed. > This allows us to cleanup usage of SIN_PROXY and after that > it appears that we don't need sockaddr_inarp at all. Attached patch > does that. I didn't notice any functionality regressions, and I'd be > grateful if anyone points me at a test case, that would. > > P.S. More reading on the history can be found here: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=12357 Excellent. More cruft going away. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 11:49:30 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 971FB66B for ; Wed, 30 Jan 2013 11:49:30 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 243E823E for ; Wed, 30 Jan 2013 11:49:29 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r0UBnMRj085909; Wed, 30 Jan 2013 15:49:22 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r0UBnMRn085908; Wed, 30 Jan 2013 15:49:22 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 30 Jan 2013 15:49:22 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: [patch] good bye sockaddr_inarp Message-ID: <20130130114922.GG84981@glebius.int.ru> References: <20130130092544.GA84981@FreeBSD.org> <510907DC.3040900@networx.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <510907DC.3040900@networx.ch> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 11:49:30 -0000 On Wed, Jan 30, 2013 at 12:45:32PM +0100, Andre Oppermann wrote: A> On 30.01.2013 10:25, Gleb Smirnoff wrote: A> > Hello! A> > A> > It looks to me that the only thing the sockaddr_inarp was A> > ever used for is to carry the SIN_PROXY flag. A> > A> > The SIN_PROXY flag in its turn, meant install a "proxy only" A> > ARP entry. Such entry behaves as any "published" entry, but A> > doesn't modify the routing table of the host. A> > A> > Please correct me, if I am wrong in the above ^^. A> A> Proxy arp is used for ppp for example when the remote end is A> given an IP address from a locally connected network. Usually A> the IP address was obtained via DHCP. The ppp server then A> installs a proxy ARP entry for this IP address to receive all A> packets for it and forward them over the PPP link. I understand that, thanks :) This functionality isn't broken by my change. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 16:30:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4BCAAEEE; Wed, 30 Jan 2013 16:30:45 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id C2969718; Wed, 30 Jan 2013 16:30:45 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 2D355B911; Wed, 30 Jan 2013 11:30:45 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Allow tcpdrop to use non-space separators Date: Wed, 30 Jan 2013 11:13:25 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301291205.41301.jhb@freebsd.org> <5108572D.1090905@freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301301113.25418.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 30 Jan 2013 11:30:45 -0500 (EST) Cc: Andre Oppermann , Luigi Rizzo , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:30:46 -0000 On Tuesday, January 29, 2013 6:17:03 pm Luigi Rizzo wrote: > On Tue, Jan 29, 2013 at 3:11 PM, Andre Oppermann wrote: > > > On 29.01.2013 18:05, John Baldwin wrote: > > > >> A common use case I have at work is to find a busted connection using > >> netstat > >> -n or sockstat and then want to tcpdrop it. However, tcpdrop requires > >> spaces > >> between the address and port so I can't simply cut and paste from one > >> terminal > >> window into another to generate the tcpdrop command. This patch adds > >> support > >> for having a decimal (netstat output) or colon (sockstat output) between > >> the > >> address and port instead of a space. It is careful to look for the last > >> of > >> these tokens to avoid parsing part of the address as the port. > >> > > > > Excellent. Can netstat be changed from decimal to colon output as well? > > The decimal output is completely outdated and probably from a time when > > not even dinosaurs were [created|evolved] yet. Colon output for port > > numbers is *the* standard all around. I'd be nervous about breaking scripts if we change the netstat output. Also, in the case of IPv6 the period is actually better than the colon for readability. > i was going to say i'd really love to have the parsing code in some kind of > library function. I find myself writing this code again and again (and > presumably > i am not the only one) each time with new bugs and features... > > i know that non-standard library functions are a pain when porting software > (see humanize_* stuff) but better than duplication. Actually, if we had a reverse version of either strspn or strpbrk then it would be trivial to write this. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 16:30:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0E5C4F3A for ; Wed, 30 Jan 2013 16:30:47 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id E098A71B for ; Wed, 30 Jan 2013 16:30:46 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 3A5EEB979; Wed, 30 Jan 2013 11:30:46 -0500 (EST) From: John Baldwin To: freebsd-net@freebsd.org Subject: Re: [PATCH] Allow tcpdrop to use non-space separators Date: Wed, 30 Jan 2013 11:14:55 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301291205.41301.jhb@freebsd.org> <20130129231042.52622.qmail@f5-external.bushwire.net> In-Reply-To: <20130129231042.52622.qmail@f5-external.bushwire.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301301114.55770.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 30 Jan 2013 11:30:46 -0500 (EST) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 16:30:47 -0000 On Tuesday, January 29, 2013 6:10:42 pm Mark Delany wrote: > On 29Jan13, John Baldwin allegedly wrote: > > A common use case I have at work is to find a busted connection using netstat > > -n or sockstat and then want to tcpdrop it. However, tcpdrop requires spaces > > between the address and port so I can't simply cut and paste from one terminal > > window into another to generate the tcpdrop command. This patch adds support > > for having a decimal (netstat output) or colon (sockstat output) > > Any thoughts on including '#' as a valid port delimiter? this is > mentioned in http://tools.ietf.org/html/rfc5952 Section 6 as an > (albeit lowly) option and it does have the benefit of avoiding both of > the ip4v/v6 delimiters. I'm not aware of any of the tools in the base system at least that use that convention, so in terms of the original goal of making it easier to cut and paste from the output of one program to the parameters to tcpdrop I don't think it fits. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:01:06 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3DC96E1A; Wed, 30 Jan 2013 17:01:06 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 12E648EE; Wed, 30 Jan 2013 17:01:06 +0000 (UTC) Received: from pakbsde14.localnet (unknown [38.105.238.108]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 789FFB978; Wed, 30 Jan 2013 12:01:05 -0500 (EST) From: John Baldwin To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Date: Wed, 30 Jan 2013 11:58:33 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p22; KDE/4.5.5; amd64; ; ) References: <201301221511.02496.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> <5108562A.1040603@freebsd.org> In-Reply-To: <5108562A.1040603@freebsd.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201301301158.33838.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Wed, 30 Jan 2013 12:01:05 -0500 (EST) Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:01:06 -0000 On Tuesday, January 29, 2013 6:07:22 pm Andre Oppermann wrote: > On 29.01.2013 19:50, John Baldwin wrote: > > On Thursday, January 24, 2013 11:14:40 am John Baldwin wrote: > >>>> Agree, per-socket option could be useful than global sysctls under > >>>> certain situation. However, in addition to the per-socket option, > >>>> could global sysctl nodes to disable idle_restart/idle_cwv help too? > >>> > >>> No. This is far too dangerous once it makes it into some tuning guide. > >>> The threat of congestion breakdown is real. The Internet, or any packet > >>> network, can only survive in the long term if almost all follow the rules > >>> and self-constrain to remain fair to the others. What would happen if > >>> nobody would respect the traffic lights anymore? > >> > >> The problem with this argument is Linux has already had this as a tunable > >> option for years and the Internet hasn't melted as a result. > >> > >>> Since this seems to be a burning issue I'll come up with a patch in the > >>> next days to add a decaying restartCWND that'll be fair and allow a very > >>> quick ramp up if no loss occurs. > >> > >> I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option > >> is useful both with and without a decaying restartCWND? > > > > *ping* > > > > Andre, do you object to adding the new socket option? > > Yes, unfortunately I do object. This option, combined with the inflated > CWND at the end of a burst, effectively removes much, if not all, of the > congestion control mechanisms originally put in place to allow multiple > [TCP] streams co-exist on the same pipe. Not having any decay or timeout > makes it even worse by doing this burst after an arbitrary amount of time > when network conditions and the congestion situation have certainly changed. You have completely ignored the fact that Linux has had this as a global option for years and the Internet has not melted. A socket option is far more fine-grained than their tunable (and requires code changes, not something a random sysadmin can just toggle as "tuning"). > The primary principle of TCP is be cooperative with competing streams and > fairly share bandwidth on a given link. Whenever the ACK clock came to a > halt for some time we must re-probe (slowstart from a restartCWND) the link > to compensate for our lack of knowledge of the current link and congestion > situation. Doing that with a decay function and floor equaling the IW (10 > segments nowadays) gives a rapid ramp up especially on LAN RTTs while avoiding > a blind burst and subsequent loss cycle. I understand all that, but it isn't applicable to my use case. I'm not sharing the bandwidth with anyone but other connections of my own (and they are all lower priority than this one). Also, I have idle periods of hundreds of milliseconds (large than an RTT on this cross-continental link that also has high bandwidth), so it seems that even a decayed restartCWND will be useless to me as it will have decayed down to nothing before I finally restart after long idle periods. > If you absolutely know that you're the only one on that network and you want > pure wirespeed then a TCP cc_null module doing away with all congestion control > may be the right answer. The infrastructure is in place and it can be selected > per socket. Plus it can be loaded as a module and thus doesn't have to be part > of the base system. No, I do not think that doing away with all congestion control will work for my case. Even though we have a dedicated line, etc. that doesn't mean congestion is impossible and that I don't want the "normal" feedback to apply during the non-restart cases. BTW, I looked at using alternate congestion control algorithms (cc_cubic and some of the others) first before resorting to adding this option and they either did not fix the issue or were buggy. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:11:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E0726207; Wed, 30 Jan 2013 17:11:24 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id CB5A5975; Wed, 30 Jan 2013 17:11:24 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (ool-45775fce.dyn.optonline.net [69.119.95.206]) by elvis.mu.org (Postfix) with ESMTPSA id E35271A3DB2; Wed, 30 Jan 2013 09:11:23 -0800 (PST) Message-ID: <5109543B.4020304@mu.org> Date: Wed, 30 Jan 2013 12:11:23 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> <5108562A.1040603@freebsd.org> <201301301158.33838.jhb@freebsd.org> In-Reply-To: <201301301158.33838.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb , Andre Oppermann X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:11:25 -0000 On 1/30/13 11:58 AM, John Baldwin wrote: > On Tuesday, January 29, 2013 6:07:22 pm Andre Oppermann wrote: >> >> Yes, unfortunately I do object. This option, combined with the inflated >> CWND at the end of a burst, effectively removes much, if not all, of the >> congestion control mechanisms originally put in place to allow multiple >> [TCP] streams co-exist on the same pipe. Not having any decay or timeout >> makes it even worse by doing this burst after an arbitrary amount of time >> when network conditions and the congestion situation have certainly changed. > You have completely ignored the fact that Linux has had this as a global > option for years and the Internet has not melted. A socket option is far more > fine-grained than their tunable (and requires code changes, not something a > random sysadmin can just toggle as "tuning"). I agree with John here. While Andre's objection makes sense, since the majority of Linux/Unix hosts now have this as a global option I can't think of why you would force FreeBSD to be a final holdout. -Alfred From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:26:21 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 99E44417 for ; Wed, 30 Jan 2013 17:26:21 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 02AAAA31 for ; Wed, 30 Jan 2013 17:26:20 +0000 (UTC) Received: (qmail 90553 invoked from network); 30 Jan 2013 18:46:19 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Jan 2013 18:46:19 -0000 Message-ID: <510957B9.8070203@freebsd.org> Date: Wed, 30 Jan 2013 18:26:17 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> <5108562A.1040603@freebsd.org> <201301301158.33838.jhb@freebsd.org> In-Reply-To: <201301301158.33838.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:26:21 -0000 On 30.01.2013 17:58, John Baldwin wrote: > On Tuesday, January 29, 2013 6:07:22 pm Andre Oppermann wrote: >> On 29.01.2013 19:50, John Baldwin wrote: >>> On Thursday, January 24, 2013 11:14:40 am John Baldwin wrote: >>>>>> Agree, per-socket option could be useful than global sysctls under >>>>>> certain situation. However, in addition to the per-socket option, >>>>>> could global sysctl nodes to disable idle_restart/idle_cwv help too? >>>>> >>>>> No. This is far too dangerous once it makes it into some tuning guide. >>>>> The threat of congestion breakdown is real. The Internet, or any packet >>>>> network, can only survive in the long term if almost all follow the rules >>>>> and self-constrain to remain fair to the others. What would happen if >>>>> nobody would respect the traffic lights anymore? >>>> >>>> The problem with this argument is Linux has already had this as a tunable >>>> option for years and the Internet hasn't melted as a result. >>>> >>>>> Since this seems to be a burning issue I'll come up with a patch in the >>>>> next days to add a decaying restartCWND that'll be fair and allow a very >>>>> quick ramp up if no loss occurs. >>>> >>>> I think this could be useful. OTOH, I still think the TCP_IGNOREIDLE option >>>> is useful both with and without a decaying restartCWND? >>> >>> *ping* >>> >>> Andre, do you object to adding the new socket option? >> >> Yes, unfortunately I do object. This option, combined with the inflated >> CWND at the end of a burst, effectively removes much, if not all, of the >> congestion control mechanisms originally put in place to allow multiple >> [TCP] streams co-exist on the same pipe. Not having any decay or timeout >> makes it even worse by doing this burst after an arbitrary amount of time >> when network conditions and the congestion situation have certainly changed. > > You have completely ignored the fact that Linux has had this as a global > option for years and the Internet has not melted. Sure. A friend of mine does free climbing and he hasn't crashed yet. He also runs all filesystems async with disk write cache enabled, no backup and hasn't lost a file yet. ;-) > A socket option is far more > fine-grained than their tunable (and requires code changes, not something a > random sysadmin can just toggle as "tuning"). Agreed that a socket option is much more difficult to use. >> The primary principle of TCP is be cooperative with competing streams and >> fairly share bandwidth on a given link. Whenever the ACK clock came to a >> halt for some time we must re-probe (slowstart from a restartCWND) the link >> to compensate for our lack of knowledge of the current link and congestion >> situation. Doing that with a decay function and floor equaling the IW (10 >> segments nowadays) gives a rapid ramp up especially on LAN RTTs while avoiding >> a blind burst and subsequent loss cycle. > > I understand all that, but it isn't applicable to my use case. I'm not sharing > the bandwidth with anyone but other connections of my own (and they are all > lower priority than this one). Also, I have idle periods of hundreds of > milliseconds (large than an RTT on this cross-continental link that also has > high bandwidth), so it seems that even a decayed restartCWND will be useless to > me as it will have decayed down to nothing before I finally restart after long > idle periods. OK. >> If you absolutely know that you're the only one on that network and you want >> pure wirespeed then a TCP cc_null module doing away with all congestion control >> may be the right answer. The infrastructure is in place and it can be selected >> per socket. Plus it can be loaded as a module and thus doesn't have to be part >> of the base system. > > No, I do not think that doing away with all congestion control will work for > my case. Even though we have a dedicated line, etc. that doesn't mean > congestion is impossible and that I don't want the "normal" feedback to apply > during the non-restart cases. BTW, I looked at using alternate congestion > control algorithms (cc_cubic and some of the others) first before resorting to > adding this option and they either did not fix the issue or were buggy. You can simply create your own congestion control algorithm with only the restart window changed. See (pseudo) code below. BTW, I just noticed that the other cc algos don't do not reset the idle window. -- Andre /* boilerplate from netinet/cc/cc_newreno.c here. */ struct cc_algo jhb_cc_algo = { .name = "jhb_full_restartCWND", .ack_received = newreno_ack_received, .after_idle = jhb_after_idle, .cong_signal = newreno_cong_signal, .post_recovery = newreno_post_recovery, }; static void jhb_after_idle(struct cc_var *ccv) { return; } From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:29:54 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3B6A45FA for ; Wed, 30 Jan 2013 17:29:54 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 97011A6C for ; Wed, 30 Jan 2013 17:29:53 +0000 (UTC) Received: (qmail 90573 invoked from network); 30 Jan 2013 18:49:51 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 30 Jan 2013 18:49:51 -0000 Message-ID: <5109588D.9070504@freebsd.org> Date: Wed, 30 Jan 2013 18:29:49 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> <5108562A.1040603@freebsd.org> <201301301158.33838.jhb@freebsd.org> <5109543B.4020304@mu.org> In-Reply-To: <5109543B.4020304@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:29:54 -0000 On 30.01.2013 18:11, Alfred Perlstein wrote: > On 1/30/13 11:58 AM, John Baldwin wrote: >> On Tuesday, January 29, 2013 6:07:22 pm Andre Oppermann wrote: >>> >>> Yes, unfortunately I do object. This option, combined with the inflated >>> CWND at the end of a burst, effectively removes much, if not all, of the >>> congestion control mechanisms originally put in place to allow multiple >>> [TCP] streams co-exist on the same pipe. Not having any decay or timeout >>> makes it even worse by doing this burst after an arbitrary amount of time >>> when network conditions and the congestion situation have certainly changed. >> You have completely ignored the fact that Linux has had this as a global >> option for years and the Internet has not melted. A socket option is far more >> fine-grained than their tunable (and requires code changes, not something a >> random sysadmin can just toggle as "tuning"). > > I agree with John here. > > While Andre's objection makes sense, since the majority of Linux/Unix hosts now have this as a > global option I can't think of why you would force FreeBSD to be a final holdout. Unless OpenBSD, NetBSD, Solaris/Ilumos also support this it is hardly a majority of Linux/Unix hosts. And this isn't something a "sysadmin" should tune at all. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:32:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D067279D for ; Wed, 30 Jan 2013 17:32:33 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id B3A72A98 for ; Wed, 30 Jan 2013 17:32:33 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (ool-45775fce.dyn.optonline.net [69.119.95.206]) by elvis.mu.org (Postfix) with ESMTPSA id 331AD1A3C77 for ; Wed, 30 Jan 2013 09:32:33 -0800 (PST) Message-ID: <51095930.1050900@mu.org> Date: Wed, 30 Jan 2013 12:32:32 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201301291350.39931.jhb@freebsd.org> <5108562A.1040603@freebsd.org> <201301301158.33838.jhb@freebsd.org> <5109543B.4020304@mu.org> <5109588D.9070504@freebsd.org> In-Reply-To: <5109588D.9070504@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:32:33 -0000 On 1/30/13 12:29 PM, Andre Oppermann wrote: > On 30.01.2013 18:11, Alfred Perlstein wrote: >> On 1/30/13 11:58 AM, John Baldwin wrote: >>> On Tuesday, January 29, 2013 6:07:22 pm Andre Oppermann wrote: >>>> >>>> Yes, unfortunately I do object. This option, combined with the >>>> inflated >>>> CWND at the end of a burst, effectively removes much, if not all, >>>> of the >>>> congestion control mechanisms originally put in place to allow >>>> multiple >>>> [TCP] streams co-exist on the same pipe. Not having any decay or >>>> timeout >>>> makes it even worse by doing this burst after an arbitrary amount >>>> of time >>>> when network conditions and the congestion situation have certainly >>>> changed. >>> You have completely ignored the fact that Linux has had this as a >>> global >>> option for years and the Internet has not melted. A socket option >>> is far more >>> fine-grained than their tunable (and requires code changes, not >>> something a >>> random sysadmin can just toggle as "tuning"). >> >> I agree with John here. >> >> While Andre's objection makes sense, since the majority of Linux/Unix >> hosts now have this as a >> global option I can't think of why you would force FreeBSD to be a >> final holdout. > > Unless OpenBSD, NetBSD, Solaris/Ilumos also support this it is hardly a > majority of Linux/Unix hosts. And this isn't something a "sysadmin" > should > tune at all. > My apologies, I should have been more clear. I was speaking of majority of install base, not majority of distros. -Alfred From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 17:55:44 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 51FC7E28; Wed, 30 Jan 2013 17:55:44 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x229.google.com (we-in-x0229.1e100.net [IPv6:2a00:1450:400c:c03::229]) by mx1.freebsd.org (Postfix) with ESMTP id C1B8DB9E; Wed, 30 Jan 2013 17:55:43 +0000 (UTC) Received: by mail-we0-f169.google.com with SMTP id t11so1467982wey.14 for ; Wed, 30 Jan 2013 09:55:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=9F4OY5XpBA103oyGnbGA+D34EOnoh9vwFdA9qpOkKaM=; b=zEJF63THvmP9H5E6jTaR0RfGyrxFAuGWb2NR71F8nydB1HLtgiodi3arA3QcCb4vqR /7kXvJzEEimxqaPjxAzdqzD+NtiPbon9CUVN/OqF/7YVW7KLVp6SSQ2YNxuEeFNTeJJu rGKQ1w9/I58CSLiezvegu3+5pV3lmJGyi3kVWeue0DYXSEyzqIlcBpRFN3IHCixoCtmE 04R4pIzjoAmzsR4RKxrG+MXdMKjUkyXn2xj3JFSDzQ+uDDmHObxmihiYUAVQq4DEuwsn E3QyRiR0WLioFUakBqUBLXuyhwBTtlqPqT9o25EqxdouMMkE2BUUHOhLQ2H9YeSxudKy 6dvw== MIME-Version: 1.0 X-Received: by 10.194.57.82 with SMTP id g18mr10688884wjq.25.1359568542840; Wed, 30 Jan 2013 09:55:42 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.67.6 with HTTP; Wed, 30 Jan 2013 09:55:42 -0800 (PST) In-Reply-To: <201301301114.55770.jhb@freebsd.org> References: <201301291205.41301.jhb@freebsd.org> <20130129231042.52622.qmail@f5-external.bushwire.net> <201301301114.55770.jhb@freebsd.org> Date: Wed, 30 Jan 2013 09:55:42 -0800 X-Google-Sender-Auth: 02Jr_777IOECYKODVF4hBtRIUUM Message-ID: Subject: Re: [PATCH] Allow tcpdrop to use non-space separators From: Adrian Chadd To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 17:55:44 -0000 ... guys, Just add a new feature to netstat that takes the host:port delimiter character on the command line. Default to the existing semantics. Done/done. Adrian (yay, linux solutions!) From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 18:54:36 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 9CBE385A for ; Wed, 30 Jan 2013 18:54:36 +0000 (UTC) (envelope-from nvass@gmx.com) Received: from mout.gmx.net (mout.gmx.net [74.208.4.200]) by mx1.freebsd.org (Postfix) with ESMTP id 5EBDDEE5 for ; Wed, 30 Jan 2013 18:54:36 +0000 (UTC) Received: from mailout-us.gmx.com ([172.19.198.46]) by mrigmx.server.lan (mrigmxus002) with ESMTP (Nemesis) id 0MKqSy-1U0cnr3M7E-0002DX for ; Wed, 30 Jan 2013 19:54:35 +0100 Received: (qmail invoked by alias); 30 Jan 2013 18:54:35 -0000 Received: from 130.43.68.242.dsl.dyn.forthnet.gr (EHLO [192.168.1.66]) [130.43.68.242] by mail.gmx.com (mp-us006) with SMTP; 30 Jan 2013 13:54:35 -0500 X-Authenticated: #46156728 X-Provags-ID: V01U2FsdGVkX1+LntZchmOLTnPrdqjog+TjofKX7SlccdwkYSf3YB wg8UqUbDiXYrR3 Message-ID: <51096C62.2060602@gmx.com> Date: Wed, 30 Jan 2013 20:54:26 +0200 From: Nikos Vassiliadis User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: net@freebsd.org Subject: Re: [PATCH] Allow tcpdrop to use non-space separators References: <201301291205.41301.jhb@freebsd.org> In-Reply-To: <201301291205.41301.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 18:54:36 -0000 On 1/29/2013 7:05 PM, John Baldwin wrote: > A common use case I have at work is to find a busted connection using netstat > -n or sockstat and then want to tcpdrop it. However, tcpdrop requires spaces Hi, While you are there, could you please review this? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/151996 It adds an interactive use flag(-i) so the user can drop connections interactively: > lab# tcpdrop -ia > drop 192.168.73.195 16456 195.167.100.39 80? > drop 192.168.73.195 37746 195.167.100.39 80? y > 192.168.73.195 37746 195.167.100.39 80: dropped > drop 192.168.73.195 41749 195.167.100.39 80? yes > 192.168.73.195 41749 195.167.100.39 80: dropped > drop 192.168.73.60 22 192.168.73.192 60763? > drop 192.168.73.60 22 192.168.73.192 60585? Thanks, Nikos From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 20:20:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BE91D5F0 for ; Wed, 30 Jan 2013 20:20:27 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ia0-x236.google.com (ia-in-x0236.1e100.net [IPv6:2607:f8b0:4001:c02::236]) by mx1.freebsd.org (Postfix) with ESMTP id 830392FE for ; Wed, 30 Jan 2013 20:20:27 +0000 (UTC) Received: by mail-ia0-f182.google.com with SMTP id w33so2921865iag.13 for ; Wed, 30 Jan 2013 12:20:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=dVbvQoBUdhSCbVQa2Pq497T5nqe98prKJcBydADLE5U=; b=C9MbW+GE5DjAGhcUijcjXy26uus5wdXijun+DXmWIu12NycIlO+DfEgWdTJTuJQ0X3 6tbybg/hoDZqHWtZBeO0A31yQQYV+djN/uZEnyJl9O5BIfUmYuIGJELbM74ZtE02Xd13 Ycm2eiFnNVNT7/coIHPk3fYEv85HL/cGoiDfxxnswfQmnazJUVexGYrNNcr7UmRtqFT1 1jBKFy1mSwrhJQWlKDTJjhN4+gtLrm8mRVDZ+nNTLNDQ4v3DWMl7Yz/w66WWaASp5HkP mXy64Udd9/yPzFKthZefpf2m4S3PpC/pyxl5Yhh4I3JgpvWsG0rQWmyfB2QGE4YSm2XI btyw== MIME-Version: 1.0 X-Received: by 10.50.42.200 with SMTP id q8mr4287704igl.102.1359577226142; Wed, 30 Jan 2013 12:20:26 -0800 (PST) Received: by 10.64.53.100 with HTTP; Wed, 30 Jan 2013 12:20:25 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Jan 2013 15:20:25 -0500 Message-ID: Subject: Re: Block ACK in Ralink RT2860 From: Ramanujan Seshadri To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 20:20:27 -0000 Thank you. I also wanted to know the function where the Block ACK Window will be decided. is it decided during the ADDBA session establishment or does it change dynamically. Thankyou Ram On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon wrote: > > Message: 6 > > Date: Thu, 24 Jan 2013 12:23:55 -0500 > > From: Ramanujan Seshadri > > To: freebsd-net@freebsd.org > > Subject: Block ACK in Ralink RT2860 > > Message-ID: > > C58KyA80kgVqenHj8xEkmkKDNHnmbQkZoyKQ-K6r_7V4GGA@mail.gmail.com> > > Content-Type: text/plain; charset=ISO-8859-1 > > > > Hi all, > > I am trying to read the contents of block ack's in a Ralink RT2860 > driver. > > Can you please help me to know which function i should be looking into ? > > At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag at > http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559 > > Then, the diver should receive BA packets, and you can read them. > > > AK > From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 21:01:13 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 463D8F3A for ; Wed, 30 Jan 2013 21:01:13 +0000 (UTC) (envelope-from prvs=735d6b704=kcity@whm4.bsc.rw) Received: from BKDC-DMZ-ESA-01.idc.bsc.rw (BKDC-DMZ-ESA-01.idc.bsc.rw [197.243.16.9]) by mx1.freebsd.org (Postfix) with ESMTP id 8558A6C6 for ; Wed, 30 Jan 2013 21:01:11 +0000 (UTC) Authentication-Results: BKDC-DMZ-ESA-01.idc.bsc.rw; dkim=neutral (message not signed) header.i=none Received-SPF: None (BKDC-DMZ-ESA-01.idc.bsc.rw: no sender authenticity information available from domain of pnutall@safway-llc.com) identity=pra; client-ip=41.74.172.40; receiver=BKDC-DMZ-ESA-01.idc.bsc.rw; envelope-from="kcity@whm4.bsc.rw"; x-sender="pnutall@safway-llc.com"; x-conformance=sidf_compatible Received-SPF: None (BKDC-DMZ-ESA-01.idc.bsc.rw: no sender authenticity information available from domain of kcity@whm4.bsc.rw) identity=mailfrom; client-ip=41.74.172.40; receiver=BKDC-DMZ-ESA-01.idc.bsc.rw; envelope-from="kcity@whm4.bsc.rw"; x-sender="kcity@whm4.bsc.rw"; x-conformance=sidf_compatible Received-SPF: None (BKDC-DMZ-ESA-01.idc.bsc.rw: no sender authenticity information available from domain of postmaster@whm4.bsc.rw) identity=helo; client-ip=41.74.172.40; receiver=BKDC-DMZ-ESA-01.idc.bsc.rw; envelope-from="kcity@whm4.bsc.rw"; x-sender="postmaster@whm4.bsc.rw"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsAOADSICVEpSqwo/2dsb2JhbABCA4J3p1KMYIQTg1MWc4IEUwFuIAciLIV9gkagW4ZaiEySAo0hNgcFgykDlg2GEIo7gnmBbTU X-IronPort-AV: E=Sophos;i="4.84,569,1355090400"; d="scan'208";a="2738217" Received: from unknown (HELO whm4.bsc.rw) ([41.74.172.40]) by BKDC-DMZ-ESA-01.idc.bsc.rw with ESMTP; 30 Jan 2013 22:59:55 +0200 Received: from kcity by whm4.bsc.rw with local (Exim 4.80) (envelope-from ) id 1U0ejZ-0003jW-UI for freebsd-net@freebsd.org; Wed, 30 Jan 2013 22:58:18 +0200 To: freebsd-net@freebsd.org Subject: Request for Price Quote & Credit Application X-PHP-Script: www.kigalicity.gov.rw/IMG/config/scripts/example/m.php for 199.114.222.103 From: Peter Nutall MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit Message-Id: Date: Wed, 30 Jan 2013 22:58:17 +0200 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: pnutall@safway-llc.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:01:13 -0000 Dear Sales Dept, We are currently looking for quote and availability on the listed items below to be used for our internal needs. Safway Services, LLC would like to establish an account for Net 30 Terms with your company. 1. InFocus Systems IN5122 Lumen Projector XGA Resolution - WXGA 2. Seagate ST31000524AS Barracuda Hard Drive - 1TB, SATA 6Gbps, 7200 RPM, 32MB 3. Hewlett-Packard 22 O.E.M Tri-colour Inkjet Print Cartridge (C9352AN) Thank you and have a great day! -- Peter Nutall Purchasing Manager Safway Services, LLC N19 W24200 Riverwood Dr. Waukesha, WI 53188 T: 262.347.3723 Ext 2 F: 262.468.3027 DISCLAIMER: This e-mail is intended for the use of the addressee(s) only and may contain privileged, confidential, or proprietary information that is exempt from disclosure under law. If you are not the intended recipient, please do not read, copy, use or disclose the contents of this communication to others. Please notify the sender that you have received this e-mail in error by replying to the e-mail. Please then delete the e-mail and destroy any copies of it. Thank you. From owner-freebsd-net@FreeBSD.ORG Wed Jan 30 22:45:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B7EC5DA3 for ; Wed, 30 Jan 2013 22:45:18 +0000 (UTC) (envelope-from moonlightakkiy@yahoo.ca) Received: from nm23.bullet.mail.bf1.yahoo.com (nm23.bullet.mail.bf1.yahoo.com [98.139.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 5B52CB09 for ; Wed, 30 Jan 2013 22:45:15 +0000 (UTC) Received: from [98.139.212.153] by nm23.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2013 22:45:14 -0000 Received: from [98.139.211.200] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 30 Jan 2013 22:45:14 -0000 Received: from [127.0.0.1] by smtp209.mail.bf1.yahoo.com with NNFMP; 30 Jan 2013 22:45:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.ca; s=s1024; t=1359585914; bh=6l8e/ye1EhS45Bgfqk3hrcGaxpdVnVrxnDz07OjTedA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Received:MIME-Version:X-Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type; b=YkFy/m/J1PHjXabdbMKUTOGSE6Sgco6+FucMVr25ln9WYBBytGXjDPtfG9TtJiUegnodfzTpOK3rGX4aYrmu708XHkHRvARxkZp9Wo5Oq6o/afkFH/1pvoXZjVD+G1bs0i+uGiYICPgL0ENOOzqjJ+Qsku21zSI+9fw6vG+415g= X-Yahoo-Newman-Id: 947876.21850.bm@smtp209.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .dZOMDoVM1mRjWlVfmwSJsJMusEkoUU89F.ZP6s1yAvjCyz HFS20wqZGoWHUq2VfhyWELX38muv47r.grMfhN9FNQNz7il7YXDwrXruLkTE 2pGf9BIYgMVnBlmMRCzHd9CIqXx_OpqjzNC0MOO4H8QFOkvkfxdkZCeKZt7R zKukvu3EaaUWBuAN7.CfiETSx_Fxwt.i6HBMjOoApkckA2WAZK3TPtsz9XDt Ck6qK5YdZw0hlFOavlfI7_vcFPwIFmjEPrso8u6qE6H5zyS9BHYfwADxHuDy ZNumL66QX.S0J3yvVTgAGGoDQcXRH1GdPSGZcHMsyeFZ0X04Qb_z3UKn1_J1 YzqJa7mQ1A_o_ybJBdhR9C4lnNhZT0FikW5aV2T53a6KOHu2XPRhtcfquxvM 22cEboSKXssl46uU9Vj_wXLJBVJJJRxr.SxPUzbaGZ3dlavB_vLhKoDRlWei BrEKgplXRCDQaMWDyy31W2BbtYaLnP3ealGXvX606Z56C6Lw9dzHnHP7jmF6 zajrQJ8iAodQb8ZiG7iEmwWSX10xo_RPz0k3dv1RO0FN66Tun2xVMTUpf X-Yahoo-SMTP: Xr6qjFWswBAEmd20sAvB4Q3keqXvXsIH9TjJ Received: from mail-pa0-f51.google.com (moonlightakkiy@209.85.220.51 with plain) by smtp209.mail.bf1.yahoo.com with SMTP; 30 Jan 2013 14:45:14 -0800 PST Received: by mail-pa0-f51.google.com with SMTP id hz1so432145pad.10 for ; Wed, 30 Jan 2013 14:45:13 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.83.136 with SMTP id q8mr14840551pay.83.1359585913968; Wed, 30 Jan 2013 14:45:13 -0800 (PST) Received: by 10.68.52.170 with HTTP; Wed, 30 Jan 2013 14:45:13 -0800 (PST) In-Reply-To: References: Date: Wed, 30 Jan 2013 15:45:13 -0700 Message-ID: Subject: Re: Block ACK in Ralink RT2860 From: PseudoCylon To: Ramanujan Seshadri Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:45:18 -0000 On Wed, Jan 30, 2013 at 1:20 PM, Ramanujan Seshadri wrote: > Thank you. I also wanted to know the function where the Block ACK Window > will be decided. is it decided during the ADDBA session establishment or > does it change dynamically. The hardware will aggregate packets until any of following limits hit max http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L782 * rt2860_txwi.flags RT2860_TX_MPDU_DSITY_SHIFT 000 == no restriction 001 == 1/4 us 010 == 1/2 us ... 111 == 16 us * rt2860_txwi.xflags RT2860_TX_BAWINSIZE_SHIFT (frame count) http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L93 * RT2860_MAX_LEN_CFG bit 12:13 00 == 8k bytes 01 == 16k 10 == 32k 11 == 64k At a quick look, none of them is set in current code. Also, RT2860_TX_AMPDU flag need to be set to make the h/w aggregate packets. How is ampdu working on ral(4)? I cannot test because I do not have any ral(4) nic (only have run(4) nics). AK > > > On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon > wrote: >> >> > Message: 6 >> > Date: Thu, 24 Jan 2013 12:23:55 -0500 >> > From: Ramanujan Seshadri >> > To: freebsd-net@freebsd.org >> > Subject: Block ACK in Ralink RT2860 >> > Message-ID: >> > >> > >> > Content-Type: text/plain; charset=ISO-8859-1 >> > >> > Hi all, >> > I am trying to read the contents of block ack's in a Ralink RT2860 >> > driver. >> > Can you please help me to know which function i should be looking into ? >> >> At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag >> at >> http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559 >> >> Then, the diver should receive BA packets, and you can read them. >> >> >> AK > > From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 00:42:17 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7819C7F8; Thu, 31 Jan 2013 00:42:17 +0000 (UTC) (envelope-from john@saltant.com) Received: from homiemail-a89.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by mx1.freebsd.org (Postfix) with ESMTP id 4EFD8F87; Thu, 31 Jan 2013 00:42:16 +0000 (UTC) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 045DE318064; Wed, 30 Jan 2013 16:42:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:subject:content-type: content-transfer-encoding; s=saltant.com; bh=GQz+Tw4yfbTKf/2LOxz 3Tg0u0qs=; b=Tw/GcLyHRpjUaksUuhomBMEmjt6fRpoZmh5TMVzv3iso26TnF+t E+E1H4+gvISud55tE/OEcsqAREIdfgRcU5pVgkwyHuYZ3t6fAKZ2XeucDkRp3NUj zVdntEGhyLS+lLufLb9D/VuJG1dztA1nrpiDxlIPhaGbJ8h5u3ynAPtw= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 9F84131805C; Wed, 30 Jan 2013 16:42:09 -0800 (PST) Message-ID: <5109BDE0.6040306@saltant.com> Date: Wed, 30 Jan 2013 19:42:08 -0500 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: bug-followup@FreeBSD.org, freebsd-net@freebsd.org Subject: Re: bin/105614: [patch] setkey(8): Creating NULL encryption ESP SAs with setkey fails X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 00:42:17 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I found today that this bug still exists in 9.1-STABLE r245089, and that the suggested patch appears to fix it. If any further testing or analysis is needed prior to committing a fix, I would be glad to help. CC: freebsd-net@ in the hopes of being noticed and adopted -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCb3gAAoJEEdKvTwaez9w4k8H/3sX3Z4UXcDxDGxFr7Mkhruf tpye1L8L6RM1ojatg+sPNnHKfasTULU7YDvgULDcDQfUXZ9UsSGXO+rWbyWpsWpq l2mLl5oxxQf5lcazshxuApkmhsvKKOBI6wAtXz0y/i88wpCREiqVIGRLL30KK+yh ENOkDz08iFtaKpK7+fIFmlJjSc4e8uXnA6Lnr0rjcDXW77KkmA+nFcw0x0FhZDKn pRSzX2hRaGLak6U5Bj03/lsxnsZSVIHg7ztqJSEvp+YQfmeA1ENxlnCdeAP0Polk HFO4ROPHW0sWvjfJypcohxbWgyIkJbYcPeqnBfoKyUUpEATFuXNX4dLtAIVjOqA= =3N3O -----END PGP SIGNATURE----- From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 04:32:10 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id ECBEB907 for ; Thu, 31 Jan 2013 04:32:10 +0000 (UTC) (envelope-from lists@eitanadler.com) Received: from mail-ve0-f174.google.com (mail-ve0-f174.google.com [209.85.128.174]) by mx1.freebsd.org (Postfix) with ESMTP id AF6B398B for ; Thu, 31 Jan 2013 04:32:10 +0000 (UTC) Received: by mail-ve0-f174.google.com with SMTP id c13so1676292vea.19 for ; Wed, 30 Jan 2013 20:32:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=gzeu9AS/sCNN2kKsi2eLAXrm7sD4wWYeDgkIsm1QLeM=; b=jhLhJeN/xk6MYPLsvM8JgfDyMNEhC1Zl3S/6eCy5P6Gz1H8fEWqL0gZYStHRP6FPnU lqq5e6ldbDpybv2kv37xZJLgWoi6diZ2/QXiHLFCwIqi0zKCQQ0rxScp8Qd2JLb0rCES 0XnpqzriG98fXLjVFTprZX7qWOdZVVdEKnmAo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=gzeu9AS/sCNN2kKsi2eLAXrm7sD4wWYeDgkIsm1QLeM=; b=Jt17339V3G+RGt/+lTSaNj+nssngHjoTaOL4HVY0ptu90JOMIH5lutXwHnzYvGabDj 5XBXNWZ7cYVdfssXslky4rz4jg3TOfw008qz8kX3XvFqbcOW8LqeeKYHQHSdwVuQqJoz agKfer5yl/aoDrC7mb9N+AA4LEXKnbPB4SEuk6iTucfG19+Hjc/Ff4+4s//1WMyhNxMB 8eHIs+jHr5iF/3ld7gbazaSH9GdawVF+pfUdALlazKIbWnu783dnAOdyqCujc8DrxCXw vKEkxm8rlhXFLpnbzuyb62uiXlV+XhKxOCoNWSXUai/dm9mIj7ojggnnJNCs3Y1viP0T QVdA== X-Received: by 10.220.150.136 with SMTP id y8mr6887832vcv.34.1359606724090; Wed, 30 Jan 2013 20:32:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.195.70 with HTTP; Wed, 30 Jan 2013 20:31:33 -0800 (PST) In-Reply-To: <5109BDE0.6040306@saltant.com> References: <5109BDE0.6040306@saltant.com> From: Eitan Adler Date: Wed, 30 Jan 2013 23:31:33 -0500 Message-ID: Subject: Re: bin/105614: [patch] setkey(8): Creating NULL encryption ESP SAs with setkey fails To: "John W. O'Brien" Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQmMw9D2kHywvKROrqBcU6GG6yomD5IsP/h8fIm1u8vkc7LFgWykBXMwcyYPyCC4ZmtPZWdX Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 04:32:11 -0000 On 30 January 2013 19:42, John W. O'Brien wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I found today that this bug still exists in 9.1-STABLE r245089, and > that the suggested patch appears to fix it. > > If any further testing or analysis is needed prior to committing a > fix, I would be glad to help. > > CC: freebsd-net@ in the hopes of being noticed and adopted The patch is maleformed in the PR. Perhaps you could attach and resend? -- Eitan Adler From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 08:45:23 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id E315C3C3 for ; Thu, 31 Jan 2013 08:45:23 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id CD5BC310 for ; Thu, 31 Jan 2013 08:45:23 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,575,1355126400"; d="scan'208";a="14589303" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 31 Jan 2013 00:45:17 -0800 Received: from vmwexceht03-prd.hq.netapp.com (vmwexceht03-prd.hq.netapp.com [10.106.76.241]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0V8jGhl008396; Thu, 31 Jan 2013 00:45:17 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0328.009; Thu, 31 Jan 2013 00:45:16 -0800 From: "Eggert, Lars" To: "mjl@luckie.org.nz" Subject: Re: high cpu usage on natd / dhcpd Thread-Topic: high cpu usage on natd / dhcpd Thread-Index: AQHN/49K3QG1cuBZpEGa6wjl1WYXnA== Date: Thu, 31 Jan 2013 08:45:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 08:45:23 -0000 Hi, > I have a small system running FreeBSD 8.2 that does NAT using ipfw and=20 > natd to systems attached to two interfaces: em0 and wlan0. I have a=20 > dhcpd daemon issuing leases on those interfaces. The system has an em1=20 > interface plugged into a cable modem where it obtains a DHCP lease from=20 > an ISP. >=20 > For some reason, when traffic from the Internet terminates on the system= =20 > itself (I scp a file from the computer) the natd and dhcpd processes=20 > consume significant CPU, and the throughput is less than I expect.=20 > Traffic that passes through to a computer behind the NAT flows without=20 > causing the natd or dhcpd processes to measurably consume CPU. I see exactly the same issue on -STABLE. Have you been able to figure out t= he cause? Thanks, Lars= From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 09:43:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9565231B for ; Thu, 31 Jan 2013 09:43:37 +0000 (UTC) (envelope-from kevlo@kevlo.org) Received: from ns.kevlo.org (kevlo.org [220.128.136.52]) by mx1.freebsd.org (Postfix) with ESMTP id 2AB6F7DD for ; Thu, 31 Jan 2013 09:43:36 +0000 (UTC) Received: from srg.kevlo.org (git.kevlo.org [220.128.136.52]) by ns.kevlo.org (8.14.5/8.14.5) with ESMTP id r0V9goVf084577; Thu, 31 Jan 2013 17:42:50 +0800 (CST) (envelope-from kevlo@kevlo.org) Message-ID: <510A3CA3.2010803@kevlo.org> Date: Thu, 31 Jan 2013 17:42:59 +0800 From: Kevin Lo User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: high cpu usage on natd / dhcpd References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" , "mjl@luckie.org.nz" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 09:43:37 -0000 On 2013/01/31 16:45, Eggert, Lars wrote: > Hi, > >> I have a small system running FreeBSD 8.2 that does NAT using ipfw and >> natd to systems attached to two interfaces: em0 and wlan0. I have a >> dhcpd daemon issuing leases on those interfaces. The system has an em1 >> interface plugged into a cable modem where it obtains a DHCP lease from >> an ISP. >> >> For some reason, when traffic from the Internet terminates on the system >> itself (I scp a file from the computer) the natd and dhcpd processes >> consume significant CPU, and the throughput is less than I expect. >> Traffic that passes through to a computer behind the NAT flows without >> causing the natd or dhcpd processes to measurably consume CPU. > I see exactly the same issue on -STABLE. Have you been able to figure out the cause? Use ipfw nat instead. It uses the libalias(3) in kernel and avoids gigantic natd(8) overhead. > > Thanks, > Lars > Kevin From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 10:53:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4B01BE21 for ; Thu, 31 Jan 2013 10:53:36 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx1.netapp.com (mx1.netapp.com [216.240.18.38]) by mx1.freebsd.org (Postfix) with ESMTP id 109BBACB for ; Thu, 31 Jan 2013 10:53:35 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,575,1355126400"; d="scan'208";a="238686919" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx1-out.netapp.com with ESMTP; 31 Jan 2013 02:52:27 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r0VAqP7h000842; Thu, 31 Jan 2013 02:52:26 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Thu, 31 Jan 2013 02:52:24 -0800 From: "Eggert, Lars" To: Kevin Lo Subject: Re: high cpu usage on natd / dhcpd Thread-Topic: high cpu usage on natd / dhcpd Thread-Index: AQHN/49K3QG1cuBZpEGa6wjl1WYXnJhjtbOAgAATZoA= Date: Thu, 31 Jan 2013 10:52:23 +0000 Message-ID: References: <510A3CA3.2010803@kevlo.org> In-Reply-To: <510A3CA3.2010803@kevlo.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3CC1A1924D75A748852EED670B45D6BB@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" , "mjl@luckie.org.nz" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:53:36 -0000 Hi, On Jan 31, 2013, at 10:42, Kevin Lo wrote: > Use ipfw nat instead. It uses the libalias(3) in kernel and avoids > gigantic natd(8) overhead. I tried that, but it froze the system. Lars From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 12:43:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E644AB9A; Thu, 31 Jan 2013 12:43:38 +0000 (UTC) (envelope-from john@saltant.com) Received: from homiemail-a35.g.dreamhost.com (caiajhbdccac.dreamhost.com [208.97.132.202]) by mx1.freebsd.org (Postfix) with ESMTP id C6EBB1CD; Thu, 31 Jan 2013 12:43:38 +0000 (UTC) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 1995454058; Thu, 31 Jan 2013 04:43:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=saltant.com; h=message-id :date:from:mime-version:to:cc:subject:references:in-reply-to: content-type; s=saltant.com; bh=hKktUKWf97V61Boque7sazY5DDo=; b= OH4vw5ZKIq8v3Ed685Tza49i1Gj2bAiH8T2X3wCJ9FyS7U3D8tfKbU8vUzKC72+P VuZOi9l29Nq49e8IWC6n9HcdXdoq7Xa9r7P/5H1uCJjxk4J6ATtLIctfpaE8cxRJ IwxFDZh7s1MZ8MMbksBRJ+pg82uWzVehKMJfzeNbSZA= Received: from imago.y.saltant.net (vice.saltant.net [96.227.187.16]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: john@saltant.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id 766F054057; Thu, 31 Jan 2013 04:43:31 -0800 (PST) Message-ID: <510A66F2.6080907@saltant.com> Date: Thu, 31 Jan 2013 07:43:30 -0500 From: "John W. O'Brien" Organization: Saltant Solutions User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: Eitan Adler Subject: Re: bin/105614: [patch] setkey(8): Creating NULL encryption ESP SAs with setkey fails References: <5109BDE0.6040306@saltant.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/mixed; boundary="------------000206080500030101040004" Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:43:39 -0000 This is a multi-part message in MIME format. --------------000206080500030101040004 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/30/2013 11:31 PM, Eitan Adler wrote: > The patch is maleformed in the PR. Perhaps you could attach and > resend? Gladly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iQEcBAEBAgAGBQJRCmbyAAoJEEdKvTwaez9woYkH/0Wm/KjM+6ggRfDs6hcHDE0X J1KCr3+Y2NAkCXk76uQB2S0K4g1NMF6oIP3JWAMaRKww9m9kaWTHz9wZAqeaVa8c DriGjePFLUs+ukjRWuYKwYbTHzF/21DTxzOvkqAXOnprZiwY4T4a+WtF0SPAL5lO FyZTtH0XV+jW3o5sZ5XFQeNhAwbREvvv9VUp6mw6IoUi0dDcfeF3GVE/a63d2YDy A4UKqsQOIC/hzQqtQBrSOfXTPylb0C4mjflzX50lMLfNI3Xi7NA/NnyGG2p1FSW1 XHngu2TSULx6OQOenX/xUh2Kag1yBxOv32UKNuR2/zX4CO5q8+CVZx7tQS9lkY0= =irDK -----END PGP SIGNATURE----- --------------000206080500030101040004 Content-Type: text/plain; charset=UTF-8; name="patch-sbin__setkey__parse.y.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="patch-sbin__setkey__parse.y.txt" SW5kZXg6IHBhcnNlLnkKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gcGFyc2UueQkocmV2aXNpb24gMjQ1 OTQ3KQorKysgcGFyc2UueQkod29ya2luZyBjb3B5KQpAQCAtMTAxMCw3ICsxMDEwLDggQEAK IAlsID0gc2l6ZW9mKHN0cnVjdCBzYWRiX21zZyk7CiAKIAkvKiBzZXQgZW5jcnlwdGlvbiBh bGdvcml0aG0sIGlmIHByZXNlbnQuICovCi0JaWYgKHNhdHlwZSAhPSBTQURCX1hfU0FUWVBF X0lQQ09NUCAmJiBwX2tleV9lbmMpIHsKKwlpZiAoc2F0eXBlICE9IFNBREJfWF9TQVRZUEVf SVBDT01QICYmCisJICAgIChwX2tleV9lbmMgfHwgc2F0eXBlID09IFNBREJfU0FUWVBFX0VT UCkpIHsKIAkJc3RydWN0IHNhZGJfa2V5IG1fa2V5OwogCiAJCW1fa2V5LnNhZGJfa2V5X2xl biA9Cg== --------------000206080500030101040004-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 15:04:28 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36C2891B for ; Thu, 31 Jan 2013 15:04:28 +0000 (UTC) (envelope-from mjl@luckie.org.nz) Received: from cdptpa-omtalb.mail.rr.com (cdptpa-omtalb.mail.rr.com [75.180.132.120]) by mx1.freebsd.org (Postfix) with ESMTP id ED694CB2 for ; Thu, 31 Jan 2013 15:04:27 +0000 (UTC) X-Authority-Analysis: v=2.0 cv=acPjbGUt c=1 sm=0 a=aIgkrZOPZtJQBHPFbnUF7Q==:17 a=lrOb0CNyTTcA:10 a=XBbVgglCP-sA:10 a=vPikwmRbe7UA:10 a=VhVxFnc1AAAA:8 a=iY0PzhIkGeEA:10 a=6pt3igK9rp8OJd7gMdoA:9 a=wPNLvfGTeEIA:10 a=_92z0Kcydohi69pVtA0A:9 a=aIgkrZOPZtJQBHPFbnUF7Q==:117 X-Cloudmark-Score: 0 X-Authenticated-User: X-Originating-IP: 76.88.32.44 Received: from [76.88.32.44] ([76.88.32.44:37692] helo=spandex.luckie.org.nz) by cdptpa-oedge03.mail.rr.com (envelope-from ) (ecelerity 2.2.3.46 r()) with ESMTP id D5/7F-26261-8B78A015; Thu, 31 Jan 2013 15:03:20 +0000 Received: from mylar.luckie.org.nz ([192.168.2.20]) by spandex.luckie.org.nz with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1U0vfb-0006gX-NX; Thu, 31 Jan 2013 07:03:19 -0800 Message-ID: <510A87B8.7000705@luckie.org.nz> Date: Thu, 31 Jan 2013 07:03:20 -0800 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Eggert, Lars" Subject: Re: high cpu usage on natd / dhcpd References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigF45E47D05C07D33B9E22062D" Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:04:28 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF45E47D05C07D33B9E22062D Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 01/31/13 00:45, Eggert, Lars wrote: > Hi, >=20 >> I have a small system running FreeBSD 8.2 that does NAT using ipfw and= =20 >> natd to systems attached to two interfaces: em0 and wlan0. I have a=20 >> dhcpd daemon issuing leases on those interfaces. The system has an em= 1=20 >> interface plugged into a cable modem where it obtains a DHCP lease fro= m=20 >> an ISP. >> >> For some reason, when traffic from the Internet terminates on the syst= em=20 >> itself (I scp a file from the computer) the natd and dhcpd processes=20 >> consume significant CPU, and the throughput is less than I expect.=20 >> Traffic that passes through to a computer behind the NAT flows without= =20 >> causing the natd or dhcpd processes to measurably consume CPU. >=20 > I see exactly the same issue on -STABLE. Have you been able to figure o= ut the cause? sudo ipfw list 00501 allow ip from any to any via lo0 00502 allow ip from any to any via em0 00503 allow ip from any to any via wlan0 00504 allow ip from any to any via vr0 00505 allow ip from any to any via gif0 00506 allow ip from any to any via tun0 00510 allow ip from me to not me out via em1 00550 divert 8668 ip from any to any via em1 Rule 510 fixes it. --------------enigF45E47D05C07D33B9E22062D 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.19 (FreeBSD) iEYEARECAAYFAlEKh7wACgkQKyuDKSEQAGCduwCgsVw26i3syBMI1M85VjFNHOUs wmEAn21nX7S/Ox9SlMGOGyLU0RKQ0qTX =BTaf -----END PGP SIGNATURE----- --------------enigF45E47D05C07D33B9E22062D-- From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 15:50:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 7011775A for ; Thu, 31 Jan 2013 15:50:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4667AF37 for ; Thu, 31 Jan 2013 15:50:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0VFo02N055744 for ; Thu, 31 Jan 2013 15:50:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0VFo0C5055739; Thu, 31 Jan 2013 15:50:00 GMT (envelope-from gnats) Date: Thu, 31 Jan 2013 15:50:00 GMT Message-Id: <201301311550.r0VFo0C5055739@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: George Kontostanos Subject: re:kern/169438: [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: George Kontostanos List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:50:01 -0000 The following reply was made to PR kern/169438; it has been noted by GNATS. From: George Kontostanos To: bug-followup@FreeBSD.org, sakuma.takayuki@jp.fujitsu.com Cc: Subject: re:kern/169438: [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work Date: Thu, 31 Jan 2013 17:44:39 +0200 I am facing the same problem in 2 FreeBSD 9.1 boxes. I was wondering if this has been resolved or if there is an patch for this. Thanks -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 17:31:15 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6F20D7B4; Thu, 31 Jan 2013 17:31:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4919273A; Thu, 31 Jan 2013 17:31:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r0VHVEfk075889; Thu, 31 Jan 2013 17:31:14 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r0VHVEe7075885; Thu, 31 Jan 2013 17:31:14 GMT (envelope-from linimon) Date: Thu, 31 Jan 2013 17:31:14 GMT Message-Id: <201301311731.r0VHVEe7075885@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/175734: no ethernet detected on system with EG20T PCH chipset ATOM E6xx series X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 17:31:15 -0000 Old Synopsis: compatibility with EG20T PCH chipset ATOM E6xx series New Synopsis: no ethernet detected on system with EG20T PCH chipset ATOM E6xx series Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 31 17:29:11 UTC 2013 Responsible-Changed-Why: Although this is system-specific, I'll take a chance on assigning this to freebsd-net in case someone knows of a way to convince an existing driver to see this chip. http://www.freebsd.org/cgi/query-pr.cgi?pr=175734 From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 20:03:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0FB5C88; Thu, 31 Jan 2013 20:03:40 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ve0-f173.google.com (mail-ve0-f173.google.com [209.85.128.173]) by mx1.freebsd.org (Postfix) with ESMTP id 5E5C1E85; Thu, 31 Jan 2013 20:03:40 +0000 (UTC) Received: by mail-ve0-f173.google.com with SMTP id oz10so2379530veb.32 for ; Thu, 31 Jan 2013 12:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=sw5RyhXMoxVXY1iSdh6Y3aJfGGiaFYq3M4J/TcauwUU=; b=uOE8zaVKkbIo0rHwzsNhkbN3xZr2XStAQNdfJd9MrBhaaW/CLd0Vt0DMvw8aatPle1 8n0pVu0PR+jimB84fnpj1B4Xs13RTqdu2aza5Z6k2sZBQnIB3UPunpZO6uMo151iK50Q LLyrTRMkOdjQtiK+CCwlWXmPW7Tvc+T18zPrgId+iA7I2SJEI1Ap8HlwjNXulLzhz1KR zTqJE48N5CDAHaolRzce4OmhwDRqWwHlrMBQsosUoWqR0r8B7UyHDqUP1VSS8IWj19S7 oF+ly2HHOjLLKCAQzx8aSObxVMf49amzwqo3WoeOl8u5mAMH7ThdQl6husICy9tGRQTd lAEg== MIME-Version: 1.0 X-Received: by 10.52.92.225 with SMTP id cp1mr4843141vdb.41.1359662619433; Thu, 31 Jan 2013 12:03:39 -0800 (PST) Received: by 10.221.12.75 with HTTP; Thu, 31 Jan 2013 12:03:39 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 12:03:39 -0800 Message-ID: Subject: Re: e1000 serdes link flap From: Jack Vogel To: Neel Natu Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: Jack F Vogel , freebsd-net , Ryan Stone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 20:03:40 -0000 I will not commit this patch, this is shared code used by all the different OS's we do drivers for, and it is unnecessary in any case, because the latest version of the internal code has this resolved.... So, I will soon do some updates to the e1000 drivers anyway and as part of that I will sync the shared code base with the latest, this should address the issue... OK? Cheers, Jack On Mon, Jan 28, 2013 at 8:14 PM, Neel Natu wrote: > Hi Jack, > > On Wed, Jan 23, 2013 at 2:58 PM, Ryan Stone wrote: > > On Wed, Jan 23, 2013 at 2:13 AM, Neel Natu wrote: > >> > >> Hi, > >> > >> I am running into a problem in head with the e1000 link state > >> detection logic attached to a 82571EB serdes controller. > >> > >> The symptom is that the link state keeps flapping between "up" and > "down". > >> > >> After I enabled the debug output in > >> 'e1000_check_for_serdes_link_82571()' this is what I see: > >> > >> e1000_check_for_serdes_link_82571 > >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 > >> FORCED_UP -> AN_PROG > >> em6: link state changed to DOWN > >> e1000_check_for_serdes_link_82571 > >> ctrl = 0x4c0201, status = 0x803a4, rxcw = 0x44000000 > >> AN_PROG -> FORCED_UP > >> em6: link state changed to UP > >> e1000_check_for_serdes_link_82571 > >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 > >> FORCED_UP -> AN_PROG > >> em6: link state changed to DOWN > >> > >> > >> The problem goes away if I apply the following patch to bring the link > >> state detection logic in line with the e1000e driver in Linux: > >> > >> Index: e1000_82571.c > >> =================================================================== > >> --- e1000_82571.c (revision 245766) > >> +++ e1000_82571.c (working copy) > >> @@ -1712,10 +1712,8 @@ > >> * auto-negotiation in the TXCW register and > >> disable > >> * forced link in the Device Control register in > >> an > >> * attempt to auto-negotiate with our link > >> partner. > >> - * If the partner code word is null, stop > forcing > >> - * and restart auto negotiation. > >> */ > >> - if ((rxcw & E1000_RXCW_C) || !(rxcw & > >> E1000_RXCW_CW)) { > >> + if ((rxcw & E1000_RXCW_C) != 0) { > >> /* Enable autoneg, and unforce link up > */ > >> E1000_WRITE_REG(hw, E1000_TXCW, > >> mac->txcw); > >> E1000_WRITE_REG(hw, E1000_CTRL, > >> > >> I am not sure why the !(rxcw & E1000_RXCW_CW) check was added and the > >> e1000 SDM does not have any more information. > >> > >> Jack, can you take a look at the patch and commit if it looks alright? > > > > > > I have this change applied internally. I thought that it was something > > funny in my environment, so I never tried to push it upstream. Sorry for > > costing you time in having to debug this. :( > > Are you planning to commit this patch? > > I am happy to get you more information from my system if it helps you > get to the bottom of this quicker. > > best > Neel > From owner-freebsd-net@FreeBSD.ORG Thu Jan 31 22:29:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D7612662; Thu, 31 Jan 2013 22:29:24 +0000 (UTC) (envelope-from neelnatu@gmail.com) Received: from mail-ve0-f171.google.com (mail-ve0-f171.google.com [209.85.128.171]) by mx1.freebsd.org (Postfix) with ESMTP id 87ACA84C; Thu, 31 Jan 2013 22:29:24 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id b10so2494589vea.30 for ; Thu, 31 Jan 2013 14:29:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=765TEOAGEJQFtLx9tjI9ta3oZNDCPupJZo/zu7Mszqs=; b=smDAufsciRO1rWgaegn+qk34rB/j7zQ0L8VAZfDx7lAJkyWKH83yQ/IUGcr1xWJoCO rGiSWDvV0HNlCR66N5ZQh8Un54mKpDpGKWqIFn7qsXcFMAHQ+SQmq2hZUc9l07TwwlXg n2Kg90bmrd6JKI6X/ET9/iK120Y8j2p5PiGqvggvORFQYw3qcSjAPwnPgQPmAa2/njxu hFTbodMUNQGQ0Fbfa3HovnNMKLOW93MQwCYxHU8ZMjt0vFa5l8cJ5TWozlvvskw5hwf7 4ecXcO7Zkd2LtuvozyXSc+1PhLRlWslMFyJQgUP/PZn03kVa8rS3tviUFdEi+jjJnJIE agGg== MIME-Version: 1.0 X-Received: by 10.52.27.50 with SMTP id q18mr8543177vdg.20.1359671358461; Thu, 31 Jan 2013 14:29:18 -0800 (PST) Received: by 10.220.21.141 with HTTP; Thu, 31 Jan 2013 14:29:18 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 14:29:18 -0800 Message-ID: Subject: Re: e1000 serdes link flap From: Neel Natu To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Cc: Jack F Vogel , freebsd-net , Ryan Stone X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 22:29:24 -0000 Hi Jack, On Thu, Jan 31, 2013 at 12:03 PM, Jack Vogel wrote: > I will not commit this patch, this is shared code used by all the different > OS's we do > drivers for, and it is unnecessary in any case, because the latest version > of the internal > code has this resolved.... So, I will soon do some updates to the e1000 > drivers anyway > and as part of that I will sync the shared code base with the latest, this > should address > the issue... OK? Sounds good. best Neel > > Cheers, > > Jack > > > > On Mon, Jan 28, 2013 at 8:14 PM, Neel Natu wrote: >> >> Hi Jack, >> >> On Wed, Jan 23, 2013 at 2:58 PM, Ryan Stone wrote: >> > On Wed, Jan 23, 2013 at 2:13 AM, Neel Natu wrote: >> >> >> >> Hi, >> >> >> >> I am running into a problem in head with the e1000 link state >> >> detection logic attached to a 82571EB serdes controller. >> >> >> >> The symptom is that the link state keeps flapping between "up" and >> >> "down". >> >> >> >> After I enabled the debug output in >> >> 'e1000_check_for_serdes_link_82571()' this is what I see: >> >> >> >> e1000_check_for_serdes_link_82571 >> >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 >> >> FORCED_UP -> AN_PROG >> >> em6: link state changed to DOWN >> >> e1000_check_for_serdes_link_82571 >> >> ctrl = 0x4c0201, status = 0x803a4, rxcw = 0x44000000 >> >> AN_PROG -> FORCED_UP >> >> em6: link state changed to UP >> >> e1000_check_for_serdes_link_82571 >> >> ctrl = 0x4c0241, status = 0x803a7, rxcw = 0x44000000 >> >> FORCED_UP -> AN_PROG >> >> em6: link state changed to DOWN >> >> >> >> >> >> The problem goes away if I apply the following patch to bring the link >> >> state detection logic in line with the e1000e driver in Linux: >> >> >> >> Index: e1000_82571.c >> >> =================================================================== >> >> --- e1000_82571.c (revision 245766) >> >> +++ e1000_82571.c (working copy) >> >> @@ -1712,10 +1712,8 @@ >> >> * auto-negotiation in the TXCW register and >> >> disable >> >> * forced link in the Device Control register >> >> in >> >> an >> >> * attempt to auto-negotiate with our link >> >> partner. >> >> - * If the partner code word is null, stop >> >> forcing >> >> - * and restart auto negotiation. >> >> */ >> >> - if ((rxcw & E1000_RXCW_C) || !(rxcw & >> >> E1000_RXCW_CW)) { >> >> + if ((rxcw & E1000_RXCW_C) != 0) { >> >> /* Enable autoneg, and unforce link up >> >> */ >> >> E1000_WRITE_REG(hw, E1000_TXCW, >> >> mac->txcw); >> >> E1000_WRITE_REG(hw, E1000_CTRL, >> >> >> >> I am not sure why the !(rxcw & E1000_RXCW_CW) check was added and the >> >> e1000 SDM does not have any more information. >> >> >> >> Jack, can you take a look at the patch and commit if it looks alright? >> > >> > >> > I have this change applied internally. I thought that it was something >> > funny in my environment, so I never tried to push it upstream. Sorry >> > for >> > costing you time in having to debug this. :( >> >> Are you planning to commit this patch? >> >> I am happy to get you more information from my system if it helps you >> get to the bottom of this quicker. >> >> best >> Neel > > From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 00:48:34 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id EF7DF300 for ; Fri, 1 Feb 2013 00:48:34 +0000 (UTC) (envelope-from ksramanujan@gmail.com) Received: from mail-ia0-x22d.google.com (ia-in-x022d.1e100.net [IPv6:2607:f8b0:4001:c02::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 9A193E9E for ; Fri, 1 Feb 2013 00:48:34 +0000 (UTC) Received: by mail-ia0-f173.google.com with SMTP id h37so326310iak.32 for ; Thu, 31 Jan 2013 16:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Nks55rUYdCOKBp7LLxv/hOB4ltYNSBUINtZZv5bkzNg=; b=mXaDa88f6XAThowof1GGUZu7Y53ty5nawoNJqxmORm6ipsHF0W4yMeJGmizdrlxnwK RKfqfe3Y5DjjIrDii7ZNHI1sm3WjK7xXRLhhM0QH/+5XsZhebAqXSAdCSLUMZBR1rjes p+1d4kSPjX0N9LiA+/f/TcXLvZfANc2qZM6hMBVJqFfGwV3n2aRk2yOPcr6UpUqG9b2A 9fvQxjIwww2N3gaYzZRLzS6+YN2SHyymfVfAldA1ZTGJxkozhdlIoymm0P3jVgkf2enx acJvyvzI38QNt06IMa+FS3kW/V6bo1G0IEc7IV1Rc9HyXQWc+cPoUpr0CB38ASe5z60l ZqeQ== MIME-Version: 1.0 X-Received: by 10.50.42.200 with SMTP id q8mr2684015igl.102.1359679714138; Thu, 31 Jan 2013 16:48:34 -0800 (PST) Received: by 10.64.53.100 with HTTP; Thu, 31 Jan 2013 16:48:33 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 19:48:33 -0500 Message-ID: Subject: Re: Block ACK in Ralink RT2860 From: Ramanujan Seshadri To: PseudoCylon Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 00:48:35 -0000 I am testing the driver code witht he ralink nic. Yes the frame aggregation works, since i get higher throughput. I am actually tryign to know how many frames (MPDU's) are aggregated each time in an AMPDU. Regarding the MPDU density - i was wondering how it should affect the Frame aggregation. Since MPDU density is the time duration between each MPDU sent within the AMPDU. So, how does this matter to the hardware for aggregating the number of frames. It just sends MPDU's with the set interval. The other two limits make sense, the BAWinSize and the MAX_LEN_CFG. Ram On Wed, Jan 30, 2013 at 5:45 PM, PseudoCylon wrote: > On Wed, Jan 30, 2013 at 1:20 PM, Ramanujan Seshadri > wrote: > > Thank you. I also wanted to know the function where the Block ACK Window > > will be decided. is it decided during the ADDBA session establishment or > > does it change dynamically. > > The hardware will aggregate packets until any of following limits hit max > http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L782 > * rt2860_txwi.flags > RT2860_TX_MPDU_DSITY_SHIFT > 000 == no restriction > 001 == 1/4 us > 010 == 1/2 us > ... > 111 == 16 us > * rt2860_txwi.xflags > RT2860_TX_BAWINSIZE_SHIFT (frame count) > > http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L93 > * RT2860_MAX_LEN_CFG bit 12:13 > 00 == 8k bytes > 01 == 16k > 10 == 32k > 11 == 64k > > At a quick look, none of them is set in current code. Also, > RT2860_TX_AMPDU flag need to be set to make the h/w aggregate packets. > > How is ampdu working on ral(4)? I cannot test because I do not have > any ral(4) nic (only have run(4) nics). > > > AK > > > > > > > On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon > > wrote: > >> > >> > Message: 6 > >> > Date: Thu, 24 Jan 2013 12:23:55 -0500 > >> > From: Ramanujan Seshadri > >> > To: freebsd-net@freebsd.org > >> > Subject: Block ACK in Ralink RT2860 > >> > Message-ID: > >> > > >> > > >> > Content-Type: text/plain; charset=ISO-8859-1 > >> > > >> > Hi all, > >> > I am trying to read the contents of block ack's in a Ralink RT2860 > >> > driver. > >> > Can you please help me to know which function i should be looking > into ? > >> > >> At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag > >> at > >> http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559 > >> > >> Then, the diver should receive BA packets, and you can read them. > >> > >> > >> AK > > > > > From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 01:01:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AB7AA48D; Fri, 1 Feb 2013 01:01:46 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by mx1.freebsd.org (Postfix) with ESMTP id 0E4F5F24; Fri, 1 Feb 2013 01:01:45 +0000 (UTC) Received: by mail-wi0-f174.google.com with SMTP id hj13so65115wib.1 for ; Thu, 31 Jan 2013 17:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=frp79jqIAZdm39ZDtxvghQ3kV9rVzXC4SaBjoF6JIUg=; b=GsiTsSba+aZwFRLqd3GUte2JPPMdDTe+PThG0dwaE26Hu77w1iax+V1Tuit97CoiV0 TTew5PHmnRmkVoI2jRB+dTpo1RFBqgE19YTimsQXKLoz7qBACDjDlETP4kpEm/AYxJWK hFUY8pVzSx61t+5XQCpRyz4jyG/Kwm1nQBApmo9+BDT15+uFlS2YnNgdCQRJp0Pew8nE pKK95Hk4qTjHQvmnKfuzomtOGzN6PfDIfmCkdQaNTX5fOgtYhFyLVCk9BHv+PRv4Nqyf qyBVYGtHxs28rGYLnaANjFh/CHlbGu47/6EHVwsPfhfjripSyBmNJ7/BvaMV1fgyQCMm R95g== MIME-Version: 1.0 X-Received: by 10.180.8.130 with SMTP id r2mr18077546wia.28.1359680505214; Thu, 31 Jan 2013 17:01:45 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.67.6 with HTTP; Thu, 31 Jan 2013 17:01:45 -0800 (PST) In-Reply-To: References: Date: Thu, 31 Jan 2013 17:01:45 -0800 X-Google-Sender-Auth: 9QlApiN2WjfqbRKXfVSpAJFV99s Message-ID: Subject: Re: Block ACK in Ralink RT2860 From: Adrian Chadd To: Ramanujan Seshadri Content-Type: text/plain; charset=ISO-8859-1 Cc: FreeBSD Net , PseudoCylon , freebsd-wireless@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 01:01:46 -0000 Hi, So the 30 second version: * the maximum aggregation size in 802.11n is 65536 bytes, including the between-frame delimiters; * mpdu density defines how big those delimiters are - they're calculated either in bytes or as a function of the currently selected rate and duration, which ends up being a set of bytes anyway; * some hardware may require extra delimiter time between frames to "reset" internal frame processing between MPDUs. The atheros hardware, for examples, sets the default mpdu density to 8 microseconds to allow the encryption hardware to reset fully. It's only needed at the higher rates, but I've not sat down and totally mapped out what behaviour is there so I do it for all rates; * .. and later atheros hardware has a minimum per-MPDU timing and delimiters are added to that to "pad" out a frame to a minimum duration in microseconds. Again, to meet timing requirements in the chip; * bawinsize is negotiated during ADDBA negotiation. The maximum window size is 64 frames but devices may negotiate smaller window sizes if they like; * some hardware / drivers may limit the size of aggregates anyway - eg, the ath(4) aggregation code limits the per-AMPDU size to 32 frames even if the window is 64 frames. This is done to limit the effects of poor reception. Again, I could do a smarter job of it in ideal(er) situations but I've been focusing on other things. HTH, adrian On 31 January 2013 16:48, Ramanujan Seshadri wrote: > I am testing the driver code witht he ralink nic. Yes the frame > aggregation works, since i get higher throughput. I am actually tryign to > know how many frames (MPDU's) are aggregated each time in an AMPDU. > > Regarding the MPDU density - i was wondering how it should affect the Frame > aggregation. Since MPDU density is the time duration between each MPDU sent > within the AMPDU. So, how does this matter to the hardware for aggregating > the number of frames. It just sends MPDU's with the set interval. > > The other two limits make sense, the BAWinSize and the MAX_LEN_CFG. > > Ram > > On Wed, Jan 30, 2013 at 5:45 PM, PseudoCylon wrote: > >> On Wed, Jan 30, 2013 at 1:20 PM, Ramanujan Seshadri >> wrote: >> > Thank you. I also wanted to know the function where the Block ACK Window >> > will be decided. is it decided during the ADDBA session establishment or >> > does it change dynamically. >> >> The hardware will aggregate packets until any of following limits hit max >> http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L782 >> * rt2860_txwi.flags >> RT2860_TX_MPDU_DSITY_SHIFT >> 000 == no restriction >> 001 == 1/4 us >> 010 == 1/2 us >> ... >> 111 == 16 us >> * rt2860_txwi.xflags >> RT2860_TX_BAWINSIZE_SHIFT (frame count) >> >> http://fxr.watson.org/fxr/source/dev/ral/rt2860reg.h#L93 >> * RT2860_MAX_LEN_CFG bit 12:13 >> 00 == 8k bytes >> 01 == 16k >> 10 == 32k >> 11 == 64k >> >> At a quick look, none of them is set in current code. Also, >> RT2860_TX_AMPDU flag need to be set to make the h/w aggregate packets. >> >> How is ampdu working on ral(4)? I cannot test because I do not have >> any ral(4) nic (only have run(4) nics). >> >> >> AK >> >> > >> > >> > On Thu, Jan 24, 2013 at 5:13 PM, PseudoCylon >> > wrote: >> >> >> >> > Message: 6 >> >> > Date: Thu, 24 Jan 2013 12:23:55 -0500 >> >> > From: Ramanujan Seshadri >> >> > To: freebsd-net@freebsd.org >> >> > Subject: Block ACK in Ralink RT2860 >> >> > Message-ID: >> >> > >> >> > >> >> > Content-Type: text/plain; charset=ISO-8859-1 >> >> > >> >> > Hi all, >> >> > I am trying to read the contents of block ack's in a Ralink RT2860 >> >> > driver. >> >> > Can you please help me to know which function i should be looking >> into ? >> >> >> >> At default, all BA packets are dropped by h/w. Clear RT2860_DROP_BA flag >> >> at >> >> http://fxr.watson.org/fxr/source/dev/ral/rt2860.c#L3559 >> >> >> >> Then, the diver should receive BA packets, and you can read them. >> >> >> >> >> >> AK >> > >> > >> > _______________________________________________ > 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 Fri Feb 1 06:09:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 2B49819B for ; Fri, 1 Feb 2013 06:09:05 +0000 (UTC) (envelope-from vijju.singh@gmail.com) Received: from mail-ee0-f47.google.com (mail-ee0-f47.google.com [74.125.83.47]) by mx1.freebsd.org (Postfix) with ESMTP id A08CCCD0 for ; Fri, 1 Feb 2013 06:09:04 +0000 (UTC) Received: by mail-ee0-f47.google.com with SMTP id e52so1845005eek.20 for ; Thu, 31 Jan 2013 22:09:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=/AvTqCffX6UPidxtiA6Zb+bYoy4kjn++EZI5gAp96/0=; b=nFMWtOsWfP6XGpC1/0hznHO+SGFSUflteoFALxjVbpMCFK2o5/Rr8NrNjtwSMbkthz ig4g6qnTh4nVgx5jMcMmL4XDetvj6Vg2pXdnEFOJHNctwAdKIUOq72JZmOFiNHhDmTZJ vEeI21zuhmh3NBmD66aFzWWgGowN4uL8OFxX6PLb9MliX+Xqhm8OlYiH9cHCHVk+jG2c lXghoUwjd1Rer3qLd5vNrr4jph6B9DUnfXfK/xu/786zCkgnadYxwnqVte7+zxapLag+ dXtn/AW559CrAWx3F5z0NLVHj0Asz+cAdpGPm6FCB6v4gA17HpCVBIupE2CLy5kpmxQg 7BDw== MIME-Version: 1.0 X-Received: by 10.14.173.196 with SMTP id v44mr35532220eel.29.1359698943596; Thu, 31 Jan 2013 22:09:03 -0800 (PST) Received: by 10.223.161.80 with HTTP; Thu, 31 Jan 2013 22:09:03 -0800 (PST) Date: Thu, 31 Jan 2013 22:09:03 -0800 Message-ID: Subject: Why call ETHER_BPF_MTAP on Tx when not tracing From: Vijay Singh To: "freebsd-net@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 06:09:05 -0000 I see that BPFIF_LOCK() in bpf_mtap() is getting invoked, even though I am not tracing the interface. Is this expected? -vijay PS: I am running 8.2. From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 09:59:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3F37C45C for ; Fri, 1 Feb 2013 09:59:02 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by mx1.freebsd.org (Postfix) with ESMTP id 2179186E for ; Fri, 1 Feb 2013 09:59:01 +0000 (UTC) Received: by mail-pb0-f46.google.com with SMTP id mc17so2086941pbc.19 for ; Fri, 01 Feb 2013 01:59:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=JYd6S3ZhBL/FstB44v7BJufZED3QRh6fqVowS/Nldc8=; b=aeTs0M4Hdapy5SrNa+Z1BoSBxUZxqY9p7ROrHMK5FlYUTAVdM38IAT2asFhGQHk8e8 Ouk2HlBbMO5bZsctmxD1+DO7MrPWsni7PngcF91yE0hiXp2fM9u/NxBzCDYUJDMG1Cd9 T+eqt1lULnNDA7XlNbYmUbwvizuRvCJIkFcgWYglOsTBPvsMdvmVRiDtMwYf6aXRJRb2 370kr2rv3xz/b5GlDofAWPUZZ1gCjYD+7434oJCiUQwj8o2cD+eULvn/CTTmQ/K3N7VQ BxB3CZfdBhCYZbV3iJWnB07SNfI+Jm4Xw+kuB6Q8xjHCPmMDe7qLtZl38xb5yP+xf/ig /9SQ== MIME-Version: 1.0 X-Received: by 10.68.237.129 with SMTP id vc1mr15770118pbc.123.1359712741512; Fri, 01 Feb 2013 01:59:01 -0800 (PST) Received: by 10.68.34.198 with HTTP; Fri, 1 Feb 2013 01:59:01 -0800 (PST) Date: Fri, 1 Feb 2013 11:59:01 +0200 Message-ID: Subject: Tunneling IPv4 over IPv6 VPN From: George Kontostanos To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 09:59:02 -0000 Hi everyone! I am trying to tunnel IPv4 traffic over an IPv6 VPN. So far it is unsuccessful. Both machines are running FreeBSD 9.1-RELEASE. They are acting as gateways and they both have assigned /64 IPv6 subnets. The purpose is to encapsulate the non routable IPv4 traffic behind those gateways into the IPv6 VPN. For the sake of simplicity I will present the configuration of the first machine. The second has exactly the reverse. (Kernels are compiled with IPsec) #ifconfig gif0 create #ifconfig gif0 ipv6 tunnel xxxx:fc50:1001:5f00::86 xxxx:580:8f00:2c00::2093 #ifconfig gif0 alias 10.10.10.4 10.1.1.3 The tunnel comes up, machine a can ping machine b and vice versa. > ping 10.1.1.3 PING 10.1.1.3 (10.1.1.3): 56 data bytes 64 bytes from 10.1.1.3: icmp_seq=0 ttl=64 time=187.772 ms 64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=184.516 ms 64 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=185.563 ms ipsec-tools comes in to create the actual IPsec connection. setkey.conf: flush; spdflush; spdadd 10.1.1.0/24 10.10.10.0/24 any -P out ipsec esp/tunnel/xxxx:fc50:1001:5f00::86-xxxx:580:8f00:2c00::2093/use; spdadd 10.10.10.0/24 10.1.1.0/24 any -P in ipsec esp/tunnel/xxxx:580:8f00:2c00::2093-xxxx:fc50:1001:5f00::86/use; racoon.conf: path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; log debug; padding # options are not to be changed { maximum_length 20; # maximum padding length randomize off; # enable randomize length strict_check off; # enable strict check exclusive_tail off; # extract last one octet } listen # address [port] that racoon will listening on { isakmp xxxx:580:8f00:2c00::2093 [500]; } timer # timing options. change as needed { counter 5; # maximum trying count to send interval 20 sec; # maximum interval to resend persend 1; # the number of packets per a send phase1 60 sec; phase2 25 sec; } remote xxxx:fc50:1001:5f00::86 [500] { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; lifetime time 8 hour; initial_contact on; passive off; proposal_check obey; generate_policy off; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo anonymous { pfs_group 5; lifetime time 12 hour ; encryption_algorithm blowfish,3des,des; # authentication_algorithm hmac_md5,hmac_sha1; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } Once the IPsec is established: 2013-01-31 18:02:20: DEBUG: KEYMAT computed. 2013-01-31 18:02:20: DEBUG: call pk_sendupdate 2013-01-31 18:02:20: DEBUG: encryption(blowfish) 2013-01-31 18:02:20: DEBUG: hmac(sha1) 2013-01-31 18:02:20: DEBUG: call pfkey_send_update2 2013-01-31 18:02:20: DEBUG: pfkey update sent. 2013-01-31 18:02:20: DEBUG: encryption(blowfish) 2013-01-31 18:02:20: DEBUG: hmac(sha1) 2013-01-31 18:02:20: DEBUG: call pfkey_send_add2 (NAT flavor) 2013-01-31 18:02:20: DEBUG: call pfkey_send_add2 2013-01-31 18:02:20: DEBUG: pfkey add sent. 2013-01-31 18:02:20: DEBUG: pk_recv: retry[0] recv() 2013-01-31 18:02:20: DEBUG: got pfkey UPDATE message 2013-01-31 18:02:20: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=15238148(0xe88404) 2013-01-31 18:02:20: INFO: IPsec-SA established: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=15238148(0xe88404) 2013-01-31 18:02:20: DEBUG: === 2013-01-31 18:02:20: DEBUG: pk_recv: retry[0] recv() 2013-01-31 18:02:20: DEBUG: got pfkey ADD message 2013-01-31 18:02:20: INFO: IPsec-SA established: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=109946295(0x68da5b7) 2013-01-31 18:02:20: DEBUG: === I can only ping the IPv6 endpoints. The IPv4 simply time outs. I run a tcpdump but didn't see anything that it could assist me. I suspect that my problem is in the spd policies. I also run into an older PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=169438&cat=) which looks similar. The ipsec_output.c though seems different in that part. Any help will be appreciated! Thanks -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 10:03:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BACDA759 for ; Fri, 1 Feb 2013 10:03:55 +0000 (UTC) (envelope-from gkontos.mail@gmail.com) Received: from mail-pa0-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by mx1.freebsd.org (Postfix) with ESMTP id 9CE0C8B9 for ; Fri, 1 Feb 2013 10:03:55 +0000 (UTC) Received: by mail-pa0-f54.google.com with SMTP id fa10so568704pad.41 for ; Fri, 01 Feb 2013 02:03:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=JYd6S3ZhBL/FstB44v7BJufZED3QRh6fqVowS/Nldc8=; b=oICyjrbn7YlQku64Qo94Jt+8LrHPiyCVYVjhNdUdxv71f2TGzFYwZJaP4dDS7ne66/ rjv9ywq7znNHIanrlPaTe44TgyyHZWnZq2VQHQgq5RGiaadbbsQvu/yn71ZZlgHj3ibp ojyxCRn8fWvvMbIiF/cbWDD1aTgrsYF5N5NCmgKTtWt75z0yOk3yZvU/XNkcWiSFjj0V wgY0wvVV/9hbMtBIx2n2KeZCYpW4DasQx6jkPuTXGzQTao5dVNiJt2e3rfT01kPV0foe veSWnAXnCRKdMgGTQZYU+hQgTerQVgMD60LhWtebqM6DW5RD23TqDm2W15KQWNanfvmY kcJQ== MIME-Version: 1.0 X-Received: by 10.68.238.165 with SMTP id vl5mr24591454pbc.0.1359712600281; Fri, 01 Feb 2013 01:56:40 -0800 (PST) Received: by 10.68.34.198 with HTTP; Fri, 1 Feb 2013 01:56:40 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 11:56:40 +0200 Message-ID: Subject: Re: Welcome to the "freebsd-net" mailing list From: George Kontostanos To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 10:03:55 -0000 Hi everyone! I am trying to tunnel IPv4 traffic over an IPv6 VPN. So far it is unsuccessful. Both machines are running FreeBSD 9.1-RELEASE. They are acting as gateways and they both have assigned /64 IPv6 subnets. The purpose is to encapsulate the non routable IPv4 traffic behind those gateways into the IPv6 VPN. For the sake of simplicity I will present the configuration of the first machine. The second has exactly the reverse. (Kernels are compiled with IPsec) #ifconfig gif0 create #ifconfig gif0 ipv6 tunnel xxxx:fc50:1001:5f00::86 xxxx:580:8f00:2c00::2093 #ifconfig gif0 alias 10.10.10.4 10.1.1.3 The tunnel comes up, machine a can ping machine b and vice versa. > ping 10.1.1.3 PING 10.1.1.3 (10.1.1.3): 56 data bytes 64 bytes from 10.1.1.3: icmp_seq=0 ttl=64 time=187.772 ms 64 bytes from 10.1.1.3: icmp_seq=1 ttl=64 time=184.516 ms 64 bytes from 10.1.1.3: icmp_seq=2 ttl=64 time=185.563 ms ipsec-tools comes in to create the actual IPsec connection. setkey.conf: flush; spdflush; spdadd 10.1.1.0/24 10.10.10.0/24 any -P out ipsec esp/tunnel/xxxx:fc50:1001:5f00::86-xxxx:580:8f00:2c00::2093/use; spdadd 10.10.10.0/24 10.1.1.0/24 any -P in ipsec esp/tunnel/xxxx:580:8f00:2c00::2093-xxxx:fc50:1001:5f00::86/use; racoon.conf: path include "/usr/local/etc/racoon" ; path pre_shared_key "/usr/local/etc/racoon/psk.txt" ; log debug; padding # options are not to be changed { maximum_length 20; # maximum padding length randomize off; # enable randomize length strict_check off; # enable strict check exclusive_tail off; # extract last one octet } listen # address [port] that racoon will listening on { isakmp xxxx:580:8f00:2c00::2093 [500]; } timer # timing options. change as needed { counter 5; # maximum trying count to send interval 20 sec; # maximum interval to resend persend 1; # the number of packets per a send phase1 60 sec; phase2 25 sec; } remote xxxx:fc50:1001:5f00::86 [500] { exchange_mode aggressive,main; doi ipsec_doi; situation identity_only; lifetime time 8 hour; initial_contact on; passive off; proposal_check obey; generate_policy off; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo anonymous { pfs_group 5; lifetime time 12 hour ; encryption_algorithm blowfish,3des,des; # authentication_algorithm hmac_md5,hmac_sha1; authentication_algorithm hmac_sha1; compression_algorithm deflate ; } Once the IPsec is established: 2013-01-31 18:02:20: DEBUG: KEYMAT computed. 2013-01-31 18:02:20: DEBUG: call pk_sendupdate 2013-01-31 18:02:20: DEBUG: encryption(blowfish) 2013-01-31 18:02:20: DEBUG: hmac(sha1) 2013-01-31 18:02:20: DEBUG: call pfkey_send_update2 2013-01-31 18:02:20: DEBUG: pfkey update sent. 2013-01-31 18:02:20: DEBUG: encryption(blowfish) 2013-01-31 18:02:20: DEBUG: hmac(sha1) 2013-01-31 18:02:20: DEBUG: call pfkey_send_add2 (NAT flavor) 2013-01-31 18:02:20: DEBUG: call pfkey_send_add2 2013-01-31 18:02:20: DEBUG: pfkey add sent. 2013-01-31 18:02:20: DEBUG: pk_recv: retry[0] recv() 2013-01-31 18:02:20: DEBUG: got pfkey UPDATE message 2013-01-31 18:02:20: DEBUG: pfkey UPDATE succeeded: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=15238148(0xe88404) 2013-01-31 18:02:20: INFO: IPsec-SA established: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=15238148(0xe88404) 2013-01-31 18:02:20: DEBUG: === 2013-01-31 18:02:20: DEBUG: pk_recv: retry[0] recv() 2013-01-31 18:02:20: DEBUG: got pfkey ADD message 2013-01-31 18:02:20: INFO: IPsec-SA established: ESP/Tunnel xxxx:580:8f00:2c00::2093[500]-> xxxx:fc50:1001:5f00::86[500] spi=109946295(0x68da5b7) 2013-01-31 18:02:20: DEBUG: === I can only ping the IPv6 endpoints. The IPv4 simply time outs. I run a tcpdump but didn't see anything that it could assist me. I suspect that my problem is in the spd policies. I also run into an older PR (http://www.freebsd.org/cgi/query-pr.cgi?pr=169438&cat=) which looks similar. The ipsec_output.c though seems different in that part. Any help will be appreciated! Thanks -- George Kontostanos --- http://www.aisecure.net From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 12:04:23 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A43B2925 for ; Fri, 1 Feb 2013 12:04:23 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id 1F7B4FA8 for ; Fri, 1 Feb 2013 12:04:22 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r11C4ErD097458 for ; Fri, 1 Feb 2013 16:04:14 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r11C4EQ1097457 for net@FreeBSD.org; Fri, 1 Feb 2013 16:04:14 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 1 Feb 2013 16:04:14 +0400 From: Gleb Smirnoff To: net@FreeBSD.org Subject: m_get2() name Message-ID: <20130201120414.GG91075@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 12:04:23 -0000 Hi! The m_get2() function allocates a single mbuf with enough space to hold specified amount of data. It can return either a single mbuf, an mbuf with a standard cluster, page size cluster, or jumbo cluster. It is alredy utilized in pfsync, bpf, libalias and soon to be utilized in ieee802111. There are probably more places in stack where it can be used. The question is about its name. Once introduced, I just gave it name "m_get2" to avoid discussion with myself about bikeshed colour and continue hacking. Now it is getting used wider, and before we branch any stable branch off the head, we have last chance to rename it to smth more meaningful. Any ideas on better name are welcome. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 12:18:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 0442CC32 for ; Fri, 1 Feb 2013 12:18:10 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id A85DAE6 for ; Fri, 1 Feb 2013 12:18:09 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=dhcp170-36-red.yandex.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1U1Fch-000JHF-A6; Fri, 01 Feb 2013 16:21:39 +0400 Message-ID: <510BB26B.9040807@FreeBSD.org> Date: Fri, 01 Feb 2013 16:17:47 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Vijay Singh Subject: Re: Why call ETHER_BPF_MTAP on Tx when not tracing References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 12:18:10 -0000 On 01.02.2013 10:09, Vijay Singh wrote: > I see that BPFIF_LOCK() in bpf_mtap() is getting invoked, even > though I am not tracing the interface. Is this expected? This should not happen, since BPF_MTAP macro checks if BFP consumers are present (via bpf_peers_present()) before calling bpf_mtap. Btw, locking model is different in -current, you can take a look on BPF changes in head starting from r233937. > > -vijay > > PS: I am running 8.2. > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net To > unsubscribe, send any mail to > "freebsd-net-unsubscribe@freebsd.org" > -- WBR, Alexander From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 12:40:10 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1566E729; Fri, 1 Feb 2013 12:40:10 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 0738B240; Fri, 1 Feb 2013 12:40:09 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (ool-45775fce.dyn.optonline.net [69.119.95.206]) by elvis.mu.org (Postfix) with ESMTPSA id 5DC011A3DDA; Fri, 1 Feb 2013 04:39:59 -0800 (PST) Message-ID: <510BB79D.8040707@mu.org> Date: Fri, 01 Feb 2013 07:39:57 -0500 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: m_get2() name References: <20130201120414.GG91075@FreeBSD.org> In-Reply-To: <20130201120414.GG91075@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 12:40:10 -0000 On 2/1/13 7:04 AM, Gleb Smirnoff wrote: > Hi! > > The m_get2() function allocates a single mbuf with enough space > to hold specified amount of data. It can return either a single mbuf, > an mbuf with a standard cluster, page size cluster, or jumbo cluster. > > It is alredy utilized in pfsync, bpf, libalias and soon to be utilized > in ieee802111. There are probably more places in stack where it can be used. > > The question is about its name. Once introduced, I just gave it name > "m_get2" to avoid discussion with myself about bikeshed colour and continue > hacking. Now it is getting used wider, and before we branch any stable branch > off the head, we have last chance to rename it to smth more meaningful. > > Any ideas on better name are welcome. > m_getbs - mbuf get buffer size. conveniently also maps to: m_getbs - mbuf get bike shed. This is a cool function. Maybe it should take an int*error arg as well for ENOBUFS/EINVAL? -Alfred From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 13:04:52 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DA04E1BD for ; Fri, 1 Feb 2013 13:04:52 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id C1A4239C for ; Fri, 1 Feb 2013 13:04:51 +0000 (UTC) Received: (qmail 42639 invoked from network); 1 Feb 2013 14:24:23 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Feb 2013 14:24:23 -0000 Message-ID: <510BBD66.4080903@freebsd.org> Date: Fri, 01 Feb 2013 14:04:38 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: m_get2() name References: <20130201120414.GG91075@FreeBSD.org> In-Reply-To: <20130201120414.GG91075@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:04:52 -0000 On 01.02.2013 13:04, Gleb Smirnoff wrote: > Hi! > > The m_get2() function allocates a single mbuf with enough space > to hold specified amount of data. It can return either a single mbuf, > an mbuf with a standard cluster, page size cluster, or jumbo cluster. While m_get2() is a good function, I'm not too happy with it returning jumbo clusters. The size of jumbo cluster is not well specified and can be anything above 2K, from 4K to 16K or more. The network stack hacker can't rely on any particular size above PAGE_SIZE to be present. So I recommend to make PAGE_SIZE the largest cluster size to be available in a single mbuf allocator. PAGE_SIZE is a known quantity and plays well with the allocator. Anything larger than PAGE_SIZE causes contig_malloc to be used as the requirement is physically contiguous pages for those clusters. After some uptime this may become more difficult to allocate and can lead to premature allocation failures while still plenty of memory would be around. The allocation overhead for such jumbo zones is higher in UMA than for PAGE_SIZE clusters. There is also some overlap with m_getm2() which returns an mbuf chain of specified size. The only difference being chain vs. single mbuf. m_get2() can be simply implemented on top of m_getm2() by using the flags field to restrict it to one mbuf only instead of a chain to avoid code duplication. > It is alredy utilized in pfsync, bpf, libalias and soon to be utilized > in ieee802111. There are probably more places in stack where it can be used. > > The question is about its name. Once introduced, I just gave it name > "m_get2" to avoid discussion with myself about bikeshed colour and continue > hacking. Now it is getting used wider, and before we branch any stable branch > off the head, we have last chance to rename it to smth more meaningful. This is mostly matter of "compatibility" we want keep with original BSD code. The right names would be m_get() and m_getm() for single mbuf and chain allocations of a certain supplied minimum size. As far as I see it the other BSDs have evolved quite a bit and a significant number of differences exists these days making porting more involved than just copying the files. Having a clean API would be only a minor additional inconvenience IMHO. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 13:15:57 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 822EE539; Fri, 1 Feb 2013 13:15:57 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from cell.glebius.int.ru (glebius.int.ru [81.19.69.10]) by mx1.freebsd.org (Postfix) with ESMTP id EB75A696; Fri, 1 Feb 2013 13:15:56 +0000 (UTC) Received: from cell.glebius.int.ru (localhost [127.0.0.1]) by cell.glebius.int.ru (8.14.6/8.14.6) with ESMTP id r11DFtjc097754; Fri, 1 Feb 2013 17:15:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.glebius.int.ru (8.14.6/8.14.6/Submit) id r11DFtlI097753; Fri, 1 Feb 2013 17:15:55 +0400 (MSK) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.glebius.int.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Fri, 1 Feb 2013 17:15:55 +0400 From: Gleb Smirnoff To: Andre Oppermann Subject: Re: m_get2() name Message-ID: <20130201131555.GJ91075@glebius.int.ru> References: <20130201120414.GG91075@FreeBSD.org> <510BBD66.4080903@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <510BBD66.4080903@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:15:57 -0000 On Fri, Feb 01, 2013 at 02:04:38PM +0100, Andre Oppermann wrote: A> > The m_get2() function allocates a single mbuf with enough space A> > to hold specified amount of data. It can return either a single mbuf, A> > an mbuf with a standard cluster, page size cluster, or jumbo cluster. A> A> While m_get2() is a good function, I'm not too happy with it returning A> jumbo clusters. The size of jumbo cluster is not well specified and A> can be anything above 2K, from 4K to 16K or more. The network stack A> hacker can't rely on any particular size above PAGE_SIZE to be present. A> A> So I recommend to make PAGE_SIZE the largest cluster size to be available A> in a single mbuf allocator. PAGE_SIZE is a known quantity and plays well A> with the allocator. Anything larger than PAGE_SIZE causes contig_malloc A> to be used as the requirement is physically contiguous pages for those A> clusters. After some uptime this may become more difficult to allocate A> and can lead to premature allocation failures while still plenty of A> memory would be around. The allocation overhead for such jumbo zones A> is higher in UMA than for PAGE_SIZE clusters. I am against API that forbids allocating jumbo clusters. The kernel has them, albeit their disadvantages. And API should offer them to drivers and modules. If some module doesn't want to get a jumbo clustered mbuf from m_get2(), then it should not request above PAGE_SIZE from m_get2() and that's all. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 13:41:41 2013 Return-Path: Delivered-To: net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 122E1B07 for ; Fri, 1 Feb 2013 13:41:41 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id D84DD7B5 for ; Fri, 1 Feb 2013 13:41:39 +0000 (UTC) Received: (qmail 42795 invoked from network); 1 Feb 2013 15:01:17 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Feb 2013 15:01:17 -0000 Message-ID: <510BC60C.4020500@freebsd.org> Date: Fri, 01 Feb 2013 14:41:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Gleb Smirnoff Subject: Re: m_get2() name References: <20130201120414.GG91075@FreeBSD.org> <510BBD66.4080903@freebsd.org> <20130201131555.GJ91075@glebius.int.ru> In-Reply-To: <20130201131555.GJ91075@glebius.int.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 13:41:41 -0000 On 01.02.2013 14:15, Gleb Smirnoff wrote: > On Fri, Feb 01, 2013 at 02:04:38PM +0100, Andre Oppermann wrote: > A> > The m_get2() function allocates a single mbuf with enough space > A> > to hold specified amount of data. It can return either a single mbuf, > A> > an mbuf with a standard cluster, page size cluster, or jumbo cluster. > A> > A> While m_get2() is a good function, I'm not too happy with it returning > A> jumbo clusters. The size of jumbo cluster is not well specified and > A> can be anything above 2K, from 4K to 16K or more. The network stack > A> hacker can't rely on any particular size above PAGE_SIZE to be present. > A> > A> So I recommend to make PAGE_SIZE the largest cluster size to be available > A> in a single mbuf allocator. PAGE_SIZE is a known quantity and plays well > A> with the allocator. Anything larger than PAGE_SIZE causes contig_malloc > A> to be used as the requirement is physically contiguous pages for those > A> clusters. After some uptime this may become more difficult to allocate > A> and can lead to premature allocation failures while still plenty of > A> memory would be around. The allocation overhead for such jumbo zones > A> is higher in UMA than for PAGE_SIZE clusters. > > I am against API that forbids allocating jumbo clusters. The kernel has them, > albeit their disadvantages. And API should offer them to drivers and modules. > If some module doesn't want to get a jumbo clustered mbuf from m_get2(), then > it should not request above PAGE_SIZE from m_get2() and that's all. I'm not saying that it should be forbidden to allocate jumbo clusters. It's just that they are no guaranteed to be available at all or in particular sizes except for PAGE_SIZE. The risk is that a developer uses the convenient API m_get2() for a 7K buffer and expects it work everywhere which is not the case. Something that can't be relied on should be automatic but explicit with the surrounding run or compile time tests. I'd also like to note that we have mbuf chains for the reason that large contiguous allocations are difficult and not as performant as PAGE_SIZEd and smaller ones. If your code needs a > PAGE_SIZE jumbo cluster you have done something wrong (to paraphrase PHK). The only reason we actually got > PAGE_SIZE jumbo clusters is old NIC which couldn't do inbound S/G DMA. These are long gone and every jumbo frame capable NIC can do S/G DMA into, for example, PAGE_SIZE mbuf clusters. For casual readers a jumbo cluster > PAGE_SIZE is contiguous not only in virtual kernel address space but also physically in actual RAM. While both may cause some allocation difficulties, its mostly physical part in pmap which eventually suffers from fragmentation. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 14:54:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 962E5237 for ; Fri, 1 Feb 2013 14:54:02 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x233.google.com (ie-in-x0233.1e100.net [IPv6:2607:f8b0:4001:c03::233]) by mx1.freebsd.org (Postfix) with ESMTP id 49306AE9 for ; Fri, 1 Feb 2013 14:54:02 +0000 (UTC) Received: by mail-ie0-f179.google.com with SMTP id k11so2255736iea.24 for ; Fri, 01 Feb 2013 06:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=LnImIsazjExnylActvwOI02Fn25myPRxP/YTvguWzrE=; b=yuAi1acrsdVdlPqHYNCVxy6JK8g3P3VuJzBCLAjK2LOKuZjPsoslg9mDU+zVnrcTTC VNoUnLh0VXpCJKnZSxP2nVeKz52ZFXiZy/jdorF5UwgHFRIzt90Qw9wIkR4yEIju7/eT 6nj2ztkNAirarlG6ZRiT4XWw8eRjfKdk0tcpge0mPiAb6V19cMg3HiofiuoX6RnqR5oG L8KxAwJmUjZfwL7TXGpxulYvmJ5vzMkzXDzsuok/4pfn8CsFXRtWxmodrMNvqJRSclRN OlcRKxUvNrbn714J94kEw1ZsBvVa3IwbplAqoDbpSi/ImvpJzYioL+g+mJijhWrL8qtj RNtQ== X-Received: by 10.50.222.195 with SMTP id qo3mr1413182igc.14.1359730441923; Fri, 01 Feb 2013 06:54:01 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id b13sm2745331igp.7.2013.02.01.06.53.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 06:54:00 -0800 (PST) Message-ID: <510BD6FF.9090101@gmail.com> Date: Fri, 01 Feb 2013 09:53:51 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Subject: amd64 vs i386 in_cksum_hdr() with unaligned data Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 14:54:02 -0000 Hi -net, Sorry for the lengthy email. TLDR: If the IP header is not aligned on an even address then the amd64 version of in_cksum_hdr() will not work while the i386 version of it will. I came across this problem while working on custom software using the FreeBSD bridge. Our code sometimes decapsulate packets with the resulting header starting on an odd address and we need to send it through the FreeBSD bridge where we hit in_cksum_hdr() in bridge_pfil(). While this always worked on i386 we started seeing 'reversed' checksums on amd64: 21:47:29.178620 IP (tos 0x0, ttl 63, id 3819, offset 0, flags [none], proto ICMP (1), length 84) 192.168.76.100 > 192.168.73.200: ICMP echo request, id 44019, seq 2, length 64 21:47:29.179972 IP (tos 0x0, ttl 62, id 1701, offset 0, flags [none], proto ICMP (1), length 84, bad cksum 875e (->5e87)!) 192.168.73.200 > 192.168.76.100: ICMP echo reply, id 44019, seq 2, length 64 Please note the reversed checksum on the ICMP reply (as if someone had called htons on ip_sum ...). Needless to say this caused a lot of head scratching over here. Now it looks like the i386 version of in_cksum_hdr() is totally different then the amd64 one. A current workaround for us is to use in_cksum() in if_bridge.c by applying this patch: diff --git a/freebsd/sys/net/if_bridge.c b/freebsd/sys/net/if_bridge.c index 24a4522..fbd9aec 100644 --- a/freebsd/sys/net/if_bridge.c +++ b/freebsd/sys/net/if_bridge.c @@ -3894,9 +3894,11 @@ ipfwpass: #endif /* Recalculate the ip checksum */ ip->ip_sum = 0; +#if 0 /* Dirty Hack */ if (hlen == sizeof(struct ip)) ip->ip_sum = in_cksum_hdr(ip); else +#endif ip->ip_sum = in_cksum(*mp, hlen); break; et voila! Problem fixed. or not ... At least this gets us going but I think the scope of this problem is much bigger then the bridge code alone. The FreeBSD source uses in_cksum_hdr() in many other places then if_bridge.c and while the i386 version of it is capable of dealing with unaligned addresses the amd64 one is not (we haven't checked other architectures). My question(s) to the list is what is the proper way to fix this? Should we replace all occurrence of in_cksum_hdr() with in_cksum()? Should we write another inline assembly of the in_cksum_hdr function for 64bit? Should in_cksum_hdr() in amd64 changed to deal with misaligned addresses? Other solutions? Thanks, Karim. From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 15:22:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 90C33BA4 for ; Fri, 1 Feb 2013 15:22:19 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-ie0-x22c.google.com (mail-ie0-x22c.google.com [IPv6:2607:f8b0:4001:c03::22c]) by mx1.freebsd.org (Postfix) with ESMTP id 668DAD24 for ; Fri, 1 Feb 2013 15:22:19 +0000 (UTC) Received: by mail-ie0-f172.google.com with SMTP id c10so3494199ieb.17 for ; Fri, 01 Feb 2013 07:22:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DvNCPcEDoyLATeFYGrcP3lxRfBASyjcma6a0sSSgC0o=; b=WMftFc2k56BR6H4n45tKAaLW1U9nAkI92dAHBB+5Bw5CeyBSGWpK4e9KvtGYxZ+vSj sj2uUJhtrprgi8oDoVOdWJ+GMwl8vso79LTRy0MEMhdcMgcxCY1jl0NfLQl2Jb2WN3Qr 3HRIlwmOFFzBburDJjAQhZhxTy5NQWyiS5LqyIVyPq+MXk4/Zx5xe383nKMiQgqPqgIv ladJ8xGHJrYixUtke4LOa4ECSbvP19F0n64gH92ZEISoRZstK4QYhGr8f0dgYbmK9pYm uwijVSpaLUX4ehl0274MNiUfsE5SaFEVOMEmEqZgnD/DTDWBnuMaUUjt26jBiFQWfDuq 4A/A== X-Received: by 10.42.30.132 with SMTP id v4mr9701549icc.34.1359732138480; Fri, 01 Feb 2013 07:22:18 -0800 (PST) Received: from [192.168.1.73] ([208.85.112.101]) by mx.google.com with ESMTPS id as6sm2565509igc.8.2013.02.01.07.22.16 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 01 Feb 2013 07:22:17 -0800 (PST) Message-ID: <510BDDA2.6010503@gmail.com> Date: Fri, 01 Feb 2013 10:22:10 -0500 From: Karim Fodil-Lemelin User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: amd64 vs i386 in_cksum_hdr() with unaligned data References: <510BD6FF.9090101@gmail.com> In-Reply-To: <510BD6FF.9090101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 15:22:19 -0000 On 01/02/2013 9:53 AM, Karim Fodil-Lemelin wrote: > Hi -net, > > Sorry for the lengthy email. > > TLDR: If the IP header is not aligned on an even address then the > amd64 version of in_cksum_hdr() will not work while the i386 version > of it will. > > I came across this problem while working on custom software using the > FreeBSD bridge. Our code sometimes decapsulate packets with the > resulting header starting on an odd address and we need to send it > through the FreeBSD bridge where we hit in_cksum_hdr() in > bridge_pfil(). While this always worked on i386 we started seeing > 'reversed' checksums on amd64: > > 21:47:29.178620 IP (tos 0x0, ttl 63, id 3819, offset 0, flags [none], > proto ICMP (1), length 84) > 192.168.76.100 > 192.168.73.200: ICMP echo request, id 44019, seq > 2, length 64 > 21:47:29.179972 IP (tos 0x0, ttl 62, id 1701, offset 0, flags [none], > proto ICMP (1), length 84, bad cksum 875e (->5e87)!) > 192.168.73.200 > 192.168.76.100: ICMP echo reply, id 44019, seq 2, > length 64 > > Please note the reversed checksum on the ICMP reply (as if someone had > called htons on ip_sum ...). Needless to say this caused a lot of head > scratching over here. > > Now it looks like the i386 version of in_cksum_hdr() is totally > different then the amd64 one. A current workaround for us is to use > in_cksum() in if_bridge.c by applying this patch: > > diff --git a/freebsd/sys/net/if_bridge.c b/freebsd/sys/net/if_bridge.c > index 24a4522..fbd9aec 100644 > --- a/freebsd/sys/net/if_bridge.c > +++ b/freebsd/sys/net/if_bridge.c > @@ -3894,9 +3894,11 @@ ipfwpass: > #endif > /* Recalculate the ip checksum */ > ip->ip_sum = 0; > +#if 0 /* Dirty Hack */ > if (hlen == sizeof(struct ip)) > ip->ip_sum = in_cksum_hdr(ip); > else > +#endif > ip->ip_sum = in_cksum(*mp, hlen); > > break; > > et voila! Problem fixed. or not ... At least this gets us going but I > think the scope of this problem is much bigger then the bridge code > alone. > > The FreeBSD source uses in_cksum_hdr() in many other places then > if_bridge.c and while the i386 version of it is capable of dealing > with unaligned addresses the amd64 one is not (we haven't checked > other architectures). My question(s) to the list is what is the proper > way to fix this? Should we replace all occurrence of in_cksum_hdr() > with in_cksum()? Should we write another inline assembly of the > in_cksum_hdr function for 64bit? Should in_cksum_hdr() in amd64 > changed to deal with misaligned addresses? Other solutions? > > Thanks, > > Karim. > _______________________________________________ > 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" Quick follow up on this, the following patch fixed the issue for us: diff --git a/freebsd/sys/amd64/amd64/in_cksum.c b/freebsd/sys/amd64/amd64/in_cksum.c index ae02e91..71749e1 100644 --- a/freebsd/sys/amd64/amd64/in_cksum.c +++ b/freebsd/sys/amd64/amd64/in_cksum.c @@ -233,9 +233,13 @@ skip_start: u_int in_cksum_hdr(const struct ip *ip) { - u_int64_t sum = in_cksumdata(ip, sizeof(struct ip)); - union q_util q_util; - union l_util l_util; - REDUCE16; - return (~sum & 0xffff); + u_int64_t sum; + union q_util q_util; + union l_util l_util; + if ((uintptr_t)ip & 1) + sum = in_cksumdata(ip, sizeof(struct ip)) << 8; + else + sum = in_cksumdata(ip, sizeof(struct ip)); + REDUCE16; + return (~sum & 0xffff); } From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 17:30:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0C5DB431 for ; Fri, 1 Feb 2013 17:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id DA2842FC for ; Fri, 1 Feb 2013 17:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r11HU1YU049584 for ; Fri, 1 Feb 2013 17:30:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r11HU1hk049583; Fri, 1 Feb 2013 17:30:01 GMT (envelope-from gnats) Date: Fri, 1 Feb 2013 17:30:01 GMT Message-Id: <201302011730.r11HU1hk049583@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Marius Strobl Subject: Re: kern/175734: no ethernet detected on system with EG20T PCH chipset ATOM E6xx series X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Marius Strobl List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 17:30:02 -0000 The following reply was made to PR kern/175734; it has been noted by GNATS. From: Marius Strobl To: bug-followup@FreeBSD.org, m.spano@meta-srl.com Cc: Subject: Re: kern/175734: no ethernet detected on system with EG20T PCH chipset ATOM E6xx series Date: Fri, 1 Feb 2013 18:21:34 +0100 FreeBSD simply has no driver supporting this MAC, yet, i.e. a counterpart to the Linux pch_gbe. From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 21:21:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2441F185 for ; Fri, 1 Feb 2013 21:21:20 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id CE24BF61 for ; Fri, 1 Feb 2013 21:21:19 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id 5EA7BF06C5F for ; Fri, 1 Feb 2013 21:21:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; s=selector1; bh=Ts+2cF4JmCqYxq57vmIonBWLEGA=; b= jr2LCfv2uXibcUn29atMsVwUjDJIlIQrzPjL6WcjZ6+MpxNjAdIisGJGAWaH+XZy H81L2/DOByaR0aKO3yvU0PC5OChFzZS1EthNO363zvTHE+cS74N6MPJebOzG85Pj Jrc3vQk2ARhuBFgPM8zodFjz2kBeY7LRQ8TvidhuCiQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=from :content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; q=dns; s=selector1; b=AzxF9kVAy2hnP/bNwUNVC0E2 9xD9tqTrRYpMhvyzLF6P49SLP0LvsKVBd5bUObr+9qqDcZMF4E2LR2djuUD8zYY7 lSi6BJgg8a3coVUSGLFcNMOxqO/auvMaHwO6TMI4SQVQREcIS9b1E2Vnw3bvXIUh dvVoiKNq4L+hFuk9xpo= Received: from vpn132.rw1.your.org (vpn132.rw1.your.org [204.9.51.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 6C212F06C5A for ; Fri, 1 Feb 2013 21:21:17 +0000 (UTC) From: Kevin Day Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Syncookies break with Windows 8 Message-Id: Date: Fri, 1 Feb 2013 15:21:15 -0600 To: freebsd-net@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) X-Mailer: Apple Mail (2.1499) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 21:21:20 -0000 We've got a large cluster of HTTP servers, each server handling = >10,000req/sec. Occasionally, and during periods of heavy load, we'd get = complaints from some users that downloads were working but going = EXTREMELY slowly. After a whole lot of debugging, we narrowed it down to = being only Windows 8 clients experiencing this problem. It turns out = that FreeBSD's implementation of syncookies is likely violating RFC1323. When syncookies kicks in, either because the syncache limit is reached = or net.inet.tcp.syncookies_only is set, some shortcuts are taken with = regard to TCP connections. Unlike some other syncookies implementations = which (ab)use timestamps to store options, the FreeBSD implementation of = syncookies discards TCP options such as window scaling. In itself this = isn't a bad thing, but it becomes a bad thing because we then lie and = pretend that we are supporting window scaling. According to RFC1323, if you want to use TCP window scaling, the client = says so on the initial SYN. If the server is also willing to use = scaling, it says so on the SYN/ACK. If both parties included a scaling = option on their respective SYN, you assume window scaling is working and = proceed to use it. If one or both parties don't have a scaling option, = you don't scale at all. The problem here is that with syncookies, we = don't save the wscale parameter from the client's SYN, but offer to use = window scaling anyway on our SYN/ACK, so the client thinks we = successfully negotiated window scaling even though we haven't. This is how a normal window scaled connection happens: client > server: Flags [S], win 65535, options [mss 1460,nop,wscale = 4,nop,nop,sackOK], length 0 (client is connecting, offering a window of 64K, but if scaling is = negotiated wants to scale future window sizes by 4 bits) server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale = 5,sackOK,eol], length 0 (server is ACKing the client's SYN, also offering an unscaled window of = 64K, but wanting to shift by 5 going forward) The server and client both offered window scaling, so they're now using = it from this point on. All window sizes sent/received are shifted by the = appropriate number of bits. When syncookies kicks in on the server, and the client is anything BUT = Windows 8, this happens: client > server: Flags [S], win 65535, options [mss 1460,nop,wscale = 4,nop,nop,sackOK], length 0 However, syncookies cause the options to get lost. The client sent the = "wscale 4" parameter, but we immediately forgot it. server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale = 5,sackOK,eol], length 0 (server is ACKing the client's SYN, also offering an unscaled window of = 64K, but wanting to shift by 5 going forward) The server sent a wscale back on its SYN/ACK, so the client thinks = window scaling is now in effect. But it's not, the server didn't = remember the client's wscale option, so it's not scaling any of the = received window sizes that are coming in from the client. This doesn't = actually hurt much. The client thinks it's telling us it has a 1MB = window open, but we're only hearing that it's sent a 64K window, so = that's all we ever use. It's "failing safe" here, and nothing actually = breaks. Now throw Windows 8 into the mix. Windows 8's TCP auto tuning is much = more aggressive than previous versions of Windows. I honestly can't tell = if this is a bug or intentional design, but Windows will sometimes, = intermittently, advertise a much much larger wscale option than it = actually needs. This is a mild example of what happens: client > server: Flags [S], win 8192, options [mss 1460,nop,wscale = 8,nop,nop,sackOK], length 0 (client is connecting, offering an unscaled window of 8192 bytes, but = wants to negotiate window scaling of 8 bits if the server will accept = it) server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale = 5,sackOK,eol], length 0 (server is ACKing the client's SYN, also offering an unscaled window of = 64K, but wanting to shift by 5 going forward) We're at the same point here as in the above example, the client now = believes we've successfully negotiated window scaling, but on the server = side we're treating all window sizes coming from the client as being = shifted by 0. So the client sends it's first ACK: client > server: Flags [.], seq 1, ack 1, win 256, length 0 The client believes we're still scaling everything it says by 8 bits, = but it only wants to give us a 64K window, so it's saying 256 here. = (256<<8 =3D 65536). We don't remember that we agreed to shift everything = by 8, so we treat that as just 256. The connection now proceeds, but we = think we can only send 256 bytes at a time. It is extremely slow. I have seen Windows 8 attempt to use wscale parameters of 8 all way up = to 10. While I've only caught a few cases of this happening in the wild, = when it's using 10 we end up thinking we only have a 64 byte window and = things get really silly really fast. I've been talking with someone on Microsoft's side of things about why = Windows is choosing to do this. But my own view of this is that if = syncookies are being used in their current state (we lose the client's = wscale option), we can't advertise wscale on the SYN/ACK. My reading of = RFC1323 says that if we put a wscale option in our SYN/ACK that means we = agreed to use the client's wscale in their SYN. I don't think that's = correct. If syncookies are being used, we should advertise MIN(sb_max, = TCP_MAXWIN) with no scaling and stay within the RFC. This doesn't affect Linux because it uses timestamp options to stuff the = client's wscale, so it gets re-learned on the ACK. OpenBSD and OS X = don't have syncookies. NetBSD seems to have the same problem if it's new = syncookie implementation gets turned on.=20 Any thoughts? Was there a reason why we're forcing the use of wscale on = syncookie connections? -- Kevin From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 22:05:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0FC15B7E for ; Fri, 1 Feb 2013 22:05:53 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by mx1.freebsd.org (Postfix) with ESMTP id D4F0D12A for ; Fri, 1 Feb 2013 22:05:52 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id wc20so4619233obb.15 for ; Fri, 01 Feb 2013 14:05:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=uUfSExXB6yfoWAY4nBsGKhlcAQ+7Qt8R0xoMluLevS0=; b=LJ1NRkPGxHRWg8zLsBPeIvAnBDbzzMNjLCLO1FiWHXzWbVpNWXkC4IDxWgX9hc0EB6 sQOwqV95JECl/PLOgcRKPH5swPIXl5UjVkJrnYXMsSKLOr/TDZjCIGFAB3x3mM+ZQSCN nQlvTpfPrCrtZujUt0vsFeAorO3GbQSy7YHq5CvnEkMOarxbzlhFdLPn1YydvdOJTekI SHSh62MloSM6xvGpHTm2Ihab456OeXfM5wGLDiHjTt6soY5Paz+nsMuIt/p3n1vTOTkS 36S1x0jUqA5XB/eTpETiJOl9zHauwb6xxkCqGMjTloMdihlhDs5I+TKzrlF1i8jtmyy4 OdOA== MIME-Version: 1.0 X-Received: by 10.60.27.161 with SMTP id u1mr10934946oeg.1.1359756351901; Fri, 01 Feb 2013 14:05:51 -0800 (PST) Sender: carpeddiem@gmail.com Received: by 10.60.150.239 with HTTP; Fri, 1 Feb 2013 14:05:51 -0800 (PST) In-Reply-To: References: Date: Fri, 1 Feb 2013 17:05:51 -0500 X-Google-Sender-Auth: uWPEyF0dEytSHvKd1rAQxIN7wX8 Message-ID: Subject: Re: Syncookies break with Windows 8 From: Ed Maste To: Kevin Day Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:05:53 -0000 On 1 February 2013 16:21, Kevin Day wrote: > We've got a large cluster of HTTP servers, each server handling >10,000re= q/sec. Occasionally, and during periods of heavy load, we'd get complaints = from some users that downloads were working but going EXTREMELY slowly. Aft= er a whole lot of debugging, we narrowed it down to being only Windows 8 cl= ients experiencing this problem. It turns out that FreeBSD's implementation= of syncookies is likely violating RFC1323. Kevin, Thanks for the thorough analysis and report, although I didn't see mention of which FreeBSD version you're running. It looks like andre@ added storage of the window scale option in the timestamp many years ago in r162277[1], so I'm curious if you have an old version or there's an issue with this implementation. > This implementation extends the orginal idea and first implementation > of FreeBSD by using not only the initial sequence number field to store > information but also the timestamp field if present. This way we can > keep track of the entire state we need to know to recreate the session in > its original form. Almost all TCP speakers implement RFC1323 timestamps > these days. For those that do not we still have to live with the known > shortcomings of the ISN only SYN cookies. The use of the timestamp field > causes the timestamps to be randomized if syncookies are enabled. -Ed [1] http://svnweb.freebsd.org/base?view=3Drevision&revision=3D162277 From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 22:25:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CE771CE7; Fri, 1 Feb 2013 22:25:26 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id 887C1195; Fri, 1 Feb 2013 22:25:26 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id 0FCFAF06C33; Fri, 1 Feb 2013 22:25:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=rypa939gCBSnFNIVq/LrrD4PiC4=; b=1hbHJ1ufuHEjZr81Sr bLzEmWYcQE1AKBO0DFLrWwmR1gs3PxHWlhiFPPJrLN2g5P93c3qVA7ee5u1fRowD PGMLHLcgFr8HnS5zIYdTqwhU+Ppapw848gQQyGbLrMm3b9D5mWbJcpjRT6fbI/Ym AVB7xOxUz8RK6SMWyMiqsMQcA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=0aiMRHe2TCkJ+AO4gg7/mczx9rJTvI+3re7UB0vEmJ0u3AuYLvi grTnxFUzSyuM1ed0AwNLxxfOcVjjnOGOUKQsLcpt/bKlB3CwUunTAIsMTr+iySo9 sVD/O08ic9fLHznhj5ghvJ7xhByv/KoUsJuB78b0nkghkym5UCT+7tZE= Received: from vpn132.rw1.your.org (vpn132.rw1.your.org [204.9.51.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 7DA9DF06C32; Fri, 1 Feb 2013 22:25:25 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Syncookies break with Windows 8 From: Kevin Day In-Reply-To: Date: Fri, 1 Feb 2013 16:25:23 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <87E3F8C6-1027-49E5-8ED3-C0A499D71864@your.org> References: To: Ed Maste X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:25:26 -0000 On Feb 1, 2013, at 4:05 PM, Ed Maste wrote: > On 1 February 2013 16:21, Kevin Day wrote: >> We've got a large cluster of HTTP servers, each server handling = >10,000req/sec. Occasionally, and during periods of heavy load, we'd get = complaints from some users that downloads were working but going = EXTREMELY slowly. After a whole lot of debugging, we narrowed it down to = being only Windows 8 clients experiencing this problem. It turns out = that FreeBSD's implementation of syncookies is likely violating RFC1323. >=20 > Kevin, >=20 > Thanks for the thorough analysis and report, although I didn't see > mention of which FreeBSD version you're running. It looks like andre@ > added storage of the window scale option in the timestamp many years > ago in r162277[1], so I'm curious if you have an old version or > there's an issue with this implementation. This is in 9.1. I saw that change, but based it's not kicking in here (i = think) because Windows wasn't setting a TSopt option in the initial SYN. = RFC1323 says: A TCP may send the Timestamps option (TSopt) in an initial segment (i.e., segment containing a SYN bit and no ACK bit), and may send a TSopt in other segments only if it re- ceived a TSopt in the initial segment for the connection. The client is not setting TSopt on the SYN, so we can't set it on the = SYN/ACK.=20 I can't tell if RFC1323 is saying you MUST support timestamps if you = have window scaling or not: It is vitally important to use the RTTM mechanism with big windows; otherwise, the door is opened to some dangerous instabilities due to aliasing. Furthermore, the option is probably useful for all TCP's, since it simplifies the sender. It appears that the code here won't do window scaling stuffing into = timestamps if we didn't get a timestamp on the SYN though. On = connection: /* * A timestamp received in a SYN makes * it ok to send timestamp requests and replies. */ if (to->to_flags & TOF_TS) { sc->sc_tsreflect =3D to->to_tsval; sc->sc_ts =3D tcp_ts_getticks(); sc->sc_flags |=3D SCF_TIMESTAMP; } Then later on the syncookies ACK: /* Additional parameters are stored in the timestamp if present. = */ if (sc->sc_flags & SCF_TIMESTAMP) { data =3D ((sc->sc_flags & SCF_SIGNATURE) ? 1 : 0); /* = TCP-MD5, 1 bit */ data |=3D ((sc->sc_flags & SCF_SACK) ? 1 : 0) << 1; /* = SACK, 1 bit */ data |=3D sc->sc_requested_s_scale << 2; /* SWIN scale, = 4 bits */ data |=3D sc->sc_requested_r_scale << 6; /* RWIN scale, = 4 bits */ data |=3D md5_buffer[2] << 10; /* more digest = bits */ data ^=3D md5_buffer[3]; sc->sc_ts =3D data; sc->sc_tsoff =3D data - tcp_ts_getticks(); /* = after XOR */ } If SCF_TIMESTAMP doesn't get set, the server doesn't do this. Here's an example tcpdump showing what's happening, with = syncookies_only=3D1 set: 14:22:16.696366 IP (tos 0x0, ttl 118, id 18606, offset 0, flags [DF], = proto TCP (6), length 52) client.49637 > server.80: Flags [S], cksum 0xe8c0 (correct), seq = 4056314475, win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], = length 0 14:22:16.696386 IP (tos 0x0, ttl 64, id 60489, offset 0, flags [DF], = proto TCP (6), length 52) server.80 > client.49637: Flags [S.], cksum 0x400e (incorrect -> = 0x5f10), seq 3099521508, ack 4056314476, win 65535, options [mss = 1460,nop,wscale 5,sackOK,eol], length 0 14:22:16.708523 IP (tos 0x0, ttl 118, id 18607, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9ddf (correct), seq 1, = ack 1, win 256, length 0 14:22:16.708537 IP (tos 0x0, ttl 119, id 18608, offset 0, flags [DF], = proto TCP (6), length 452) client.49637 > server.80: Flags [P.], cksum 0x9aec (correct), seq = 1:413, ack 1, win 256, length 412 14:22:16.711885 IP (tos 0x0, ttl 64, id 60794, offset 0, flags [DF], = proto TCP (6), length 296) server.80 > client.49637: Flags [.], cksum 0x4102 (incorrect -> = 0xdd41), seq 1:257, ack 413, win 65535, length 256 14:22:16.782746 IP (tos 0x0, ttl 119, id 18609, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9b44 (correct), seq = 413, ack 257, win 255, length 0 14:22:16.782758 IP (tos 0x0, ttl 64, id 62354, offset 0, flags [DF], = proto TCP (6), length 295) server.80 > client.49637: Flags [.], cksum 0x4101 (incorrect -> = 0x8d90), seq 257:512, ack 413, win 65535, length 255 14:22:16.844941 IP (tos 0x0, ttl 119, id 18610, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9a46 (correct), seq = 413, ack 512, win 254, length 0 14:22:16.844953 IP (tos 0x0, ttl 64, id 63448, offset 0, flags [DF], = proto TCP (6), length 294) server.80 > client.49637: Flags [.], cksum 0x4100 (incorrect -> = 0x9a46), seq 512:766, ack 413, win 65535, length 254 14:22:16.906469 IP (tos 0x0, ttl 119, id 18611, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9949 (correct), seq = 413, ack 766, win 253, length 0 14:22:16.906481 IP (tos 0x0, ttl 64, id 64738, offset 0, flags [DF], = proto TCP (6), length 293) server.80 > client.49637: Flags [.], cksum 0x40ff (incorrect -> = 0x9949), seq 766:1019, ack 413, win 65535, length 253 14:22:16.968393 IP (tos 0x0, ttl 119, id 18612, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x984d (correct), seq = 413, ack 1019, win 252, length 0 14:22:16.968414 IP (tos 0x0, ttl 64, id 788, offset 0, flags [DF], proto = TCP (6), length 292) server.80 > client.49637: Flags [.], cksum 0x40fe (incorrect -> = 0x984d), seq 1019:1271, ack 413, win 65535, length 252 14:22:17.036097 IP (tos 0x0, ttl 119, id 18613, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9752 (correct), seq = 413, ack 1271, win 251, length 0 14:22:17.036114 IP (tos 0x0, ttl 64, id 1973, offset 0, flags [DF], = proto TCP (6), length 291) server.80 > client.49637: Flags [.], cksum 0x40fd (incorrect -> = 0x9752), seq 1271:1522, ack 413, win 65535, length 251 14:22:17.095046 IP (tos 0x0, ttl 119, id 18614, offset 0, flags [DF], = proto TCP (6), length 40) client.49637 > server.80: Flags [.], cksum 0x9652 (correct), seq = 413, ack 1522, win 256, length 0 14:22:17.095062 IP (tos 0x0, ttl 64, id 3218, offset 0, flags [DF], = proto TCP (6), length 296) server.80 > client.49637: Flags [.], cksum 0x4102 (incorrect -> = 0x9652), seq 1522:1778, ack 413, win 65535, length 256 You can see where it looks like(from an outside observer) scaling was = properly negotiated, but the server is treating the lengths as unshifted = amounts. -- Kevin From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 22:39:40 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 5162BE53 for ; Fri, 1 Feb 2013 22:39:40 +0000 (UTC) (envelope-from oppermann@networx.ch) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 9FC5F202 for ; Fri, 1 Feb 2013 22:39:39 +0000 (UTC) Received: (qmail 49725 invoked from network); 1 Feb 2013 23:59:13 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 1 Feb 2013 23:59:13 -0000 Message-ID: <510C4424.4030701@networx.ch> Date: Fri, 01 Feb 2013 23:39:32 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kevin Day Subject: Re: Syncookies break with Windows 8 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:39:40 -0000 On 01.02.2013 22:21, Kevin Day wrote: > We've got a large cluster of HTTP servers, each server handling >10,000req/sec. Occasionally, and > during periods of heavy load, we'd get complaints from some users that downloads were working but > going EXTREMELY slowly. After a whole lot of debugging, we narrowed it down to being only Windows > 8 clients experiencing this problem. It turns out that FreeBSD's implementation of syncookies is > likely violating RFC1323. > > When syncookies kicks in, either because the syncache limit is reached or > net.inet.tcp.syncookies_only is set, some shortcuts are taken with regard to TCP connections. > Unlike some other syncookies implementations which (ab)use timestamps to store options, the > FreeBSD implementation of syncookies discards TCP options such as window scaling. In itself this > isn't a bad thing, but it becomes a bad thing because we then lie and pretend that we are > supporting window scaling. This is not true. FreeBSD uses bits in the timestamp to encode all recognized TCP options including window scaling. > According to RFC1323, if you want to use TCP window scaling, the client says so on the initial > SYN. If the server is also willing to use scaling, it says so on the SYN/ACK. If both parties > included a scaling option on their respective SYN, you assume window scaling is working and > proceed to use it. If one or both parties don't have a scaling option, you don't scale at all. > The problem here is that with syncookies, we don't save the wscale parameter from the client's > SYN, but offer to use window scaling anyway on our SYN/ACK, so the client thinks we successfully > negotiated window scaling even though we haven't. The syncookie window scale is stored in the timestamp. Of course this becomes problematic as you describe when timestamps are not active on an connection. > This is how a normal window scaled connection happens: > > client > server: Flags [S], win 65535, options [mss 1460,nop,wscale 4,nop,nop,sackOK], length 0 > (client is connecting, offering a window of 64K, but if scaling is negotiated wants to scale > future window sizes by 4 bits) > > server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale 5,sackOK,eol], length 0 > (server is ACKing the client's SYN, also offering an unscaled window of 64K, but wanting to shift > by 5 going forward) > > The server and client both offered window scaling, so they're now using it from this point on. > All window sizes sent/received are shifted by the appropriate number of bits. No timestamps. > When syncookies kicks in on the server, and the client is anything BUT Windows 8, this happens: > > client > server: Flags [S], win 65535, options [mss 1460,nop,wscale 4,nop,nop,sackOK], length 0 > However, syncookies cause the options to get lost. The client sent the "wscale 4" parameter, but > we immediately forgot it. > > server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale 5,sackOK,eol], length 0 > (server is ACKing the client's SYN, also offering an unscaled window of 64K, but wanting to shift > by 5 going forward) > > The server sent a wscale back on its SYN/ACK, so the client thinks window scaling is now in > effect. But it's not, the server didn't remember the client's wscale option, so it's not scaling > any of the received window sizes that are coming in from the client. This doesn't actually hurt > much. The client thinks it's telling us it has a 1MB window open, but we're only hearing that > it's sent a 64K window, so that's all we ever use. It's "failing safe" here, and nothing actually > breaks. > > > Now throw Windows 8 into the mix. Windows 8's TCP auto tuning is much more aggressive than > previous versions of Windows. I honestly can't tell if this is a bug or intentional design, but > Windows will sometimes, intermittently, advertise a much much larger wscale option than it > actually needs. This is a mild example of what happens: > > client > server: Flags [S], win 8192, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0 > (client is connecting, offering an unscaled window of 8192 bytes, but wants to negotiate window > scaling of 8 bits if the server will accept it) > > server > client: Flags [S.], win 65535, options [mss 1460,nop,wscale 5,sackOK,eol], length 0 > (server is ACKing the client's SYN, also offering an unscaled window of 64K, but wanting to shift > by 5 going forward) > > We're at the same point here as in the above example, the client now believes we've successfully > negotiated window scaling, but on the server side we're treating all window sizes coming from the > client as being shifted by 0. So the client sends it's first ACK: > > client > server: Flags [.], seq 1, ack 1, win 256, length 0 > > The client believes we're still scaling everything it says by 8 bits, but it only wants to give > us a 64K window, so it's saying 256 here. (256<<8 = 65536). We don't remember that we agreed to > shift everything by 8, so we treat that as just 256. The connection now proceeds, but we think we > can only send 256 bytes at a time. It is extremely slow. Yeah, that's bad. > I have seen Windows 8 attempt to use wscale parameters of 8 all way up to 10. While I've only > caught a few cases of this happening in the wild, when it's using 10 we end up thinking we only > have a 64 byte window and things get really silly really fast. Indeed. > I've been talking with someone on Microsoft's side of things about why Windows is choosing to do > this. But my own view of this is that if syncookies are being used in their current state (we > lose the client's wscale option), we can't advertise wscale on the SYN/ACK. My reading of RFC1323 > says that if we put a wscale option in our SYN/ACK that means we agreed to use the client's > wscale in their SYN. I don't think that's correct. If syncookies are being used, we should > advertise MIN(sb_max, TCP_MAXWIN) with no scaling and stay within the RFC. > > This doesn't affect Linux because it uses timestamp options to stuff the client's wscale, so it > gets re-learned on the ACK. OpenBSD and OS X don't have syncookies. NetBSD seems to have the same > problem if it's new syncookie implementation gets turned on. This can't be because of the lack of timestamps. Linux must be encoding the scale in the ISS taking away bits from the cookie. I haven't looked into how Linux actually does it recently. > Any thoughts? Was there a reason why we're forcing the use of wscale on syncookie connections? We can change the behavior of syncookies in a couple of ways to deal with this problem: 1/ send syncookies only when the syncache overflows and set wscale to 0 in the SYN-ACK when timestamps are not active. 2/ move the wscale bits from timestamp encoding to the ISS taking bits away from the cookie. At the moment we send syncookies on every SYN-ACK and bump the oldest entry from the syncache when it is full. That results in potentially every segment degrading to syncookie only. The default values are insufficient for such high loads. In general at 10,000 connections per second you should significantly increase the size of your syncache to 3 * conn/sec at least. In the loader you can set these tunables: net.inet.tcp.syncache.hashsize = 2048 net.inet.tcp.syncache.bucketlimit = 32 net.inet.tcp.syncache.cachelimit = 65536 These settings are a bit more complicated than they should be. Going forward I have to take a closer look at the modifications in 1/ and 2/ and possibly combinations of both. The main issue is the tradeoff in cookie bits vs. cookie life time and how fast the hash can be cracked these days. OTOH a too complicated hash would cost us significant cpu power too. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 22:54:47 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 71BC637D for ; Fri, 1 Feb 2013 22:54:47 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id 3B2D32A8 for ; Fri, 1 Feb 2013 22:54:47 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id C12EBF06C5F; Fri, 1 Feb 2013 22:54:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=A4fNsr5EwB4QDtRQ0KTHiGDd9dA=; b=bOj7wFOlqvkKDdnpJw iFv/gGvXkbk0KyEQ4oKtVaLgpVy1zm3C50/oPLzqL+PAz/LWEAjUpM6yu7+akoBl AwyEnd6CI19rInVa006hChBKefj6gbrxBLsYr6zxyzDRloRRRIRpOIQ/R+bx6dxs EMpo63hHaSlb6cWmx4Vtgtkpc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=aX4BhL7D6ZEjBLMdWNR1r5vqMNLD9WyGGlN30eVI4PhoofFeLhd auA+KY40XcE4GQIzRVYaOi1shEyTefiqx+0EaE9XGpo3c1PmK+DhdVZAVg4aijwD gBC8V3JCuKRInOZqOosRNTHSsWRUqkcGUBfhJfPEBx+8UZU4+C6O5AnQ= Received: from vpn132.rw1.your.org (vpn132.rw1.your.org [204.9.51.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 13D2CF06C63; Fri, 1 Feb 2013 22:54:45 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Syncookies break with Windows 8 From: Kevin Day In-Reply-To: <510C4424.4030701@networx.ch> Date: Fri, 1 Feb 2013 16:54:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <510C4424.4030701@networx.ch> To: Andre Oppermann X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 22:54:47 -0000 On Feb 1, 2013, at 4:39 PM, Andre Oppermann = wrote: >=20 > This is not true. FreeBSD uses bits in the timestamp to encode all > recognized TCP options including window scaling. >=20 Sorry, you are correct here. Reading through a half dozen TCP = implementations in the last day trying to figure out what was happening = and it all turns into a blur. :) >> This doesn't affect Linux because it uses timestamp options to stuff = the client's wscale, so it >> gets re-learned on the ACK. OpenBSD and OS X don't have syncookies. = NetBSD seems to have the same >> problem if it's new syncookie implementation gets turned on. >=20 > This can't be because of the lack of timestamps. Linux must be > encoding the scale in the ISS taking away bits from the cookie. >=20 > I haven't looked into how Linux actually does it recently. >=20 In Linux, it appears if timestamps are not enabled, either because = they're turned off by sysctl or the server didn't see one from the = client, it disables scaling. http://fxr.watson.org/fxr/source/net/ipv4/syncookies.c?v=3Dlinux-2.6#L235 wscale_ok defaults to 0. It's set to '1' only if the server saw_tstamp, = sysctl_tcp_timestamps isn't turned off, etc.=20 >> Any thoughts? Was there a reason why we're forcing the use of wscale = on syncookie connections? >=20 > We can change the behavior of syncookies in a couple of ways to > deal with this problem: >=20 > 1/ send syncookies only when the syncache overflows and set wscale > to 0 in the SYN-ACK when timestamps are not active. >=20 That sounds similar to Linux, if I'm reading the code correctly. > At the moment we send syncookies on every SYN-ACK and bump the oldest > entry from the syncache when it is full. That results in potentially > every segment degrading to syncookie only. The default values are > insufficient for such high loads. >=20 > In general at 10,000 connections per second you should significantly > increase the size of your syncache to 3 * conn/sec at least. >=20 > In the loader you can set these tunables: >=20 > net.inet.tcp.syncache.hashsize =3D 2048 > net.inet.tcp.syncache.bucketlimit =3D 32 > net.inet.tcp.syncache.cachelimit =3D 65536 >=20 > These settings are a bit more complicated than they should be. >=20 We're doing similar. During a DDoS we tried changing to syncookies_only = and somehow that got left that way, which is how we ran into this = problem more reliably. Turning that off, and using higher syncache sizes = helped hide this greatly, but it's probably still happening here and = elsewhere occasionally. -- Kevin From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 23:09:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C07966F6 for ; Fri, 1 Feb 2013 23:09:19 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1349A31F for ; Fri, 1 Feb 2013 23:09:18 +0000 (UTC) Received: (qmail 49823 invoked from network); 2 Feb 2013 00:28:53 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 2 Feb 2013 00:28:53 -0000 Message-ID: <510C4B17.4040509@freebsd.org> Date: Sat, 02 Feb 2013 00:09:11 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kevin Day Subject: Re: Syncookies break with Windows 8 References: <510C4424.4030701@networx.ch> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:09:19 -0000 On 01.02.2013 23:54, Kevin Day wrote: > > On Feb 1, 2013, at 4:39 PM, Andre Oppermann wrote: >> >> This is not true. FreeBSD uses bits in the timestamp to encode all recognized TCP options >> including window scaling. >> > > Sorry, you are correct here. Reading through a half dozen TCP implementations in the last day > trying to figure out what was happening and it all turns into a blur. :) I can imagine... :) >>> This doesn't affect Linux because it uses timestamp options to stuff the client's wscale, so >>> it gets re-learned on the ACK. OpenBSD and OS X don't have syncookies. NetBSD seems to have >>> the same problem if it's new syncookie implementation gets turned on. >> >> This can't be because of the lack of timestamps. Linux must be encoding the scale in the ISS >> taking away bits from the cookie. >> >> I haven't looked into how Linux actually does it recently. >> > > In Linux, it appears if timestamps are not enabled, either because they're turned off by sysctl > or the server didn't see one from the client, it disables scaling. > > http://fxr.watson.org/fxr/source/net/ipv4/syncookies.c?v=linux-2.6#L235 > > wscale_ok defaults to 0. It's set to '1' only if the server saw_tstamp, sysctl_tcp_timestamps > isn't turned off, etc. OK. >>> Any thoughts? Was there a reason why we're forcing the use of wscale on syncookie >>> connections? >> >> We can change the behavior of syncookies in a couple of ways to deal with this problem: >> >> 1/ send syncookies only when the syncache overflows and set wscale to 0 in the SYN-ACK when >> timestamps are not active. >> > > That sounds similar to Linux, if I'm reading the code correctly. > >> At the moment we send syncookies on every SYN-ACK and bump the oldest entry from the syncache >> when it is full. That results in potentially every segment degrading to syncookie only. The >> default values are insufficient for such high loads. >> >> In general at 10,000 connections per second you should significantly increase the size of your >> syncache to 3 * conn/sec at least. >> >> In the loader you can set these tunables: >> >> net.inet.tcp.syncache.hashsize = 2048 net.inet.tcp.syncache.bucketlimit = 32 >> net.inet.tcp.syncache.cachelimit = 65536 >> >> These settings are a bit more complicated than they should be. >> > > We're doing similar. During a DDoS we tried changing to syncookies_only and somehow that got left > that way, which is how we ran into this problem more reliably. Turning that off, and using higher > syncache sizes helped hide this greatly, but it's probably still happening here and elsewhere > occasionally. I'm working on a solution. Have to make sure that the chance to crack a reduced cookie during its 30 seconds lifetime isn't too high. That means involving our resident crypto experts for verification. -- Andre From owner-freebsd-net@FreeBSD.ORG Fri Feb 1 23:49:22 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 69253CFB for ; Fri, 1 Feb 2013 23:49:22 +0000 (UTC) (envelope-from ask@develooper.com) Received: from mbox1.develooper.com (mbox1.develooper.com [207.171.7.178]) by mx1.freebsd.org (Postfix) with ESMTP id 529A5656 for ; Fri, 1 Feb 2013 23:49:21 +0000 (UTC) Received: from mbox1.develooper.com (mbox1.develooper.com [127.0.0.1]) by mbox1.develooper.com (Postfix) with ESMTP id 6D4EB175ACD for ; Fri, 1 Feb 2013 15:24:37 -0800 (PST) Received: (qmail 26666 invoked from network); 1 Feb 2013 23:24:37 -0000 Received: from unknown (HELO ask.bur.sol) (ask@mail.dev@64.235.248.131) by smtp.develooper.com with ESMTPA; 1 Feb 2013 23:24:37 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Carp configuration errors From: =?iso-8859-1?Q?Ask_Bj=F8rn_Hansen?= In-Reply-To: Date: Fri, 1 Feb 2013 15:24:37 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <4946BA07-B722-42C7-B5B0-505167541EBA@develooper.com> References: <0154442B-C0E9-4731-A85E-1A44F3ED1F47@develooper.com> To: Anton Yuzhaninov X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Feb 2013 23:49:22 -0000 On Jan 25, 2013, at 2:13, Anton Yuzhaninov wrote: > ABrH> After upgrading to 9.1 it seems like carp doesn't pay attention = to advskew anymore. I have two boxes each setup with carp0 and carp1; = the intention is that in regular operation proxy1 is master for carp0 = and proxy2 for carp1. However, whichever box comes up second is BACKUP = for both. >=20 > 1. Do your have sysctl net.inet.carp.preempt=3D1 ? With preempt=3D0 = box > comes up second should be in backup state. Indeed, that fixed it! And thank you for the hint about = net.inet.carp.log. Thank you again. Ask= From owner-freebsd-net@FreeBSD.ORG Sat Feb 2 12:00:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3EDDF99E for ; Sat, 2 Feb 2013 12:00:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 32677D3B for ; Sat, 2 Feb 2013 12:00:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r12C01Jb060160 for ; Sat, 2 Feb 2013 12:00:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r12C013a060156; Sat, 2 Feb 2013 12:00:01 GMT (envelope-from gnats) Date: Sat, 2 Feb 2013 12:00:01 GMT Message-Id: <201302021200.r12C013a060156@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: dfilter@FreeBSD.ORG (dfilter service) Subject: Re: kern/154850: commit references a PR X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 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, 02 Feb 2013 12:00:01 -0000 The following reply was made to PR kern/154850; it has been noted by GNATS. From: dfilter@FreeBSD.ORG (dfilter service) To: bug-followup@FreeBSD.org Cc: Subject: Re: kern/154850: commit references a PR Date: Sat, 2 Feb 2013 11:54:12 +0000 (UTC) Author: avg Date: Sat Feb 2 11:54:00 2013 New Revision: 246245 URL: http://svnweb.freebsd.org/changeset/base/246245 Log: ng_ether: track interface renaming Also sanitize interface names that can potentially contain characters that are prohibited in netgraph names. PR: kern/154850 (sanitizing of names) Discussed with: eri, melifaro Submitted by: Nikolay Denev (sanitizing code) Reviewed by: eri, glebius MFC after: 17 days Modified: head/sys/netgraph/ng_ether.c Modified: head/sys/netgraph/ng_ether.c ============================================================================== --- head/sys/netgraph/ng_ether.c Sat Feb 2 11:41:05 2013 (r246244) +++ head/sys/netgraph/ng_ether.c Sat Feb 2 11:54:00 2013 (r246245) @@ -117,6 +117,8 @@ static ng_rcvdata_t ng_ether_rcvdata; static ng_disconnect_t ng_ether_disconnect; static int ng_ether_mod_event(module_t mod, int event, void *data); +static eventhandler_tag ng_ether_ifnet_arrival_cookie; + /* List of commands and how to convert arguments to/from ASCII */ static const struct ng_cmdlist ng_ether_cmdlist[] = { { @@ -214,6 +216,24 @@ static struct ng_type ng_ether_typestruc NETGRAPH_INIT(ether, &ng_ether_typestruct); /****************************************************************** + UTILITY FUNCTIONS +******************************************************************/ +static void +ng_ether_sanitize_ifname(const char *ifname, char *name) +{ + int i; + + for (i = 0; i < IFNAMSIZ; i++) { + if (ifname[i] == '.' || ifname[i] == ':') + name[i] = '_'; + else + name[i] = ifname[i]; + if (name[i] == '\0') + break; + } +} + +/****************************************************************** ETHERNET FUNCTION HOOKS ******************************************************************/ @@ -282,6 +302,7 @@ ng_ether_output(struct ifnet *ifp, struc static void ng_ether_attach(struct ifnet *ifp) { + char name[IFNAMSIZ]; priv_p priv; node_p node; @@ -319,10 +340,9 @@ ng_ether_attach(struct ifnet *ifp) priv->hwassist = ifp->if_hwassist; /* Try to give the node the same name as the interface */ - if (ng_name_node(node, ifp->if_xname) != 0) { - log(LOG_WARNING, "%s: can't name node %s\n", - __func__, ifp->if_xname); - } + ng_ether_sanitize_ifname(ifp->if_xname, name); + if (ng_name_node(node, name) != 0) + log(LOG_WARNING, "%s: can't name node %s\n", __func__, name); } /* @@ -378,6 +398,32 @@ ng_ether_link_state(struct ifnet *ifp, i } } +/* + * Interface arrival notification handler. + * The notification is produced in two cases: + * o a new interface arrives + * o an existing interface got renamed + * Currently the first case is handled by ng_ether_attach via special + * hook ng_ether_attach_p. + */ +static void +ng_ether_ifnet_arrival_event(void *arg __unused, struct ifnet *ifp) +{ + char name[IFNAMSIZ]; + node_p node = IFP2NG(ifp); + + /* + * Just return if it's a new interface without an ng_ether companion. + */ + if (node == NULL) + return; + + /* Try to give the node the same name as the new interface name */ + ng_ether_sanitize_ifname(ifp->if_xname, name); + if (ng_name_node(node, name) != 0) + log(LOG_WARNING, "%s: can't re-name node %s\n", __func__, name); +} + /****************************************************************** NETGRAPH NODE METHODS ******************************************************************/ @@ -771,6 +817,9 @@ ng_ether_mod_event(module_t mod, int eve ng_ether_input_orphan_p = ng_ether_input_orphan; ng_ether_link_state_p = ng_ether_link_state; + ng_ether_ifnet_arrival_cookie = + EVENTHANDLER_REGISTER(ifnet_arrival_event, + ng_ether_ifnet_arrival_event, NULL, EVENTHANDLER_PRI_ANY); break; case MOD_UNLOAD: @@ -783,6 +832,9 @@ ng_ether_mod_event(module_t mod, int eve * is MOD_UNLOAD, so there's no need to detach any nodes. */ + EVENTHANDLER_DEREGISTER(ifnet_arrival_event, + ng_ether_ifnet_arrival_cookie); + /* Unregister function hooks */ ng_ether_attach_p = NULL; ng_ether_detach_p = NULL; _______________________________________________ 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"