From owner-freebsd-net@FreeBSD.ORG Sun May 9 09:41:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 84439106566B; Sun, 9 May 2010 09:41:06 +0000 (UTC) (envelope-from kes-kes@yandex.ru) Received: from forward1.mail.yandex.net (forward1.mail.yandex.net [77.88.46.6]) by mx1.freebsd.org (Postfix) with ESMTP id 15C1A8FC15; Sun, 9 May 2010 09:41:05 +0000 (UTC) Received: from smtp4.mail.yandex.net (smtp4.mail.yandex.net [77.88.46.104]) by forward1.mail.yandex.net (Yandex) with ESMTP id C8DFB69E863D; Sun, 9 May 2010 13:27:44 +0400 (MSD) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1273397264; bh=+GjRPjaqEdBdkrtvgX1lxJMqdSBOsPOQuzdhk5vmJFk=; h=Date:From:Reply-To:Message-ID:To:CC:Subject:In-Reply-To: References:MIME-Version:Content-Type:Content-Transfer-Encoding; b=UZauwqUFnDM/q6dfJXbnyHqHmSv7vo0JZlfH9ebJrhg0fqok3iUVXl3jpLbfXiSek dsc8p1cRU4rJzf7e0eU9/N0PT7oGG6gk+KcbEjBlkKvh9xSfLsf6mxa8/oozL/p2C7 GB085jwb+Ab6HrcEbIDQaQQRhI69zHZbhWBJsnjY= Received: from HOMEUSER (unknown [77.93.36.201]) by smtp4.mail.yandex.net (Yandex) with ESMTPA id 5FD7312809F; Sun, 9 May 2010 13:27:44 +0400 (MSD) X-Nat-Received: from [192.168.9.8]:1736 [ident-empty] by SPAM FILTER: with TPROXY id 1273397293.92419 abuse-to kes-kes@yandex.ru Date: Sun, 9 May 2010 12:27:43 +0300 From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= X-Mailer: The Bat! (v4.0.24) Professional Organization: =?windows-1251?B?188gyu7t/Oru4iwgRnJlZUxpbmU=?= X-Priority: 3 (Normal) Message-ID: <809964673.20100509122743@yandex.ru> To: julian@FreeBSD.org In-Reply-To: <201005081705.o48H52x3045574@freefall.freebsd.org> References: <201005081705.o48H52x3045574@freefall.freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Transfer-Encoding: 8bit X-Yandex-TimeMark: 1273397264 X-Yandex-Spam: 1 X-Yandex-Front: smtp4.mail.yandex.net Cc: freebsd-net@FreeBSD.org Subject: Re[2]: kern/146394: [vlan] IP source address for outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 09:41:06 -0000 Здравствуйте, Julian. Вы писали 8 мая 2010 г., 20:05:02: jFo> Synopsis: [vlan] IP source address for outgoing connections jFo> State-Changed-From-To: open->feedback jFo> State-Changed-By: julian jFo> State-Changed-When: Sat May 8 09:47:30 PDT 2010 jFo> State-Changed-Why: jFo> The behaviour you quote as a bug is expected and useful and I don't think it is a bug. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. jFo> Anyhow there are ways to do what you want. jFo> firstly: what you are talking about will ONLY happen if you do not bind the jFo> socke to an address, so looking in the config file and binding it will jFo> fix it. Most programs have an option to do this. I had to do this yesterday with named. jFo> (though I didn't find such an option in ntpd). jFo> You need to look at what is going on using sockstat and netstat -aAn jFo> any socket that has a local address of "*" will have this behaviour. jFo> If you can't do this then you can use the jail command to force a program that jFo> does not support binding to be bound. jFo> Put it in a jail that has the same root as the rest of the system jFo> but has a forced IP address of that you want. jFo> Let me know if this solved your problem an dwe can close the bug. Actually your suggestion (jail), not mine (setip tool) will not resolve the problem. 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(KERNEL)-(rl1)(192.168.1.1/24)<----192.168.1.0/24 now if 192.168.0.7 will enable connection to 192.168.1.1:80 it will get answer from 192.168.0.1:80 this seems like spoofing =( and some services like mpd<-->radiusd in this situations will fail: response is from untrusted source and md5 chechsum mismatch I agree with you, that I can force daemon to bind to some IP, but in this situation bind *.1812 (or any other service) seems useless despite on in 99% of cases it works fine. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. This is ok, for packets when connection is negitiated from router to client, but in situations when client do connection to 192.168.1.1 it must get response from 192.168.1.1 and not from any other machine. Do you agree? Router do connections to lan: So connections from ROUTER to 192.168.0.0/24 will have 192.168.0.1 IP in packets as source address So connections from ROUTER to 192.168.1.0/24 will have 192.168.1.1 IP in packets as source address Router is response to lan: So in connections from CLIENT to router. Router must response from that IP to which client have established connection Case 1: query: 192.168.0.7 -> 192.168.0.1 response: 192.168.0.1 -> 192.168.0.7 Case 2: query: 192.168.0.7 -> 192.168.1.1 response: 192.168.1.1 -> 192.168.0.7 So if client can establish connection to IP from other net he MUST get response from that IP! If client is not allowed to establish connection to IP from other net it MUST not get any response packet at all (Except maybe icmp: host is unreachable or etc.) bring to notice: if client can establish connection to IP from other net it CAN get response from that IP so router MUST resonse from that IP to which client establish connection and ONLY if router establish connection itself it MUST, as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave Look at this example: R.E.A.L/32 (lo0) 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(ROUTER0)-(rl1)(192.168.1.1/24) | | | | 192.168.0.7/24 192.168.1.7/24 (rl1) (rl0) (ROUTER1) (ROUTER2) (rl0) (rl1) SOME.REAL.IP.1 SOME.REAL.IP.2 \ / \-------------------- CLIENT --------------------------/ 192.168.0.1 is allowed on ROUTER1 and is nated to SOME.REAL.IP.1 192.168.1.1 is allowed on ROUTER2 and is nated to SOME.REAL.IP.2 on ROUTER1: route add R.E.A.L/32 192.168.0.1 on ROUTER2: route add R.E.A.L/32 192.168.1.1 on ROUTER0: there two default gateways with equal costs 0/0 192.168.0.7 0/0 192.168.1.7 Now as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave if CLIENT establish connection to R.E.A.L it will get 50% packet response from SOME.REAL.IP.1 and 50% from SOME.REAL.IP.2 %-) also because of NAT on ROUTER1 and ROUTER2 we will have resource leak tcpdump on CLIENT willshow: CLIENT -> R.E.A.L SOME.REAL.IP.1 -> CLIENT CLIENT -> R.E.A.L SOME.REAL.IP.2 -> CLIENT Bring notice that that response packet have different IPs! from resource we are establish connection. In 99% this work, 1% -- WILL NOT! As I have said: >>So if client can establish connection to IP from other net he MUST get response from that IP! in this situations everithing is expected: 1. No resource leak on ROUTER1 and ROUTER2 and maybe ROUTER3... 2. tcpdump on client: CLIENT -> R.E.A.L R.E.A.L -> CLIENT CLIENT -> R.E.A.L R.E.A.L -> CLIENT Another case: Router establish connection to CLIENT This is the case your rule MUST apply: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave jFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=146394 -- Eugen Konkov mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Sun May 9 13:43:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A66B9106564A for ; Sun, 9 May 2010 13:43:30 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id 50A1C8FC2B for ; Sun, 9 May 2010 13:43:30 +0000 (UTC) Received: (qmail 90163 invoked by uid 60001); 9 May 2010 13:43:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273412609; bh=TYYeKxOng2diqDzCLWpmZZog1vV0TTsJ9TGPeJZppVs=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=cOcBIVDVJqhIZLdBugfi4oqFyOmCqb1bnGq/NK5cGmwp7AVqx78z/IAhQZ+ieMduaKvYsKTtli2FkcHhP0k91IaT6fQksNidl8dsG/pSrL/3c5QLKd9URruXyPvIeyEkpzqAmx6sfNYi8IyX+WisjQXYTHQGTxxU7maBDr5QVJ4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=WqduifL1dxU8x4rSb6wLzQY2FgxRs/GrviiGy5xQQIQDT3yoYC4o2sbYXeHAmLeEpnQrn0Ka/005WxWPNsUi1J1/LFbQs7JpqRhYjgy1DkZPNUlIuFnD/rER665pzCVg08rDmOBnSlIJXxMHHk2KmmiqT5bid5GYFCoQUJolUME=; Message-ID: <473112.87657.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: BbyP8E4VM1kdICaQHL3giW6jTy2qMbQt4GbBg6uRXrhi3Al Uiu.0PoCHH6fJoinWEBSRBPRfLdwM6gtWdsLymuaCxqP21RJbOAikgKVdxdZ yWDPCrNLzronaRijo9qvuMW02WYoAZJhzEZrmleLflxJOaYczo9o.QzD9PL3 xtNRkcY50Zft9EEY55fW4h0E6Ripi6pylz.1ipVZrKosR4gqx1oPL_uLiLWo P_HtSGmmJRyEhL0MegjJ8fvsfQG5fhU6nB.vh_8p1yQvfoiEs6I.EmTgmLx4 Ij6E- Received: from [98.203.21.152] by web63906.mail.re1.yahoo.com via HTTP; Sun, 09 May 2010 06:43:29 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Sun, 9 May 2010 06:43:29 -0700 (PDT) From: Barney Cordoba To: Vincent Hoffman , Murat Balaban In-Reply-To: <1273323582.3304.31.camel@efe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org, grarpamp Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 13:43:30 -0000 --- On Sat, 5/8/10, Murat Balaban wrote: > From: Murat Balaban > Subject: Re: Intel 10Gb > To: "Vincent Hoffman" > Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org, "grarpamp" > Date: Saturday, May 8, 2010, 8:59 AM > > Much of the FreeBSD networking stack has been made parallel > in order to > cope with high packet rates at 10 Gig/sec operation. > > I've seen good numbers (near 10 Gig) in my tests involving > TCP/UDP > send/receive. (latest Intel driver). > > As far as BPF is concerned, above statement does not hold > true, > since there is some work that needs to be done here in > terms > of BPF locking and parallelism. My tests show that there > is a high lock contention around "bpf interface lock", > resulting > in input errors at high packet rates and with many bpf > devices. > > I belive GSoC 2010 project, Multiqueue BPF, is a milestone > for this: > http://www.freebsd.org/projects/ideas/ideas.html#p-multiqbpf > > I'm also working on this problem myself and will post a > diff whenever > I have something usable. > > > -- > Murat > http://www.enderunix.org/murat/ > > > > On Sat, 2010-05-08 at 10:01 +0100, Vincent Hoffman > > wrote: > > Looks a little like > > http://lists.freebsd.org/pipermail/svn-src-all/2010-May/023679.html > > but for intel. cool. > > > > Vince > > On 07/05/2010 23:01, grarpamp wrote: > > > Just wondering in general these days how close > FreeBSD is to > > > full 10Gb rates at various packet sizes from > minimum ethernet > > > frame to max jumbo 65k++. For things like BPF, > ipfw/pf, routing, > > > switching, etc. > > > http://www.ntop.org/blog/?p=86 > > > _______________________________________________ Blah, Blah, Blah. Let's see some real numbers on real networks under real loads. Until then, you've got nothing. BC From owner-freebsd-net@FreeBSD.ORG Sun May 9 17:12:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id E8B98106564A; Sun, 9 May 2010 17:12:27 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 493AC8FC13; Sun, 9 May 2010 17:12:26 +0000 (UTC) Received: by wwd20 with SMTP id 20so641885wwd.13 for ; Sun, 09 May 2010 10:12:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OK4RJYhBGfSrCwbocgcSFmwMkxfVYKRrfyPrwjNPYW8=; b=P5O2lGO0gxXKyc3KfwpQudgPDXcinGtZKPWLVdWh9a/Hz3TtUv9vcgsyJZ1Y+5+7P4 XAO0RWlPmD0XiEoqkZMyMRcdIMqUzMkWnCjjhWm7Cp0URbG/wI6iTIoe2wGFgJ0uH13U aINQ4AKoonYSlc7Jgvnk2Xm8DCOWEyrtBsttY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BbvfOvAycPJ1XspT8mFKlpN7qeR6hoQ1cMe5YJFQSS8hozmoNT2Dg9YGxbZ2LbTvGY JAd6s1bbSzxJvc0lXpixZ6sfgy95Pa8ne/zWMR2+aKxA8j0N4Wz0EfnGR96xn5M6TlQz 9rS20HY17n/Pa8AlUGZxgCOR2Dxh9B2NyK9KA= MIME-Version: 1.0 Received: by 10.216.87.68 with SMTP id x46mr1709896wee.145.1273425145932; Sun, 09 May 2010 10:12:25 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Sun, 9 May 2010 10:12:25 -0700 (PDT) In-Reply-To: <473112.87657.qm@web63906.mail.re1.yahoo.com> References: <1273323582.3304.31.camel@efe> <473112.87657.qm@web63906.mail.re1.yahoo.com> Date: Sun, 9 May 2010 10:12:25 -0700 Message-ID: From: Jack Vogel To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, grarpamp , Vincent Hoffman Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 17:12:28 -0000 On Sun, May 9, 2010 at 6:43 AM, Barney Cordoba wrote: > > > --- On Sat, 5/8/10, Murat Balaban wrote: > > > From: Murat Balaban > > Subject: Re: Intel 10Gb > > To: "Vincent Hoffman" > > Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org, "grarpamp" > > > Date: Saturday, May 8, 2010, 8:59 AM > > > > Much of the FreeBSD networking stack has been made parallel > > in order to > > cope with high packet rates at 10 Gig/sec operation. > > > > I've seen good numbers (near 10 Gig) in my tests involving > > TCP/UDP > > send/receive. (latest Intel driver). > > > > As far as BPF is concerned, above statement does not hold > > true, > > since there is some work that needs to be done here in > > terms > > of BPF locking and parallelism. My tests show that there > > is a high lock contention around "bpf interface lock", > > resulting > > in input errors at high packet rates and with many bpf > > devices. > > > > I belive GSoC 2010 project, Multiqueue BPF, is a milestone > > for this: > > http://www.freebsd.org/projects/ideas/ideas.html#p-multiqbpf > > > > I'm also working on this problem myself and will post a > > diff whenever > > I have something usable. > > > > > > -- > > Murat > > http://www.enderunix.org/murat/ > > > > > > > > On Sat, 2010-05-08 at 10:01 +0100, Vincent Hoffman > > > > wrote: > > > Looks a little like > > > http://lists.freebsd.org/pipermail/svn-src-all/2010-May/023679.html > > > but for intel. cool. > > > > > > Vince > > > On 07/05/2010 23:01, grarpamp wrote: > > > > Just wondering in general these days how close > > FreeBSD is to > > > > full 10Gb rates at various packet sizes from > > minimum ethernet > > > > frame to max jumbo 65k++. For things like BPF, > > ipfw/pf, routing, > > > > switching, etc. > > > > http://www.ntop.org/blog/?p=86 > > > > _______________________________________________ > > Blah, Blah, Blah. Let's see some real numbers on real networks under > real loads. Until then, you've got nothing. > > BC > > > Blah blah blah, you're one to talk, do you EVER do anything but criticize others? Nothing is right. Jack From owner-freebsd-net@FreeBSD.ORG Sun May 9 23:26:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C302106564A for ; Sun, 9 May 2010 23:26:38 +0000 (UTC) (envelope-from bms@incunabulum.net) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id F0B898FC0C for ; Sun, 9 May 2010 23:26:37 +0000 (UTC) Received: from compute1.internal (compute1.internal [10.202.2.41]) by gateway1.messagingengine.com (Postfix) with ESMTP id 4951DF545B for ; Sun, 9 May 2010 19:26:37 -0400 (EDT) Received: from heartbeat2.messagingengine.com ([10.202.2.161]) by compute1.internal (MEProxy); Sun, 09 May 2010 19:26:37 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=messagingengine.com; h=message-id:date:from:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding; s=smtpout; bh=f30PSYJenaAVbfJgqOlc4yDYhcM=; b=qClSSD1zVZj5d3U9vP6BI7ep1wOOtxaHvSFRntFE8Ycw+WnJDtnXLViWEYA6Nio163WdTcmumsS56QXkplR1pOwRQFJDA01tgd15v1eLoQRs8PxasEDoBt+LoQIIiGX9XGAUJ2I1c202l9+KiRgVyTsMgKimBe30fzJYzyM0+9E= X-Sasl-enc: fqjNlblVFvLgt39veB8COgnnb0YeHIxHn9UwxOxrDVW1 1273447594 Received: from anglepoise.lon.incunabulum.net (cpc2-dals7-0-0-cust253.hari.cable.virginmedia.com [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 019924C111 for ; Sun, 9 May 2010 19:26:33 -0400 (EDT) Message-ID: <4BE744A8.80301@incunabulum.net> Date: Mon, 10 May 2010 00:26:32 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.1.9) Gecko/20100425 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <473112.87657.qm@web63906.mail.re1.yahoo.com> In-Reply-To: <473112.87657.qm@web63906.mail.re1.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2010 23:26:38 -0000 On 05/09/10 14:43, Barney Cordoba wrote: > > Blah, Blah, Blah. Let's see some real numbers on real networks under > real loads. Until then, you've got nothing. > But that's also blah blah on your part, Barney. As long as the peak throughput under load in testing is above the median range for the kind of traffic you intend (which your grossly general statement omits to describe), it's fine. Otherwise, why not offer to help test Murat's patches-- instead of dissing him on a public mailing list? To share, or to shaft... From owner-freebsd-net@FreeBSD.ORG Mon May 10 04:12:15 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F2A0E1065676; Mon, 10 May 2010 04:12:15 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id C942F8FC13; Mon, 10 May 2010 04:12:15 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4A4CFaM090260; Mon, 10 May 2010 04:12:15 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4A4CFK0090256; Mon, 10 May 2010 04:12:15 GMT (envelope-from linimon) Date: Mon, 10 May 2010 04:12:15 GMT Message-Id: <201005100412.o4A4CFK0090256@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-i386@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146263: [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/if_addmulti when adding many IPv6 aliases X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 04:12:16 -0000 Old Synopsis: Panic in em(4) SIOCADDMULTI/em_set_multi/if_addmulti when adding many IPv6 aliases New Synopsis: [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/if_addmulti when adding many IPv6 aliases Responsible-Changed-From-To: freebsd-i386->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 10 04:11:56 UTC 2010 Responsible-Changed-Why: This is probably not machine-specific. http://www.freebsd.org/cgi/query-pr.cgi?pr=146263 From owner-freebsd-net@FreeBSD.ORG Mon May 10 04:15:52 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 66CAE1065672; Mon, 10 May 2010 04:15:52 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3DEFB8FC0C; Mon, 10 May 2010 04:15:52 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4A4FpJS091567; Mon, 10 May 2010 04:15:51 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4A4Fp3G091563; Mon, 10 May 2010 04:15:51 GMT (envelope-from linimon) Date: Mon, 10 May 2010 04:15:51 GMT Message-Id: <201005100415.o4A4Fp3G091563@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146427: [mwl] Additional virtual access points don't work on mwl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 04:15:52 -0000 Old Synopsis: Additional virtual access points don't work on mwl New Synopsis: [mwl] Additional virtual access points don't work on mwl Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 10 04:15:28 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146427 From owner-freebsd-net@FreeBSD.ORG Mon May 10 04:17:01 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9EC851065670; Mon, 10 May 2010 04:17:01 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 763378FC12; Mon, 10 May 2010 04:17:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4A4H19w091636; Mon, 10 May 2010 04:17:01 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4A4H1KU091632; Mon, 10 May 2010 04:17:01 GMT (envelope-from linimon) Date: Mon, 10 May 2010 04:17:01 GMT Message-Id: <201005100417.o4A4H1KU091632@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146426: [mwl] 802.11n rates not possible on mwl X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 04:17:01 -0000 Old Synopsis: 802.11n rates not possible on mwl New Synopsis: [mwl] 802.11n rates not possible on mwl Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 10 04:16:47 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146426 From owner-freebsd-net@FreeBSD.ORG Mon May 10 04:17:20 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1748D106564A; Mon, 10 May 2010 04:17:20 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id E2A338FC14; Mon, 10 May 2010 04:17:19 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4A4HJbr091683; Mon, 10 May 2010 04:17:19 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4A4HJJN091679; Mon, 10 May 2010 04:17:19 GMT (envelope-from linimon) Date: Mon, 10 May 2010 04:17:19 GMT Message-Id: <201005100417.o4A4HJJN091679@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146425: [mwl] mwl dropping all packets during and after high usage on 802.11n X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 04:17:20 -0000 Old Synopsis: mwl dropping all packets during and after high usage on 802.11n New Synopsis: [mwl] mwl dropping all packets during and after high usage on 802.11n Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon May 10 04:17:06 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146425 From owner-freebsd-net@FreeBSD.ORG Mon May 10 11:07:02 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 9F0EA1065672 for ; Mon, 10 May 2010 11:07:02 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8CB9F8FC20 for ; Mon, 10 May 2010 11:07:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AB72RO082153 for ; Mon, 10 May 2010 11:07:02 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AB71Ta082151 for freebsd-net@FreeBSD.org; Mon, 10 May 2010 11:07:01 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 10 May 2010 11:07:01 GMT Message-Id: <201005101107.o4AB71Ta082151@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 11:07:02 -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/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146263 net [em] [panic] Panic in em(4) SIOCADDMULTI/em_set_multi/ o kern/146250 net [netinet] [patch] Races on interface alias removal 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/145918 net [ae] After spontaneous ae0 "watchdog timeout", "stray o kern/145826 net [ath] Unable to configure adhoc mode on ath0/wlan0 o kern/145825 net [panic] panic: soabort: so_count o kern/145777 net [wpi] Intel 3945ABG driver breaks the connection after o kern/145728 net [lagg] Stops working lagg between two servers. o kern/145621 net [bge] [panic] bge watchdog timeout --resetting -> cras o kern/145462 net [netgraph] [patch] panic kernel when ng_ipfw send ip p o kern/144987 net [wpi] [panic] injecting packets with wlaninject using o kern/144898 net [wpi] [panic] wpi panics system 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 kern/144777 net [arp] proxyarp broken in 8.0 [regression] o kern/144755 net [iwi] [panic] iwi panic when issuing /etc/rc.d/netif r o kern/144724 net [bwn] if_bwn does not pass traffic when in PIO mode o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144680 net [em] em(4) problem with dual-port adapter o kern/144642 net [rum] [panic] Enabling rum interface causes panic o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 o kern/144572 net [carp] CARP preemption mode traffic partially goes to o kern/144561 net [ixgbe] [patch] ixgbe driver errors o kern/144529 net [sctp] sctp over ipv6 appears to not calculate checksu o kern/144505 net [bwn] [patch] Error in macro CALC_COEFF2. o kern/144494 net [ixgbe] ixgbe driver not built as module f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144206 net Marvell Yukon NIC not working under FreeBSD o kern/144000 net [tcp] setting TCP_MAXSEG by setsockopt() does not seem o kern/143939 net [ipfw] [em] ipfw nat and em interface rxcsum problem o kern/143874 net [wpi] Wireless 3945ABG error. wpi0 could not allocate o kern/143868 net [ath] [patch] allow Atheros watchdog timeout to be tun 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/143595 net [wpi] [panic] Creating virtual interface over wpi0 in 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/143573 net [em] em(4) NIC crashes intermittently o kern/143285 net [em] [regression] jumbo frames broken in 8.0 o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o conf/143079 net hostapd(8) startup missing multi wlan functionality o kern/143074 net [wi]: wi driver triggers panic o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142907 net [wpi] if_wpi unstable on ibm/lenovo x60 -- suspect fir o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142766 net [ipw] [regression] ipw(4) with Intel PRO/wireless 2100 o kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142019 net [em] em needs "ifconfig em0 down up" when link was gon 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 o kern/141843 net [em] [vlan] Intel txcsum and assigned vlan invoke wron o kern/141777 net [rum] [patch] Support usbdevs / rum(4) for Buffalo WLI f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/141720 net [sctp] [lor] [hang] sctp-create vs. sctp-it causes sys o kern/141698 net [sctp] [panic] Own lock on stcb at return from input o kern/141697 net [sctp] [panic] lock (sleep mutex) sctp-tcb not locked o kern/141696 net [rum] [panic] rum(4)+ vimage = kernel panic o kern/141695 net [sctp] [panic] kernel page fault with non-sleepable lo o kern/141314 net Network Performance has decreased by 30% [regression] o kern/141285 net [em] hangs down/up intel nic during creating vlan o kern/141023 net [carp] CARP arp replays with wrong src mac o kern/140796 net [ath] [panic] privileged instruction fault o kern/140778 net [em] randomly panic in vlan/em o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140728 net [em] [patch] Fast irq registration in em driver o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140647 net [em] [patch] e1000 driver does not correctly handle mu o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140597 net [netinet] [patch] implement Lost Retransmission Detect o kern/140567 net [ath] [patch] ath is not worked on my notebook PC o kern/140564 net [wpi] Problem with Intel(R) PRO/Wireless 3945ABG o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140326 net [em] em0: watchdog timeout when communicating to windo o kern/140245 net [ath] [panic] Kernel panic during network activity on 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/140051 net [bce] [arp] ARP not sent through Bridge Firewall with 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 o kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139162 net [fwip] [panic] 8.0-RC1 panics if using IP over firewir o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139079 net [wpi] Failure to attach wpi(4) 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/138739 net [wpi] wpi(4) does not work very well under 8.0-BETA4 o kern/138694 net [bge] FreeBSD 6.3 release does not recognize Broadcom o amd64/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/138660 net [igb] igb driver troubles in 8.0-BETA4 o kern/138652 net [tcp] TCP window scaling value calculated incorrectly? o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138427 net [wpi] [panic] Kernel panic after trying set monitor wl o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 o kern/138046 net [tcp] tcp sockets stay in SYN_SENT even after receivin o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 o bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137795 net [sctp] [panic] mtx_lock() of destroyed mutex o kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o kern/137775 net [netgraph] [patch] Add XMIT_FAILOVER to ng_one2many o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137592 net [ath] panic - 7-STABLE (Aug 7, 2009 UTC) crashes on ne o bin/137484 net [patch] Integer overflow in wpa_supplicant(8) base64 e 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/137317 net [tcp] logs full of syncache problems o kern/137279 net [bge] [panic] Page fault (fatal trap 12) NFS server w/ 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/136943 net [wpi] [lor] wpi0_com_lock / wpi0 o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136876 net [bge] bge will not resume properly after suspend o kern/136836 net [ath] atheros card stops functioning after about 12 ho o bin/136661 net [patch] ndp(8) ignores -f option o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/136426 net [panic] spawning several dhclients in parallel panics o kern/136168 net [em] em driver initialization fails on Intel 5000PSL m o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/135222 net [igb] low speed routing between two igb interfaces o kern/134956 net [em] FreeBSD 7.1 & 7.2, Intel PRO/1000 PT Quad Port Se o kern/134931 net [route] Route messages sent to all socket listeners re o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134401 net [msk] [panic] Kernel Fatal trap 12: page fault while i o kern/134168 net [ral] ral driver problem on RT2525 2.4GHz transceiver o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/134079 net [em] "em0: Invalid MAC address" in FreeBSD-Current ( 8 o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133902 net [tun] Killing tun0 iface ssh tunnel causes Panic Strin o kern/133786 net [netinet] [patch] ip_input might cause kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133613 net [wpi] [panic] kernel panic in wpi(4) 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/133328 net [bge] [panic] Kernel panics with Windows7 client o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre o kern/133218 net [carp] [hang] use of carp(4) causes system to freeze f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133204 net [msk] msk driver timeouts o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs f bin/132911 net ip6fw(8): argument type of fill_icmptypes is wrong and o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o kern/132885 net [wlan] 802.1x broken after SVN rev 189592 o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132832 net [netinet] [patch] tcp_output() might generate invalid o bin/132798 net [patch] ggatec(8): ggated/ggatec connection slowdown p o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132722 net [ath] Wifi ath0 associates fine with AP, but DHCP or I 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/132669 net [xl] 3c905-TX send DUP! in reply on ping (sometime) o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132285 net [carp] alias gives incorrect hash in dmesg o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/132107 net [carp] carp(4) advskew setting ignored when carp IP us o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o kern/131549 net ifconfig(8) can't clear 'monitor' mode on the wireless o kern/131536 net [netinet] [patch] kernel does allow manipulation of su o bin/131365 net route(8): route add changes interpretation of network o kern/131153 net [iwi] iwi doesn't see a wireless network f kern/131087 net [ipw] [panic] ipw / iwi - no sent/received packets; iw 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 o kern/129750 net [ath] Atheros AR5006 exits on "cannot map register spa f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow o kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129352 net [xl] [patch] xl0 watchdog timeout 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 kern/128917 net [wpi] [panic] if_wpi and wpa+tkip causing kernel panic o kern/128840 net [igb] page fault under load with igb/LRO o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o conf/128334 net [request] use wpa_cli in the "WPA DHCP" situation o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127928 net [tcp] [patch] TCP bandwidth gets squeezed every time t o kern/127834 net [ixgbe] [patch] wrong error counting 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 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/127102 net [wpi] Intel 3945ABG low throughput o kern/127057 net [udp] Unable to send UDP packet via IPv6 socket to IPv o kern/127050 net [carp] ipv6 does not work on carp interfaces [regressi o kern/126945 net [carp] CARP interface destruction with ifconfig destro o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126714 net [carp] CARP interface renaming makes system no longer o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126688 net [ixgbe] [patch] 1.4.7 ixgbe driver panic with 4GB and o kern/126475 net [ath] [panic] ath pcmcia card inevitably panics under o kern/126339 net [ipw] ipw driver drops the connection o kern/126214 net [ath] txpower problem with Atheros wifi card o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125816 net [carp] [if_bridge] carp stuck in init when using bridg f kern/125502 net [ral] ifconfig ral0 scan produces no output unless in 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/124767 net [iwi] Wireless connection using iwi0 driver (Intel 220 o kern/124753 net [ieee80211] net80211 discards power-save queue packets 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. p kern/123961 net [vr] [patch] Allow vr interface to handle vlans 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 bin/123633 net ifconfig(8) doesn't set inet and ether address in one f kern/123617 net [tcp] breaking connection when client downloading file o kern/123603 net [tcp] tcp_do_segment and Received duplicate SYN 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 kern/123429 net [nfe] [hang] "ifconfig nfe up" causes a hard system lo o kern/123347 net [bge] bge1: watchdog timeout -- linkstate changed to D o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123256 net [wpi] panic: blockable sleep lock with wpi(4) f kern/123172 net [bce] Watchdog timeout problems with if_bce 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 o kern/122928 net [em] interface watchdog timeouts and stops receiving p f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122772 net [em] em0 taskq panic, tcp reassembly bug causes radix o kern/122743 net [mbuf] [panic] vm_page_unwire: invalid wire count: 0 o kern/122697 net [ath] Atheros card is not well supported 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/122195 net [ed] Alignment problems in if_ed o kern/122058 net [em] [panic] Panic on em1: taskq 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 o kern/121872 net [wpi] driver fails to attach on a fujitsu-siemens s711 s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121706 net [netinet] [patch] "rtfree: 0xc4383870 has 1 refs" emit o kern/121624 net [em] [regression] Intel em WOL fails after upgrade to 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/121298 net [em] [panic] Fatal trap 12: page fault while in kernel 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/121080 net [bge] IPv6 NUD problem on multi address config on bge0 o kern/120966 net [rum] kernel panic with if_rum and WPA encryption p docs/120945 net [patch] ip6(4) man page lacks documentation for TCLASS o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o kern/120232 net [nfe] [patch] Bring in nfe(4) to RELENG_6 o kern/120130 net [carp] [panic] carp causes kernel panics in any conste o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr a kern/118879 net [bge] [patch] bge has checksum problems on the 5703 ch o kern/118727 net [netgraph] [patch] [request] add new ng_pf module a kern/118238 net [bce] [patch] bce driver shows "no carrier" on Intel S s kern/117717 net [panic] Kernel panic with Bittorrent client. o kern/117448 net [carp] 6.2 kernel crash [regression] o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o kern/117043 net [em] Intel PWLA8492MT Dual-Port Network adapter EEPROM o kern/116747 net [ndis] FreeBSD 7.0-CURRENT crash with Dell TrueMobile 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/113895 net [xl] xl0 fails on 6.2-RELEASE but worked fine on 5.5-R 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 kern/112570 net [bge] packet loss with bge driver on BCM5704 chipset 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/111457 net [ral] ral(4) freeze o kern/110140 net [ipw] ipw fails under load o kern/109733 net [bge] bge link state issues [regression] o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o kern/109308 net [pppd] [panic] Multiple panics kernel ppp suspected [r o kern/109251 net [re] [patch] if_re cardbus card won't attach o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/108542 net [bce] Huge network latencies with 6.2-RELEASE / STABLE o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o kern/107850 net [bce] bce driver link negotiation is faulty o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/106243 net [nve] double fault panic in if_nve.c on high loads 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/105348 net [ath] ath device stopps TX 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/104485 net [bge] Broadcom BCM5704C: Intermittent on newer chip ve 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 f bin/97392 net ppp(8) hangs instead terminating o kern/97306 net [netgraph] NG_L2TP locks after connection with failed f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/96030 net [bfe] [patch] Install hangs with Broadcomm 440x NIC in 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 s kern/94863 net [bge] [patch] hack to get bge(4) working on IBM e326m o kern/94162 net [bge] 6.x kenel stale with bge(4) o kern/93886 net [ath] Atheros/D-Link DWL-G650 long delay to associate 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 f kern/92552 net A serious bug in most network drivers from 5.X to 6.X s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/92090 net [bge] bge0: watchdog timeout -- resetting 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/91594 net [em] FreeBSD > 5.4 w/ACPI fails to detect Intel Pro/10 o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/90890 net [vr] Problems with network: vr0: tx shutdown timeout s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if f kern/88082 net [ath] [panic] cts protection for ath0 causes panic o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87506 net [vr] [patch] Fix alias support on vr interfaces o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/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 o kern/84202 net [ed] [patch] Holtek HT80232 PCI NIC recognition on Fre 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 bin/82185 net [patch] ndp(8) can delete the incorrect entry s kern/81147 net [net] [patch] em0 reinitialization while adding aliase o kern/80853 net [ed] [patch] add support for Compex RL2000/ISA in PnP o kern/79895 net [ipf] 5.4-RC2 breaks ipfilter NAT when using netgraph f kern/79262 net [dc] Adaptec ANA-6922 not fully supported o bin/79228 net [patch] extend arp(8) to be able to create blackhole r o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if p kern/77913 net [wi] [patch] Add the APDL-325 WLAN pccard to wi(4) o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time f kern/73538 net [bge] problem with the Broadcom BCM5788 Gigabit Ethern 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/66225 net [netgraph] [patch] extend ng_eiface(4) control message s kern/60293 net [patch] FreeBSD arp poison patch o kern/54383 net [nfs] [patch] NFS root configurations without dynamic f i386/45773 net [bge] Softboot causes autoconf failure on Broadcom 570 s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/35442 net [sis] [patch] Problem transmitting runts in if_sis dri o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". 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 o conf/23063 net [arp] [patch] for static ARP tables in rc.network 422 problems total. From owner-freebsd-net@FreeBSD.ORG Mon May 10 14:10:05 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id B1A281065672 for ; Mon, 10 May 2010 14:10:05 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 8755C8FC13 for ; Mon, 10 May 2010 14:10:05 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4AEA5mq042788 for ; Mon, 10 May 2010 14:10:05 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4AEA5JX042787; Mon, 10 May 2010 14:10:05 GMT (envelope-from gnats) Date: Mon, 10 May 2010 14:10:05 GMT Message-Id: <201005101410.o4AEA5JX042787@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: John Bayly Cc: Subject: Re: bin/146377: [ppp] [tun] Interface doesn't clear addresses when PPPoE connection closes X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Bayly List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 14:10:05 -0000 The following reply was made to PR bin/146377; it has been noted by GNATS. From: John Bayly To: bug-followup@FreeBSD.org, john.bayly@tipstrade.net Cc: Subject: Re: bin/146377: [ppp] [tun] Interface doesn't clear addresses when PPPoE connection closes Date: Mon, 10 May 2010 14:49:04 +0100 This is a multi-part message in MIME format. --------------090209090702000507070503 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Having had a good look at the source over the weekend (Spanish Grand Prix was dull as ever), I've seen that my suggestion of putting a call to iface_Clear somewhere in bundle_close was a tad off the mark. Noticing that the calls to iface_Add & iface_Clear appear to come from ipcp & ipv6cp (makes sense really) it's clear that the call to clear the interface's addresses should come from there too. Also, the call to clear should be made at the last possible moment, to make sure that connection is definitely closed, so I add the call in the LayerFinish method for both ipcp & ipv6cp. I've attached diffs for both files. I've tested the patched version, and by calling close in interactive mode, and by disconnecting the phone cable (so that the connection will drop after 5 LCP echoes are lost) I now have the desired effect of the addresses being cleared from the interface. I'm going to run with this patched version as I can't see how this could cause any catastrophic issues. Would this be an acceptable solution for future releases? John --------------090209090702000507070503 Content-Type: text/plain; name="ipcp.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipcp.c.diff" LS0tIGlwY3AuYy5vcmlnIDIwMTAtMDUtMTAgMTM6Mjc6MjIuMDAwMDAwMDAwICswMTAwDQor KysgaXBjcC5jICAgICAgMjAxMC0wNS0xMCAxMzo0MjoyMy4wMDAwMDAwMDAgKzAxMDANCkBA IC0yNSw3ICsyNSw3IEBADQogICogT1VUIE9GIFRIRSBVU0UgT0YgVEhJUyBTT0ZUV0FSRSwg RVZFTiBJRiBBRFZJU0VEIE9GIFRIRSBQT1NTSUJJTElUWSBPRg0KICAqIFNVQ0ggREFNQUdF Lg0KICAqDQotICogJEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9wcHAvaXBjcC5jLHYgMS4xMjMu MjAuMSAyMDA5LzA0LzE1IDAzOjE0OjI2IGtlbnNtaXRoIEV4cCAkDQorICogJEZyZWVCU0Q6 IHNyYy91c3Iuc2Jpbi9wcHAvaXBjcC5jLHYgMS4xMjMuMjAuMS4xIDIwMTAvMDUvMTAgMTM6 NDM6MDAgam9obmJheWx5IEV4cCAkDQogICovDQoNCiAjaW5jbHVkZSA8c3lzL3BhcmFtLmg+ DQpAQCAtODI5LDYgKzgyOSwxMCBAQA0KICAgLyogV2UncmUgbm93IGRvd24gKi8NCiAgIHN0 cnVjdCBpcGNwICppcGNwID0gZnNtMmlwY3AoZnApOw0KDQorICAvKiBDbGVhciBhbGwgYWRk cmVzc2VzIGZyb20gdGhlIGludGVyZmFjZSAqLw0KKyAgaWZhY2VfQ2xlYXIoZnAtPmJ1bmRs ZS0+aWZhY2UsICZmcC0+YnVuZGxlLT5uY3AsIEFGX0lORVQsDQorICAgICAgICAgICAgICAg ICAgIElGQUNFX0NMRUFSX0FMTCk7DQorDQogICBsb2dfUHJpbnRmKExvZ0lQQ1AsICIlczog TGF5ZXJGaW5pc2guXG4iLCBmcC0+bGluay0+bmFtZSk7DQogICB0aHJvdWdocHV0X3N0b3Ao JmlwY3AtPnRocm91Z2hwdXQpOw0KICAgdGhyb3VnaHB1dF9sb2coJmlwY3AtPnRocm91Z2hw dXQsIExvZ0lQQ1AsIE5VTEwpOw== --------------090209090702000507070503 Content-Type: text/plain; name="ipv6cp.c.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipv6cp.c.diff" LS0tIGlwdjZjcC5jLm9yaWcgICAgICAgMjAxMC0wNS0xMCAxMzoyOTo0OC4wMDAwMDAwMDAg KzAxMDANCisrKyBpcHY2Y3AuYyAgICAyMDEwLTA1LTEwIDEzOjQzOjA5LjAwMDAwMDAwMCAr MDEwMA0KQEAgLTIzLDcgKzIzLDcgQEANCiAgKiBPVVQgT0YgVEhFIFVTRSBPRiBUSElTIFNP RlRXQVJFLCBFVkVOIElGIEFEVklTRUQgT0YgVEhFIFBPU1NJQklMSVRZIE9GDQogICogU1VD SCBEQU1BR0UuDQogICoNCi0gKiAkRnJlZUJTRDogc3JjL3Vzci5zYmluL3BwcC9pcHY2Y3Au Yyx2IDEuMTcuMjAuMSAyMDA5LzA0LzE1IDAzOjE0OjI2IGtlbnNtaXRoIEV4cCAkDQorICog JEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi9wcHAvaXB2NmNwLmMsdiAxLjE3LjIwLjEuMSAyMDEw LzA1LzEwIDEzOjQzOjAwIGpvaG5iYXlseSBFeHAgJA0KICAqLw0KDQogI2luY2x1ZGUgPHN5 cy9wYXJhbS5oPg0KQEAgLTU4Niw2ICs1ODYsMTAgQEANCiAgIC8qIFdlJ3JlIG5vdyBkb3du ICovDQogICBzdHJ1Y3QgaXB2NmNwICppcHY2Y3AgPSBmc20yaXB2NmNwKGZwKTsNCg0KKyAg LyogQ2xlYXIgYWxsIGFkZHJlc3NlcyBmcm9tIHRoZSBpbnRlcmZhY2UgKi8NCisgIGlmYWNl X0NsZWFyKGZwLT5idW5kbGUtPmlmYWNlLCAmZnAtPmJ1bmRsZS0+bmNwLCBBRl9JTkVUNiwN CisgICAgICAgICAgICAgICAgICAgSUZBQ0VfQ0xFQVJfQUxMKTsNCisNCiAgIGxvZ19Qcmlu dGYoTG9nSVBWNkNQLCAiJXM6IExheWVyRmluaXNoLlxuIiwgZnAtPmxpbmstPm5hbWUpOw0K ICAgdGhyb3VnaHB1dF9zdG9wKCZpcHY2Y3AtPnRocm91Z2hwdXQpOw0KICAgdGhyb3VnaHB1 dF9sb2coJmlwdjZjcC0+dGhyb3VnaHB1dCwgTG9nSVBWNkNQLCBOVUxMKTs= --------------090209090702000507070503-- From owner-freebsd-net@FreeBSD.ORG Mon May 10 18:13:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1CBEE1065675; Mon, 10 May 2010 18:13:10 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7371C8FC0A; Mon, 10 May 2010 18:13:09 +0000 (UTC) Received: by wyb32 with SMTP id 32so340557wyb.13 for ; Mon, 10 May 2010 11:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=B6dVSIcrdGPjT3xA6JyMnMlp7OCkWpMOcAz9r+SZfrQ=; b=nqhFkSLznRv90rJTGJ9VzgiKBRBnjokqp6JcCKso/l2gQltPNg08cCqDfskIVYlcmy kz7eynlE8Ju80DdBzBC+uxWqVciC1bAYDOdjErY3DIaHoKGTFBD7Zfg5Ggo5UVVKpmWE zab5deCUz+b4y0LD5XJy3cWipiae61QqvgeZE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=m4PAv6/SW09NE5F0KnrVLvaAm8fpFIr0cZzHFlQsr4EgkHMJkVDJvrZ2AQ9/Vkqd1N k3T428Xa7lAgyhRfQiN4pd7qz3X/ffdZqkz2Nkw+T8LBPz1TTjCmY5oi1eRT+h74YTqq gBs6/ayISI+XmPuxmmQ7bD9MWz5Ws8huZZGKE= Received: by 10.216.85.143 with SMTP id u15mr2679300wee.205.1273515188156; Mon, 10 May 2010 11:13:08 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.216.86.137 with HTTP; Mon, 10 May 2010 11:12:48 -0700 (PDT) In-Reply-To: <4BE82011.6050009@cs.duke.edu> References: <4BD885C6.10600@FreeBSD.org> <20100429204544.GC1286@arthur.nitro.dk> <1272998683.2406.38.camel@localhost.localdomain> <20100504190328.GC31196@valentine.liquidneon.com> <4BE80F07.8090309@cs.duke.edu> <4BE82011.6050009@cs.duke.edu> From: Ivan Voras Date: Mon, 10 May 2010 20:12:48 +0200 X-Google-Sender-Auth: EoIhzMjkOhcUL1qUaIXZRaX2j5c Message-ID: To: Andrew Gallatin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org, developers@freebsd.org Subject: Re: FreeBSD.org IPv6 issue - AAAA records disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 18:13:10 -0000 On 10 May 2010 17:02, Andrew Gallatin wrote: > Ivan Voras wrote: > In the case of 143046, he says that disabling IPv6 support in his > jails solved the problem. =C2=A0He also saw the panic:sbdrop, as well > as some others which makes it seem like something is holding a > pointer to a free mbuf and modifying it behind the back of the > new owner. =C2=A0He saw this most often: > > Tracing pid 12 tid 100063 td 0xffffff00092c7390 > mb_free_ext() at mb_free_ext+0x15 > m_freem() at m_freem+0x23 > ether_input() at ether_input+0x56 > mxge_intr() at mxge_intr+0x5b2 > intr_event_execute_handlers() at intr_event_execute_handlers+0x132 > ithread_loop() at ithread_loop+0x7d > fork_exit() at fork_exit+0x121 > fork_trampoline() at fork_trampoline+0xe > > This is coming from the "discard frame w/o packet header" > codepath in ether_input. =C2=A0With the way I stock my rings, > this is impossible unless something else is scribbling on > my mbufs. I have a different trace but the dmesg buffer on crashed machines usually contains the message "em0: discard frame w/o packet header" just before the panic so this still looks like it. Here are my most usual traces: #1 0xffffffff8058d179 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff8058d5ac in panic ( fmt=3D0xffffffff80971c38 "%s: sockbuf %p and mbuf %p clashing") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff805ea6d4 in sbsndptr (sb=3DNA) at /usr/src/sys/kern/uipc_sockbuf.c:954 #4 0xffffffff806ff812 in tcp_output (tp=3D0xffffff0001ae46e0) at /usr/src/sys/netinet/tcp_output.c:814 #5 0xffffffff8070c274 in tcp_usr_send (so=3D0xffffff0001f7ed48, flags=3D0,= m=3DNA) at tcp_offload.h:282 #6 0xffffffff805f05b6 in sosend_generic (so=3D0xffffff0001f7ed48, addr=3D0= x0, uio=3D0x0, top=3D0xffffff0001909c00, control=3D0x0, flags=3DNA) at /usr/src/sys/kern/uipc_socket.c:1256 #7 0xffffffff8077c93f in svc_vc_reply (xprt=3D0xffffff00018ba000, msg=3DNA= ) at /usr/src/sys/rpc/svc_vc.c:732 #8 0xffffffff8077851a in svc_sendreply_common (rqstp=3D0xffffff00425f2800, rply=3D0xffffff8070811990, body=3D0xffffff006c70f000) at /usr/src/sys/rpc/svc.c:538 #9 0xffffffff807793b9 in svc_sendreply_mbuf (NA) at /usr/src/sys/rpc/svc.c:594 #10 0xffffffff80760669 in nfssvc_program (rqst=3D0xffffff00425f2800, xprt= =3DNA) at /usr/src/sys/nfsserver/nfs_srvkrpc.c:371 #11 0xffffffff80778f42 in svc_run_internal (pool=3D0xffffff00016cea00, ismaster=3D0) at /usr/src/sys/rpc/svc.c:893 #12 0xffffffff807792bb in svc_thread_start (arg=3DNA) at /usr/src/sys/rpc/svc.c:1198 #13 0xffffffff80564b78 in fork_exit ( callout=3D0xffffffff807792b0 , arg=3D0xffffff00016cea= 00, frame=3D0xffffff8070811c80) at /usr/src/sys/kern/kern_fork.c:843 #14 0xffffffff808594ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 (Note: NFS, for what it's worth) And: #1 0xffffffff805a2a69 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xffffffff805a2e9c in panic (fmt=3D0xffffffff8098f15f "sbdrop") at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xffffffff80603a53 in sbdrop_internal (sb=3DNA) at /usr/src/sys/kern/uipc_sockbuf.c:858 #4 0xffffffff80710ae7 in tcp_do_segment (m=3D0xffffff0001941500, th=3D0xffffff000194157c, so=3D0xffffff0032efaaa0, tp=3D0xffffff00ddc7f0= 00, drop_hdrlen=3D52, tlen=3D14, iptos=3D0 '\0', ti_locked=3D2) at /usr/src/sys/netinet/tcp_input.c:2355 #5 0xffffffff807128d2 in tcp_input (m=3D0xffffff0001941500, off0=3DNA) at /usr/src/sys/netinet/tcp_input.c:1020 #6 0xffffffff806ae23a in ip_input (m=3D0xffffff0001941500) at /usr/src/sys/netinet/ip_input.c:804 #7 0xffffffff8065b30d in swi_net (arg=3DNA) at /usr/src/sys/net/netisr.c:7= 16 #8 0xffffffff8057bf8d in intr_event_execute_handlers (p=3DNA) at /usr/src/sys/kern/kern_intr.c:1220 #9 0xffffffff8057d63e in ithread_loop (arg=3D0xffffff00014b66c0) at /usr/src/sys/kern/kern_intr.c:1233 #10 0xffffffff80579f58 in fork_exit ( callout=3D0xffffffff8057d5b0 , arg=3D0xffffff00014b66c0, frame=3D0xffffff8000044c80) at /usr/src/sys/kern/kern_fork.c:843 #11 0xffffffff8086f3ae in fork_trampoline () at /usr/src/sys/amd64/amd64/exception.S:561 #12 0x0000000000000000 in ?? () (Looks like a regular input path) > I think something may be holding onto an mbuf after free, > then re-freeing it. =C2=A0But only after somebody else allocated > it. =C2=A0 I was hoping that the mbuf double free referenced > above was the smoking gun, but it turns out that there isn't > even a bge interface in my pr (just bce and mxge). Since I have an em it looks interface-agnostic. Also, moving this to freebsd-net@. From owner-freebsd-net@FreeBSD.ORG Mon May 10 19:35:44 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DCA7B1065673 for ; Mon, 10 May 2010 19:35:44 +0000 (UTC) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AE0CE8FC12 for ; Mon, 10 May 2010 19:35:44 +0000 (UTC) Received: from [172.24.98.37] ([192.75.139.252]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id o4AJ7lJw057724 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 10 May 2010 12:07:49 -0700 (PDT) (envelope-from sam@errno.com) Message-Id: From: Sam Leffler To: Luigi Rizzo In-Reply-To: <20100420215527.GA75324@onelab2.iet.unipi.it> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 10 May 2010 15:07:46 -0400 References: <20100420172845.GA71187@onelab2.iet.unipi.it> <20100420215527.GA75324@onelab2.iet.unipi.it> X-Mailer: Apple Mail (2.936) X-DCC-x.dcc-servers-Metrics: ebb.errno.com; whitelist Cc: net@freebsd.org Subject: Re: max_linkhdr defaults to 16, too short ? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 19:35:44 -0000 On Apr 20, 2010, at 5:55 PM, Luigi Rizzo wrote: > On Tue, Apr 20, 2010 at 07:28:45PM +0200, Luigi Rizzo wrote: >> just noticed that sys/kern/uipc_domain.c still sets max_linkhdr=16 >> as a default. >> The value is often used to reserve head space in mbufs for >> the MAC header. As such, 16 is too short for systems that make >> use of vlans, and the effect might be that we would need >> additional mbuf entries or at least move stuff down >> as the vlan tag is added. >> >> Any objection to bumping the default to 20 ? > > forgot to mention: > > max_linkhdr is available as a sysctl, kern.max_linkhdr , but other > than that, there is no code in sys/ that sets the value, so systems > are stuck at 16 unless users override the default. We need a coherent way to handle max_linkhdr. I hacked it in net80211 to insure bridged 802.11 frames have sufficient contiguous space in the mbufs but never did something like define an api and generate events/callbacks on changes. Last I looked doing this right was non- trivial. Sam From owner-freebsd-net@FreeBSD.ORG Mon May 10 20:49:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id AF5051065670 for ; Mon, 10 May 2010 20:49:25 +0000 (UTC) (envelope-from ml@netfence.it) Received: from cp-out8.libero.it (cp-out8.libero.it [212.52.84.108]) by mx1.freebsd.org (Postfix) with ESMTP id 17CA68FC0A for ; Mon, 10 May 2010 20:49:24 +0000 (UTC) Received: from soth.ventu (151.51.8.163) by cp-out8.libero.it (8.5.107) id 4BDF0CE30136902E for freebsd-net@freebsd.org; Mon, 10 May 2010 22:49:23 +0200 Received: from alamar.ventu (alamar.ventu [10.1.2.18]) by soth.ventu (8.14.4/8.14.3) with ESMTP id o4AKnHHv005329 for ; Mon, 10 May 2010 22:49:17 +0200 (CEST) (envelope-from ml@netfence.it) Message-ID: <4BE8714D.8080608@netfence.it> Date: Mon, 10 May 2010 22:49:17 +0200 From: Andrea Venturoli User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; it-IT; rv:1.9.1.9) Gecko/20100402 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Warnings with TSO on em X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 May 2010 20:49:25 -0000 Hello. For quite a while, I've been seeing in the logs a lot of messages like the following: snort: (snort_decoder) WARNING: IP dgm len < IP Hdr len! I'm not sure about this, but I suspect they started when I upgraded from 6.3 to 7.2. Today, while investigating another problem, I decided I had to move this out of the way; tcpdump showed zero-length IP packets and Google told me they might be the result of TSO on the em cards. So I checked and, yes, I had TSO enabled (by default). "ifconfig em0 -tso" made this noise go away. Now I'm looking for some more insight: if it's only a performance problem, I don't think I'll be hit, but could there be other side effects? # uname -a FreeBSD xxxxx.xxxxxxxx.xx 7.2-RELEASE-p7 FreeBSD 7.2-RELEASE-p7 #9: ... # pciconf -l|grep em em0@pci0:6:0:0: class=0x020000 card=0x34768086 chip=0x10968086 rev=0x01 hdr=0x00 em1@pci0:6:0:1: class=0x020000 card=0x34768086 chip=0x10968086 rev=0x01 hdr=0x00 I found some thread suggesting this might possibly be a bug with the em driver, but there was no follow up for more than a year. bye & Thanks av. P.S. I had another problem on this machine: when I bonded the the two "em" interfaces into a "lagg" one, carp stopped working properly. Now I wonder if the two issues might be related... From owner-freebsd-net@FreeBSD.ORG Tue May 11 12:59:51 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F15191065677 for ; Tue, 11 May 2010 12:59:51 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63906.mail.re1.yahoo.com (web63906.mail.re1.yahoo.com [69.147.97.121]) by mx1.freebsd.org (Postfix) with SMTP id AAFB38FC12 for ; Tue, 11 May 2010 12:59:51 +0000 (UTC) Received: (qmail 10635 invoked by uid 60001); 11 May 2010 12:59:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273582790; bh=RMGwqI1OtH2/hJx297UYwmSUI8J/5Qk3K+cdp2pSuHg=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=m703tIYGYMBy+1XYbmHuowAI6iosVut4dDjv5zgyLtC6R9laW7ZlznsYhEH9lQOxuFt3SeiV91E8wL47uDfQlcnG2PvICAum0OYtxQVeNOzu7yIP38H9iEQTdsGdjeINuAPvfaLOh5MXidquIeitAa3jXnLVCCho1LwE/qX6rg4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=as/HoNaL7r6fZuAAWDGttECM0J8Jy7d5L0/z7iSGP1m3N9tSRuVWwwUlmWGO1yAYWQ4i9oA/HOcQah/Forgal+H57s8ksiNvDi7XdNXpDqpwJ5PFdMA4BbtZwjitSLDJZwzO1hf7lMlD6AoN1ij+gFFSofNZWRkEZYX8vRpo5HA=; Message-ID: <980105.10457.qm@web63906.mail.re1.yahoo.com> X-YMail-OSG: WFbHVxcVM1legPPiOyyO82PUKAyKxVqDgDMjkTJpo5pQOhe SQ9kdCEFq4ekbLUc9.1_qVA04i3E0LzMcI10KZLSTjkdaVtOEAThCzU4cyyI S0rPn9lqzslIVXH72JF9oMuMiDKWnqjLDOMulm2EO2POCvV4oRU1RyxN5yly k8o_Qb648QqXskAG7F8Z3iE4hG2.d4NugPg3JZ202rGRB82t.aEFUZAnXU6T oOC3wsKbj9I3cTMSMa2pNQr0LAidQW4JUblbJ7cGrbnD8pscVl_1q9khtHO9 dLFxDmVsoXdUt2fv505aGcW2u1OJCJRE- Received: from [98.203.21.152] by web63906.mail.re1.yahoo.com via HTTP; Tue, 11 May 2010 05:59:50 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Tue, 11 May 2010 05:59:50 -0700 (PDT) From: Barney Cordoba To: Jack Vogel In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, grarpamp , Vincent Hoffman Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 12:59:52 -0000 =0A=0A--- On Sun, 5/9/10, Jack Vogel wrote:=0A=0A> From= : Jack Vogel =0A> Subject: Re: Intel 10Gb=0A> To: "Barne= y Cordoba" =0A> Cc: "Murat Balaban" , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, "grarpa= mp" , "Vincent Hoffman" =0A> Date: = Sunday, May 9, 2010, 1:12 PM=0A> On Sun, May 9, 2010 at 6:43 AM,=0A> Barney= Cordoba wrote:=0A> =0A> >=0A> >=0A> > --- On Sat= , 5/8/10, Murat Balaban =0A> wrote:=0A> >=0A> > > From= : Murat Balaban =0A> > > Subject: Re: Intel 10Gb=0A> >= > To: "Vincent Hoffman" =0A> > > Cc: freebsd-net@freeb= sd.org,=0A> freebsd-performance@freebsd.org,=0A> "grarpamp"=0A> > =0A> > > Date: Saturday, May 8, 2010, 8:59 AM=0A> > >=0A> > > Mu= ch of the FreeBSD networking stack has been=0A> made parallel=0A> > > in or= der to=0A> > > cope with high packet rates at 10 Gig/sec=0A> operation.=0A>= > >=0A> > > I've seen good numbers (near 10 Gig) in my tests=0A> involving= =0A> > > TCP/UDP=0A> > > send/receive. (latest Intel driver).=0A> > >=0A> >= > As far as BPF is concerned, above statement does=0A> not hold=0A> > > tr= ue,=0A> > > since there is some work that needs to be done=0A> here in=0A> = > > terms=0A> > > of BPF locking and parallelism. My tests show=0A> that th= ere=0A> > > is a high lock contention around "bpf interface=0A> lock",=0A> = > > resulting=0A> > > in input errors at high packet rates and with=0A> man= y bpf=0A> > > devices.=0A> > >=0A> > > I belive GSoC 2010 project, Multique= ue BPF, is a=0A> milestone=0A> > > for this:=0A> > > http://www.freebsd.org= /projects/ideas/ideas.html#p-multiqbpf=0A> > >=0A> > > I'm also working on = this problem myself and will=0A> post a=0A> > > diff whenever=0A> > > I hav= e something usable.=0A> > >=0A> > >=0A> > > --=0A> > > Murat=0A> > > http:/= /www.enderunix.org/murat/=0A> > >=0A> > >=0A> > >=0A> > > On Sat, 2010-05-0= 8 at 10:01 +0100, Vincent=0A> Hoffman=0A> > >=0A> > >=A0 wrote:=0A> > > > L= ooks a little like=0A> > > > http://lists.freebsd.org/pipermail/svn-src-all= /2010-May/023679.html=0A> > > > but for intel. cool.=0A> > > >=0A> > > > Vi= nce=0A> > > > On 07/05/2010 23:01, grarpamp wrote:=0A> > > > > Just wonderi= ng in general these days=0A> how close=0A> > > FreeBSD is to=0A> > > > > fu= ll 10Gb rates at various packet sizes=0A> from=0A> > > minimum ethernet=0A>= > > > > frame to max jumbo 65k++. For things=0A> like BPF,=0A> > > ipfw/pf= , routing,=0A> > > > > switching, etc.=0A> > > > > http://www.ntop.org/blog= /?p=3D86=0A> > > > >=0A> _______________________________________________=0A= > >=0A> > Blah, Blah, Blah. Let's see some real numbers on real=0A> network= s under=0A> > real loads. Until then, you've got nothing.=0A> >=0A> > BC=0A= > >=0A> >=0A> >=0A> Blah blah blah, you're one to talk, do you EVER do anyt= hing=0A> but=0A> criticize others? Nothing is right.=0A> =0A> Jack=0A=0ATho= se who expect pats on the back for not getting the job done have no=0Achanc= e of succeeding. Without criticism you only have delusion.=0A=0AI'm not cri= ticizing the work, even though its worthy of criticism. I'm =0Acriticizing = touting successes without any real-world evidence to support=0Athe claim.= =0A=0ABC=0A=0A=0A From owner-freebsd-net@FreeBSD.ORG Tue May 11 13:51:10 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id F4220106564A; Tue, 11 May 2010 13:51:09 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id B66AA8FC19; Tue, 11 May 2010 13:51:09 +0000 (UTC) Received: from grapeape2.cs.duke.edu (grapeape2.cs.duke.edu [152.3.140.76]) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o4BDp5kb008584 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 09:51:05 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o4BDp5kb008584 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1273585865; bh=sJ4HXaoJGcjlwosClQLRaemaLSaYjhPgnfgE2LGqOrw=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:In-Reply-To; b=dtnsbOENfuHYNaPeHg1mDSYHIrdCEn4Ttv+4rx8aqMWrH+JJLnfY2S/8QKJ9onsap GjqGz/cHztHdxjBgeMBahxB365e75b22fh4HH2B6q8oyjW4SOejRsFaOpu12exM+O9 wso4eQP0nRwhWIBjvVtFQGi2QVjLwaARmNi2CgnY= Received: (from gallatin@localhost) by grapeape2.cs.duke.edu (8.12.10/8.12.10/Submit) id o4BDp3nH029426; Tue, 11 May 2010 09:51:03 -0400 (EDT) Date: Tue, 11 May 2010 09:51:03 -0400 From: Andrew Gallatin To: Murat Balaban Message-ID: <20100511135103.GA29403@grapeape2.cs.duke.edu> References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1273323582.3304.31.camel@efe> X-Operating-System: SunOS 5.10 on an sun4u User-Agent: Mutt/1.5.13 (2006-08-11) Cc: freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 13:51:10 -0000 Murat Balaban [murat@enderunix.org] wrote: > > Much of the FreeBSD networking stack has been made parallel in order to > cope with high packet rates at 10 Gig/sec operation. > > I've seen good numbers (near 10 Gig) in my tests involving TCP/UDP > send/receive. (latest Intel driver). > > As far as BPF is concerned, above statement does not hold true, > since there is some work that needs to be done here in terms > of BPF locking and parallelism. My tests show that there > is a high lock contention around "bpf interface lock", resulting > in input errors at high packet rates and with many bpf devices. If you're interested in 10GbE packet sniffing at line rate on the cheap, have a look at the Myri10GE "sniffer" interface. This is a special software package that takes a normal mxge(4) NIC, and replaces the driver/firmware with a "myri_snf" driver/firmware which is optimized for packet sniffing. Using this driver/firmware combo, we can receive minimal packets at line rate (14.8Mpps) to userspace. You can even access this using a libpcap interface. The trick is that the fast paths are OS-bypass, and don't suffer from OS overheads, like lock contention. See http://www.myri.com/scs/SNF/doc/index.html for details. Best Regards, Drew From owner-freebsd-net@FreeBSD.ORG Tue May 11 13:56:01 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 874EC1065672; Tue, 11 May 2010 13:56:01 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 46E9A8FC22; Tue, 11 May 2010 13:56:01 +0000 (UTC) Received: from [172.31.193.10] (rrcs-98-101-145-84.midsouth.biz.rr.com [98.101.145.84]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o4BDtx56009313 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 May 2010 09:56:00 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o4BDtx56009313 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1273586160; bh=IHj1FoctcFXiXYQBCObrrQUEP5QvOs9dpS9hc6wLxww=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=L76c7vDYh8wmvZaYLLSfZC1JFIYPkxUpmPC9SymZwGMWgtAa4DxQwbBpnbz5T91yy 0nrb8j8IlVegrMWonjURXdQDkis7nM6U8bXOIfiYzyM4szuH42LQhLToNTFbsMkBGA Qw5nEXa++6HxZcQweRK11NnIT3sQ08YTWxgsX0X8= Message-ID: <4BE961EA.2060806@cs.duke.edu> Date: Tue, 11 May 2010 09:55:54 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: David Malone References: <4BD885C6.10600@FreeBSD.org> <20100429204544.GC1286@arthur.nitro.dk> <1272998683.2406.38.camel@localhost.localdomain> <20100504190328.GC31196@valentine.liquidneon.com> <4BE80F07.8090309@cs.duke.edu> <4BE82011.6050009@cs.duke.edu> <20100511092000.GA12735@walton.maths.tcd.ie> In-Reply-To: <20100511092000.GA12735@walton.maths.tcd.ie> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD net mailing list , Ivan Voras , developers@FreeBSD.org Subject: Re: FreeBSD.org IPv6 issue - AAAA records disabled X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 13:56:01 -0000 David Malone wrote: > On Mon, May 10, 2010 at 11:02:41AM -0400, Andrew Gallatin wrote: >> I think something may be holding onto an mbuf after free, >> then re-freeing it. But only after somebody else allocated >> it. I was hoping that the mbuf double free referenced >> above was the smoking gun, but it turns out that there isn't >> even a bge interface in my pr (just bce and mxge). > > Weren't there some bugs fixed recently that alowed the arp/ndp code > to free packets that weren't previously being freed? They'd be good > candidates for something that holds onto an mbuf for a while and > then frees it. Unfortunately, I think at least the PR I'm looking into pre-dates those fixes -- these problems started in r202120 (early Jan). I need to ask what he upgraded from. When did IPv6 become unstable for others? Drew From owner-freebsd-net@FreeBSD.ORG Tue May 11 17:30:09 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F456106570C for ; Tue, 11 May 2010 17:30:09 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 4CEFD8FC08 for ; Tue, 11 May 2010 17:30:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4BHU8Uu096450 for ; Tue, 11 May 2010 17:30:08 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4BHU8eL096445; Tue, 11 May 2010 17:30:08 GMT (envelope-from gnats) Date: Tue, 11 May 2010 17:30:08 GMT Message-Id: <201005111730.o4BHU8eL096445@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= Cc: Subject: Re: kern/146394: [vlan] IP source address for outgoing connections X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 17:30:09 -0000 The following reply was made to PR kern/146394; it has been noted by GNATS. From: =?windows-1251?B?yu7t/Oru4iDF4uPl7ejp?= To: bug-followup@FreeBSD.org, kes-kes@yandex.ru Cc: Subject: Re: kern/146394: [vlan] IP source address for outgoing connections Date: Tue, 11 May 2010 20:05:36 +0300 jFo> Synopsis: [vlan] IP source address for outgoing connections jFo> State-Changed-From-To: open->feedback jFo> State-Changed-By: julian jFo> State-Changed-When: Sat May 8 09:47:30 PDT 2010 jFo> State-Changed-Why: jFo> The behaviour you quote as a bug is expected and useful and I don't think it is a bug. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. jFo> Anyhow there are ways to do what you want. jFo> firstly: what you are talking about will ONLY happen if you do not bind the jFo> socke to an address, so looking in the config file and binding it will jFo> fix it. Most programs have an option to do this. I had to do this yesterday with named. jFo> (though I didn't find such an option in ntpd). jFo> You need to look at what is going on using sockstat and netstat -aAn jFo> any socket that has a local address of "*" will have this behaviour. jFo> If you can't do this then you can use the jail command to force a program that jFo> does not support binding to be bound. jFo> Put it in a jail that has the same root as the rest of the system jFo> but has a forced IP address of that you want. jFo> Let me know if this solved your problem an dwe can close the bug. Actually your suggestion (jail), not mine (setip tool) will not resolve the problem. 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(KERNEL)-(rl1)(192.168.1.1/24)<----192.168.1.0/24 now if 192.168.0.7 will enable connection to 192.168.1.1:80 it will get answer from 192.168.0.1:80 this seems like spoofing =( and some services like mpd<-->radiusd in this situations will fail: response is from untrusted source and md5 chechsum mismatch I agree with you, that I can force daemon to bind to some IP, but in this situation bind *.1812 (or any other service) seems useless despite on in 99% of cases it works fine. jFo> Any non-bound socket will 'bind' itself to the address of the interface through which the jFo> outgoing packet will leave. If you do not do this there is no guarantee that the jFo> client will be able to get to the responding address as it may be on a differnet network. This is ok, for packets when connection is negitiated from router to client, but in situations when client do connection to 192.168.1.1 it must get response from 192.168.1.1 and not from any other machine. Do you agree? Router do connections to lan: So connections from ROUTER to 192.168.0.0/24 will have 192.168.0.1 IP in packets as source address So connections from ROUTER to 192.168.1.0/24 will have 192.168.1.1 IP in packets as source address Router is response to lan: So in connections from CLIENT to router. Router must response from that IP to which client have established connection Case 1: query: 192.168.0.7 -> 192.168.0.1 response: 192.168.0.1 -> 192.168.0.7 Case 2: query: 192.168.0.7 -> 192.168.1.1 response: 192.168.1.1 -> 192.168.0.7 So if client can establish connection to IP from other net he MUST get response from that IP! If client is not allowed to establish connection to IP from other net it MUST not get any response packet at all (Except maybe icmp: host is unreachable or etc.) bring to notice: if client can establish connection to IP from other net it CAN get response from that IP so router MUST resonse from that IP to which client establish connection and ONLY if router establish connection itself it MUST, as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave Look at this example: R.E.A.L/32 (lo0) 192.168.0.0/24 ---->[192.168.0.1/24](rl0)-(ROUTER0)-(rl1)(192.168.1.1/24) | | | | 192.168.0.7/24 192.168.1.7/24 (rl1) (rl0) (ROUTER1) (ROUTER2) (rl0) (rl1) SOME.REAL.IP.1 SOME.REAL.IP.2 \ / \-------------------- CLIENT --------------------------/ 192.168.0.1 is allowed on ROUTER1 and is nated to SOME.REAL.IP.1 192.168.1.1 is allowed on ROUTER2 and is nated to SOME.REAL.IP.2 on ROUTER1: route add R.E.A.L/32 192.168.0.1 on ROUTER2: route add R.E.A.L/32 192.168.1.1 on ROUTER0: there two default gateways with equal costs 0/0 192.168.0.7 0/0 192.168.1.7 Now as you said: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave if CLIENT establish connection to R.E.A.L it will get 50% packet response from SOME.REAL.IP.1 and 50% from SOME.REAL.IP.2 %-) also because of NAT on ROUTER1 and ROUTER2 we will have resource leak tcpdump on CLIENT willshow: CLIENT -> R.E.A.L SOME.REAL.IP.1 -> CLIENT CLIENT -> R.E.A.L SOME.REAL.IP.2 -> CLIENT Bring notice that that response packet have different IPs! from resource we are establish connection. In 99% this work, 1% -- WILL NOT! As I have said: >>So if client can establish connection to IP from other net he MUST get response from that IP! in this situations everithing is expected: 1. No resource leak on ROUTER1 and ROUTER2 and maybe ROUTER3... 2. tcpdump on client: CLIENT -> R.E.A.L R.E.A.L -> CLIENT CLIENT -> R.E.A.L R.E.A.L -> CLIENT Another case: Router establish connection to CLIENT This is the case your rule MUST apply: jFo> 'bind' itself to the address of the interface through which the outgoing packet will leave jFo> http://www.freebsd.org/cgi/query-pr.cgi?pr=146394 -- Eugen Konkov mailto:kes-kes@yandex.ru From owner-freebsd-net@FreeBSD.ORG Tue May 11 18:14:27 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3223C106564A for ; Tue, 11 May 2010 18:14:27 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id EBDA18FC14 for ; Tue, 11 May 2010 18:14:26 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o4BIEPfN071211 for ; Tue, 11 May 2010 14:14:25 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201005111814.o4BIEPfN071211@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 May 2010 14:14:19 -0400 To: freebsd-net@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 18:14:27 -0000 [trying on freebsd-net since no response on stable] I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant seem to understand from sockstat -l and netstat -naW On RELENG_7, sockstat -l makes sense to me .... www httpd 83005 4 tcp4 *:443 *:* www httpd 82217 3 tcp4 *:80 *:* www httpd 82217 4 tcp4 *:443 *:* www httpd 38942 3 tcp4 *:80 *:* www httpd 38942 4 tcp4 *:443 *:* root httpd 1169 3 tcp4 *:80 *:* root httpd 1169 4 tcp4 *:443 *:* various processes listening on all bound IP addresses on ports 80 and 443. On RELENG_8 however, it shows up with an extra entry (at the end) www httpd 29005 4 tcp4 *:* *:* www httpd 29004 3 tcp4 6 *:80 *:* www httpd 29004 4 tcp4 *:* *:* www httpd 29003 3 tcp4 6 *:80 *:* www httpd 29003 4 tcp4 *:* *:* www httpd 66731 3 tcp4 6 *:80 *:* www httpd 66731 4 tcp4 *:* *:* root httpd 72197 3 tcp4 6 *:80 *:* root httpd 72197 4 tcp4 *:* *:* *:80 makes sense to me... process is listening on all IPs for port 80. What does *:* mean then ? Netstat gives a slightly different version of it Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp4 0 0 *.1984 *.* LISTEN tcp4 0 0 *.* *.* CLOSED tcp46 0 0 *.80 *.* LISTEN state closed ? ---Mike -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Tue May 11 19:42:53 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8101C1065672 for ; Tue, 11 May 2010 19:42:53 +0000 (UTC) (envelope-from barnaclewes@gmail.com) Received: from mail-qy0-f190.google.com (mail-qy0-f190.google.com [209.85.221.190]) by mx1.freebsd.org (Postfix) with ESMTP id 385BC8FC12 for ; Tue, 11 May 2010 19:42:53 +0000 (UTC) Received: by qyk28 with SMTP id 28so161714qyk.27 for ; Tue, 11 May 2010 12:42:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=noiOVe+MDsqfjEUnPbVIFb818VoM+/O4tRP0Es5mIvE=; b=tra/VS3RGQGHqynHF5yIQmF6/ktRkWxBCgRXJxjDNH0hsvQm8rVeEG6vKZwn+LmtOp t25AgL0ZkpJJdYCdEPl2IWGKnSReITXg4pVH6LJJHrkL+X+0XNQjUeJ4qskjv8yaeRCS MOFYhZq4d+LOA0WHqNB0G4tc/eeCrV7sE0LiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=s20aKrVIJ5EjrmSFSjd/z04NeUu8+WQjXD8mvZrQmqafwi8FiZyEUiY8zekOJCSpp5 UaZqvcmWtFpVIIjjfazpa8IVOEtOLXRARpuZ/GwxPksdxL3/WWHZVVQtIxrPyy9liCHb A1rL2bIunuuGasgEulJXx2v043GqHFBnnaqEg= MIME-Version: 1.0 Received: by 10.224.66.100 with SMTP id m36mr4218880qai.126.1273605602078; Tue, 11 May 2010 12:20:02 -0700 (PDT) Received: by 10.229.25.200 with HTTP; Tue, 11 May 2010 12:20:02 -0700 (PDT) In-Reply-To: <201005111814.o4BIEPfN071211@lava.sentex.ca> References: <201005111814.o4BIEPfN071211@lava.sentex.ca> Date: Tue, 11 May 2010 12:20:02 -0700 Message-ID: From: Wes Peters To: Mike Tancsa Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net@freebsd.org Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:42:53 -0000 The output header is instructive: USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS www httpd 18423 3 tcp4 6 *:80 *:* www httpd 18423 4 tcp4 *:* *:* www httpd 25184 3 tcp4 6 *:80 *:* www httpd 25184 4 tcp4 *:* *:* Same as 7, it's the foreign address. This is normally only useful for connected sockets. On Tue, May 11, 2010 at 11:14 AM, Mike Tancsa wrote: > [trying on freebsd-net since no response on stable] > > I noticed that apache on RELENG_8 and RELENG_7 shows up with output I can= t > seem to understand from sockstat -l and netstat -naW > > On RELENG_7, sockstat -l makes sense to me > .... > www =A0 =A0 =A0httpd =A0 =A0 =A083005 4 =A0tcp4 =A0 *:443 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 *:* > www =A0 =A0 =A0httpd =A0 =A0 =A082217 3 =A0tcp4 =A0 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > www =A0 =A0 =A0httpd =A0 =A0 =A082217 4 =A0tcp4 =A0 *:443 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 *:* > www =A0 =A0 =A0httpd =A0 =A0 =A038942 3 =A0tcp4 =A0 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > www =A0 =A0 =A0httpd =A0 =A0 =A038942 4 =A0tcp4 =A0 *:443 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 *:* > root =A0 =A0 httpd =A0 =A0 =A01169 =A03 =A0tcp4 =A0 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > root =A0 =A0 httpd =A0 =A0 =A01169 =A04 =A0tcp4 =A0 *:443 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 *:* > > > various processes listening on all bound IP addresses on ports 80 and 443= . > > On =A0RELENG_8 however, it shows up with an extra entry (at the end) > > www =A0 =A0 =A0httpd =A0 =A0 =A029005 4 =A0tcp4 =A0 *:* =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 *:* > www =A0 =A0 =A0httpd =A0 =A0 =A029004 3 =A0tcp4 6 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > www =A0 =A0 =A0httpd =A0 =A0 =A029004 4 =A0tcp4 =A0 *:* =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 *:* > www =A0 =A0 =A0httpd =A0 =A0 =A029003 3 =A0tcp4 6 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > www =A0 =A0 =A0httpd =A0 =A0 =A029003 4 =A0tcp4 =A0 *:* =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 *:* > www =A0 =A0 =A0httpd =A0 =A0 =A066731 3 =A0tcp4 6 *:80 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0*:* > www =A0 =A0 =A0httpd =A0 =A0 =A066731 4 =A0tcp4 =A0 *:* =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 *:* > root =A0 =A0 httpd =A0 =A0 =A072197 3 =A0tcp4 6 *:80 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0*:* > root =A0 =A0 httpd =A0 =A0 =A072197 4 =A0tcp4 =A0 *:* =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 *:* > > > *:80 makes sense to me... process is listening on all IPs for port 80. = =A0What > does *:* mean then ? > > Netstat gives a slightly different version of it > > Active Internet connections (including servers) > Proto Recv-Q Send-Q =A0Local Address =A0 =A0 =A0 =A0 =A0Foreign Address = =A0 =A0 =A0 (state) > tcp4 =A0 =A0 =A0 0 =A0 =A0 =A00 *.1984 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *.= * =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LISTEN > tcp4 =A0 =A0 =A0 0 =A0 =A0 =A00 *.* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0*.* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0CLOSED > tcp46 =A0 =A0 =A00 =A0 =A0 =A00 *.80 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = *.* =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0LISTEN > > state closed ? > > =A0 =A0 =A0 =A0---Mike > > > > -------------------------------------------------------------------- > Mike Tancsa, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0tel +1 519 651 3400 > Sentex Communications, =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0mike@sentex.net > Providing Internet since 1994 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0www.= sentex.net > Cambridge, Ontario Canada =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= www.sentex.net/mike > > _______________________________________________ > 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" > --=20 Against stupidity the very gods Themselves contend in vain. Friedrich Schiller From owner-freebsd-net@FreeBSD.ORG Tue May 11 19:43:39 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3627D106567A for ; Tue, 11 May 2010 19:43:39 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 069A08FC1B for ; Tue, 11 May 2010 19:43:38 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o4BJhbdQ071732; Tue, 11 May 2010 15:43:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201005111943.o4BJhbdQ071732@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 11 May 2010 15:43:31 -0400 To: Wes Peters From: Mike Tancsa In-Reply-To: References: <201005111814.o4BIEPfN071211@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 19:43:39 -0000 At 03:20 PM 5/11/2010, Wes Peters wrote: >The output header is instructive: > >USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >www httpd 25184 4 tcp4 *:* *:* > >Same as 7, it's the foreign address. This is normally only useful for >connected sockets. Hi, Sorry, I think I am missing something obvious ? The LOCAL ADDRESS shows as *:* as well. To me that reads as its listening on all interfaces and all ports, no ? RELENG_7 does not have that line or notion in its output ? ---Mike >On Tue, May 11, 2010 at 11:14 AM, Mike Tancsa wrote: > > [trying on freebsd-net since no response on stable] > > > > I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant > > seem to understand from sockstat -l and netstat -naW > > > > On RELENG_7, sockstat -l makes sense to me > > .... > > www httpd 83005 4 tcp4 *:443 *:* > > www httpd 82217 3 tcp4 *:80 *:* > > www httpd 82217 4 tcp4 *:443 *:* > > www httpd 38942 3 tcp4 *:80 *:* > > www httpd 38942 4 tcp4 *:443 *:* > > root httpd 1169 3 tcp4 *:80 *:* > > root httpd 1169 4 tcp4 *:443 *:* > > > > > > various processes listening on all bound IP addresses on ports 80 and 443. > > > > On RELENG_8 however, it shows up with an extra entry (at the end) > > > > www httpd 29005 4 tcp4 *:* *:* > > www httpd 29004 3 tcp4 6 *:80 *:* > > www httpd 29004 4 tcp4 *:* *:* > > www httpd 29003 3 tcp4 6 *:80 *:* > > www httpd 29003 4 tcp4 *:* *:* > > www httpd 66731 3 tcp4 6 *:80 *:* > > www httpd 66731 4 tcp4 *:* *:* > > root httpd 72197 3 tcp4 6 *:80 *:* > > root httpd 72197 4 tcp4 *:* *:* > > > > > > *:80 makes sense to me... process is listening on all IPs for > port 80. What > > does *:* mean then ? > > > > Netstat gives a slightly different version of it > > > > Active Internet connections (including servers) > > Proto Recv-Q Send-Q Local Address Foreign Address (state) > > tcp4 0 0 *.1984 *.* LISTEN > > tcp4 0 0 *.* *.* CLOSED > > tcp46 0 0 *.80 *.* LISTEN > > > > state closed ? > > > > ---Mike > > > > > > > > -------------------------------------------------------------------- > > Mike Tancsa, tel +1 519 651 3400 > > Sentex Communications, mike@sentex.net > > Providing Internet since 1994 www.sentex.net > > Cambridge, Ontario Canada www.sentex.net/mike > > > > _______________________________________________ > > 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" > > > > > >-- >Against stupidity the very gods Themselves contend in vain. > Friedrich Schiller -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Tue May 11 20:23:56 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A30C106566C for ; Tue, 11 May 2010 20:23:56 +0000 (UTC) (envelope-from gjp@in-addr.com) Received: from noop.in-addr.com (mail.in-addr.com [IPv6:2001:470:8:162::1]) by mx1.freebsd.org (Postfix) with ESMTP id 423888FC0C for ; Tue, 11 May 2010 20:23:56 +0000 (UTC) Received: from gjp by noop.in-addr.com with local (Exim 4.54 (FreeBSD)) id 1OBvyv-000KxC-HA; Tue, 11 May 2010 16:23:09 -0400 Date: Tue, 11 May 2010 16:23:09 -0400 To: Wes Peters Message-ID: <20100511202309.GB59765@in-addr.com> References: <201005111814.o4BIEPfN071211@lava.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: From: Gary Palmer Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:23:56 -0000 On Tue, May 11, 2010 at 12:20:02PM -0700, Wes Peters wrote: > The output header is instructive: > > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > www httpd 18423 3 tcp4 6 *:80 *:* > www httpd 18423 4 tcp4 *:* *:* > www httpd 25184 3 tcp4 6 *:80 *:* > www httpd 25184 4 tcp4 *:* *:* > > Same as 7, it's the foreign address. This is normally only useful for > connected sockets. Wes, Your example has 2 "LOCAL ADDRESS" values of "*:*" in addition to the "*:*" in the FOREIGN ADDRESS column. I must admit I share Mike's puzzlement as to the meaning of *:* as the local address of a listening socket for a daemon Regards, Gary From owner-freebsd-net@FreeBSD.ORG Tue May 11 20:24:11 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 67A101065675 for ; Tue, 11 May 2010 20:24:11 +0000 (UTC) (envelope-from julianelischer@gmail.com) Received: from mail-ew0-f224.google.com (mail-ew0-f224.google.com [209.85.219.224]) by mx1.freebsd.org (Postfix) with ESMTP id E5AE68FC24 for ; Tue, 11 May 2010 20:24:10 +0000 (UTC) Received: by ewy24 with SMTP id 24so1504615ewy.13 for ; Tue, 11 May 2010 13:24:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=eTd13AXoy2e1s645UrcGSbgElcluFF8vKl9V/ahIMyY=; b=CYdvSbvde97nOH10PmaX9qFl4ejWDyP10BIl7tz83xN5lM3KeklKhYNpWYishhIYmE zCPEyVopiKfTVA+tHj5Ba05WGGQpz4Sdv6tpdN5Dqr2949dWbS0vAb+aKkzOiqQLeX7q sNPFRIIqmqMNH7ano93TTGNZxBJ/7W1t/ibgM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ZiFrEX6qeC9NmNqSTVeftslaVoAD9GlG9dcDsg3jaBsa4fXO4a7lMaUEyBJG0FMF4C WN73xdsKgAvwyS6jkeluurtWehGKrCBnD4lmiuT+cYe+7/QXdw4L/8gSZP7zW/V7qRrr DQBFFjYtiUU5W5lJaCize1XK7WUNi4MfgCdo0= Received: by 10.213.43.210 with SMTP id x18mr2717015ebe.64.1273609449555; Tue, 11 May 2010 13:24:09 -0700 (PDT) Received: from julian-mac.elischer.org (h-67-100-89-137.snfccasy.static.covad.net [67.100.89.137]) by mx.google.com with ESMTPS id 14sm3367465ewy.6.2010.05.11.13.24.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 11 May 2010 13:24:07 -0700 (PDT) Sender: Julian Elischer Message-ID: <4BE9BCE2.7070303@elischer.org> Date: Tue, 11 May 2010 13:24:02 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Wes Peters References: <201005111814.o4BIEPfN071211@lava.sentex.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, Mike Tancsa Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 20:24:11 -0000 On 5/11/10 12:20 PM, Wes Peters wrote: > The output header is instructive: > > USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS > www httpd 18423 3 tcp4 6 *:80 *:* > www httpd 18423 4 tcp4 *:* *:* > www httpd 25184 3 tcp4 6 *:80 *:* > www httpd 25184 4 tcp4 *:* *:* > > Same as 7, it's the foreign address. This is normally only useful for > connected sockets. > > On Tue, May 11, 2010 at 11:14 AM, Mike Tancsa wrote: >> [trying on freebsd-net since no response on stable] >> >> I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant >> seem to understand from sockstat -l and netstat -naW >> >> On RELENG_7, sockstat -l makes sense to me >> .... >> www httpd 83005 4 tcp4 *:443 *:* >> www httpd 82217 3 tcp4 *:80 *:* >> www httpd 82217 4 tcp4 *:443 *:* >> www httpd 38942 3 tcp4 *:80 *:* >> www httpd 38942 4 tcp4 *:443 *:* >> root httpd 1169 3 tcp4 *:80 *:* >> root httpd 1169 4 tcp4 *:443 *:* >> >> >> various processes listening on all bound IP addresses on ports 80 and 443. >> >> On RELENG_8 however, it shows up with an extra entry (at the end) >> >> www httpd 29005 4 tcp4 *:* *:* >> www httpd 29004 3 tcp4 6 *:80 *:* >> www httpd 29004 4 tcp4 *:* *:* >> www httpd 29003 3 tcp4 6 *:80 *:* >> www httpd 29003 4 tcp4 *:* *:* >> www httpd 66731 3 tcp4 6 *:80 *:* >> www httpd 66731 4 tcp4 *:* *:* >> root httpd 72197 3 tcp4 6 *:80 *:* >> root httpd 72197 4 tcp4 *:* *:* >> >> >> *:80 makes sense to me... process is listening on all IPs for port 80. What >> does *:* mean then ? I believe it has created a socket but not used it for anything it may be the 6 socket... otherwise I don't see what a "tcp4 6" is meant to be. >> >> Netstat gives a slightly different version of it >> >> Active Internet connections (including servers) >> Proto Recv-Q Send-Q Local Address Foreign Address (state) >> tcp4 0 0 *.1984 *.* LISTEN >> tcp4 0 0 *.* *.* CLOSED >> tcp46 0 0 *.80 *.* LISTEN >> >> state closed ? >> >> ---Mike >> >> >> >> -------------------------------------------------------------------- >> Mike Tancsa, tel +1 519 651 3400 >> Sentex Communications, mike@sentex.net >> Providing Internet since 1994 www.sentex.net >> Cambridge, Ontario Canada www.sentex.net/mike >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > > From owner-freebsd-net@FreeBSD.ORG Tue May 11 23:10:03 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7D545106566B for ; Tue, 11 May 2010 23:10:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 54D498FC21 for ; Tue, 11 May 2010 23:10:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4BNA3cp085595 for ; Tue, 11 May 2010 23:10:03 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4BNA37f085593; Tue, 11 May 2010 23:10:03 GMT (envelope-from gnats) Date: Tue, 11 May 2010 23:10:03 GMT Message-Id: <201005112310.o4BNA37f085593@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Ben Smith Cc: Subject: Re: kern/146358: [vlan] wrong destination MAC address X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ben Smith List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2010 23:10:03 -0000 The following reply was made to PR kern/146358; it has been noted by GNATS. From: Ben Smith To: bug-followup@FreeBSD.org, bsmith@boltnet.com Cc: Subject: Re: kern/146358: [vlan] wrong destination MAC address Date: Tue, 11 May 2010 15:39:38 -0700 I was digging through the UPDATING and CVS notes for 8.0 and saw FLOWTABLE. I did some more digging and rebooted a box with FLOWTABLE disabled. The box does not exhibit these same problems with it disabled, I have had it running for a couple hours now. This seems to be a decent work around and may indicate where the source of the problem is. I had tried disabling carp which didn't fix it. -ben From owner-freebsd-net@FreeBSD.ORG Wed May 12 10:59:41 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C7831106566B for ; Wed, 12 May 2010 10:59:41 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (www.unsane.co.uk [85.233.185.162]) by mx1.freebsd.org (Postfix) with ESMTP id 0C1508FC15 for ; Wed, 12 May 2010 10:59:39 +0000 (UTC) Received: from vhoffman.lon.namesco.net (2.67-246-213.ippool.namesco.net [213.246.67.2]) (authenticated bits=0) by unsane.co.uk (8.14.4/8.14.4) with ESMTP id o4CAxbZT099215 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Wed, 12 May 2010 11:59:38 +0100 (BST) (envelope-from vince@unsane.co.uk) Message-ID: <4BEA8A19.9070105@unsane.co.uk> Date: Wed, 12 May 2010 11:59:37 +0100 From: Vincent Hoffman User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: freebsd-net@freebsd.org X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Fwd: ath0 not working and getting device timeouts with recent stable X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 10:59:41 -0000 Forwarding as no answer on freebsd-stable (although a 2nd problem report did appear yesterday from someone else with the same device string but different card and chip ids see *http://groups.google.com/group/mailing.freebsd.stable/browse_thread/thread/0cc4e313e063736a*) I'll add a PR in bit. I'm having issues getting my wireless card working with a recent stable. It was working with 8.0-RELEASE I created wlan0 manually for debug ifconfig wlan0 create wlandev ath0 wlanmode station country GB wpa_supplicant -B -i wlan0 -c /etc/wpa_supplicant.conf ifconfig wlan0 10.0.0.1/25 if I then ping a known reachable IP on that network I cause a device timeout. [root@ostracod ~/wlandebug]# ping 10.0.0.32 PING 10.0.0.32 (10.0.0.32): 56 data bytes ping: sendto: Network is down ping: sendto: Network is down ^C --- 10.0.0.32 ping statistics --- 14 packets transmitted, 0 packets received, 100.0% packet loss May 8 23:13:38 ostracod kernel: wlan0: Ethernet address: 00:24:23:07:fb:5d May 8 23:13:41 ostracod kernel: wlan0: link state changed to UP May 8 23:16:15 ostracod kernel: wlan0: link state changed to DOWN May 8 23:16:20 ostracod kernel: ath0: device timeout May 8 23:16:25 ostracod kernel: wlan0: link state changed to UP Some device info Its a Zotac ION-ITX-D Atom motherboard with an "Azurewave AR5B91" wireless card. ath0@pci0:4:0:0: class=0x028000 card=0x10671a3b chip=0x002a168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR5B91 Wireless Network Adapter (0001)' class = network [root@ostracod ~/wlandebug]# uname -a FreeBSD ostracod.unsane.co.uk 8.0-STABLE FreeBSD 8.0-STABLE #1 r207610: Tue May 4 15:44:19 BST 2010 toor@ostracod.unsane.co.uk:/scratch/obj/usr/src/sys/OSTRACOD amd64 [root@ostracod ~/wlandebug]# more /etc/wpa_supplicant.conf ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=wheel # # home network; allow all valid ciphers network={ ssid="V_WAP" scan_ssid=1 key_mgmt=NONE wep_tx_keyidx=0 wep_key0=xxxxxxxxxxxxxxxxxxxxxxxx } I did try wpa instead of wep with the same results. I've tried wlandebug -i wlan0 debug+assoc+auth+output+power and I get May 8 23:46:50 ostracod kernel: wlan0: send probe req on channel 12 bssid ff:ff:ff:ff:ff:ff ssid "V_WAP" May 8 23:46:50 ostracod kernel: wlan0: send probe req on channel 12 bssid ff:ff:ff:ff:ff:ff ssid "" May 8 23:46:50 ostracod kernel: wlan0: received probe_resp from 94:44:52:0f:2f:c3 rssi 13 May 8 23:46:50 ostracod kernel: wlan0: received beacon from 94:44:52:0f:2f:c3 rssi 14 May 8 23:46:50 ostracod kernel: wlan0: received beacon from 94:44:52:0f:2f:c3 rssi 14 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:46:50 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:46:50 ostracod kernel: wlan0: received auth from 94:44:52:0f:2f:c3 rssi 65 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] recv auth frame with algorithm 0 seq 2 May 8 23:46:50 ostracod kernel: [94:44:52:0f:2f:c3] send assoc_req on channel 1 May 8 23:46:50 ostracod kernel: wlan0: received assoc_resp from 94:44:52:0f:2f:c3 rssi 66 May 8 23:46:50 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] assoc success at aid 3: long preamble, long slot time May 8 23:46:50 ostracod kernel: wlan0: associated with 94:44:52:0f:2f:c3 ssid "V_WAP" channel 1 start 0Mb May 8 23:46:50 ostracod kernel: wlan0: link state changed to UP May 8 23:47:42 ostracod kernel: wlan0: beacon miss, mode STA state RUN May 8 23:47:42 ostracod kernel: wlan0: send probe req on channel 1 bssid 94:44:52:0f:2f:c3 ssid "V_WAP" May 8 23:47:43 ostracod kernel: wlan0: beacon miss, mode STA state RUN May 8 23:47:43 ostracod kernel: wlan0: link state changed to DOWN May 8 23:47:43 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:47:43 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:47:43 ostracod kernel: wlan0: ieee80211_start: ignore queue, in AUTH state May 8 23:47:47 ostracod kernel: ath0: device timeout May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] station assoc via MLME May 8 23:47:53 ostracod kernel: [94:44:52:0f:2f:c3] send auth on channel 1 May 8 23:47:53 ostracod kernel: wlan0: received auth from 94:44:52:0f:2f:c3 rssi 67 May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] recv auth frame with algorithm 0 seq 2 May 8 23:47:53 ostracod kernel: [94:44:52:0f:2f:c3] send assoc_req on channel 1 May 8 23:47:53 ostracod kernel: wlan0: received assoc_resp from 94:44:52:0f:2f:c3 rssi 67 May 8 23:47:53 ostracod kernel: wlan0: [94:44:52:0f:2f:c3] assoc success at aid 3: long preamble, long slot time May 8 23:47:53 ostracod kernel: wlan0: associated with 94:44:52:0f:2f:c3 ssid "V_WAP" channel 1 start 0Mb May 8 23:47:53 ostracod kernel: wlan0: link state changed to UP Any suggestions welcome. Vince _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Wed May 12 12:47:04 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7BC001065673 for ; Wed, 12 May 2010 12:47:04 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from mailrelay1.rambler.ru (mailrelay1.rambler.ru [81.19.66.239]) by mx1.freebsd.org (Postfix) with ESMTP id 3DD448FC2A for ; Wed, 12 May 2010 12:47:04 +0000 (UTC) Received: from localhost (sysoev.ru [81.19.68.137]) by mailrelay1.rambler.ru (Postfix) with ESMTP id E837A192DC87 for ; Wed, 12 May 2010 16:47:02 +0400 (MSD) Date: Wed, 12 May 2010 16:47:02 +0400 From: Igor Sysoev To: freebsd-net@freebsd.org Message-ID: <20100512124702.GJ2679@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Subject: net.inet.tcp.slowstart_flightsize in 8-STABLE X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 12:47:04 -0000 It seems that net.inet.tcp.slowstart_flightsize does not work in 8-STABLE. For a long time I used slowstart_flightsize=2 on FreeBSD 4, 6, and 7 hosts. However, FreeBSD-8 always starts with the single packet. I saw this on different versions of 8-STABLE since 8 Oct 2009 till 04 Apr 2010. -- Igor Sysoev http://sysoev.ru/en/ From owner-freebsd-net@FreeBSD.ORG Wed May 12 14:08:43 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 649EC106566C; Wed, 12 May 2010 14:08:43 +0000 (UTC) (envelope-from emaste@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 3DAE68FC27; Wed, 12 May 2010 14:08:43 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4CE8hPG000257; Wed, 12 May 2010 14:08:43 GMT (envelope-from emaste@freefall.freebsd.org) Received: (from emaste@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4CE8h5Y000253; Wed, 12 May 2010 14:08:43 GMT (envelope-from emaste) Date: Wed, 12 May 2010 14:08:43 GMT Message-Id: <201005121408.o4CE8h5Y000253@freefall.freebsd.org> To: emaste@FreeBSD.org, freebsd-net@FreeBSD.org, rstone@FreeBSD.org From: emaste@FreeBSD.org Cc: Subject: Re: kern/127834: [ixgbe] [patch] wrong error counting X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 14:08:43 -0000 Synopsis: [ixgbe] [patch] wrong error counting Responsible-Changed-From-To: freebsd-net->rstone Responsible-Changed-By: emaste Responsible-Changed-When: Wed May 12 14:07:07 UTC 2010 Responsible-Changed-Why: Ryan checked on this; it is fixed in -CURRENT. He'll check the state of stable/8 and stable/7. http://www.freebsd.org/cgi/query-pr.cgi?pr=127834 From owner-freebsd-net@FreeBSD.ORG Wed May 12 15:46:39 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 68FD6106564A; Wed, 12 May 2010 15:46:39 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [69.147.83.40]) by mx1.freebsd.org (Postfix) with ESMTP id 411708FC1E; Wed, 12 May 2010 15:46:39 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4CFkdc2085744; Wed, 12 May 2010 15:46:39 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4CFkcPH085740; Wed, 12 May 2010 15:46:39 GMT (envelope-from linimon) Date: Wed, 12 May 2010 15:46:39 GMT Message-Id: <201005121546.o4CFkcPH085740@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 15:46:39 -0000 Old Synopsis: device timeouts for ath wlan device on recent stable. New Synopsis: [ath] [wlan] device timeouts for ath wlan device on recent stable. Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed May 12 15:46:23 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146517 From owner-freebsd-net@FreeBSD.ORG Wed May 12 17:31:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2808A1065673; Wed, 12 May 2010 17:31:29 +0000 (UTC) (envelope-from brueffer@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id F39198FC16; Wed, 12 May 2010 17:31:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4CHVSHC082177; Wed, 12 May 2010 17:31:28 GMT (envelope-from brueffer@freefall.freebsd.org) Received: (from brueffer@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4CHVSZe082173; Wed, 12 May 2010 19:31:28 +0200 (CEST) (envelope-from brueffer) Date: Wed, 12 May 2010 19:31:28 +0200 (CEST) Message-Id: <201005121731.o4CHVSZe082173@freefall.freebsd.org> To: John.Giacomoni@LineRateSystems.com, brueffer@FreeBSD.org, freebsd-net@FreeBSD.org, brueffer@FreeBSD.org From: brueffer@FreeBSD.org Cc: Subject: Re: kern/144494: [ixgbe] ixgbe driver not built as module X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 17:31:29 -0000 Synopsis: [ixgbe] ixgbe driver not built as module State-Changed-From-To: open->patched State-Changed-By: brueffer State-Changed-When: Wed May 12 19:30:56 CEST 2010 State-Changed-Why: Committed, thanks! Responsible-Changed-From-To: freebsd-net->brueffer Responsible-Changed-By: brueffer Responsible-Changed-When: Wed May 12 19:30:56 CEST 2010 Responsible-Changed-Why: MFC reminder. http://www.freebsd.org/cgi/query-pr.cgi?pr=144494 From owner-freebsd-net@FreeBSD.ORG Wed May 12 17:45:06 2010 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B3161065675 for ; Wed, 12 May 2010 17:45:06 +0000 (UTC) (envelope-from sem@FreeBSD.org) Received: from mail.ciam.ru (mail.ciam.ru [91.209.218.18]) by mx1.freebsd.org (Postfix) with ESMTP id 2E4D48FC15 for ; Wed, 12 May 2010 17:45:06 +0000 (UTC) Received: from dhcp170-37-red.yandex.net ([95.108.170.37]) by mail.ciam.ru with esmtpa (Exim 4.x) id 1OCFzU-0000Wk-Q1 for freebsd-net@FreeBSD.org; Wed, 12 May 2010 21:45:04 +0400 Message-ID: <4BEAE920.2020001@FreeBSD.org> Date: Wed, 12 May 2010 21:45:04 +0400 From: Sergey Matveychuk User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: tcp_input: Listen socket: Socket allocation failed due to limits or memory shortage X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 17:45:06 -0000 Hello. I was annoyed by the subject message and decided to dig it a little. The message appears sporadically and caused my application accept(2) error. I've quickly discovered it's not a listen queue overflow. I've increased kern.ipc.somaxconn to 1024 and listen(2) backlog argument too (netstat -Lan output: tcp4 0/0/1024 *.8542). But without a success. (My application serves only 3-5 connection simultaneously). Moreover, listen queue overflows counter (netstat -s) was not increased. I've decided it's a syncache or syncookie problem. First, I've set net.inet.tcp.syncookies_only=1. But it does not help. Second, I've set it back to 0 and set net.inet.tcp.syncookies=0. The messages gone. A message I've wrote before (syncache_expand: Segment failed SYNCOOKIE authentication, segment rejected (probably spoofed)) of course gone too. May be somebody who familiar with syncookies can comment it? -- Sem. From owner-freebsd-net@FreeBSD.ORG Wed May 12 17:50:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 36F0F106566C for ; Wed, 12 May 2010 17:50:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by mx1.freebsd.org (Postfix) with ESMTP id 0A0558FC12 for ; Wed, 12 May 2010 17:50:39 +0000 (UTC) Received: from mdt-xp.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.14.3/8.14.3) with ESMTP id o4CHoaAI079582; Wed, 12 May 2010 13:50:37 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <201005121750.o4CHoaAI079582@lava.sentex.ca> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 12 May 2010 13:50:31 -0400 To: Julian Elischer From: Mike Tancsa In-Reply-To: <4BE9BCE2.7070303@elischer.org> References: <201005111814.o4BIEPfN071211@lava.sentex.ca> <4BE9BCE2.7070303@elischer.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 17:50:40 -0000 At 04:24 PM 5/11/2010, Julian Elischer wrote: >On 5/11/10 12:20 PM, Wes Peters wrote: >>The output header is instructive: >> >>USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >>www httpd 18423 3 tcp4 6 *:80 *:* >>www httpd 18423 4 tcp4 *:* *:* >>www httpd 25184 3 tcp4 6 *:80 *:* >>www httpd 25184 4 tcp4 *:* *:* >> >>Same as 7, it's the foreign address. This is normally only useful for >>connected sockets. >> >>On Tue, May 11, 2010 at 11:14 AM, Mike Tancsa wrote: >>>[trying on freebsd-net since no response on stable] >>> >>>I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant >>>seem to understand from sockstat -l and netstat -naW >>> >>>On RELENG_7, sockstat -l makes sense to me >>>.... >>>www httpd 83005 4 tcp4 *:443 *:* >>>www httpd 82217 3 tcp4 *:80 *:* >>>www httpd 82217 4 tcp4 *:443 *:* >>>www httpd 38942 3 tcp4 *:80 *:* >>>www httpd 38942 4 tcp4 *:443 *:* >>>root httpd 1169 3 tcp4 *:80 *:* >>>root httpd 1169 4 tcp4 *:443 *:* >>> >>> >>>various processes listening on all bound IP addresses on ports 80 and 443. >>> >>>On RELENG_8 however, it shows up with an extra entry (at the end) >>> >>>www httpd 29005 4 tcp4 *:* *:* >>>www httpd 29004 3 tcp4 6 *:80 *:* >>>www httpd 29004 4 tcp4 *:* *:* >>>www httpd 29003 3 tcp4 6 *:80 *:* >>>www httpd 29003 4 tcp4 *:* *:* >>>www httpd 66731 3 tcp4 6 *:80 *:* >>>www httpd 66731 4 tcp4 *:* *:* >>>root httpd 72197 3 tcp4 6 *:80 *:* >>>root httpd 72197 4 tcp4 *:* *:* >>> >>> >>>*:80 makes sense to me... process is listening on all IPs for port 80. What >>>does *:* mean then ? > >I believe it has created a socket but not used it for anything >it may be the 6 socket... otherwise I don't see what a "tcp4 6" is >meant to be. Should not sockstat and netstat agree ? one says closed, the other not ---Mike >>>Netstat gives a slightly different version of it >>> >>>Active Internet connections (including servers) >>>Proto Recv-Q Send-Q Local Address Foreign Address (state) >>>tcp4 0 0 *.1984 *.* LISTEN >>>tcp4 0 0 *.* *.* CLOSED >>>tcp46 0 0 *.80 *.* LISTEN >>> >>>state closed ? >>> >>> ---Mike >>> >>> >>> >>>-------------------------------------------------------------------- >>>Mike Tancsa, tel +1 519 651 3400 >>>Sentex Communications, mike@sentex.net >>>Providing Internet since 1994 www.sentex.net >>>Cambridge, Ontario Canada www.sentex.net/mike >>> >>>_______________________________________________ >>>freebsd-net@freebsd.org mailing list >>>http://lists.freebsd.org/mailman/listinfo/freebsd-net >>>To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> >> -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike From owner-freebsd-net@FreeBSD.ORG Wed May 12 19:03:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1872D1065670 for ; Wed, 12 May 2010 19:03:38 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-243-Pennsylvania.hfc.comcastbusiness.net [75.149.8.243]) by mx1.freebsd.org (Postfix) with ESMTP id E23678FC13 for ; Wed, 12 May 2010 19:03:37 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id 7AF408BC04C for ; Wed, 12 May 2010 15:03:19 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOFpS0CNoS98 for ; Wed, 12 May 2010 15:03:18 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id 615208BC048 for ; Wed, 12 May 2010 15:03:18 -0400 (EDT) From: Andrew Boyer Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 12 May 2010 15:03:34 -0400 Message-Id: To: freebsd-net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: ixgbe 2.1.7 can't disable LRO on 82599? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 19:03:38 -0000 Hello all, I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to = FreeBSD 7.1. With some fiddling it seems to work on both 82598 and = 82599 controllers. On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued = and ...lro_flushed to stop incrementing, as expected. There's also a = significant throughput hit which would seem to indicate that it took = effect. However, it appears that LRO is always enabled on 82599. 'ifconfig ix0 = -lro' removes the LRO flag from the port in ifconfig but the = ...hw_lro_merge counter continues to increase. The throughput reported = by the iperf port is the same with or without LRO on. Any advice? Am I misinterpreting something? Thanks, Andrew P.S. We need to disable LRO because we don't have Appropriate Byte = Counting support and LRO causes TCP ACK havoc without it. -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Wed May 12 20:28:19 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6B7D4106566B for ; Wed, 12 May 2010 20:28:19 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id F2D9C8FC0A for ; Wed, 12 May 2010 20:28:18 +0000 (UTC) Received: by wyg36 with SMTP id 36so244500wyg.13 for ; Wed, 12 May 2010 13:28:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=fY+xPfHHoqfTipllzTf54grJZBYgY/VeV7EzNA2fdKo=; b=Wk1UxaEPJHccZeZdPBraU1EwMxVtOpuF+4oj2Vx1bl51bLtdlclBdauoSq3b0w2G78 L8z38W4C9ZByIVGWmBP/OJIK0Y4gWkje4r3n1nctrnV5p2PrGwykD2M9pMmHVklk4H8K O3juIoMf6cBb9XDbplexLv+wb5I3bAVuWrFtY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=d7UGH4Ywp5LepE0fkdBMR2zjeNJVvC3bOBBUp7Ml0LLGRoL0CwM66QnXCDhHWk5t0+ YBZT4CJKR/L+ezLonq+27L/7TsU8FbBloOiyoj4LyWyx3NvYigw3JeerqN81hU8aUiqD F0k6Pk9mOWhLRSErohWqvMMwUCTThxFoZdr8U= MIME-Version: 1.0 Received: by 10.216.90.199 with SMTP id e49mr5027423wef.38.1273696096025; Wed, 12 May 2010 13:28:16 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Wed, 12 May 2010 13:28:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 13:28:14 -0700 Message-ID: From: Jack Vogel To: Andrew Boyer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ixgbe 2.1.7 can't disable LRO on 82599? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:28:19 -0000 Oh, this is because the 82598 is doing HW RSC which is a different code path from the LRO that the 598 does, and that may be the problem, I will need to look into that. Thanks for the report. And, yes, LRO is a major improvement in 10G performance, as is TSO. Are you sure you have no alternative to disabling? Cheers, Jack On Wed, May 12, 2010 at 12:03 PM, Andrew Boyer wrote: > Hello all, > I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to FreeBSD > 7.1. With some fiddling it seems to work on both 82598 and 82599 > controllers. > > On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued and > ...lro_flushed to stop incrementing, as expected. There's also a > significant throughput hit which would seem to indicate that it took effect. > > However, it appears that LRO is always enabled on 82599. 'ifconfig ix0 > -lro' removes the LRO flag from the port in ifconfig but the ...hw_lro_merge > counter continues to increase. The throughput reported by the iperf port is > the same with or without LRO on. > > Any advice? Am I misinterpreting something? > > Thanks, > Andrew > > P.S. We need to disable LRO because we don't have Appropriate Byte > Counting support and LRO causes TCP ACK havoc without it. > > -------------------------------------------------- > Andrew Boyer aboyer@averesystems.com > > > > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed May 12 20:29:16 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 312C41065679 for ; Wed, 12 May 2010 20:29:16 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id B572C8FC13 for ; Wed, 12 May 2010 20:29:15 +0000 (UTC) Received: by wwd20 with SMTP id 20so429979wwd.13 for ; Wed, 12 May 2010 13:29:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=heolT5ouogaaLK6FfZTk/tKBqcT7fof8tTxSveB/jxo=; b=KDTDK9sApgLrHKhrtVpyTvk5iLfEUa4xB/i7l34u4HicGTepGzcOQewNcgxN68GRvx e99O2+C9sCt2pMLkB7V85S6Oz+MFhDFcLkEzWx9Vg1l2HgqHuJGXiguvhCqxlIIE9y2h kYuQTY3wXWxLdn1Mo4tnKwCGduLAN7inb1VZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=GUzZGmNjyP/JuEbD4IREJIkBCbEi1eF9fJ9jLgty5vXh9vfO+kt6/GV2Fno+VjSMyr 7e129maNgJoOpEAPbs+1ULjLyGrUAxBwnV5Yal+nW11rDJeFWN2+fCr56HhzIJrQKo9I NUwAxtXbqxhJwkJI/n1W/1m627L9SYS53bKIk= MIME-Version: 1.0 Received: by 10.216.174.76 with SMTP id w54mr4830819wel.213.1273696154485; Wed, 12 May 2010 13:29:14 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Wed, 12 May 2010 13:29:13 -0700 (PDT) In-Reply-To: References: Date: Wed, 12 May 2010 13:29:13 -0700 Message-ID: From: Jack Vogel To: Andrew Boyer Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re: ixgbe 2.1.7 can't disable LRO on 82599? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2010 20:29:16 -0000 Correction, the 82599 is doing HW RSC, I'm sluggish after a good Indian lunch :) On Wed, May 12, 2010 at 1:28 PM, Jack Vogel wrote: > Oh, this is because the 82598 is doing HW RSC which is a different code > path from the LRO that the 598 > does, and that may be the problem, I will need to look into that. Thanks > for the report. > > And, yes, LRO is a major improvement in 10G performance, as is TSO. Are you > sure you have no > alternative to disabling? > > Cheers, > > Jack > > > > On Wed, May 12, 2010 at 12:03 PM, Andrew Boyer wrote: > >> Hello all, >> I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to FreeBSD >> 7.1. With some fiddling it seems to work on both 82598 and 82599 >> controllers. >> >> On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued and >> ...lro_flushed to stop incrementing, as expected. There's also a >> significant throughput hit which would seem to indicate that it took effect. >> >> However, it appears that LRO is always enabled on 82599. 'ifconfig ix0 >> -lro' removes the LRO flag from the port in ifconfig but the ...hw_lro_merge >> counter continues to increase. The throughput reported by the iperf port is >> the same with or without LRO on. >> >> Any advice? Am I misinterpreting something? >> >> Thanks, >> Andrew >> >> P.S. We need to disable LRO because we don't have Appropriate Byte >> Counting support and LRO causes TCP ACK havoc without it. >> >> -------------------------------------------------- >> Andrew Boyer aboyer@averesystems.com >> >> >> >> >> _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >> > > From owner-freebsd-net@FreeBSD.ORG Thu May 13 13:53:29 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD1A1065673; Thu, 13 May 2010 13:53:29 +0000 (UTC) (envelope-from rpaulo@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 070628FC1C; Thu, 13 May 2010 13:53:29 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DDrS69067828; Thu, 13 May 2010 13:53:28 GMT (envelope-from rpaulo@freefall.freebsd.org) Received: (from rpaulo@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DDrRVU067824; Thu, 13 May 2010 13:53:27 GMT (envelope-from rpaulo) Date: Thu, 13 May 2010 13:53:27 GMT Message-Id: <201005131353.o4DDrRVU067824@freefall.freebsd.org> To: vince@unsane.co.uk, rpaulo@FreeBSD.org, freebsd-net@FreeBSD.org From: rpaulo@FreeBSD.org Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 13:53:29 -0000 Synopsis: [ath] [wlan] device timeouts for ath wlan device on recent stable. State-Changed-From-To: open->feedback State-Changed-By: rpaulo State-Changed-When: Thu May 13 13:52:34 UTC 2010 State-Changed-Why: Can you try 8.0-RELEASE again? I want to make sure that the problem isn't hardware related. http://www.freebsd.org/cgi/query-pr.cgi?pr=146517 From owner-freebsd-net@FreeBSD.ORG Thu May 13 15:48:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6CE5F1065725 for ; Thu, 13 May 2010 15:48:54 +0000 (UTC) (envelope-from aboyer@averesystems.com) Received: from zimbra.averesystems.com (75-149-8-243-Pennsylvania.hfc.comcastbusiness.net [75.149.8.243]) by mx1.freebsd.org (Postfix) with ESMTP id 2478F8FC1C for ; Thu, 13 May 2010 15:48:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zimbra.averesystems.com (Postfix) with ESMTP id DA9758BC04C for ; Thu, 13 May 2010 11:48:36 -0400 (EDT) X-Virus-Scanned: amavisd-new at averesystems.com Received: from zimbra.averesystems.com ([127.0.0.1]) by localhost (zimbra.averesystems.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1SVPrzudkbQ for ; Thu, 13 May 2010 11:48:35 -0400 (EDT) Received: from riven.arriad.com (fw.arriad.com [10.0.0.16]) by zimbra.averesystems.com (Postfix) with ESMTPSA id DD5FF8BC048 for ; Thu, 13 May 2010 11:48:34 -0400 (EDT) From: Andrew Boyer Mime-Version: 1.0 (Apple Message framework v1078) Date: Thu, 13 May 2010 11:48:49 -0400 In-Reply-To: To: freebsd-net@freebsd.org References: Message-Id: <9CD0086A-0B7C-4D13-B8BD-3380634597F3@averesystems.com> X-Mailer: Apple Mail (2.1078) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: ixgbe 2.1.7 can't disable LRO on 82599? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 15:48:54 -0000 All,=20 The solution was simple. Check to make sure the IFCAP_LRO bit is set = before calling ixgbe_setup_hw_rsc(). -Andrew --- a/src/sys/dev/ixgbe/ixgbe.c +++ b/src/sys/dev/ixgbe/ixgbe.c @@ -3728,6 +3728,9 @@ ixgbe_setup_receive_ring(struct rx_ring *rxr) ** Disable RSC when RXCSUM is off */ if ((adapter->hw.mac.type =3D=3D ixgbe_mac_82599EB) && + (ifp->if_capenable & IFCAP_LRO) && (ifp->if_capenable & IFCAP_RXCSUM)) ixgbe_setup_hw_rsc(rxr); else if (ifp->if_capenable & IFCAP_LRO) { On May 12, 2010, at 4:29 PM, Jack Vogel wrote: > Correction, the 82599 is doing HW RSC, I'm sluggish after a good = Indian lunch :) >=20 >=20 > On Wed, May 12, 2010 at 1:28 PM, Jack Vogel wrote: > Oh, this is because the 82598 is doing HW RSC which is a different = code path from the LRO that the 598 > does, and that may be the problem, I will need to look into that. = Thanks for the report. >=20 > And, yes, LRO is a major improvement in 10G performance, as is TSO. = Are you sure you have no > alternative to disabling? >=20 > Cheers, >=20 > Jack >=20 >=20 > On Wed, May 12, 2010 at 12:03 PM, Andrew Boyer = wrote: > Hello all, > I'm using the 2.1.7 version of ixgbe from -CURRENT, backported to = FreeBSD 7.1. With some fiddling it seems to work on both 82598 and = 82599 controllers. >=20 > On 82598, 'ifconfig ix0 -lro' causes dev.ix.0.counters.rxr0.lro_queued = and ...lro_flushed to stop incrementing, as expected. There's also a = significant throughput hit which would seem to indicate that it took = effect. >=20 > However, it appears that LRO is always enabled on 82599. 'ifconfig = ix0 -lro' removes the LRO flag from the port in ifconfig but the = ...hw_lro_merge counter continues to increase. The throughput reported = by the iperf port is the same with or without LRO on. >=20 > Any advice? Am I misinterpreting something? >=20 > Thanks, > Andrew >=20 > P.S. We need to disable LRO because we don't have Appropriate Byte = Counting support and LRO causes TCP ACK havoc without it. -------------------------------------------------- Andrew Boyer aboyer@averesystems.com From owner-freebsd-net@FreeBSD.ORG Thu May 13 21:30:10 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6288D1065672 for ; Thu, 13 May 2010 21:30:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 384FA8FC0C for ; Thu, 13 May 2010 21:30:10 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4DLUAfs063245 for ; Thu, 13 May 2010 21:30:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4DLUAkm063240; Thu, 13 May 2010 21:30:10 GMT (envelope-from gnats) Date: Thu, 13 May 2010 21:30:10 GMT Message-Id: <201005132130.o4DLUAkm063240@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Vincent Hoffman Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vincent Hoffman List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2010 21:30:10 -0000 The following reply was made to PR kern/146517; it has been noted by GNATS. From: Vincent Hoffman To: bug-followup@FreeBSD.org, vince@unsane.co.uk Cc: Subject: Re: kern/146517: [ath] [wlan] device timeouts for ath wlan device on recent stable. Date: Thu, 13 May 2010 22:22:59 +0100 Hi, I retested using the 8.0-RELEASE usb livefs. I did not get any timeouts. I did see some packet loss (approx 5-10%) however which I dont remember seeing when i was at 8-RELEASE. Vince From owner-freebsd-net@FreeBSD.ORG Fri May 14 03:18:21 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E40E106564A; Fri, 14 May 2010 03:18:21 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 64F718FC1C; Fri, 14 May 2010 03:18:21 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4E3IL5D063007; Fri, 14 May 2010 03:18:21 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4E3ILKR063003; Fri, 14 May 2010 03:18:21 GMT (envelope-from linimon) Date: Fri, 14 May 2010 03:18:21 GMT Message-Id: <201005140318.o4E3ILKR063003@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146539: [arp] arp pub not working properly X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 03:18:21 -0000 Old Synopsis: arp pub not working properly New Synopsis: [arp] arp pub not working properly Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 14 03:18:06 UTC 2010 Responsible-Changed-Why: Over to maintainer. http://www.freebsd.org/cgi/query-pr.cgi?pr=146539 From owner-freebsd-net@FreeBSD.ORG Fri May 14 06:59:58 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D74FC106566C for ; Fri, 14 May 2010 06:59:58 +0000 (UTC) (envelope-from cmb@pfsense.org) Received: from mail.pfsense.org (mail.pfsense.org [69.64.6.29]) by mx1.freebsd.org (Postfix) with ESMTP id B397F8FC0A for ; Fri, 14 May 2010 06:59:58 +0000 (UTC) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.pfsense.org (Postfix) with ESMTP id B29F925136 for ; Fri, 14 May 2010 01:42:18 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.pfsense.org Received: from mail.pfsense.org ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mb0POnSZR8Ri for ; Fri, 14 May 2010 01:42:12 -0500 (EST) Received: from [172.29.28.10] (unknown [172.29.28.10]) by mail.pfsense.org (Postfix) with ESMTPSA id C3A8A23A6E for ; Fri, 14 May 2010 01:42:11 -0500 (EST) Message-Id: From: Chris Buechler To: net@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 14 May 2010 02:42:09 -0400 X-Mailer: Apple Mail (2.936) Cc: Subject: regression in dc(4) from 7.2 to RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 06:59:58 -0000 one of our users has reported a regression in dc(4) on RELENG_8, the cards work fine on 7.2 and previous versions, but no longer function at all with RELENG_8 as of about a week ago. http://forum.pfsense.org/index.php/topic,24964.msg129488.html#msg129488 dmesg from it working, from 7.2: cbb0: at device 11.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [ITHREAD] cbb1: at device 11.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [ITHREAD] dc0: port 0x1080-0x10ff mem 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on cardbus0 miibus1: on dc0 tdkphy0: PHY 0 on miibus1 tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:xx:xx:xx:xx:56 dc0: [ITHREAD] dc1: port 0x1100-0x117f mem 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on cardbus1 miibus2: on dc1 tdkphy1: PHY 0 on miibus2 tdkphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc1: Ethernet address: 00:xx:xx:xx:xx:66 dc1: [ITHREAD] Not working, RELENG_8: cbb0: at device 11.0 on pci0 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 cbb0: [FILTER] cbb1: at device 11.1 on pci0 cardbus1: on cbb1 pccard1: <16-bit PCCard bus> on cbb1 cbb1: [FILTER] cardbus0: Unable to allocate resource to read CIS. cardbus0: Unable to allocate resources for CIS cardbus0: Unable to allocate resource to read CIS. cardbus0: Unable to allocate resources for CIS dc0: port 0x1080-0x10ff mem 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on cardbus0 dc0: No station address in CIS! device_attach: dc0 attach returned 6 cardbus1: Unable to allocate resource to read CIS. cardbus1: Unable to allocate resources for CIS cardbus1: Unable to allocate resource to read CIS. cardbus1: Unable to allocate resources for CIS dc1: port 0x1080-0x10ff mem 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on cardbus1 dc1: No station address in CIS! device_attach: dc1 attach returned 6 We can apply patches to our builds for this person and others to test and confirm the fix, before it's committed into FreeBSD. Chris From owner-freebsd-net@FreeBSD.ORG Fri May 14 08:56:28 2010 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D1B3A106567B; Fri, 14 May 2010 08:56:28 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (unknown [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id A9E968FC1D; Fri, 14 May 2010 08:56:28 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id o4E8uS4d073492; Fri, 14 May 2010 08:56:28 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id o4E8uSek073488; Fri, 14 May 2010 08:56:28 GMT (envelope-from linimon) Date: Fri, 14 May 2010 08:56:28 GMT Message-Id: <201005140856.o4E8uSek073488@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/146534: [icmp6] wrong source address in echo reply X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 08:56:28 -0000 Old Synopsis: [icmpv6] wrong source address in echo reply New Synopsis: [icmp6] wrong source address in echo reply Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri May 14 08:54:45 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=146534 From owner-freebsd-net@FreeBSD.ORG Fri May 14 07:53:35 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 330F81065670 for ; Fri, 14 May 2010 07:53:35 +0000 (UTC) (envelope-from jiani1012@126.com) Received: from m15-4.126.com (m15-4.126.com [220.181.15.4]) by mx1.freebsd.org (Postfix) with ESMTP id 824158FC22 for ; Fri, 14 May 2010 07:53:31 +0000 (UTC) Received: from jiani1012 ( [124.205.28.146] ) by ajax-webmail-wmsvr4 (Coremail) ; Fri, 14 May 2010 15:53:28 +0800 (CST) Date: Fri, 14 May 2010 15:53:28 +0800 (CST) From: jiani1012 To: "Paul B Mahol" Message-ID: <4ce970a1.1bc70.12895cdbd14.Coremail.jiani1012@126.com> In-Reply-To: References: <20100506120022.A331D10656C2@hub.freebsd.org> <45e58af.dfb8.128723a15b9.Coremail.jiani1012@126.com> MIME-Version: 1.0 X-Originating-IP: [124.205.28.146] X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 100504(10496.3041.3041) Copyright (c) 2002-2010 www.mailtech.cn 126com X-CM-CTRLDATA: qVzyxWZvb3Rlcl9odG09MTgzMzoxMzA= X-CM-TRANSID: BMqowKCLG814Ae1LnmIQAA--.11494W X-CM-SenderInfo: xmld0xarqrjqqrswhudrp/1tbitAnQlEX9dbiJogABsm X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== X-Mailman-Approved-At: Fri, 14 May 2010 11:34:49 +0000 Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-net@freebsd.org Subject: Re:Re: convert Windows NDIS drivers for use with FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 07:53:35 -0000 WWVzLCBJIHVzZSBuZGlzZ2VuKDgpIGluc3RlYWQuIElucHV0IHRoZSBuZXRhdGh3LmluZiBhbmQg YXRody5zeXMgZmlsZSwgYXBwZWFyczoKc2VnbWVudGF0aW9uIGZhdWx0IChjb3JlIGR1bXBlZCkK Q09OVkVSU0lPTiBGQUlMRUQKCgrU2jIwMTAtMDUtMDggMjA6MjA6NDajrCJQYXVsIEIgTWFob2wi IDxvbmVtZGFAZ21haWwuY29tPiDQtLXAo7oKPk9uIDUvNy8xMCwgamlhbmkxMDEyIDxqaWFuaTEw MTJAMTI2LmNvbT4gd3JvdGU6Cj4+IEhpIGFsbCwKPj4gICAgICAgSSBhbSB1c2luZyB4cDMyNjQt Ny43LjAuMzI5LXdocWwuemlwIGZpbGUgZnJvbSBBdGhlcm9zLgo+PiAgICAgICAgICAjY2QgL3N5 cy9tb2R1bGVzL25kaXMKPj4gICAgICAgICAgI21ha2UgaW5zdGFsbAo+PiAgICAgICAgICAjY2Qg L3N5cy9tb2R1bGVzL2lmX25kaXMKPj4gICAgICAgICAgI21ha2UgaW5zdGFsbAo+PiAgICAgICAg ICAjbmRpc2N2dCAtaSBuZXRhdGh3eC5pbmYgLXMgYXRod3guc3lzIC1vIG5kaXNfZHJpdmVyX2Rh dGEuaAo+PiAoc3ludGF4IGVycm9yKQo+PiAgICAgIFdoZW4gdHJ5aW5nIHRvIGNvbnZlcnQgdGhl IG9uZXMgYXRod3guc3lzIGFuZCBuZXRhdGh3eC5pbmYgSSBhbSBnZXR0aW5nCj4+IHRoZSBlcnJv cjoKPj4gICAgICAgICA+IG5kaXNjdnQ6IGxpbmUgNTExNzogOiBzeW50YXggZXJyb3IuCj4+ICAg ICAgICAgPiBDT05WRVJTSU9OIEZBSUxFRAo+PiAgICAgIHNhbWUgZm9yICBuZXRhdGh3LmluZiBh dGh3LnN5cwo+PiAgICAgIEhvdyB0byBkbyBpdD8KPj4gICAgIFRoYW5rIHlvdSBpbiBhZHZhbmNl IQo+Pgo+PiBKZW55Cj4KPldoeSB5b3UgYXJlIG5vdCB1c2luZyBuZGlzZ2VuKDgpPwo= From owner-freebsd-net@FreeBSD.ORG Fri May 14 12:30:10 2010 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E26461065670 for ; Fri, 14 May 2010 12:30:09 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 230698FC18 for ; Fri, 14 May 2010 12:30:08 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA04818; Fri, 14 May 2010 15:13:58 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4BED3E85.5000803@icyb.net.ua> Date: Fri, 14 May 2010 15:13:57 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100319) MIME-Version: 1.0 To: Chris Buechler References: In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Stable , net@freebsd.org Subject: Re: regression in dc(4) from 7.2 to RELENG_8 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:30:10 -0000 on 14/05/2010 09:42 Chris Buechler said the following: > one of our users has reported a regression in dc(4) on RELENG_8, the > cards work fine on 7.2 and previous versions, but no longer function at > all with RELENG_8 as of about a week ago. > http://forum.pfsense.org/index.php/topic,24964.msg129488.html#msg129488 Perhaps this might be a cardbus issue (or even a more general issue) rather than a dc(4) issue. But first please try this patch reversed: --- a/sys/dev/dc/if_dc.c +++ b/sys/dev/dc/if_dc.c @@ -331,7 +331,6 @@ static driver_t dc_driver = { static devclass_t dc_devclass; -DRIVER_MODULE(dc, cardbus, dc_driver, dc_devclass, 0, 0); DRIVER_MODULE(dc, pci, dc_driver, dc_devclass, 0, 0); DRIVER_MODULE(miibus, dc, miibus_driver, miibus_devclass, 0, 0); > dmesg from it working, from 7.2: > cbb0: at device 11.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [ITHREAD] > cbb1: at device 11.1 on pci0 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [ITHREAD] > dc0: port 0x1080-0x10ff mem > 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on > cardbus0 > miibus1: on dc0 > tdkphy0: PHY 0 on miibus1 > tdkphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc0: Ethernet address: 00:xx:xx:xx:xx:56 > dc0: [ITHREAD] > dc1: port 0x1100-0x117f mem > 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on > cardbus1 > miibus2: on dc1 > tdkphy1: PHY 0 on miibus2 > tdkphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto > dc1: Ethernet address: 00:xx:xx:xx:xx:66 > dc1: [ITHREAD] > > Not working, RELENG_8: > cbb0: at device 11.0 on pci0 > cardbus0: on cbb0 > pccard0: <16-bit PCCard bus> on cbb0 > cbb0: [FILTER] > cbb1: at device 11.1 on pci0 > cardbus1: on cbb1 > pccard1: <16-bit PCCard bus> on cbb1 > cbb1: [FILTER] > cardbus0: Unable to allocate resource to read CIS. > cardbus0: Unable to allocate resources for CIS > cardbus0: Unable to allocate resource to read CIS. > cardbus0: Unable to allocate resources for CIS > dc0: port 0x1080-0x10ff mem > 0x88000000-0x880007ff,0x88001000-0x880017ff irq 11 at device 0.0 on > cardbus0 > dc0: No station address in CIS! > device_attach: dc0 attach returned 6 > cardbus1: Unable to allocate resource to read CIS. > cardbus1: Unable to allocate resources for CIS > cardbus1: Unable to allocate resource to read CIS. > cardbus1: Unable to allocate resources for CIS > dc1: port 0x1080-0x10ff mem > 0x88002000-0x880027ff,0x88003000-0x880037ff irq 11 at device 0.0 on > cardbus1 > dc1: No station address in CIS! > device_attach: dc1 attach returned 6 > > > We can apply patches to our builds for this person and others to test > and confirm the fix, before it's committed into FreeBSD. > > Chris > > _______________________________________________ > 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" > -- Andriy Gapon From owner-freebsd-net@FreeBSD.ORG Fri May 14 12:39:08 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 036D2106566C for ; Fri, 14 May 2010 12:39:08 +0000 (UTC) (envelope-from to.my.trociny@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by mx1.freebsd.org (Postfix) with ESMTP id 827AE8FC16 for ; Fri, 14 May 2010 12:39:07 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id l26so1244084fgb.13 for ; Fri, 14 May 2010 05:39:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:subject :organization:references:date:in-reply-to:message-id:user-agent :mime-version:content-type; bh=UfyvZsfG96h7jcfDBaLNbYYQziHVYzRUOHWbdFXwGZM=; b=PF54b5AId5XYhHTDilGOQhO9b/V/G4WCLIHt1XblgLrDGNmcvmouFv7HPieY7Lf+Iw kL4ufb6aSuyz0J9B/y9LkFovOcHQlafY5Bs13YvQ69sMAQUsOEaziD0bsk70EBm0ArTg 58Pvw7i7iUBMdZIPY8TEBCN6PnWMj1XpS5Ot0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:subject:organization:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; b=qEWtzwvJ3llXoujSrhnVZK+6gt7ko0RKcCfLn6FpGYkqJ66NoqPXgXQRwvQReNxJpI sz9ib7m8QiouDSqvl+lcCHKBqUgCPkE5HS4/l2na6kCVGAPUQZf+5mH9CpD+sTuOkKSO fCkHnVBOjMZDyrPuJo7CnzNrRBGjqiH8p+4FE= Received: by 10.87.71.21 with SMTP id y21mr2682476fgk.69.1273840746385; Fri, 14 May 2010 05:39:06 -0700 (PDT) Received: from localhost (ua1.etadirect.net [91.198.140.16]) by mx.google.com with ESMTPS id 3sm818878fge.5.2010.05.14.05.39.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 05:39:05 -0700 (PDT) From: Mikolaj Golub To: Julian Elischer Organization: TOA Ukraine References: <201005111814.o4BIEPfN071211@lava.sentex.ca> <4BE9BCE2.7070303@elischer.org> Date: Fri, 14 May 2010 15:39:03 +0300 In-Reply-To: <4BE9BCE2.7070303@elischer.org> (Julian Elischer's message of "Tue, 11 May 2010 13:24:02 -0700") Message-ID: <86pr0yiro8.fsf@zhuzha.ua1> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-net@freebsd.org, Mike Tancsa , Wes Peters Subject: Re: sockstat / netstat output 8.x vs 7.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 12:39:08 -0000 On Tue, 11 May 2010 13:24:02 -0700 Julian Elischer wrote: JE> On 5/11/10 12:20 PM, Wes Peters wrote: >> The output header is instructive: >> >> USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS >> www httpd 18423 3 tcp4 6 *:80 *:* >> www httpd 18423 4 tcp4 *:* *:* >> www httpd 25184 3 tcp4 6 *:80 *:* >> www httpd 25184 4 tcp4 *:* *:* >> >> Same as 7, it's the foreign address. This is normally only useful for >> connected sockets. >> >> On Tue, May 11, 2010 at 11:14 AM, Mike Tancsa wrote: >>> [trying on freebsd-net since no response on stable] >>> >>> I noticed that apache on RELENG_8 and RELENG_7 shows up with output I cant >>> seem to understand from sockstat -l and netstat -naW >>> >>> On RELENG_7, sockstat -l makes sense to me >>> .... >>> www httpd 83005 4 tcp4 *:443 *:* >>> www httpd 82217 3 tcp4 *:80 *:* >>> www httpd 82217 4 tcp4 *:443 *:* >>> www httpd 38942 3 tcp4 *:80 *:* >>> www httpd 38942 4 tcp4 *:443 *:* >>> root httpd 1169 3 tcp4 *:80 *:* >>> root httpd 1169 4 tcp4 *:443 *:* >>> >>> >>> various processes listening on all bound IP addresses on ports 80 and 443. >>> >>> On RELENG_8 however, it shows up with an extra entry (at the end) >>> >>> www httpd 29005 4 tcp4 *:* *:* >>> www httpd 29004 3 tcp4 6 *:80 *:* >>> www httpd 29004 4 tcp4 *:* *:* >>> www httpd 29003 3 tcp4 6 *:80 *:* >>> www httpd 29003 4 tcp4 *:* *:* >>> www httpd 66731 3 tcp4 6 *:80 *:* >>> www httpd 66731 4 tcp4 *:* *:* >>> root httpd 72197 3 tcp4 6 *:80 *:* >>> root httpd 72197 4 tcp4 *:* *:* >>> >>> >>> *:80 makes sense to me... process is listening on all IPs for port 80. What >>> does *:* mean then ? JE> I believe it has created a socket but not used it for anything JE> it may be the 6 socket... otherwise I don't see what a "tcp4 6" is JE> meant to be. Comparing RELENG_8 and RELENG_7 outputs it might be for https, which looks like is not configured on RELENG_8 host. I think socket() was called but no any other actions with the socket was performed. >>> >>> Netstat gives a slightly different version of it >>> >>> Active Internet connections (including servers) >>> Proto Recv-Q Send-Q Local Address Foreign Address (state) >>> tcp4 0 0 *.1984 *.* LISTEN >>> tcp4 0 0 *.* *.* CLOSED >>> tcp46 0 0 *.80 *.* LISTEN >>> >>> state closed ? You can reproduce this with this simple program: zhuzha:~/src/test_socket% cat test.c #include #include #include #include #include int main(int argc, char **argv) { int sockfd; if ((sockfd = socket(AF_INET, SOCK_STREAM, 0)) < 0) errx(1, "socket error"); sleep(60); return 0; } zhuzha:~/src/test_socket% make cc -g -O0 -Wall test.c -o test zhuzha:~/src/test_socket% ./test& [1] 56076 zhuzha:~/src/test_socket% sockstat|grep test golub test 56076 3 tcp4 *:* *:* zhuzha:~/src/test_socket% netstat -na |grep CLOSED tcp4 0 0 *.* *.* CLOSED -- Mikolaj Golub From owner-freebsd-net@FreeBSD.ORG Fri May 14 14:01:17 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46EE6106564A; Fri, 14 May 2010 14:01:17 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 270868FC14; Fri, 14 May 2010 14:01:09 +0000 (UTC) Received: by gwj16 with SMTP id 16so1525377gwj.13 for ; Fri, 14 May 2010 07:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=0yvqTnCrJxEGBPHRrjRmWnC7w5/rzJyxOyM4xZjTS5g=; b=ORbeAAhCWsklLBcMkpUNRMVkvpOF/U+evl/7ZQxjddAf6p76QZWpcspGvMex/VGFqE /F072nqiT1rBE/XQhBlxoMEFrZNp3LosqXJhBWbbd9aGoHp65kiGGbpWpfReQfH/oLwj K7J9hhhuYrv3S2sNYLBRwD6A438cg9ovxaMqU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hI7c9yqdVm2WBvhGpDYhqWPCIz7Syo/XhmD7OsOBgao8wxUKqv8ZA0XW/QchHmUGal HIQG+mfhJoIfwamSgW3uJYMtIBWyhln6zP/pSjDsE9dcaxT1L8j3jBlAOpGe4HMVnfYR tWZ74aRZKIYsk1Jcag6kOGdm05eP9ZBNpGEr4= MIME-Version: 1.0 Received: by 10.101.196.30 with SMTP id y30mr1087611anp.251.1273843928706; Fri, 14 May 2010 06:32:08 -0700 (PDT) Received: by 10.100.58.2 with HTTP; Fri, 14 May 2010 06:32:08 -0700 (PDT) In-Reply-To: <20100511135103.GA29403@grapeape2.cs.duke.edu> References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> Date: Fri, 14 May 2010 09:32:08 -0400 Message-ID: From: Alexander Sack To: Andrew Gallatin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:01:17 -0000 On Tue, May 11, 2010 at 9:51 AM, Andrew Gallatin wro= te: > Murat Balaban [murat@enderunix.org] wrote: >> >> Much of the FreeBSD networking stack has been made parallel in order to >> cope with high packet rates at 10 Gig/sec operation. >> >> I've seen good numbers (near 10 Gig) in my tests involving TCP/UDP >> send/receive. (latest Intel driver). >> >> As far as BPF is concerned, above statement does not hold true, >> since there is some work that needs to be done here in terms >> of BPF locking and parallelism. My tests show that there >> is a high lock contention around "bpf interface lock", resulting >> in input errors at high packet rates and with many bpf devices. > > If you're interested in 10GbE packet sniffing at line rate on the > cheap, have a look at the Myri10GE "sniffer" interface. =A0This is a > special software package that takes a normal mxge(4) NIC, and replaces > the driver/firmware with a "myri_snf" driver/firmware which is > optimized for packet sniffing. > > Using this driver/firmware combo, we can receive minimal packets at > line rate (14.8Mpps) to userspace. =A0You can even access this using a > libpcap interface. =A0The trick is that the fast paths are OS-bypass, > and don't suffer from OS overheads, like lock contention. =A0See > http://www.myri.com/scs/SNF/doc/index.html for details. But your timestamps will be atrocious at 10G speeds. Myricom doesn't timestamp packets AFAIK. If you want reliable timestamps you need to look at companies like Endace, Napatech, etc. We do a lot of packet capture and work on bpf(4) all the time. My biggest concern for reliable 10G packet capture is timestamps. The call to microtime up in catchpacket() is not going to cut it (it barely cuts it for GIGE line rate speeds). I'd be interested in doing the multi-queue bpf(4) myself (perhaps I should ask? I don't know if non-summer-of-code folks are allowed?). I believe the goal is not so much throughput but cache affinity. It would be nice if say the listener application (libpcap) could bind itself to the same core that the driver's queue is receiving packets on so everything from catching to post-processing all work with a very warm cache (theoretically). I think that's the idea. It would also allow multiple applications to subscribe to potentially different queues that are doing some form of load balancing. Again, Intel's 82599 chipset supports flow based queues (albeit the size of the flow table is limited). Note, zero-copy bpf(4) is your friend in all use cases at 10G speeds! :) -aps PS I am not sure but Intel also supports writing packets directly in cache (yet I thought the 82599 driver actually does a prefetch anyway which had me confused on why that helps) From owner-freebsd-net@FreeBSD.ORG Fri May 14 14:07:54 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3A107106564A; Fri, 14 May 2010 14:07:54 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id ED92F8FC0A; Fri, 14 May 2010 14:07:53 +0000 (UTC) Received: from [172.31.193.10] (rrcs-98-101-145-84.midsouth.biz.rr.com [98.101.145.84]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o4EE7jas024681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 10:07:45 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o4EE7jas024681 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1273846067; bh=kXi5tWSmoSa8QcZzXchvHOCewVYqctK7J0WUDkPf6hc=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=sL95rcXK77xDld358fA5oQ7Z5vCe/Xag1v6oR05mOPKvVieK20O94ANwkhWcBvdiH Z3oijdWQeM7pIzFQinoS1Q1NAbxiYxPBqDBuHWBy66KhsC6yciiXA8zDGU6MacKsIv v5H6RMOZNH8N9UtNq7vIab5fbEp4moRxeV0SHnz8= Message-ID: <4BED5929.5020302@cs.duke.edu> Date: Fri, 14 May 2010 10:07:37 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Sack References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 14:07:54 -0000 Alexander Sack wrote: <...> >> Using this driver/firmware combo, we can receive minimal packets at >> line rate (14.8Mpps) to userspace. You can even access this using a >> libpcap interface. The trick is that the fast paths are OS-bypass, >> and don't suffer from OS overheads, like lock contention. See >> http://www.myri.com/scs/SNF/doc/index.html for details. > > But your timestamps will be atrocious at 10G speeds. Myricom doesn't > timestamp packets AFAIK. If you want reliable timestamps you need to > look at companies like Endace, Napatech, etc. I see your old help ticket in our system. Yes, our timestamping is not as good as a dedicated capture card with a GPS reference, but it is good enough for most people. > PS I am not sure but Intel also supports writing packets directly in > cache (yet I thought the 82599 driver actually does a prefetch anyway > which had me confused on why that helps) You're talking about DCA. We support DCA as well (and I suspect some other 10G NICs do to). There are a few barriers to using DCA on FreeBSD, not least of which is that FreeBSD doesn't currently have the infrastructure to support it (no IOATDMA or DCA drivers). DCA is also problematic because support from system/motherboard vendors is very spotty. The vendor must provide the correct tag table in BIOS such that the tags match the CPU/core numbering in the system. Many motherboard vendors don't bother with this, and you cannot enable DCA on a lot of systems, even though the underlying chipset supports DCA. I've done hacks to force-enable it in the past, with mixed results. The problem is that DCA depends on having the correct tag table, so that packets can be prefetched into the correct CPU's cache. If the tag table is incorrect, DCA is a big pessimization, because it blows the cache in other CPUs. That said, I would *love* it if FreeBSD grew ioatdma/dca support. Jack, does Intel have any interest in porting DCA support to FreeBSD? Drew From owner-freebsd-net@FreeBSD.ORG Fri May 14 15:18:38 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F8261065673; Fri, 14 May 2010 15:18:38 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 360AB8FC15; Fri, 14 May 2010 15:18:37 +0000 (UTC) Received: by gyh20 with SMTP id 20so1516731gyh.13 for ; Fri, 14 May 2010 08:18:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ZJmkRaUGSWNAOue41Aq+/ib7rODr3nrVpztvpGlNPgE=; b=Ou8l2DMizPpyp2L0B3BFrt8eSi9sR36qCpfuCfjHBnD/8HuzzYmK349cOpN5pfg6nX mj9YbQl4KcoJnXx3UwidmszOjPaHTAp/2WZ2Ib+X7JC1uFrL9UswyX2HTFxRAxj7zfoJ OzgKeIM4M/uClgsBM1Vf3vkYHevTKY/6awyQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=NaYpCVpB7tBWMPuklzuYqHUyOhzNKJZi70jEWpX8Dc66lXqw5R345GopzTrvgt5AP8 4dTXnMRILh1ojPl/k0+MydBg8FbrpTa8f6MZImECxL8Ru9uClNc0zpV5ZbmBAy4WQtsD h/fXZoK7NDCAtFocB9erajUfsXcx+nSML8+6A= MIME-Version: 1.0 Received: by 10.101.203.9 with SMTP id f9mr1446280anq.208.1273850314273; Fri, 14 May 2010 08:18:34 -0700 (PDT) Received: by 10.100.58.2 with HTTP; Fri, 14 May 2010 08:18:33 -0700 (PDT) In-Reply-To: <4BED5929.5020302@cs.duke.edu> References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> Date: Fri, 14 May 2010 11:18:33 -0400 Message-ID: From: Alexander Sack To: Andrew Gallatin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:18:38 -0000 On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin wr= ote: > Alexander Sack wrote: > <...> >>> Using this driver/firmware combo, we can receive minimal packets at >>> line rate (14.8Mpps) to userspace. =A0You can even access this using a >>> libpcap interface. =A0The trick is that the fast paths are OS-bypass, >>> and don't suffer from OS overheads, like lock contention. =A0See >>> http://www.myri.com/scs/SNF/doc/index.html for details. >> >> But your timestamps will be atrocious at 10G speeds. =A0Myricom doesn't >> timestamp packets AFAIK. =A0If you want reliable timestamps you need to >> look at companies like Endace, Napatech, etc. > > I see your old help ticket in our system. =A0Yes, our timestamping > is not as good as a dedicated capture card with a GPS reference, > but it is good enough for most people. I was told btw that it doesn't timestamp at ALL. I am assuming NOW that is incorrect. Define *most* people. I am not knocking the Myricom card. In fact I so wish you guys would just add the ability to latch to a 1PPS for timestamping and it would be perfect. We use I think an older version of the card internally for replay. Its a great multi-purpose card. However with IPG at 10G in the nanoseconds, anyone trying to do OWDs or RTT will find it difficult compared to an Endace or Napatech card. Btw, I was referring to bpf(4) specifically, so please don't take my comments as a knock against it. >> PS I am not sure but Intel also supports writing packets directly in >> cache (yet I thought the 82599 driver actually does a prefetch anyway >> which had me confused on why that helps) > > You're talking about DCA. =A0We support DCA as well (and I suspect some > other 10G NICs do to). =A0There are a few barriers to using DCA on > FreeBSD, not least of which is that FreeBSD doesn't currently have the > infrastructure to support it (no IOATDMA or DCA drivers). Right. > DCA is also problematic because support from system/motherboard > vendors is very spotty. =A0The vendor must provide the correct tag table > in BIOS such that the tags match the CPU/core numbering in the system. > Many motherboard vendors don't bother with this, and you cannot enable > DCA on a lot of systems, even though the underlying chipset supports > DCA. =A0I've done hacks to force-enable it in the past, with mixed > results. The problem is that DCA depends on having the correct tag > table, so that packets can be prefetched into the correct CPU's cache. > If the tag table is incorrect, DCA is a big pessimization, because it > blows the cache in other CPUs. Right. > That said, I would *love* it if FreeBSD grew ioatdma/dca support. > Jack, does Intel have any interest in porting DCA support to FreeBSD? Question for Jack or Drew, what DOES FreeBSD have to do to support DCA? I thought DCA was something you just enable on the NIC chipset and if the system is IOATDMA aware, it just works. Is that not right (assuming cache tags are correct and accessible)? i.e. I thought this was hardware black magic than anything specific the OS has to do. -aps From owner-freebsd-net@FreeBSD.ORG Fri May 14 15:41:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DEFB81065680; Fri, 14 May 2010 15:41:30 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id AE9D68FC15; Fri, 14 May 2010 15:41:30 +0000 (UTC) Received: from [172.31.193.10] (rrcs-98-101-145-84.midsouth.biz.rr.com [98.101.145.84]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o4EFfMw4029229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 11:41:22 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o4EFfMw4029229 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1273851682; bh=UhxsDdqkR9mVhD1eRi0qYT3pEt2QSIHMcGElkeZQMRo=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=ItOz9nPi0INCIFRVqrgmAUcUDYQkel7bM1RNBGJH+axu/6wlcIV08ynDblvGwHbk5 +E1gvUIpl54q4TCEDfQDQFe04cgmoeScbQwYwnhMK4HCZ+mnvaYWCRQQ/v7pEXM7bG H9HE5W3zhXv7aTDwD8mYIclfp4olR/IjWbffb/Y8= Message-ID: <4BED6F1B.7070602@cs.duke.edu> Date: Fri, 14 May 2010 11:41:15 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Sack References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 15:41:31 -0000 Alexander Sack wrote: > On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin wrote: >> Alexander Sack wrote: >> <...> >>>> Using this driver/firmware combo, we can receive minimal packets at >>>> line rate (14.8Mpps) to userspace. You can even access this using a >>>> libpcap interface. The trick is that the fast paths are OS-bypass, >>>> and don't suffer from OS overheads, like lock contention. See >>>> http://www.myri.com/scs/SNF/doc/index.html for details. >>> But your timestamps will be atrocious at 10G speeds. Myricom doesn't >>> timestamp packets AFAIK. If you want reliable timestamps you need to >>> look at companies like Endace, Napatech, etc. >> I see your old help ticket in our system. Yes, our timestamping >> is not as good as a dedicated capture card with a GPS reference, >> but it is good enough for most people. > > I was told btw that it doesn't timestamp at ALL. I am assuming NOW > that is incorrect. I think you might have misunderstood how we do timestamping. I definately don't understand it, and I work there ;) I do know that there is NIC component of it (eg, it is not 100% done in the host). I also realize that it is not is good as something that is 1PPS GPS based. > Define *most* people. I may have a skewed view of the market, but it seems like some people care deeply about accurate timestamps, and others (mostly doing deep packet inspection) care only within a few milliseconds, or even seconds. > I am not knocking the Myricom card. In fact I so wish you guys would > just add the ability to latch to a 1PPS for timestamping and it would > be perfect. > > We use I think an older version of the card internally for replay. > Its a great multi-purpose card. > > However with IPG at 10G in the nanoseconds, anyone trying to do OWDs > or RTT will find it difficult compared to an Endace or Napatech card. > > Btw, I was referring to bpf(4) specifically, so please don't take my > comments as a knock against it. > >>> PS I am not sure but Intel also supports writing packets directly in >>> cache (yet I thought the 82599 driver actually does a prefetch anyway >>> which had me confused on why that helps) >> You're talking about DCA. We support DCA as well (and I suspect some >> other 10G NICs do to). There are a few barriers to using DCA on >> FreeBSD, not least of which is that FreeBSD doesn't currently have the >> infrastructure to support it (no IOATDMA or DCA drivers). > > Right. > >> DCA is also problematic because support from system/motherboard >> vendors is very spotty. The vendor must provide the correct tag table >> in BIOS such that the tags match the CPU/core numbering in the system. >> Many motherboard vendors don't bother with this, and you cannot enable >> DCA on a lot of systems, even though the underlying chipset supports >> DCA. I've done hacks to force-enable it in the past, with mixed >> results. The problem is that DCA depends on having the correct tag >> table, so that packets can be prefetched into the correct CPU's cache. >> If the tag table is incorrect, DCA is a big pessimization, because it >> blows the cache in other CPUs. > > Right. > >> That said, I would *love* it if FreeBSD grew ioatdma/dca support. >> Jack, does Intel have any interest in porting DCA support to FreeBSD? > > Question for Jack or Drew, what DOES FreeBSD have to do to support > DCA? I thought DCA was something you just enable on the NIC chipset > and if the system is IOATDMA aware, it just works. Is that not right > (assuming cache tags are correct and accessible)? i.e. I thought this > was hardware black magic than anything specific the OS has to do. IOATDMA and DCA are sort of unfairly joined for two reasons: The DCA control stuff is implemented as part of the IOATDMA PCIe device, and IOATDMA is a great usage model for DCA, since you'd want the DMAs that it does to be prefetched. To use DCA you need: - A DCA driver to talk to the IOATDMA/DCA pcie device, and obtain the tag table - An interface that a client device (eg, NIC driver) can use to obtain either the tag table, or at least the correct tag for the CPU that the interrupt handler is bound to. The basic support in a NIC driver boils down to something like: nic_interrupt_handler() { if (sc->dca.enabled && (curcpu != sc->dca.last_cpu)) { sc->dca.last_cpu = curcpu; tag = dca_get_tag(curcpu); WRITE_REG(sc, DCA_TAG, tag); } } Drew From owner-freebsd-net@FreeBSD.ORG Fri May 14 16:13:43 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA1D1106566C; Fri, 14 May 2010 16:13:43 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-yx0-f185.google.com (mail-yx0-f185.google.com [209.85.210.185]) by mx1.freebsd.org (Postfix) with ESMTP id 4C21A8FC17; Fri, 14 May 2010 16:13:42 +0000 (UTC) Received: by yxe15 with SMTP id 15so1154511yxe.7 for ; Fri, 14 May 2010 09:13:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=lfOS74UNxkCZAgwh/zVgcRQF2ud/eUL9uJjW4s62ips=; b=TRTgwISCY1g4g+AgFho4CGCNLMpbtqw5fAPF2YX00wlQNV9VRE4JTD1xb56lZZhFyM FA2+i5gqmUJd2um5lSVt0JKYVLNf91oGCwZzsE5P1sOCNpx+yZLh78AQ+6y9SBi2Lfnn pNEEeJxE6zTOl8Ca7cCFKvrLrC0APcSHTC37g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=gI5SbI53GxyAn4NWrpDGmEu+r6nY/NDJ16oywzzVZ+AWtQ7ABjCYoBX+hKSlzKO5R4 O+gJ3W1BHMG/FQEHozSsfdnhyBwIzXmpSC+cGzpvnsdRtcU+XcFZFKz3fLm6R0Gpndov Db+0gral/0ub5ycsMxMyNHF8e0jzhzirLUtBo= MIME-Version: 1.0 Received: by 10.101.203.9 with SMTP id f9mr1519158anq.208.1273853622431; Fri, 14 May 2010 09:13:42 -0700 (PDT) Received: by 10.100.58.2 with HTTP; Fri, 14 May 2010 09:13:42 -0700 (PDT) In-Reply-To: <4BED6F1B.7070602@cs.duke.edu> References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> <4BED6F1B.7070602@cs.duke.edu> Date: Fri, 14 May 2010 12:13:42 -0400 Message-ID: From: Alexander Sack To: Andrew Gallatin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:13:43 -0000 On Fri, May 14, 2010 at 11:41 AM, Andrew Gallatin wr= ote: > Alexander Sack wrote: >> On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin >> wrote: >>> Alexander Sack wrote: >>> <...> >>>>> Using this driver/firmware combo, we can receive minimal packets at >>>>> line rate (14.8Mpps) to userspace. =A0You can even access this using = a >>>>> libpcap interface. =A0The trick is that the fast paths are OS-bypass, >>>>> and don't suffer from OS overheads, like lock contention. =A0See >>>>> http://www.myri.com/scs/SNF/doc/index.html for details. >>>> But your timestamps will be atrocious at 10G speeds. =A0Myricom doesn'= t >>>> timestamp packets AFAIK. =A0If you want reliable timestamps you need t= o >>>> look at companies like Endace, Napatech, etc. >>> I see your old help ticket in our system. =A0Yes, our timestamping >>> is not as good as a dedicated capture card with a GPS reference, >>> but it is good enough for most people. >> >> I was told btw that it doesn't timestamp at ALL. =A0I am assuming NOW >> that is incorrect. > > I think you might have misunderstood how we do timestamping. > I definately don't understand it, and I work there ;) No problem. :) > I do know that there is NIC component of it (eg, it is not 100% > done in the host). =A0I also realize that it is not is good as > something that is 1PPS GPS based. I need to grab your docs and start reading it again. I would like to support data capture using the Myricom card. I somehow missed this. I had thought the timestamps were software generated only. > >> Define *most* people. > > I may have a skewed view of the market, but it seems like > some people care deeply about accurate timestamps, and > others (mostly doing deep packet inspection) care only > within a few milliseconds, or even seconds. In our case Andrew, the folks who are doing deep packet inspection REQUIRE reasonable time stamps to correlate events and do generate reasonable stats. But I hear you, if you are just looking to see the packet data, then timestamp accuracy isn't your top priority. >> Question for Jack or Drew, what DOES FreeBSD have to do to support >> DCA? =A0I thought DCA was something you just enable on the NIC chipset >> and if the system is IOATDMA aware, it just works. =A0Is that not right >> (assuming cache tags are correct and accessible)? =A0i.e. I thought this >> was hardware black magic than anything specific the OS has to do. > > IOATDMA and DCA are sort of unfairly joined for two reasons: The DCA > control stuff is implemented as part of the IOATDMA PCIe device, and > IOATDMA is a great usage model for DCA, since you'd want the DMAs > that it does to be prefetched. > > To use DCA you need: > > - A DCA driver to talk to the IOATDMA/DCA pcie device, and obtain the tag > =A0 =A0 =A0 =A0table > - An interface that a client device (eg, NIC driver) can use to obtain > =A0 =A0 =A0 =A0either the tag table, or at least the correct tag for the = CPU > =A0 =A0 =A0 =A0that the interrupt handler is bound to. =A0The basic suppo= rt in > =A0 =A0 =A0 =A0a NIC driver boils down to something like: > > nic_interrupt_handler() > { > =A0if (sc->dca.enabled && (curcpu !=3D sc->dca.last_cpu)) { > =A0 =A0 sc->dca.last_cpu =3D curcpu; > =A0 =A0 tag =3D dca_get_tag(curcpu); > =A0 =A0 WRITE_REG(sc, DCA_TAG, tag); > =A0} > } Drew, at least in the Intel documentation, it seems the NIC uses the LAPIC id to tell the PCIe TLPs where to put inbound NIC I/O (in the TLP the DCA info is stored) to the appropriate core's cache. i.e. the heuristic you gave above is more granular than what I think Intel does. I could be wrong, maybe Jack can chime in and correct me. But it seems with Intel chipsets it is a per queue parameter which allows you to bind a core cache's to a queue via DCA. The added piece to this for at least bpf(4) consumers is to have bpf(4) subscribe to these queues AND to allow an interface for libpcap applications to know where what queue is on what core and THEN bind to it. I think that is the general idea....I think! :) -aps From owner-freebsd-net@FreeBSD.ORG Fri May 14 16:22:30 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 78AE01065673; Fri, 14 May 2010 16:22:30 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.freebsd.org (Postfix) with ESMTP id 3608A8FC14; Fri, 14 May 2010 16:22:30 +0000 (UTC) Received: from [172.31.193.10] (rrcs-98-101-145-84.midsouth.biz.rr.com [98.101.145.84]) (authenticated bits=0) by duke.cs.duke.edu (8.14.2/8.14.2) with ESMTP id o4EGMKsQ001920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 14 May 2010 12:22:20 -0400 (EDT) X-DKIM: Sendmail DKIM Filter v2.8.3 duke.cs.duke.edu o4EGMKsQ001920 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail; t=1273854144; bh=wr56XOlwsERw69EPXpJL+Sjo3Vw4rfhjkik0vEY2SV4=; h=Message-ID:Date:From:MIME-Version:To:CC:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=wBBZ09/PqOw/pz2+c+vAcbaDviFXC4fUKEDsSk27EF0yN6wi0G+ybNSHbXO86Kpkr 5C+jGxW9PdIBHr0k0YrZPrmPETMJkgVHmDrim15zKgFKBuKxIByB8nDnBcESseln8x 5gdeUL60JbpVqmVAit1RItnDKPdhDzXO80qARunc= Message-ID: <4BED78B5.8000906@cs.duke.edu> Date: Fri, 14 May 2010 12:22:13 -0400 From: Andrew Gallatin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Alexander Sack References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> <4BED6F1B.7070602@cs.duke.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:22:30 -0000 Alexander Sack wrote: >> To use DCA you need: >> >> - A DCA driver to talk to the IOATDMA/DCA pcie device, and obtain the tag >> table >> - An interface that a client device (eg, NIC driver) can use to obtain >> either the tag table, or at least the correct tag for the CPU >> that the interrupt handler is bound to. The basic support in >> a NIC driver boils down to something like: >> >> nic_interrupt_handler() >> { >> if (sc->dca.enabled && (curcpu != sc->dca.last_cpu)) { >> sc->dca.last_cpu = curcpu; >> tag = dca_get_tag(curcpu); >> WRITE_REG(sc, DCA_TAG, tag); >> } >> } > > Drew, at least in the Intel documentation, it seems the NIC uses the > LAPIC id to tell the PCIe TLPs where to put inbound NIC I/O (in the > TLP the DCA info is stored) to the appropriate core's cache. i.e. the > heuristic you gave above is more granular than what I think Intel The pseudo-code above was intended to be the MSI-X interrupt handler for a single queue, not some dispatcher for multiple queues. Sorry that wasn't clear. So yes, the DCA tag value may be different per queue. > does. I could be wrong, maybe Jack can chime in and correct me. But > it seems with Intel chipsets it is a per queue parameter which allows > you to bind a core cache's to a queue via DCA. The added piece to > this for at least bpf(4) consumers is to have bpf(4) subscribe to > these queues AND to allow an interface for libpcap applications to > know where what queue is on what core and THEN bind to it. Yes, everything associated with a queue must be bound to the same core (or at least to cores which share a cache). Drew From owner-freebsd-net@FreeBSD.ORG Fri May 14 16:28:57 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E9081106566C; Fri, 14 May 2010 16:28:57 +0000 (UTC) (envelope-from Leonid.Grossman@exar.com) Received: from owa.neterion.com (mx.neterion.com [72.1.205.142]) by mx1.freebsd.org (Postfix) with ESMTP id 9D56E8FC17; Fri, 14 May 2010 16:28:57 +0000 (UTC) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 14 May 2010 12:16:46 -0400 Message-ID: <78C9135A3D2ECE4B8162EBDCE82CAD77067570BE@nekter> In-Reply-To: <4BED6F1B.7070602@cs.duke.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Intel 10Gb thread-index: AcrzfAS6x46iHf9BR7miHTqNtyKiDAABBBOA References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> <4BED6F1B.7070602@cs.duke.edu> From: "Leonid Grossman" To: "Andrew Gallatin" , "Alexander Sack" Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org Subject: RE: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 16:28:58 -0000 Neterion/Exar x3100 is one of generic 10GbE NICs that supports timestamping in hardware, along with some other packet capturing/monitoring featiures; here is a relevant paragraph from programming manual: "Receive Frame Timestamp Feature The x3100 has the ability to label each incoming frame with a timestamp to allow a host entity to record the arrival time of incoming packets. The host uses the XMAC_TIMESTAMP register to control its operation. To enable the feature, the "EN" field must be set. Once the timestamp feature is enabled, the FCS value of each frame will be replaced with the value in a free-running 32-bit counter with a default period of 3.2 ns. The "USE_LINK_ID" determines if the full 32 bits of the of the FCS are used for the timestamp, or if the most significant 2 bits are used to identify which port the frame came in on, and 30 bits are used for the timestamp. The "INTERVAL" field can be used to programmably change the period between several values: 3.2 ns (the default), 6.4 ns, 12.8 ns, 25.6 ns, 51.2 ns, 102.4 ns, and 204.8 ns. NOTE: To take advantage of this feature, "XMAC_CFG_PORTn.STRIP_FCS" must be set to 0 to pass the FCS to the host." > -----Original Message----- > From: owner-freebsd-performance@freebsd.org [mailto:owner-freebsd- > performance@freebsd.org] On Behalf Of Andrew Gallatin > Sent: Friday, May 14, 2010 8:41 AM > To: Alexander Sack > Cc: Murat Balaban; freebsd-net@freebsd.org; freebsd- > performance@freebsd.org > Subject: Re: Intel 10Gb >=20 > Alexander Sack wrote: > > On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin > wrote: > >> Alexander Sack wrote: > >> <...> > >>>> Using this driver/firmware combo, we can receive minimal packets > at > >>>> line rate (14.8Mpps) to userspace. You can even access this > using a > >>>> libpcap interface. The trick is that the fast paths are OS- > bypass, > >>>> and don't suffer from OS overheads, like lock contention. See > >>>> http://www.myri.com/scs/SNF/doc/index.html for details. > >>> But your timestamps will be atrocious at 10G speeds. Myricom > doesn't > >>> timestamp packets AFAIK. If you want reliable timestamps you need > to > >>> look at companies like Endace, Napatech, etc. > >> I see your old help ticket in our system. Yes, our timestamping > >> is not as good as a dedicated capture card with a GPS reference, > >> but it is good enough for most people. > > > > I was told btw that it doesn't timestamp at ALL. I am assuming NOW > > that is incorrect. >=20 > I think you might have misunderstood how we do timestamping. > I definately don't understand it, and I work there ;) > I do know that there is NIC component of it (eg, it is not 100% > done in the host). I also realize that it is not is good as > something that is 1PPS GPS based. >=20 > > Define *most* people. >=20 > I may have a skewed view of the market, but it seems like > some people care deeply about accurate timestamps, and > others (mostly doing deep packet inspection) care only > within a few milliseconds, or even seconds. >=20 > > I am not knocking the Myricom card. In fact I so wish you guys > would > > just add the ability to latch to a 1PPS for timestamping and it > would > > be perfect. > > > > We use I think an older version of the card internally for replay. > > Its a great multi-purpose card. > > > > However with IPG at 10G in the nanoseconds, anyone trying to do OWDs > > or RTT will find it difficult compared to an Endace or Napatech > card. > > > > Btw, I was referring to bpf(4) specifically, so please don't take my > > comments as a knock against it. > > > >>> PS I am not sure but Intel also supports writing packets directly > in > >>> cache (yet I thought the 82599 driver actually does a prefetch > anyway > >>> which had me confused on why that helps) > >> You're talking about DCA. We support DCA as well (and I suspect > some > >> other 10G NICs do to). There are a few barriers to using DCA on > >> FreeBSD, not least of which is that FreeBSD doesn't currently have > the > >> infrastructure to support it (no IOATDMA or DCA drivers). > > > > Right. > > > >> DCA is also problematic because support from system/motherboard > >> vendors is very spotty. The vendor must provide the correct tag > table > >> in BIOS such that the tags match the CPU/core numbering in the > system. > >> Many motherboard vendors don't bother with this, and you cannot > enable > >> DCA on a lot of systems, even though the underlying chipset > supports > >> DCA. I've done hacks to force-enable it in the past, with mixed > >> results. The problem is that DCA depends on having the correct tag > >> table, so that packets can be prefetched into the correct CPU's > cache. > >> If the tag table is incorrect, DCA is a big pessimization, because > it > >> blows the cache in other CPUs. > > > > Right. > > > >> That said, I would *love* it if FreeBSD grew ioatdma/dca support. > >> Jack, does Intel have any interest in porting DCA support to > FreeBSD? > > > > Question for Jack or Drew, what DOES FreeBSD have to do to support > > DCA? I thought DCA was something you just enable on the NIC chipset > > and if the system is IOATDMA aware, it just works. Is that not > right > > (assuming cache tags are correct and accessible)? i.e. I thought > this > > was hardware black magic than anything specific the OS has to do. >=20 > IOATDMA and DCA are sort of unfairly joined for two reasons: The DCA > control stuff is implemented as part of the IOATDMA PCIe device, and > IOATDMA is a great usage model for DCA, since you'd want the DMAs > that it does to be prefetched. >=20 > To use DCA you need: >=20 > - A DCA driver to talk to the IOATDMA/DCA pcie device, and obtain the > tag > table > - An interface that a client device (eg, NIC driver) can use to obtain > either the tag table, or at least the correct tag for the CPU > that the interrupt handler is bound to. The basic support in > a NIC driver boils down to something like: >=20 > nic_interrupt_handler() > { > if (sc->dca.enabled && (curcpu !=3D sc->dca.last_cpu)) { > sc->dca.last_cpu =3D curcpu; > tag =3D dca_get_tag(curcpu); > WRITE_REG(sc, DCA_TAG, tag); > } > } >=20 > Drew > _______________________________________________ > freebsd-performance@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-performance > To unsubscribe, send any mail to "freebsd-performance- > unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Fri May 14 17:01:28 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0D26F106566C; Fri, 14 May 2010 17:01:28 +0000 (UTC) (envelope-from jfvogel@gmail.com) Received: from mail-ww0-f54.google.com (mail-ww0-f54.google.com [74.125.82.54]) by mx1.freebsd.org (Postfix) with ESMTP id 651218FC08; Fri, 14 May 2010 17:01:27 +0000 (UTC) Received: by wwb18 with SMTP id 18so452024wwb.13 for ; Fri, 14 May 2010 10:01:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=mb0FBfUT//flROo8fIA4o0tNFLt84XE7zXoiURSK37c=; b=isBroku26b4zfEFdLPuqLQodE0TCQQr32Ux9ys55068MWh7mdhHF2/xqB+vUNWvS+h s+8jHgh/w9D7yu+b43ugF8RhbI6tD+557VlLqgKEjmwe+hNhfrSeDaekXN7NnRWDIojo 8+IX1xs/C+7lKW6JB6bYZ20YOPzR7GksX+3yk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=poBupNReuh0QL1hyecyb2xPpM6nN+pkxbfko9NogzVKAvKGM7995bzm8X/C35jtFOt +0KTAkl96EJFayOjMhMTt1ywAoFPHgoFHFO7F2QBfHPPITQo50KZesPH/y5MdfOnKra6 vOUnXEcXvqkdyydkmLOIT7XAux2bh5+/geqlA= MIME-Version: 1.0 Received: by 10.216.88.211 with SMTP id a61mr491807wef.65.1273856486242; Fri, 14 May 2010 10:01:26 -0700 (PDT) Received: by 10.216.29.129 with HTTP; Fri, 14 May 2010 10:01:24 -0700 (PDT) In-Reply-To: References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> Date: Fri, 14 May 2010 10:01:24 -0700 Message-ID: From: Jack Vogel To: Alexander Sack Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, Andrew Gallatin Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:01:28 -0000 On Fri, May 14, 2010 at 8:18 AM, Alexander Sack wrote: > On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin > wrote: > > Alexander Sack wrote: > > <...> > >>> Using this driver/firmware combo, we can receive minimal packets at > >>> line rate (14.8Mpps) to userspace. You can even access this using a > >>> libpcap interface. The trick is that the fast paths are OS-bypass, > >>> and don't suffer from OS overheads, like lock contention. See > >>> http://www.myri.com/scs/SNF/doc/index.html for details. > >> > >> But your timestamps will be atrocious at 10G speeds. Myricom doesn't > >> timestamp packets AFAIK. If you want reliable timestamps you need to > >> look at companies like Endace, Napatech, etc. > > > > I see your old help ticket in our system. Yes, our timestamping > > is not as good as a dedicated capture card with a GPS reference, > > but it is good enough for most people. > > I was told btw that it doesn't timestamp at ALL. I am assuming NOW > that is incorrect. > > Define *most* people. > > I am not knocking the Myricom card. In fact I so wish you guys would > just add the ability to latch to a 1PPS for timestamping and it would > be perfect. > > We use I think an older version of the card internally for replay. > Its a great multi-purpose card. > > However with IPG at 10G in the nanoseconds, anyone trying to do OWDs > or RTT will find it difficult compared to an Endace or Napatech card. > > Btw, I was referring to bpf(4) specifically, so please don't take my > comments as a knock against it. > > >> PS I am not sure but Intel also supports writing packets directly in > >> cache (yet I thought the 82599 driver actually does a prefetch anyway > >> which had me confused on why that helps) > > > > You're talking about DCA. We support DCA as well (and I suspect some > > other 10G NICs do to). There are a few barriers to using DCA on > > FreeBSD, not least of which is that FreeBSD doesn't currently have the > > infrastructure to support it (no IOATDMA or DCA drivers). > > Right. > > > DCA is also problematic because support from system/motherboard > > vendors is very spotty. The vendor must provide the correct tag table > > in BIOS such that the tags match the CPU/core numbering in the system. > > Many motherboard vendors don't bother with this, and you cannot enable > > DCA on a lot of systems, even though the underlying chipset supports > > DCA. I've done hacks to force-enable it in the past, with mixed > > results. The problem is that DCA depends on having the correct tag > > table, so that packets can be prefetched into the correct CPU's cache. > > If the tag table is incorrect, DCA is a big pessimization, because it > > blows the cache in other CPUs. > > Right. > > > That said, I would *love* it if FreeBSD grew ioatdma/dca support. > > Jack, does Intel have any interest in porting DCA support to FreeBSD? > > Question for Jack or Drew, what DOES FreeBSD have to do to support > DCA? I thought DCA was something you just enable on the NIC chipset > and if the system is IOATDMA aware, it just works. Is that not right > (assuming cache tags are correct and accessible)? i.e. I thought this > was hardware black magic than anything specific the OS has to do. > > OK, let me see if I can clarify some of this. First, there IS an I/OAT driver that I did for FreeBSD like 3 or 4 years ago, in the timeframe that we put the feature out. However, at that time all it was good for was the DMA aspect of things, and Prafulla used it to accelerate the stack copies; interest did not seem that great so I put the code aside, its not badly dated and needs to be brought up to date due to there being a few different versions of the hardware now. At one point maybe a year back I started to take the code apart thinking I would JUST do DCA, that got back-burnered due to other higher priority issues, but its still an item in my queue. I also had a nibble of an interest in using the DMA engine so perhaps I should not go down the road of just doing the DCA support in the I/OAT part of the driver. The question is how to make the infrastructure work. To answer Alexander's question, DCA support is NOT in the NIC, its in the chipset, that's why the I/OAT driver was done as a seperate driver, but the NIC was the user of the info, its been a while since I was into the code but if memory serves the I/OAT driver just enables the support in the chipset, and then the NIC driver configures its engine to use it. DCA and DMA were supported in Linux in the same driver because the chipset features were easily handled together perhaps, I'm not sure :) Fabien's data earlier in this thread suggested that a strategicallly placed prefetch did you more good than DCA did if I recall, what do you all think of that? As far as I'm concerned right now I am willing to resurrect the driver, clean it up and make the features available, we can see how valuable they are after that, how does that sound?? Cheers, Jack From owner-freebsd-net@FreeBSD.ORG Fri May 14 17:20:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BB12C1065670; Fri, 14 May 2010 17:20:23 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.211.181]) by mx1.freebsd.org (Postfix) with ESMTP id 4E7BB8FC17; Fri, 14 May 2010 17:20:22 +0000 (UTC) Received: by ywh11 with SMTP id 11so1435813ywh.7 for ; Fri, 14 May 2010 10:20:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=NqZFPlSfG/uLdkjsSIhq0IKDA7WAKPdN7ilFOtGm9+w=; b=IDgwxHdm74Kgk2FJLScPB1UoCFE04h33HrVAw/23/vR2ty56DjTwrNJoygQoqS+ifz lGwzrRZ2F9Qb/INVO+5e7O7wzf0w+a0LRYV9j3HcbcbGBoIKXI6PUPhEenws3QFKYZN2 1zHE5eIWoGnOoYo6llPcxbkAVyKpFd2TF8bXc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=FduRR33H5djFfHR3E4R4QgkxAbntHDD+cKpq7VeKhBNFikjm66jFGaD5t4II89oXw7 /j/2zkE6yT3ojxsvprUVT/y9n1Ds8Vs5bS3+m9cAW1ItBg5MGZp8F2JgRNUgzGF9Twg3 l5sr9pTxofMtM+7cX3WuqPc5WlDyK1hW/eHd0= MIME-Version: 1.0 Received: by 10.101.181.40 with SMTP id i40mr1719251anp.193.1273857622101; Fri, 14 May 2010 10:20:22 -0700 (PDT) Received: by 10.100.58.2 with HTTP; Fri, 14 May 2010 10:20:21 -0700 (PDT) In-Reply-To: References: <4BE52856.3000601@unsane.co.uk> <1273323582.3304.31.camel@efe> <20100511135103.GA29403@grapeape2.cs.duke.edu> <4BED5929.5020302@cs.duke.edu> Date: Fri, 14 May 2010 13:20:21 -0400 Message-ID: From: Alexander Sack To: Jack Vogel Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, Andrew Gallatin Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 17:20:23 -0000 On Fri, May 14, 2010 at 1:01 PM, Jack Vogel wrote: > > > On Fri, May 14, 2010 at 8:18 AM, Alexander Sack wrot= e: >> >> On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin >> wrote: >> > Alexander Sack wrote: >> > <...> >> >>> Using this driver/firmware combo, we can receive minimal packets at >> >>> line rate (14.8Mpps) to userspace. =A0You can even access this using= a >> >>> libpcap interface. =A0The trick is that the fast paths are OS-bypass= , >> >>> and don't suffer from OS overheads, like lock contention. =A0See >> >>> http://www.myri.com/scs/SNF/doc/index.html for details. >> >> >> >> But your timestamps will be atrocious at 10G speeds. =A0Myricom doesn= 't >> >> timestamp packets AFAIK. =A0If you want reliable timestamps you need = to >> >> look at companies like Endace, Napatech, etc. >> > >> > I see your old help ticket in our system. =A0Yes, our timestamping >> > is not as good as a dedicated capture card with a GPS reference, >> > but it is good enough for most people. >> >> I was told btw that it doesn't timestamp at ALL. =A0I am assuming NOW >> that is incorrect. >> >> Define *most* people. >> >> I am not knocking the Myricom card. =A0In fact I so wish you guys would >> just add the ability to latch to a 1PPS for timestamping and it would >> be perfect. >> >> We use I think an older version of the card internally for replay. >> Its a great multi-purpose card. >> >> However with IPG at 10G in the nanoseconds, anyone trying to do OWDs >> or RTT will find it difficult compared to an Endace or Napatech card. >> >> Btw, I was referring to bpf(4) specifically, so please don't take my >> comments as a knock against it. >> >> >> PS I am not sure but Intel also supports writing packets directly in >> >> cache (yet I thought the 82599 driver actually does a prefetch anyway >> >> which had me confused on why that helps) >> > >> > You're talking about DCA. =A0We support DCA as well (and I suspect som= e >> > other 10G NICs do to). =A0There are a few barriers to using DCA on >> > FreeBSD, not least of which is that FreeBSD doesn't currently have the >> > infrastructure to support it (no IOATDMA or DCA drivers). >> >> Right. >> >> > DCA is also problematic because support from system/motherboard >> > vendors is very spotty. =A0The vendor must provide the correct tag tab= le >> > in BIOS such that the tags match the CPU/core numbering in the system. >> > Many motherboard vendors don't bother with this, and you cannot enable >> > DCA on a lot of systems, even though the underlying chipset supports >> > DCA. =A0I've done hacks to force-enable it in the past, with mixed >> > results. The problem is that DCA depends on having the correct tag >> > table, so that packets can be prefetched into the correct CPU's cache. >> > If the tag table is incorrect, DCA is a big pessimization, because it >> > blows the cache in other CPUs. >> >> Right. >> >> > That said, I would *love* it if FreeBSD grew ioatdma/dca support. >> > Jack, does Intel have any interest in porting DCA support to FreeBSD? >> >> Question for Jack or Drew, what DOES FreeBSD have to do to support >> DCA? =A0I thought DCA was something you just enable on the NIC chipset >> and if the system is IOATDMA aware, it just works. =A0Is that not right >> (assuming cache tags are correct and accessible)? =A0i.e. I thought this >> was hardware black magic than anything specific the OS has to do. >> > > OK, let me see if I can clarify some of this. First, there IS an I/OAT > driver > that I did for FreeBSD like 3 or 4 years ago, in the timeframe that we pu= t > the feature out. However, at that time all it was good for was the DMA > aspect > of things, and Prafulla used it to accelerate the stack copies; interest = did > not seem that great so I put the code aside, its not badly dated and need= s > to be brought up to date due to there being a few different versions of t= he > hardware now. > > At one point maybe a year back I started to take the code apart thinking > I would JUST do DCA, that got back-burnered due to other higher priority > issues, but its still an item in my queue. > > I also had a nibble of an interest in using the DMA engine so perhaps I > should not go down the road of just doing the DCA support in the I/OAT > part of the driver. The question is how to make the infrastructure work. > > To answer Alexander's question, DCA support is NOT in the NIC, its in > the chipset, that's why the I/OAT driver was done as a seperate driver, > but the NIC was the user of the info, its been a while since I was into > the code but if memory serves the I/OAT driver just enables the support > in the chipset, and then the NIC driver configures its engine to use it. Thank you very much Jack! :) It was not clear from the docs what was where to me. I just assumed this was Intel NIC knew Intel chipset black magic! LOL. > DCA and DMA were supported in Linux in the same driver because > the chipset features were easily handled together perhaps, I'm not > sure :) Ok! (it was my other reference) > Fabien's data earlier in this thread suggested that a strategicallly > placed prefetch did you more good than DCA did if I recall, what > do you all think of that? I thought there was a thread where prefetch didn't do much for you....lol..= . If you just prefetch willy-nilly then don't you run the risk of packets hitting caches on cores outside of what the application reading them is on thereby defeating the whole purpose of prefetch? > As far as I'm concerned right now I am willing to resurrect the driver, > clean it up and make the features available, we can see how valuable > they are after that, how does that sound?? Sounds good to me. I at least put it somewhere publicly for people to look= at. -aps From owner-freebsd-net@FreeBSD.ORG Fri May 14 18:47:48 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9945F1065673 for ; Fri, 14 May 2010 18:47:48 +0000 (UTC) (envelope-from onemda@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 2D9668FC0C for ; Fri, 14 May 2010 18:47:47 +0000 (UTC) Received: by wyg36 with SMTP id 36so2206752wyg.13 for ; Fri, 14 May 2010 11:47:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=X5zCN0FQSp4bT/NJscXAvVCbiTMTdw6mWK905HbNggM=; b=IomzwdU/9LObj54lGaogEslDZlXzAYsYckHb1kfz2ArspgHvsY1ixqbRy5k3B4o/Kh nn+MPYaxv4rVT3zI4ivGxTHS6WUbdMS7aA7Penf5qO3sVBnhyflst508S08dhPtP38yN nxxzplXLDKy5BoXJzX0QLsE9bpzeJV+q8evFY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ko7n9kY61jvPSG54BIqU3vOVawmZWGD6MVlsU1CqnFg5EoDnYXTK1YlHikEKFP9joB X8UO/E3SeCoyk4kheMkKYlHwmbUUdnIUr9e775bBSPyt1dBaRSskmzTW8zLTx9X56wD6 6Fhj0WUF9EuLxVIfSlPTbWVgMvfKu06kA6wp0= MIME-Version: 1.0 Received: by 10.216.86.212 with SMTP id w62mr1067901wee.131.1273862867137; Fri, 14 May 2010 11:47:47 -0700 (PDT) Received: by 10.216.48.210 with HTTP; Fri, 14 May 2010 11:47:47 -0700 (PDT) In-Reply-To: <4ce970a1.1bc70.12895cdbd14.Coremail.jiani1012@126.com> References: <20100506120022.A331D10656C2@hub.freebsd.org> <45e58af.dfb8.128723a15b9.Coremail.jiani1012@126.com> <4ce970a1.1bc70.12895cdbd14.Coremail.jiani1012@126.com> Date: Fri, 14 May 2010 18:47:47 +0000 Message-ID: From: Paul B Mahol To: jiani1012 Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: Re: convert Windows NDIS drivers for use with FreeBSD X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 18:47:48 -0000 On 5/14/10, jiani1012 wrote: > Yes, I use ndisgen(8) instead. Input the netathw.inf and athw.sys file, > appears: > segmentation fault (core dumped) > CONVERSION FAILED inf file have missing end of line at end, open file in text editor and add empty line at and, and try again. From owner-freebsd-net@FreeBSD.ORG Fri May 14 19:07:20 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ED17A106566B for ; Fri, 14 May 2010 19:07:20 +0000 (UTC) (envelope-from list@cykotix.com) Received: from mail.lahni.com (badger.cykotix.com [65.110.58.110]) by mx1.freebsd.org (Postfix) with ESMTP id 9A8118FC17 for ; Fri, 14 May 2010 19:07:20 +0000 (UTC) Received: from mail.lahni.com (localhost [127.0.0.1]) by mail.lahni.com (Postfix) with ESMTP id 1498E2285D for ; Fri, 14 May 2010 14:56:13 -0400 (EDT) Received: by mail.lahni.com (Postfix, from userid 80) id E9B332285C; Fri, 14 May 2010 14:56:12 -0400 (EDT) Received: from slip4.cchmc.org (slip4.cchmc.org [205.142.197.72]) by webmail.lahni.com (Horde Framework) with HTTP; Fri, 14 May 2010 14:56:12 -0400 Message-ID: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> X-Priority: 3 (Normal) Date: Fri, 14 May 2010 14:56:12 -0400 From: list@cykotix.com To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:07:21 -0000 Hello, I recently just purchased 2 Soekris5501 with identical 120gb 2.5" WD Scorpio HDDs. I'm using them for network failover, using CARP, PF and pfSync on FreeBSD 8-STABLE. The short version of my problem: I setup FW2 first, imaged its hard drive to FW1. I changed the necessary configs to update the IPs and ensure FW1 was carp MASTER. Using a known working port on the switch, I continue to get 70% packet loss on FW1 on vr0 (vr0 - extif, vr1 - intif, vr2 - pfsync). If I flip FW1 and FW2, the packet loss follows FW1. I took FW1 home, plugged it into my home network on vr0 and it works fine with 0% packet loss so the interface seems fine. I also took the IP bound to vr0 on FW1 and bound it to vr0 on FW2 and the ISP isn't the problem. The long version: Both Soekris5501's use vr0 (ext), vr1 (int) and vr2 (pfsync). I was given 98.xxx.xxx.58 - .62 with .57 being the gateway IP. FW1 was assigned .59. FW2 was assigned .60 and I was going to use .58 to NAT the office traffic over CARP. If I take carp0 and carp1 down off FW1, it moves all traffic to FW2 appropriately. If I bring carp0 and carp1 back up on FW1, it assumes MASTER again as it should. FW1 /etc/rc.conf: ----------------- cloned_interfaces="carp0 carp1" ifconfig_vr0="inet 98.xxx.xxx.59 netmask 255.255.255.248" ifconfig_vr1="inet 192.168.1.10 netmask 255.255.255.0" ifconfig_vr2="inet 10.0.10.12 netmask 255.255.255.0" ifconfig_carp0="inet 98.xxx.xxx.58 netmask 255.255.255.248 pass pabsoekris1959 vhid 1" ifconfig_carp0_alias0="inet 98.xxx.xxx.61 netmask 255.255.255.248" ifconfig_carp0_alias1="inet 98.xxx.xxx.62 netmask 255.255.255.248" ifconfig_carp1="inet 192.168.1.1 netmask 255.255.255.0 pass pabsoekris1959 vhid 2" ifconfig_pfsync0="syncpeer 10.0.10.13 syncdev vr2" defaultrouter="98.xxx.xxx.57" gateway_enable="YES" FW2 /etc/rc.conf: ----------------- cloned_interfaces="carp0 carp1" ifconfig_vr0="inet 98.xxx.xxx.60 netmask 255.255.255.248" ifconfig_vr1="inet 192.168.1.11 netmask 255.255.255.0" ifconfig_vr2="inet 10.0.10.13 netmask 255.255.255.0" ifconfig_carp0="inet 98.xxx.xxx.58 netmask 255.255.255.248 pass pabsoekris1959 advskew 100 vhid 1" ifconfig_carp0_alias0="inet 98.xxx.xxx.61 netmask 255.255.255.248" ifconfig_carp0_alias1="inet 98.xxx.xxx.62 netmask 255.255.255.248" ifconfig_carp1="inet 192.168.1.1 netmask 255.255.255.0 pass pabsoekris1959 vhid 2" ifconfig_pfsync0="syncpeer 10.0.10.12 syncdev vr2" defaultrouter="98.xxx.xxx.57" gateway_enable="YES" FW1 /etc/pf.conf: ------------------------------------------------ ext_if = vr0 # External WAN interface int_if = vr1 # Internal LAN interface pfs_if = vr2 # Pfsync interface carp_extif = carp0 # External CARP interface carp_intif = carp1 ### hosts office = "192.168.1.0/24" office_ext = "98.xxx.xxx.58" soekris1 = "98.xxx.xxx.59" soekris2 = "98.xxx.xxx.60" pab = "192.168.1.2" ### icmp icmp_types = "{ echoreq, unreach }" ### tables table persist table persist file "/etc/badguys" table { $office } set block-policy drop set loginterface $ext_if set skip on lo scrub on $ext_if reassemble tcp no-df random-id ### NAT outgoing connections nat on $ext_if inet from $int_if:network to any -> $office_ext ### port forwards rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 22 rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 3389 ### ruleset block in log all # default deny block in log quick from urpf-failed # spoofed address protection block in log quick from { , } pass log from { lo0, $int_if:network, $ext_if, $carp_extif, $carp_intif } to any keep state pass in quick from keep state pass log inet proto icmp all icmp-type $icmp_types pass quick on $pfs_if proto pfsync keep state (no-sync) # enable pfsync pass on { $int_if, $ext_if } proto carp keep state (no-sync) # enable CARP FW2 /etc/pf.conf: ----------------- ext_if = vr0 # External WAN interface int_if = vr1 # Internal LAN interface pfs_if = vr2 # Pfsync interface carp_extif = carp0 # External CARP interface carp_intif = carp1 ### hosts office = "192.168.1.0/24" office_ext = "98.xxx.xxx.58" soekris1 = "98.xxx.xxx.59" soekris2 = "98.xxx.xxx.60" pab = "192.168.1.2" ### icmp icmp_types = "{ echoreq, unreach }" ### tables table persist table persist file "/etc/badguys" table { $office } set block-policy drop set loginterface $ext_if set skip on lo scrub on $ext_if reassemble tcp no-df random-id ### NAT outgoing connections nat on $ext_if inet from $int_if:network to any -> $office_ext ### port forwards rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 22 rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 3389 ### ruleset block in log all # default deny block in log quick from urpf-failed # spoofed address protection block in log quick from { , } pass log from { lo0, $int_if:network, $ext_if, $carp_extif, $carp_intif } to any keep state pass in quick from keep state pass log inet proto icmp all icmp-type $icmp_types pass quick on $pfs_if proto pfsync keep state (no-sync) # enable pfsync pass on { $int_if, $ext_if } proto carp keep state (no-sync) # enable CARP FW1 ifconfig (carp0 and carp1 are down, packet loss happens regardless): ------------------------------------------------------------------------ soekris1# ifconfig vr0: flags=8943 metric 0 mtu 1500 options=280b ether 00:00:24:cc:cb:94 inet 98.xxx.xxx.59 netmask 0xfffffff8 broadcast 98.xxx.xxx.63 media: Ethernet autoselect (100baseTX ) status: active vr1: flags=8943 metric 0 mtu 1500 options=280b ether 00:00:24:cc:cb:95 inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active vr2: flags=8843 metric 0 mtu 1500 options=280b ether 00:00:24:cc:cb:96 inet 10.0.10.12 netmask 0xffffff00 broadcast 10.0.10.255 media: Ethernet autoselect (100baseTX ) status: active pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: vr2 syncpeer: 10.0.10.13 maxupd: 128 carp0: flags=8 metric 0 mtu 1500 inet 98.xxx.xxx.61 netmask 0xfffffff8 inet 98.xxx.xxx.62 netmask 0xfffffff8 inet 98.xxx.xxx.58 netmask 0xfffffff8 carp: INIT vhid 1 advbase 1 advskew 0 carp1: flags=8 metric 0 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 carp: INIT vhid 2 advbase 1 advskew 0 FW2 ifconfig (carp0 and carp1 are up and in failover mode): ----------------------------------------------------------- soekris2# ifconfig vr0: flags=8943 metric 0 mtu 1500 options=280b ether 00:00:24:ca:40:60 inet 98.xxx.xxx.60 netmask 0xfffffff8 broadcast 98.xxx.xxx.63 media: Ethernet autoselect (100baseTX ) status: active vr1: flags=8943 metric 0 mtu 1500 options=280b ether 00:00:24:ca:40:61 inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 media: Ethernet autoselect (100baseTX ) status: active vr2: flags=8843 metric 0 mtu 1500 options=280b ether 00:00:24:ca:40:62 inet 10.0.10.13 netmask 0xffffff00 broadcast 10.0.10.255 media: Ethernet autoselect (100baseTX ) status: active pfsync0: flags=41 metric 0 mtu 1460 pfsync: syncdev: vr2 syncpeer: 10.0.10.12 maxupd: 128 carp0: flags=49 metric 0 mtu 1500 inet 98.xxx.xxx.61 netmask 0xfffffff8 inet 98.xxx.xxx.62 netmask 0xfffffff8 inet 98.xxx.xxx.58 netmask 0xfffffff8 carp: MASTER vhid 1 advbase 1 advskew 100 carp1: flags=49 metric 0 mtu 1500 inet 192.168.1.1 netmask 0xffffff00 carp: MASTER vhid 2 advbase 1 advskew 100 Regardless if I flip IPs, flip ports on the switch, anything plugged into vr0 on FW1 at the office causes 70% packet loss, yet it's fine on FW2. FW1 vr0 works fine at my house using one of my localnet IPs. Any suggestions on how to track down where this packet loss is coming from? I appreciate any input! Thanks! Patrick ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Fri May 14 19:23:23 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B39E1106566B for ; Fri, 14 May 2010 19:23:23 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-pv0-f182.google.com (mail-pv0-f182.google.com [74.125.83.182]) by mx1.freebsd.org (Postfix) with ESMTP id 8253E8FC08 for ; Fri, 14 May 2010 19:23:23 +0000 (UTC) Received: by pvh11 with SMTP id 11so1255170pvh.13 for ; Fri, 14 May 2010 12:23:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=PfsiWjQ+q/yk2RJsbvPDOd6TLpiPijCaGE8OgRPUu68=; b=DHPwZbZVdXYERTest1rw3wX9Emwi3r/Cu08z8GH97izwg5JXoOQgmq1mf5mgh3ZDlw gWewL9MUVJ4odoQu1xie1BaFwBJtCvzUpt5KrqBK1OPVUzHWfhfEBcU435PwD7aKVsiy SebK1xEXBVgb47sGW/dRaCKoTBiQ7klrKcDeY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=EWOcR0lggDvU6pShj6t61eZOe/qHiF+l0HtKMU37CvmHIolUZdB0eVHOdYpZWIJzWJ kN0pKOZn5p9qfnzPE0PPLNUqkcZRuVTEB8JM0YxD8gdzKKxRGp2jDYYJtTxnjqq5uco6 gN4Emkge3IlQm8A815nf9eOInFFrhzYePJFIc= Received: by 10.140.252.6 with SMTP id z6mr1027887rvh.229.1273865003088; Fri, 14 May 2010 12:23:23 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b10sm2273846rvn.15.2010.05.14.12.23.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 12:23:22 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 14 May 2010 12:22:39 -0700 From: Pyun YongHyeon Date: Fri, 14 May 2010 12:22:39 -0700 To: list@cykotix.com Message-ID: <20100514192239.GC24686@michelle.cdnetworks.com> References: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:23:23 -0000 On Fri, May 14, 2010 at 02:56:12PM -0400, list@cykotix.com wrote: > Hello, > > I recently just purchased 2 Soekris5501 with identical 120gb 2.5" WD > Scorpio HDDs. I'm using them for network failover, using CARP, PF and > pfSync on FreeBSD 8-STABLE. > > The short version of my problem: > > I setup FW2 first, imaged its hard drive to FW1. I changed the > necessary configs to update the IPs and ensure FW1 was carp MASTER. > Using a known working port on the switch, I continue to get 70% packet > loss on FW1 on vr0 (vr0 - extif, vr1 - intif, vr2 - pfsync). If I > flip FW1 and FW2, the packet loss follows FW1. I took FW1 home, > plugged it into my home network on vr0 and it works fine with 0% > packet loss so the interface seems fine. I also took the IP bound to > vr0 on FW1 and bound it to vr0 on FW2 and the ISP isn't the problem. > Show me the output of "sysctl dev.vr.0.stats=1" and "netstat -ndI vr0". > The long version: > > Both Soekris5501's use vr0 (ext), vr1 (int) and vr2 (pfsync). I was > given 98.xxx.xxx.58 - .62 with .57 being the gateway IP. FW1 was > assigned .59. FW2 was assigned .60 and I was going to use .58 to NAT > the office traffic over CARP. If I take carp0 and carp1 down off FW1, > it moves all traffic to FW2 appropriately. If I bring carp0 and carp1 > back up on FW1, it assumes MASTER again as it should. > > FW1 /etc/rc.conf: > ----------------- > cloned_interfaces="carp0 carp1" > ifconfig_vr0="inet 98.xxx.xxx.59 netmask 255.255.255.248" > ifconfig_vr1="inet 192.168.1.10 netmask 255.255.255.0" > ifconfig_vr2="inet 10.0.10.12 netmask 255.255.255.0" > ifconfig_carp0="inet 98.xxx.xxx.58 netmask 255.255.255.248 pass > pabsoekris1959 vhid 1" > ifconfig_carp0_alias0="inet 98.xxx.xxx.61 netmask 255.255.255.248" > ifconfig_carp0_alias1="inet 98.xxx.xxx.62 netmask 255.255.255.248" > ifconfig_carp1="inet 192.168.1.1 netmask 255.255.255.0 pass > pabsoekris1959 vhid 2" > ifconfig_pfsync0="syncpeer 10.0.10.13 syncdev vr2" > defaultrouter="98.xxx.xxx.57" > gateway_enable="YES" > > FW2 /etc/rc.conf: > ----------------- > cloned_interfaces="carp0 carp1" > ifconfig_vr0="inet 98.xxx.xxx.60 netmask 255.255.255.248" > ifconfig_vr1="inet 192.168.1.11 netmask 255.255.255.0" > ifconfig_vr2="inet 10.0.10.13 netmask 255.255.255.0" > ifconfig_carp0="inet 98.xxx.xxx.58 netmask 255.255.255.248 pass > pabsoekris1959 advskew 100 vhid 1" > ifconfig_carp0_alias0="inet 98.xxx.xxx.61 netmask 255.255.255.248" > ifconfig_carp0_alias1="inet 98.xxx.xxx.62 netmask 255.255.255.248" > ifconfig_carp1="inet 192.168.1.1 netmask 255.255.255.0 pass > pabsoekris1959 vhid 2" > ifconfig_pfsync0="syncpeer 10.0.10.12 syncdev vr2" > defaultrouter="98.xxx.xxx.57" > gateway_enable="YES" > > FW1 /etc/pf.conf: > ------------------------------------------------ > ext_if = vr0 # External WAN interface > int_if = vr1 # Internal LAN interface > pfs_if = vr2 # Pfsync interface > carp_extif = carp0 # External CARP interface > carp_intif = carp1 > > ### hosts > office = "192.168.1.0/24" > office_ext = "98.xxx.xxx.58" > soekris1 = "98.xxx.xxx.59" > soekris2 = "98.xxx.xxx.60" > pab = "192.168.1.2" > > ### icmp > icmp_types = "{ echoreq, unreach }" > > ### tables > table persist > table persist file "/etc/badguys" > table { $office } > > set block-policy drop > set loginterface $ext_if > set skip on lo > > scrub on $ext_if reassemble tcp no-df random-id > > ### NAT outgoing connections > nat on $ext_if inet from $int_if:network to any -> $office_ext > > > ### port forwards > rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 22 > rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port > 3389 > > ### ruleset > block in log all # default deny > block in log quick from urpf-failed # spoofed address protection > block in log quick from { , } > > pass log from { lo0, $int_if:network, $ext_if, $carp_extif, > $carp_intif } to any keep state > pass in quick from keep state > pass log inet proto icmp all icmp-type $icmp_types > pass quick on $pfs_if proto pfsync keep state (no-sync) # > enable pfsync > pass on { $int_if, $ext_if } proto carp keep state (no-sync) # enable > CARP > > > FW2 /etc/pf.conf: > ----------------- > ext_if = vr0 # External WAN interface > int_if = vr1 # Internal LAN interface > pfs_if = vr2 # Pfsync interface > carp_extif = carp0 # External CARP interface > carp_intif = carp1 > > ### hosts > office = "192.168.1.0/24" > office_ext = "98.xxx.xxx.58" > soekris1 = "98.xxx.xxx.59" > soekris2 = "98.xxx.xxx.60" > pab = "192.168.1.2" > > ### icmp > icmp_types = "{ echoreq, unreach }" > > > ### tables > table persist > table persist file "/etc/badguys" > table { $office } > > > set block-policy drop > set loginterface $ext_if > set skip on lo > > scrub on $ext_if reassemble tcp no-df random-id > > ### NAT outgoing connections > nat on $ext_if inet from $int_if:network to any -> $office_ext > > > ### port forwards > rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port 22 > rdr on $ext_if proto tcp from any to $office_ext port XXXXX -> $pab port > 3389 > > ### ruleset > block in log all # default deny > block in log quick from urpf-failed # spoofed address protection > block in log quick from { , } > > pass log from { lo0, $int_if:network, $ext_if, $carp_extif, > $carp_intif } to any keep state > pass in quick from keep state > pass log inet proto icmp all icmp-type $icmp_types > pass quick on $pfs_if proto pfsync keep state (no-sync) # > enable pfsync > pass on { $int_if, $ext_if } proto carp keep state (no-sync) # enable > CARP > > > FW1 ifconfig (carp0 and carp1 are down, packet loss happens regardless): > ------------------------------------------------------------------------ > soekris1# ifconfig > vr0: flags=8943 metric > 0 mtu 1500 > options=280b > ether 00:00:24:cc:cb:94 > inet 98.xxx.xxx.59 netmask 0xfffffff8 broadcast 98.xxx.xxx.63 > media: Ethernet autoselect (100baseTX ) > status: active > vr1: flags=8943 metric > 0 mtu 1500 > options=280b > ether 00:00:24:cc:cb:95 > inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > vr2: flags=8843 metric 0 mtu 1500 > options=280b > ether 00:00:24:cc:cb:96 > inet 10.0.10.12 netmask 0xffffff00 broadcast 10.0.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > pfsync0: flags=41 metric 0 mtu 1460 > pfsync: syncdev: vr2 syncpeer: 10.0.10.13 maxupd: 128 > carp0: flags=8 metric 0 mtu 1500 > inet 98.xxx.xxx.61 netmask 0xfffffff8 > inet 98.xxx.xxx.62 netmask 0xfffffff8 > inet 98.xxx.xxx.58 netmask 0xfffffff8 > carp: INIT vhid 1 advbase 1 advskew 0 > carp1: flags=8 metric 0 mtu 1500 > inet 192.168.1.1 netmask 0xffffff00 > carp: INIT vhid 2 advbase 1 advskew 0 > > > FW2 ifconfig (carp0 and carp1 are up and in failover mode): > ----------------------------------------------------------- > soekris2# ifconfig > vr0: flags=8943 metric > 0 mtu 1500 > options=280b > ether 00:00:24:ca:40:60 > inet 98.xxx.xxx.60 netmask 0xfffffff8 broadcast 98.xxx.xxx.63 > media: Ethernet autoselect (100baseTX ) > status: active > vr1: flags=8943 metric > 0 mtu 1500 > options=280b > ether 00:00:24:ca:40:61 > inet 192.168.1.11 netmask 0xffffff00 broadcast 192.168.1.255 > media: Ethernet autoselect (100baseTX ) > status: active > vr2: flags=8843 metric 0 mtu 1500 > options=280b > ether 00:00:24:ca:40:62 > inet 10.0.10.13 netmask 0xffffff00 broadcast 10.0.10.255 > media: Ethernet autoselect (100baseTX ) > status: active > pfsync0: flags=41 metric 0 mtu 1460 > pfsync: syncdev: vr2 syncpeer: 10.0.10.12 maxupd: 128 > carp0: flags=49 metric 0 mtu 1500 > inet 98.xxx.xxx.61 netmask 0xfffffff8 > inet 98.xxx.xxx.62 netmask 0xfffffff8 > inet 98.xxx.xxx.58 netmask 0xfffffff8 > carp: MASTER vhid 1 advbase 1 advskew 100 > carp1: flags=49 metric 0 mtu 1500 > inet 192.168.1.1 netmask 0xffffff00 > carp: MASTER vhid 2 advbase 1 advskew 100 > > Regardless if I flip IPs, flip ports on the switch, anything plugged > into vr0 on FW1 at the office causes 70% packet loss, yet it's fine on > FW2. FW1 vr0 works fine at my house using one of my localnet IPs. > > Any suggestions on how to track down where this packet loss is coming > from? I appreciate any input! > > Thanks! > > Patrick > > ---------------------------------------------------------------- > This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Fri May 14 19:51:55 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B8191065670 for ; Fri, 14 May 2010 19:51:55 +0000 (UTC) (envelope-from list@cykotix.com) Received: from mail.lahni.com (badger.cykotix.com [65.110.58.110]) by mx1.freebsd.org (Postfix) with ESMTP id 030E18FC12 for ; Fri, 14 May 2010 19:51:54 +0000 (UTC) Received: from mail.lahni.com (localhost [127.0.0.1]) by mail.lahni.com (Postfix) with ESMTP id 1E0712285B for ; Fri, 14 May 2010 15:56:39 -0400 (EDT) Received: by mail.lahni.com (Postfix, from userid 80) id DEDE422823; Fri, 14 May 2010 15:56:38 -0400 (EDT) Received: from slip4.cchmc.org (slip4.cchmc.org [205.142.197.72]) by webmail.lahni.com (Horde Framework) with HTTP; Fri, 14 May 2010 15:56:38 -0400 Message-ID: <20100514155638.21116k5xymc7cb8c@webmail.lahni.com> X-Priority: 3 (Normal) Date: Fri, 14 May 2010 15:56:38 -0400 From: list@cykotix.com To: freebsd-net@freebsd.org References: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> <20100514192239.GC24686@michelle.cdnetworks.com> In-Reply-To: <20100514192239.GC24686@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 19:51:55 -0000 Quoting Pyun YongHyeon : > On Fri, May 14, 2010 at 02:56:12PM -0400, list@cykotix.com wrote: >> Hello, >> >> I recently just purchased 2 Soekris5501 with identical 120gb 2.5" WD >> Scorpio HDDs. I'm using them for network failover, using CARP, PF and >> pfSync on FreeBSD 8-STABLE. >> >> The short version of my problem: >> >> I setup FW2 first, imaged its hard drive to FW1. I changed the >> necessary configs to update the IPs and ensure FW1 was carp MASTER. >> Using a known working port on the switch, I continue to get 70% packet >> loss on FW1 on vr0 (vr0 - extif, vr1 - intif, vr2 - pfsync). If I >> flip FW1 and FW2, the packet loss follows FW1. I took FW1 home, >> plugged it into my home network on vr0 and it works fine with 0% >> packet loss so the interface seems fine. I also took the IP bound to >> vr0 on FW1 and bound it to vr0 on FW2 and the ISP isn't the problem. >> > > Show me the output of "sysctl dev.vr.0.stats=1" and "netstat -ndI vr0". soekris1# sysctl dev.vr.0.stats=1 dev.vr.0.stats: -1 -> -1 soekris1# netstat -ndI vr0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop vr0 1500 00:00:24:cc:cb:94 17491 0 14993 0 0 0 vr0 1500 98.xxx.xxx.56 98.xxx.xxx.59 992 - 9374 - - - soekris2# sysctl dev.vr.0.stats=1 dev.vr.0.stats: -1 -> -1 soekris2# netstat -ndI vr0 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll Drop vr0 1500 00:00:24:ca:40:60 575909 0 588703 0 0 0 vr0 1500 98.xxx.xxx.56 98.xxx.xxx.60 10029 - 53106 - - - Let me know if you need any other information! Thanks! Patrick ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Fri May 14 21:04:25 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B33E81065673 for ; Fri, 14 May 2010 21:04:25 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id 813CF8FC1B for ; Fri, 14 May 2010 21:04:25 +0000 (UTC) Received: by pxi7 with SMTP id 7so100221pxi.13 for ; Fri, 14 May 2010 14:04:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:from:date:to:cc :subject:message-id:reply-to:references:mime-version:content-type :content-disposition:in-reply-to:user-agent; bh=qpVI4/QPopGrTzn3/oct4wWSRmXDCNB9J44cvaxnYJA=; b=s40NImRFy+PJz+Ycn4yF20Zgxn96y+H0+y4pmslDXd4iiFzu+G30KlpdmOme9XcLzr M9w8hh0vhW04uxuMJK1vs/D7acIESIMhGNvBHv1P6X2PoFpJSw3OLF5kSM7FUgb3mVtW elvMbb0WRhlWjAnpFuXdeffTddLPfVxE3jKTM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=vz6VtUzCjeG3o/ecQMDwYE78NlxnFrRnH8LNv9nn+5GyoTbotlNKaxIBcmWoIGXPWF f5Cawdp4m6ezwBXTu7tuadAMROoMnspfbQhf+wqrpi8XzSKgD03Vea9wx57ruCPnceNx fgE1adTAFyZndeKs2Vemzpha95PPJUOnYnbHE= Received: by 10.140.248.16 with SMTP id v16mr1113280rvh.230.1273871065003; Fri, 14 May 2010 14:04:25 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id b10sm2353274rvn.3.2010.05.14.14.04.23 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 14:04:24 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Fri, 14 May 2010 14:03:42 -0700 From: Pyun YongHyeon Date: Fri, 14 May 2010 14:03:42 -0700 To: list@cykotix.com Message-ID: <20100514210342.GD24686@michelle.cdnetworks.com> References: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> <20100514192239.GC24686@michelle.cdnetworks.com> <20100514155638.21116k5xymc7cb8c@webmail.lahni.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100514155638.21116k5xymc7cb8c@webmail.lahni.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 21:04:25 -0000 On Fri, May 14, 2010 at 03:56:38PM -0400, list@cykotix.com wrote: > Quoting Pyun YongHyeon : > > >On Fri, May 14, 2010 at 02:56:12PM -0400, list@cykotix.com wrote: > >>Hello, > >> > >>I recently just purchased 2 Soekris5501 with identical 120gb 2.5" WD > >>Scorpio HDDs. I'm using them for network failover, using CARP, PF and > >>pfSync on FreeBSD 8-STABLE. > >> > >>The short version of my problem: > >> > >>I setup FW2 first, imaged its hard drive to FW1. I changed the > >>necessary configs to update the IPs and ensure FW1 was carp MASTER. > >>Using a known working port on the switch, I continue to get 70% packet > >>loss on FW1 on vr0 (vr0 - extif, vr1 - intif, vr2 - pfsync). If I > >>flip FW1 and FW2, the packet loss follows FW1. I took FW1 home, > >>plugged it into my home network on vr0 and it works fine with 0% > >>packet loss so the interface seems fine. I also took the IP bound to > >>vr0 on FW1 and bound it to vr0 on FW2 and the ISP isn't the problem. > >> > > > >Show me the output of "sysctl dev.vr.0.stats=1" and "netstat -ndI vr0". > > soekris1# sysctl dev.vr.0.stats=1 > dev.vr.0.stats: -1 -> -1 > Please check the output of console. It would have printed some MAC counters maintained in driver. > soekris1# netstat -ndI vr0 > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll Drop > vr0 1500 00:00:24:cc:cb:94 17491 0 14993 > 0 0 0 > vr0 1500 98.xxx.xxx.56 98.xxx.xxx.59 992 - 9374 > - - - > No Ierrs, so MAC counters would be more helpful here. > > soekris2# sysctl dev.vr.0.stats=1 > dev.vr.0.stats: -1 -> -1 > > soekris2# netstat -ndI vr0 > Name Mtu Network Address Ipkts Ierrs Opkts > Oerrs Coll Drop > vr0 1500 00:00:24:ca:40:60 575909 0 588703 > 0 0 0 > vr0 1500 98.xxx.xxx.56 98.xxx.xxx.60 10029 - 53106 > - - - > > > Let me know if you need any other information! Thanks! > > Patrick From owner-freebsd-net@FreeBSD.ORG Fri May 14 21:22:40 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BAF55106566C for ; Fri, 14 May 2010 21:22:40 +0000 (UTC) (envelope-from list@cykotix.com) Received: from mail.lahni.com (badger.cykotix.com [65.110.58.110]) by mx1.freebsd.org (Postfix) with ESMTP id 90D138FC20 for ; Fri, 14 May 2010 21:22:40 +0000 (UTC) Received: from mail.lahni.com (localhost [127.0.0.1]) by mail.lahni.com (Postfix) with ESMTP id C46D82285B for ; Fri, 14 May 2010 17:27:25 -0400 (EDT) Received: by mail.lahni.com (Postfix, from userid 80) id 931F222823; Fri, 14 May 2010 17:27:25 -0400 (EDT) Received: from cpe-65-27-148-30.cinci.res.rr.com (cpe-65-27-148-30.cinci.res.rr.com [65.27.148.30]) by webmail.lahni.com (Horde Framework) with HTTP; Fri, 14 May 2010 17:27:25 -0400 Message-ID: <20100514172725.1937468ajpjekhog@webmail.lahni.com> X-Priority: 3 (Normal) Date: Fri, 14 May 2010 17:27:25 -0400 From: list@cykotix.com To: freebsd-net@freebsd.org References: <20100514145612.14566x4tj40yhyos@webmail.lahni.com> <20100514192239.GC24686@michelle.cdnetworks.com> <20100514155638.21116k5xymc7cb8c@webmail.lahni.com> <20100514210342.GD24686@michelle.cdnetworks.com> In-Reply-To: <20100514210342.GD24686@michelle.cdnetworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: Packet Loss on FW1 but not FW2 (CARP + PF on FBSD8) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2010 21:22:40 -0000 Quoting Pyun YongHyeon : >> >Show me the output of "sysctl dev.vr.0.stats=1" and "netstat -ndI vr0". >> >> soekris1# sysctl dev.vr.0.stats=1 >> dev.vr.0.stats: -1 -> -1 >> > > Please check the output of console. It would have printed some MAC > counters maintained in driver. >> soekris1# netstat -ndI vr0 >> Name Mtu Network Address Ipkts Ierrs Opkts >> Oerrs Coll Drop >> vr0 1500 00:00:24:cc:cb:94 17491 0 14993 >> 0 0 0 >> vr0 1500 98.xxx.xxx.56 98.xxx.xxx.59 992 - 9374 >> - - - >> FW1: vr0 statistics: Outbound good frames : 14992 Inbound good frames : 17486 Outbound errors : 0 Inbound errors : 0 Inbound no buffers : 0 Inbound no mbuf clusters: 0 Inbound FIFO overflows : 0 Inbound CRC errors : 0 Inbound frame alignment errors : 0 Inbound giant frames : 0 Inbound runt frames : 0 Outbound aborted with excessive collisions : 0 Outbound collisions : 0 Outbound late collisions : 0 Outbound underrun : 0 PCI bus errors : 0 driver restarted due to Rx/Tx shutdown failure : 0 > No Ierrs, so MAC counters would be more helpful here. >> soekris2# sysctl dev.vr.0.stats=1 >> dev.vr.0.stats: -1 -> -1 >> >> soekris2# netstat -ndI vr0 >> Name Mtu Network Address Ipkts Ierrs Opkts >> Oerrs Coll Drop >> vr0 1500 00:00:24:ca:40:60 575909 0 588703 >> 0 0 0 >> vr0 1500 98.xxx.xxx.56 98.xxx.xxx.60 10029 - 53106 >> - - - FW2: vr0 statistics: Outbound good frames : 588054 Inbound good frames : 575353 Outbound errors : 0 Inbound errors : 0 Inbound no buffers : 0 Inbound no mbuf clusters: 0 Inbound FIFO overflows : 0 Inbound CRC errors : 0 Inbound frame alignment errors : 0 Inbound giant frames : 0 Inbound runt frames : 0 Outbound aborted with excessive collisions : 0 Outbound collisions : 0 Outbound late collisions : 0 Outbound underrun : 0 PCI bus errors : 0 driver restarted due to Rx/Tx shutdown failure : 0 Patrick ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. From owner-freebsd-net@FreeBSD.ORG Sat May 15 13:23:59 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 940F11065670 for ; Sat, 15 May 2010 13:23:58 +0000 (UTC) (envelope-from barney_cordoba@yahoo.com) Received: from web63908.mail.re1.yahoo.com (web63908.mail.re1.yahoo.com [69.147.97.123]) by mx1.freebsd.org (Postfix) with SMTP id 517698FC2B for ; Sat, 15 May 2010 13:23:57 +0000 (UTC) Received: (qmail 38237 invoked by uid 60001); 15 May 2010 13:23:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1273929837; bh=YTqbwfT9mYmWVQTgyP3CKB2UfD756kj+hl140axZ8I0=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=KdhbsdYDgT5bHCR/Kf7Kyuf2Zy2dWBgC/YczY4KiLdmM1h+jYgUKUFTTuhpjZErBOHG2ZmewRXjbWrTVhBcYq/kXHKi5UZTJUFg04cLd5tOBVEjJqr9IlhWpeWT9Pq8AvtoLNg/kK1x/gr0WiQHbfmkrgrPzw8hS4Hw37IaGcbI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Rm94iVUy/4mAI3wrKIqd2aTJkRppd0e5AgmMn8WHbdC2PlU6e7WfVkPsOQZHB45vWURlxxG5KuBQGL2LZ4WCoXM04xqXW0TP2u7ujuEXe2k4KeL/dwkTpd6RyCxzwWTVUS856b/f/bnntvCZ889bhDHAOJD8miexUccbgEolB14=; Message-ID: <620965.38211.qm@web63908.mail.re1.yahoo.com> X-YMail-OSG: E7zg2pIVM1kiA2F3RPEaNz7m.6wonVexcWJEV0UcUCsqda3 ryb9NokrA.1pw_91v8d4bACZUPqYc.kynihgL0A4Pg8bBRtx3LJNpKhArLZS _M5D2T29HvF93Dnm1nmgL7.mDY0OwPHmKImNwu0BRaEdGbRuUZh9tlZqzbf2 DUm1JpAUPFfbYVE2fTYdLdG.0CjZkXBhRLdkQO7w5eIB0u8.tzO9G6ylTT3_ YbDnrATp_K3he9d.B2GRpk_82.URPyZ3NrgleOwF8F9WPXw1riTTlzbzhMCQ .VZhAaBQeHQgfsyM1IjhNSQCFd0dNRUs- Received: from [98.203.21.152] by web63908.mail.re1.yahoo.com via HTTP; Sat, 15 May 2010 06:23:57 PDT X-Mailer: YahooMailClassic/10.1.11 YahooMailWebService/0.8.103.269680 Date: Sat, 15 May 2010 06:23:57 -0700 (PDT) From: Barney Cordoba To: Jack Vogel , Alexander Sack In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, Andrew Gallatin Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 13:23:59 -0000 =0A=0A--- On Fri, 5/14/10, Alexander Sack wrote:=0A=0A= > From: Alexander Sack =0A> Subject: Re: Intel 10Gb=0A>= To: "Jack Vogel" =0A> Cc: "Murat Balaban" , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, "Andrew= Gallatin" =0A> Date: Friday, May 14, 2010, 1:20 PM= =0A> On Fri, May 14, 2010 at 1:01 PM, Jack=0A> Vogel =0A= > wrote:=0A> >=0A> >=0A> > On Fri, May 14, 2010 at 8:18 AM, Alexander Sack = =0A> wrote:=0A> >>=0A> >> On Fri, May 14, 2010 at 10:07= AM, Andrew Gallatin=0A> =0A> >> wrote:=0A> >> > Alex= ander Sack wrote:=0A> >> > <...>=0A> >> >>> Using this driver/firmware comb= o, we=0A> can receive minimal packets at=0A> >> >>> line rate (14.8Mpps) to= userspace.=0A> =A0You can even access this using a=0A> >> >>> libpcap inte= rface. =A0The trick is=0A> that the fast paths are OS-bypass,=0A> >> >>> an= d don't suffer from OS overheads,=0A> like lock contention. =A0See=0A> >> >= >> http://www.myri.com/scs/SNF/doc/index.html for=0A> details.=0A> >> >>=0A= > >> >> But your timestamps will be atrocious at=0A> 10G speeds. =A0Myricom= doesn't=0A> >> >> timestamp packets AFAIK. =A0If you want=0A> reliable tim= estamps you need to=0A> >> >> look at companies like Endace, Napatech,=0A> = etc.=0A> >> >=0A> >> > I see your old help ticket in our system.=0A> =A0Yes= , our timestamping=0A> >> > is not as good as a dedicated capture card=0A> = with a GPS reference,=0A> >> > but it is good enough for most people.=0A> >= >=0A> >> I was told btw that it doesn't timestamp at ALL.=0A> =A0I am assum= ing NOW=0A> >> that is incorrect.=0A> >>=0A> >> Define *most* people.=0A> >= >=0A> >> I am not knocking the Myricom card. =A0In fact I so=0A> wish you g= uys would=0A> >> just add the ability to latch to a 1PPS for=0A> timestampi= ng and it would=0A> >> be perfect.=0A> >>=0A> >> We use I think an older ve= rsion of the card=0A> internally for replay.=0A> >> Its a great multi-purpo= se card.=0A> >>=0A> >> However with IPG at 10G in the nanoseconds, anyone= =0A> trying to do OWDs=0A> >> or RTT will find it difficult compared to an= =0A> Endace or Napatech card.=0A> >>=0A> >> Btw, I was referring to bpf(4) = specifically, so=0A> please don't take my=0A> >> comments as a knock agains= t it.=0A> >>=0A> >> >> PS I am not sure but Intel also supports=0A> writing= packets directly in=0A> >> >> cache (yet I thought the 82599 driver=0A> ac= tually does a prefetch anyway=0A> >> >> which had me confused on why that h= elps)=0A> >> >=0A> >> > You're talking about DCA. =A0We support DCA as=0A> = well (and I suspect some=0A> >> > other 10G NICs do to). =A0There are a few= =0A> barriers to using DCA on=0A> >> > FreeBSD, not least of which is that = FreeBSD=0A> doesn't currently have the=0A> >> > infrastructure to support i= t (no IOATDMA or=0A> DCA drivers).=0A> >>=0A> >> Right.=0A> >>=0A> >> > DCA= is also problematic because support from=0A> system/motherboard=0A> >> > v= endors is very spotty. =A0The vendor must=0A> provide the correct tag table= =0A> >> > in BIOS such that the tags match the CPU/core=0A> numbering in th= e system.=0A> >> > Many motherboard vendors don't bother with=0A> this, and= you cannot enable=0A> >> > DCA on a lot of systems, even though the=0A> un= derlying chipset supports=0A> >> > DCA. =A0I've done hacks to force-enable = it in=0A> the past, with mixed=0A> >> > results. The problem is that DCA de= pends on=0A> having the correct tag=0A> >> > table, so that packets can be = prefetched into=0A> the correct CPU's cache.=0A> >> > If the tag table is i= ncorrect, DCA is a big=0A> pessimization, because it=0A> >> > blows the cac= he in other CPUs.=0A> >>=0A> >> Right.=0A> >>=0A> >> > That said, I would *= love* it if FreeBSD grew=0A> ioatdma/dca support.=0A> >> > Jack, does Intel= have any interest in porting=0A> DCA support to FreeBSD?=0A> >>=0A> >> Que= stion for Jack or Drew, what DOES FreeBSD have=0A> to do to support=0A> >> = DCA? =A0I thought DCA was something you just enable=0A> on the NIC chipset= =0A> >> and if the system is IOATDMA aware, it just works.=0A> =A0Is that n= ot right=0A> >> (assuming cache tags are correct and accessible)?=0A> =A0i.= e. I thought this=0A> >> was hardware black magic than anything specific=0A= > the OS has to do.=0A> >>=0A> >=0A> > OK, let me see if I can clarify some= of this. First,=0A> there IS an I/OAT=0A> > driver=0A> > that I did for Fr= eeBSD like 3 or 4 years ago, in the=0A> timeframe that we put=0A> > the fea= ture out. However, at that time all it was good=0A> for was the DMA=0A> > a= spect=0A> > of things, and Prafulla used it to accelerate the=0A> stack cop= ies; interest did=0A> > not seem that great so I put the code aside, its no= t=0A> badly dated and needs=0A> > to be brought up to date due to there bei= ng a few=0A> different versions of the=0A> > hardware now.=0A> >=0A> > At o= ne point maybe a year back I started to take the=0A> code apart thinking=0A= > > I would JUST do DCA, that got back-burnered due to=0A> other higher pri= ority=0A> > issues, but its still an item in my queue.=0A> >=0A> > I also h= ad a nibble of an interest in using the DMA=0A> engine so perhaps I=0A> > s= hould not go down the road of just doing the DCA=0A> support in the I/OAT= =0A> > part of the driver. The question is how to make the=0A> infrastructu= re work.=0A> >=0A> > To answer Alexander's question, DCA support is NOT in= =0A> the NIC, its in=0A> > the chipset, that's why the I/OAT driver was don= e as a=0A> seperate driver,=0A> > but the NIC was the user of the info, its= been a while=0A> since I was into=0A> > the code but if memory serves the = I/OAT driver just=0A> enables the support=0A> > in the chipset, and then th= e NIC driver configures its=0A> engine to use it.=0A> =0A> Thank you very m= uch Jack!=A0 :)=A0 It was not clear=0A> from the docs what was=0A> where to= me.=A0 I just assumed this was Intel NIC knew=0A> Intel chipset=0A> black = magic!=A0 LOL.=0A> =0A> > DCA and DMA were supported in Linux in the same d= river=0A> because=0A> > the chipset features were easily handled together= =0A> perhaps, I'm not=0A> > sure :)=0A> =0A> Ok!=A0 (it was my other refere= nce)=0A> =0A> > Fabien's data earlier in this thread suggested that a=0A> s= trategicallly=0A> > placed prefetch did you more good than DCA did if I=0A>= recall, what=0A> > do you all think of that?=0A> =0A> I thought there was = a thread where prefetch didn't do much=0A> for you....lol...=0A> =0A> If yo= u just prefetch willy-nilly then don't you run the=0A> risk of=0A> packets = hitting caches on cores outside of what the=0A> application=0A> reading the= m is on thereby defeating the whole purpose of=0A> prefetch?=0A> =0A> > As = far as I'm concerned right now I am willing to=0A> resurrect the driver,=0A= > > clean it up and make the features available, we can=0A> see how valuabl= e=0A> > they are after that, how does that sound??=0A> =0A> Sounds good to = me.=A0 I at least put it somewhere=0A> publicly for people to look at.=0A> = =0A> -aps=0A=0AOf course none of this has anything to do with the original = subject.=0AProcessing a monodirectional stream is really no problem, nor do= es=0Ait require any sort of special design consideration. All of this chatt= er=0Aabout card features is largely minutia. =0A=0AModern processors are so= fast that its a waste of brain cells to spend=0Atime trying to squeeze non= oseconds from packet gathering. You guys sound=0Athe same as when you were = trying to do 10Mb/s ethernet with ISA bus NICs.=0A=0AIt makes no sense to f= ocus on optimizing tires for a car which can't break=0A 80Mph. The entire p= roblem is lock contention. Until you have a driver=0Athat can scale to a po= int where 10gb/s is workable without significant=0Alock contention, you're = just feeding a dead body.=0A=0AUnless of course your goal for 10gb/s for Fr= eeBSD is for it to be a really=0Agood network monitor. =0A=0ABC =0A=0A=0A = From owner-freebsd-net@FreeBSD.ORG Sat May 15 17:41:24 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2E66106566B for ; Sat, 15 May 2010 17:41:24 +0000 (UTC) (envelope-from jgarciaitlist@gmail.com) Received: from mail-pz0-f174.google.com (mail-pz0-f174.google.com [209.85.222.174]) by mx1.freebsd.org (Postfix) with ESMTP id AA0828FC14 for ; Sat, 15 May 2010 17:41:24 +0000 (UTC) Received: by pzk4 with SMTP id 4so2010328pzk.7 for ; Sat, 15 May 2010 10:41:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=8ipXSuRVOSbe5dI5Wb+5B0SmUKzAtjmdbeY0Whqnqzo=; b=uTuAh+FKVK1GZkvERtXAukuu93U/gSHtfI1RbB8oTDBV5AllU+0QTNsIY//JU2xHn9 6ej2NW0ov6c+LpCnUOG0JNQsUQIu5gzU9po6mpI5qqPhGA5EGayBUzYyWduz68bJm5r2 nqMtSPYaHRWUM6tHlYy8KmUx/ClqMpMgn5bLc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=X5n+5SMpXBFD1jYuNfOFkbU8xPdYLOsfnHfPRg7ijCmB3bUoQ2Y7iGcESbCqp0+tfh kbqjPKRZdg6DvSbGIrmxCLXfHLjqv/mi1O6XMgST+7ylrCIZBJOo42aExS38VuWNyNrs agUU4hTyHUprO53oaALD4uV13EzE2czHzDoMA= MIME-Version: 1.0 Received: by 10.115.64.21 with SMTP id r21mr2463426wak.23.1273945284103; Sat, 15 May 2010 10:41:24 -0700 (PDT) Received: by 10.114.209.5 with HTTP; Sat, 15 May 2010 10:41:24 -0700 (PDT) Date: Sat, 15 May 2010 13:41:24 -0400 Message-ID: From: justino garcia To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Which is faster: iSCSI to Freebsd box over 1Gb or local SATA storage with intel ICH9? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 17:41:24 -0000 Which is faster: iSCSI to Freebsd box over 1Gb or local SATA storage with intel ICH9? thanks -- Justin IT-TECH From owner-freebsd-net@FreeBSD.ORG Sat May 15 21:49:34 2010 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9666B1065673; Sat, 15 May 2010 21:49:34 +0000 (UTC) (envelope-from pisymbol@gmail.com) Received: from mail-gw0-f54.google.com (mail-gw0-f54.google.com [74.125.83.54]) by mx1.freebsd.org (Postfix) with ESMTP id 3A49D8FC14; Sat, 15 May 2010 21:49:33 +0000 (UTC) Received: by gwb15 with SMTP id 15so94344gwb.13 for ; Sat, 15 May 2010 14:49:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yt36Eh76OCLtD9PEvOo1mTycfE1DLFZStVxG0/5SHnM=; b=S3W2MpT4fxRnq8sXpSvMDjLG70iVr9JZ1LAIYQaUIh6MUGtMdhjmu+MCoPgqxSnmqG LSazrIhA5QKYhVx/wIHblrkKqM4IgqE61+a56/fott1EvC9VNBiuS3F5KPR98MKdWUqc L9TMriksCWGZz5bvKCPi+f5ALCaSuF3Fbw53M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=eUu955Vh2EPpQSxV3f8C566U+9Wncvkw80R9hkqxUznvDI8uQVL1wQl+Eb3KWL6goX /sQgqKQzRgHbaWWK83GqNflfGZznNprnmmjDXWXLouEbe3/241Ft7yLyASKfOc2Dy5ug UVjcSaStFSQGREh75aKeTfS099NPjoCmbuebI= MIME-Version: 1.0 Received: by 10.100.246.35 with SMTP id t35mr3960057anh.14.1273960173419; Sat, 15 May 2010 14:49:33 -0700 (PDT) Received: by 10.100.58.2 with HTTP; Sat, 15 May 2010 14:49:33 -0700 (PDT) In-Reply-To: <620965.38211.qm@web63908.mail.re1.yahoo.com> References: <620965.38211.qm@web63908.mail.re1.yahoo.com> Date: Sat, 15 May 2010 17:49:33 -0400 Message-ID: From: Alexander Sack To: Barney Cordoba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Murat Balaban , freebsd-net@freebsd.org, freebsd-performance@freebsd.org, Jack Vogel , Andrew Gallatin Subject: Re: Intel 10Gb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2010 21:49:34 -0000 On Sat, May 15, 2010 at 9:23 AM, Barney Cordoba wrote: > > > --- On Fri, 5/14/10, Alexander Sack wrote: > >> From: Alexander Sack >> Subject: Re: Intel 10Gb >> To: "Jack Vogel" >> Cc: "Murat Balaban" , freebsd-net@freebsd.org, free= bsd-performance@freebsd.org, "Andrew Gallatin" >> Date: Friday, May 14, 2010, 1:20 PM >> On Fri, May 14, 2010 at 1:01 PM, Jack >> Vogel >> wrote: >> > >> > >> > On Fri, May 14, 2010 at 8:18 AM, Alexander Sack >> wrote: >> >> >> >> On Fri, May 14, 2010 at 10:07 AM, Andrew Gallatin >> >> >> wrote: >> >> > Alexander Sack wrote: >> >> > <...> >> >> >>> Using this driver/firmware combo, we >> can receive minimal packets at >> >> >>> line rate (14.8Mpps) to userspace. >> =A0You can even access this using a >> >> >>> libpcap interface. =A0The trick is >> that the fast paths are OS-bypass, >> >> >>> and don't suffer from OS overheads, >> like lock contention. =A0See >> >> >>> http://www.myri.com/scs/SNF/doc/index.html for >> details. >> >> >> >> >> >> But your timestamps will be atrocious at >> 10G speeds. =A0Myricom doesn't >> >> >> timestamp packets AFAIK. =A0If you want >> reliable timestamps you need to >> >> >> look at companies like Endace, Napatech, >> etc. >> >> > >> >> > I see your old help ticket in our system. >> =A0Yes, our timestamping >> >> > is not as good as a dedicated capture card >> with a GPS reference, >> >> > but it is good enough for most people. >> >> >> >> I was told btw that it doesn't timestamp at ALL. >> =A0I am assuming NOW >> >> that is incorrect. >> >> >> >> Define *most* people. >> >> >> >> I am not knocking the Myricom card. =A0In fact I so >> wish you guys would >> >> just add the ability to latch to a 1PPS for >> timestamping and it would >> >> be perfect. >> >> >> >> We use I think an older version of the card >> internally for replay. >> >> Its a great multi-purpose card. >> >> >> >> However with IPG at 10G in the nanoseconds, anyone >> trying to do OWDs >> >> or RTT will find it difficult compared to an >> Endace or Napatech card. >> >> >> >> Btw, I was referring to bpf(4) specifically, so >> please don't take my >> >> comments as a knock against it. >> >> >> >> >> PS I am not sure but Intel also supports >> writing packets directly in >> >> >> cache (yet I thought the 82599 driver >> actually does a prefetch anyway >> >> >> which had me confused on why that helps) >> >> > >> >> > You're talking about DCA. =A0We support DCA as >> well (and I suspect some >> >> > other 10G NICs do to). =A0There are a few >> barriers to using DCA on >> >> > FreeBSD, not least of which is that FreeBSD >> doesn't currently have the >> >> > infrastructure to support it (no IOATDMA or >> DCA drivers). >> >> >> >> Right. >> >> >> >> > DCA is also problematic because support from >> system/motherboard >> >> > vendors is very spotty. =A0The vendor must >> provide the correct tag table >> >> > in BIOS such that the tags match the CPU/core >> numbering in the system. >> >> > Many motherboard vendors don't bother with >> this, and you cannot enable >> >> > DCA on a lot of systems, even though the >> underlying chipset supports >> >> > DCA. =A0I've done hacks to force-enable it in >> the past, with mixed >> >> > results. The problem is that DCA depends on >> having the correct tag >> >> > table, so that packets can be prefetched into >> the correct CPU's cache. >> >> > If the tag table is incorrect, DCA is a big >> pessimization, because it >> >> > blows the cache in other CPUs. >> >> >> >> Right. >> >> >> >> > That said, I would *love* it if FreeBSD grew >> ioatdma/dca support. >> >> > Jack, does Intel have any interest in porting >> DCA support to FreeBSD? >> >> >> >> Question for Jack or Drew, what DOES FreeBSD have >> to do to support >> >> DCA? =A0I thought DCA was something you just enable >> on the NIC chipset >> >> and if the system is IOATDMA aware, it just works. >> =A0Is that not right >> >> (assuming cache tags are correct and accessible)? >> =A0i.e. I thought this >> >> was hardware black magic than anything specific >> the OS has to do. >> >> >> > >> > OK, let me see if I can clarify some of this. First, >> there IS an I/OAT >> > driver >> > that I did for FreeBSD like 3 or 4 years ago, in the >> timeframe that we put >> > the feature out. However, at that time all it was good >> for was the DMA >> > aspect >> > of things, and Prafulla used it to accelerate the >> stack copies; interest did >> > not seem that great so I put the code aside, its not >> badly dated and needs >> > to be brought up to date due to there being a few >> different versions of the >> > hardware now. >> > >> > At one point maybe a year back I started to take the >> code apart thinking >> > I would JUST do DCA, that got back-burnered due to >> other higher priority >> > issues, but its still an item in my queue. >> > >> > I also had a nibble of an interest in using the DMA >> engine so perhaps I >> > should not go down the road of just doing the DCA >> support in the I/OAT >> > part of the driver. The question is how to make the >> infrastructure work. >> > >> > To answer Alexander's question, DCA support is NOT in >> the NIC, its in >> > the chipset, that's why the I/OAT driver was done as a >> seperate driver, >> > but the NIC was the user of the info, its been a while >> since I was into >> > the code but if memory serves the I/OAT driver just >> enables the support >> > in the chipset, and then the NIC driver configures its >> engine to use it. >> >> Thank you very much Jack!=A0 :)=A0 It was not clear >> from the docs what was >> where to me.=A0 I just assumed this was Intel NIC knew >> Intel chipset >> black magic!=A0 LOL. >> >> > DCA and DMA were supported in Linux in the same driver >> because >> > the chipset features were easily handled together >> perhaps, I'm not >> > sure :) >> >> Ok!=A0 (it was my other reference) >> >> > Fabien's data earlier in this thread suggested that a >> strategicallly >> > placed prefetch did you more good than DCA did if I >> recall, what >> > do you all think of that? >> >> I thought there was a thread where prefetch didn't do much >> for you....lol... >> >> If you just prefetch willy-nilly then don't you run the >> risk of >> packets hitting caches on cores outside of what the >> application >> reading them is on thereby defeating the whole purpose of >> prefetch? >> >> > As far as I'm concerned right now I am willing to >> resurrect the driver, >> > clean it up and make the features available, we can >> see how valuable >> > they are after that, how does that sound?? >> >> Sounds good to me.=A0 I at least put it somewhere >> publicly for people to look at. >> >> -aps > > Of course none of this has anything to do with the original subject. > Processing a monodirectional stream is really no problem, nor does > it require any sort of special design consideration. All of this chatter > about card features is largely minutia. > > Modern processors are so fast that its a waste of brain cells to spend > time trying to squeeze nonoseconds from packet gathering. You guys sound > the same as when you were trying to do 10Mb/s ethernet with ISA bus NICs. It depends on what you really mean and what lock contention you are specifically talking about. The NIC features as well as multi-queue bpf(4) is a way to distribute the load across multiple cores thereby lowering total CPU overhead (that's always good) AS WELL AS provide the ability for libpcap consumers to post-process caught packets in cache. Most third-party capture cards already do just this: they are typically stream or feed based and allow for flow based steering to distribute the load across cores. Intel only recently has added this in their 10g chipsets (Jack can correct if I'm wrong). All of these things help both in capture and post-processing. > It makes no sense to focus on optimizing tires for a car which can't brea= k > =A080Mph. The entire problem is lock contention. Until you have a driver > that can scale to a point where 10gb/s is workable without significant > lock contention, you're just feeding a dead body. Lock contention in bpf(4) or in the NIC driver or in both? :) > Unless of course your goal for 10gb/s for FreeBSD is for it to be a reall= y > good network monitor. That is exactly my goal: it would be great to see FreeBSD as a fantastic general-purpose network monitor at 10gb/s speeds. There are couple of issues one of which is also timestamping. -aps