From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 00:02:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 2F258BD4 for ; Sun, 10 Feb 2013 00:02:43 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id EE953EB0 for ; Sun, 10 Feb 2013 00:02:42 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 6CE7A5081A for ; Sat, 9 Feb 2013 16:02:20 -0800 (PST) To: freebsd-net@freebsd.org Subject: Re: Question: Why ain't I getting gigabit speed? In-Reply-To: <20130209221107.GA32563@server.rulingia.com> Date: Sat, 09 Feb 2013 16:02:20 -0800 Message-ID: <8112.1360454540@tristatelogic.com> From: "Ronald F. Guilmette" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 00:02:43 -0000 I want to thank all of the various people who offered help, advice, and suggestings regarding this problem. It's all really appreciated. Since I first posted about this issue, I have diligently tried to isolate/debug the problem. I swapped the card into a totally different system, also running FreeBSD, and found the exact same symptoms. I used other equipment to verify that both my cables and my Linksys E2000 were not the source of the problem. Lastly, I brought up the card in the exact same system where I had originally noted the problem, but under Windows rather than FreeBSD. Anyway, after all this testing, I believe that I can now say definitively that the problem is indeed bad hardware in/on the card. The card exibits essentially the same symptoms under Windows as it does under FreeBSD, i.e. running only at 100mbs, rather than the 1gbs that it should be capable of. I confess that unless and until I had done all of the testing necessary to fully confirm this, it really isn't a result that I would have either anticipated or expected. I mean really, 99% of everything that makes a card like this do what it is supposed to do is in the chip (in this case RTL8110S-32) and I would expect that Realtek wouldn't let one of those out of their factory unless and until it had passed all normal QA tests. So I guess that somehow, some way, the folks who manufactured this card somehow managed to mess up that last 1%, i.e. the "value added" that they put into building a card around the bare chip. I would have thought that screwing that part up would have actually been rather difficult, but apparently somebody did manage to pull it off. The only notable markings on the board are a white sticker on the back with a bardcode, a serial number and what looks like a model number, FG-R8110-A4-01-BC01. Results from googling around for various permu- tations of that seem to indicate that this board was originally manu- factured by "Western PA SYBA", and indeed, it looks perfectly identical to the one pictured here: http://www.tbcart.com/product/18198352477/West+Blaster+PCI+Gigabit+Desktop+1000M+network+PCI+network+adapter (The eBay vendor who sold it to me did not list the name of the manu- facturer in the relevant eBay listing, which is why I am puzzling this out after the fact.) So anyway, just a word to the wise... These specific boards may perhaps not be of the highest quality. Regards, rfg P.S. While I appreciate all the friendly advice people here have given me, i.e. to go with a card based around some non-Realtek chip, I have to say that up until now I have always and consistantly had -zero- problems with the many other Realtek-based 10/100 cards that I have owned and used. This 10/100/1000 card is the first one I've ever had that has caused me any problems. From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 05:05:47 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 927BF919; Sun, 10 Feb 2013 05:05:47 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-da0-f45.google.com (mail-da0-f45.google.com [209.85.210.45]) by mx1.freebsd.org (Postfix) with ESMTP id 66A91961; Sun, 10 Feb 2013 05:05:47 +0000 (UTC) Received: by mail-da0-f45.google.com with SMTP id w4so2324852dam.4 for ; Sat, 09 Feb 2013 21:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hldmztYVhgMyR4e3Y6mp1nsE+DMjsTq3bL99avofesA=; b=rXTcR6exzFpvlttiWo59WJCkMcC9sv0CQ47wcuDZ0d9UTO5Gra0FNaV1HANyA+TcDO 6hngwolVN2t0Nb9Z5IVBQne1XSMXHC1Md9Akrii431v3+rVJHokl7ySpMK77wq6MuHTx 1CtOKJGPgaCAn1MgX691INfy0wDlv3gMdFcNr9NqRzJmStCsY6qc2vhpqlm7JF08O8T9 uacT6Reoh7rzE6nkPAQXh2aUmRadbunaQm4V8jm/4LRkZqT/SLgKx1iaQNAlfgJmgBNa 157xC1xBAPLN0L4qhx7ieZzjRK2r4KenGe3VcCxp9gJ3m2qJH2gmw1kguHQqT7jMvr78 KIpw== MIME-Version: 1.0 X-Received: by 10.68.117.105 with SMTP id kd9mr8351713pbb.6.1360472741744; Sat, 09 Feb 2013 21:05:41 -0800 (PST) Received: by 10.67.2.65 with HTTP; Sat, 9 Feb 2013 21:05:41 -0800 (PST) In-Reply-To: <51166019.9040104@mu.org> References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> Date: Sat, 9 Feb 2013 21:05:41 -0800 Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Kevin Oberman To: Alfred Perlstein Content-Type: text/plain; charset=UTF-8 Cc: Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 05:05:47 -0000 On Sat, Feb 9, 2013 at 6:41 AM, Alfred Perlstein wrote: > On 2/7/13 12:04 PM, George Neville-Neil wrote: >> >> On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote: >> >>> On 2/6/13 4:46 AM, John Baldwin wrote: >>>> >>>> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote: >>>>> >>>>> John: >>>>> >>>>> A burst at line rate will *often* cause drops. This is because >>>>> router queues are at a finite size. Also such a burst (especially >>>>> on a long delay bandwidth network) cause your RTT to increase even >>>>> if there is no drop which is going to hurt you as well. >>>>> >>>>> A SHOULD in an RFC says you really really really really need to do it >>>>> unless there is some thing that makes you willing to override it. It is >>>>> slight wiggle room. >>>>> >>>>> In this I agree with Andre, we should not be *not* doing it. Otherwise >>>>> folks will be turning this on and it is plain wrong. It may be fine >>>>> for your network but I would not want to see it in FreeBSD. >>>>> >>>>> In my testing here at home I have put back into our stack max-burst. >>>>> This >>>>> uses Mark Allman's version (not Kacheong Poon's) where you clamp the >>>>> cwnd at >>>>> no more than 4 packets larger than your flight. All of my testing >>>>> high-bw-delay or lan has shown this to improve TCP performance. This >>>>> is because it helps you avoid bursting out so many packets that you >>>>> overflow >>>>> a queue. >>>>> >>>>> In your long-delay bw link if you do burst out too many (and you never >>>>> know how many that is since you can not predict how full all those >>>>> MPLS queues are or how big they are) you will really hurt yourself even >>>>> worse. >>>>> Note that generally in Cisco routers the default queue size is >>>>> somewhere between >>>>> 100-300 packets depending on the router. >>>> >>>> Due to the way our application works this never happens, but I am fine >>>> with >>>> just keeping this patch private. If there are other shops that need >>>> this they >>>> can always dig the patch up from the archives. >>>> >>> This is yet another time when I'm sad about how things happen in FreeBSD. >>> >>> A developer come forward with a non-default option that's very useful for >>> some specific workloads, specifically one that contributes much time and $$$ >>> to the project and the community rejects the patches even though it's been >>> successful in other OSes. >>> >>> It makes zero sense. >>> >>> John, can you repost the patch? Maybe there is a way to refactor this >>> somehow so it's like accept filters where we can plug in a hook for TCP? >>> >>> I am very disappointed, but not surprised. >>> >> I take away the complete opposite feeling. This is how we work through >> these issues. >> It's clear from the discussion that this need not be a default in the >> system, >> and is a special case. We had a reasoned discussion of what would be best >> to do >> and at least two experts in TCP weighed in on the effect this change might >> have. >> >> Not everything proposed by a developer need go into the tree, in >> particular since these >> discussions are archived we can always revisit this later. >> >> This is exactly how collaborative development should look, whether or not >> the patch >> is integrated now, next week, next year, or ever. > > > I agree that discussion is great, we have all learned quite a bit from it, > about TCP and the dangers of adjusting buffering without considerable > thought. I would not be involved in FreeBSD had this type of discussion and > information not be discussed on the lists so readily. > > However, the end result must be far different than what has occurred so far. > > If the code was deemed unacceptable for general inclusion, then we must find > a way to provide a light framework to accomplish the needs of the community > member. > > Take for instance someone who is starting a company that needs this > facility. Which OS will they choose? One who has integrated a useful > feature? Or one who has rejected it and left that code in the mailing list > archives? > > As much as expert opinion is valuable, it must include understanding and > need of handling special cases and the ability to facilitate those special > cases for our users and developers. This is a subject rather near to my heart, having fought battles with congestion back in the dark days of Windows when it essentially defaulted to TCPIGNOREIDLE. It was a huge pain, but it was the only way Windows did TCP in the early days. It simply did not implement slow-start. This was really evil, but in the days when lots of links were 56K and T-1 was mostly used for network core links, the Internet, small as it was back then, did not melt, though it glowed a frightening shade of red fairly often. Today too many systems running like this would melt thins very quickly. OTOH, I can certainly see cases, like John's, where it would be very beneficial. And, yes, Linux has it. (I don't see this a relevant in any way except as proof tat not enough people have turned it on to cause serious problems... yet!) It seems a shame to make everyone who really has a need develop their own patches or dig though old mail to find John's. What I would like to see is a way to have it available, but make it unlikely to be enabled except in a way that would put up flashing red warnings and sound sirens to warn people that it is very dangerous and can be a way to blow off a few of one's own toes. One idea that popped into my head (and may be completely ridiculous, is to make its availability dependent on a kernel option and have warning in NOTES about it contravening normal and accepted practice and that it can cause serious problems both for yourself and for others using the network. I might also note that almost all higher performance (1G and faster) networks already have a form of this...TSO. In case you hadn't noticed, TSO will take a large buffer and transmit it as multiple segments which are transmitted back to back with NO delay or awareness of congestion. I can confirm that even this limited case can and does sometimes result in packet loss when router queues are inadequate to handle the load. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 07:30:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 25DA0A5A; Sun, 10 Feb 2013 07:30:48 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id C4D63CD0; Sun, 10 Feb 2013 07:30:47 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,636,1355126400"; d="scan'208";a="18822542" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 09 Feb 2013 23:30:40 -0800 Received: from vmwexceht01-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1A7UdZw018180; Sat, 9 Feb 2013 23:30:39 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Sat, 9 Feb 2013 23:30:39 -0800 From: "Eggert, Lars" To: Kevin Oberman Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Thread-Topic: [PATCH] Add a new TCP_IGNOREIDLE socket option Thread-Index: AQHN+Nyo0gmhYvjjiEa9ZKUxU2VFfphWVHgAgAARXYCAFuhUAIAAFkGAgABOyICAAb3EAIACyoSAgADxdICAACiAAA== Date: Sun, 10 Feb 2013 07:30:38 +0000 Message-ID: References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.118] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Alfred Perlstein , Randall Stewart , John Baldwin , "" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 07:30:48 -0000 On Feb 10, 2013, at 6:05, Kevin Oberman wrote: > One idea that popped into my head (and may be completely ridiculous, > is to make its availability dependent on a kernel option and have > warning in NOTES about it contravening normal and accepted practice > and that it can cause serious problems both for yourself and for > others using the network. Also, if it gets merged, don't call it TCP_IGNOREIDLE. Call it TCP_BLAST_DA= NGEROUSLY_AFTER_IDLE. Lars= From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 08:18:02 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B695F456 for ; Sun, 10 Feb 2013 08:18:02 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo1.cc.swin.edu.au (gpo1.cc.swin.edu.au [136.186.1.30]) by mx1.freebsd.org (Postfix) with ESMTP id 32A37E90 for ; Sun, 10 Feb 2013 08:18:01 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo1.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r1A8I07Y002449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Feb 2013 19:18:00 +1100 Message-ID: <511757B8.3080407@swin.edu.au> Date: Sun, 10 Feb 2013 19:18:00 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 08:18:02 -0000 On 02/10/2013 18:30, Eggert, Lars wrote: > On Feb 10, 2013, at 6:05, Kevin Oberman wrote: >> One idea that popped into my head (and may be completely ridiculous, >> is to make its availability dependent on a kernel option and have >> warning in NOTES about it contravening normal and accepted practice >> and that it can cause serious problems both for yourself and for >> others using the network. > > Also, if it gets merged, don't call it TCP_IGNOREIDLE. Call it TCP_BLAST_DANGEROUSLY_AFTER_IDLE. TCP_AVALANCHE cheers, gja From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 09:24:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 143BE24C for ; Sun, 10 Feb 2013 09:24:45 +0000 (UTC) (envelope-from garmitage@swin.edu.au) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) by mx1.freebsd.org (Postfix) with ESMTP id 96B5110F for ; Sun, 10 Feb 2013 09:24:44 +0000 (UTC) Received: from [136.186.229.37] (garmitage.caia.swin.edu.au [136.186.229.37]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id r1A9OEDq020597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Feb 2013 20:24:36 +1100 Message-ID: <5117673E.3020203@swin.edu.au> Date: Sun, 10 Feb 2013 20:24:14 +1100 From: grenville armitage User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:16.0) Gecko/20121107 Thunderbird/16.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 09:24:45 -0000 I'm somewhat sympathetic to the purity of TCP. Nevertheless... On 02/10/2013 16:05, Kevin Oberman wrote: [..] > What I would like to see is a way to have it available, but make it > unlikely to be enabled except in a way that would put up flashing red > warnings and sound sirens to warn people that it is very dangerous and > can be a way to blow off a few of one's own toes. +1 I rather doubt the Internet will be crushed by adding a non-default option that allows FreeBSD TCP to behave More Aggressively Than It Really Should(tm) under certain circumstances. I'm certainly not denying that the sky would likely fall if everyone turned on John's proposed socket option all the time. (Such might also be said of allowing UDP applications to be free of any CC at all, or allowing new TCP CC algorithms that deviate from the prevalent norm.) But I think that FreeBSD benefits from adding more special-case knobs for the cognoscenti to twiddle, on the basis that most end-users wont bother. > One idea that popped into my head (and may be completely ridiculous, > is to make its availability dependent on a kernel option and have > warning in NOTES about it contravening normal and accepted practice > and that it can cause serious problems both for yourself and for > others using the network. Perhaps also require a sysctl to be set before John's per-socket TCP_IGNOREIDLE option has any effect. (Thus requiring a sending host's administrator to at least be complicit in enabling any subsequent ruination of their nearest bottleneck.) cheers, gja From owner-freebsd-net@FreeBSD.ORG Sun Feb 10 10:36:18 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B7236FC1 for ; Sun, 10 Feb 2013 10:36:18 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-x22e.google.com (la-in-x022e.1e100.net [IPv6:2a00:1450:4010:c03::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 2143E314 for ; Sun, 10 Feb 2013 10:36:17 +0000 (UTC) Received: by mail-la0-f46.google.com with SMTP id fq12so5033031lab.19 for ; Sun, 10 Feb 2013 02:36:15 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=PhKraS7UtcoXypVl4PClfbw2jxhXvPRd7maJ/d8hvwU=; b=L+BpMmtWhDMvBQFLpOZ3jZUGy41Wk54i5hcbyuhSrbFRpUjBsb7dm1BYyY4HupFYAf 3Kh9ETi+mikj4mheeOb1Bx53GoYfDxS3b2Xxqj11gXNjNHT17BMijdcjy0hOJCt2rjKE sueSUnw5O+obdyaG+6byMrAbhPA1Ss5ZHnso7g8wTi41iLI1BqecbDO33MMzVFcVMcx6 vN/d/kE1Wl/e6wn56vnumBucIzrBVx75f2ruiURH8MYhkT+y9uODW06106Tr4uDx6rNp JF6u8EdaGvb6U4gQhPolhGH0knBfB9XBwUg0If2ddP3zpYkb3j7NVECuGYy3d2w1NIIg m0gg== X-Received: by 10.152.110.228 with SMTP id id4mr9753230lab.34.1360492575277; Sun, 10 Feb 2013 02:36:15 -0800 (PST) Received: from zont-osx.local (ppp95-165-158-215.pppoe.spdop.ru. [95.165.158.215]) by mx.google.com with ESMTPS id go4sm11909976lbb.16.2013.02.10.02.36.13 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Feb 2013 02:36:14 -0800 (PST) Sender: Andrey Zonov Message-ID: <51177818.2090900@FreeBSD.org> Date: Sun, 10 Feb 2013 14:36:08 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2WTXXJCNJPLDAQHRIJTMU" X-Gm-Message-State: ALoCoQnwsgwU+uN2LbdzjOfjdk8QUY6Alfpu+Neq7MXkBQm4v3ETQGsPMdnHbATwHfHkqLsmlbg6 Cc: Alfred Perlstein , Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Feb 2013 10:36:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2WTXXJCNJPLDAQHRIJTMU Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/10/13 9:05 AM, Kevin Oberman wrote: >=20 > This is a subject rather near to my heart, having fought battles with > congestion back in the dark days of Windows when it essentially > defaulted to TCPIGNOREIDLE. It was a huge pain, but it was the only > way Windows did TCP in the early days. It simply did not implement > slow-start. This was really evil, but in the days when lots of links > were 56K and T-1 was mostly used for network core links, the Internet, > small as it was back then, did not melt, though it glowed a > frightening shade of red fairly often. Today too many systems running > like this would melt thins very quickly. >=20 Google made many many TCP tweaks. Increased initial window, small RTO, enabled ignore after idle and others. They published that, other people just blindly applied these tunings and the Internet still works. --=20 Andrey Zonov ------enig2WTXXJCNJPLDAQHRIJTMU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRF3gbAAoJEBWLemxX/CvTVKwIAJrSIWopSdXkWE9OJ+2ibr1d 5uKzuhnu3koUvGAxBVF+AiVEHAPcrmC726WHdtT4iPC2Z8vlQP+166A2V5R+itUK enjOE4S5Bh81nGyMYQ2x90PC21yPEC0whYTfmAFFP2hySbQI+7um1KMFgHiiU8aY UpDA573fmuCay8Z2SfeAidasaqECQsAt8QVJNHldKFK10tVyLQBLbb/UrGLw5IPi RtG/4yc9NPmE9wUIbx2MYtWIaxBLyqIYxuufzuurVNR60w4ubRSie/oRvPjEyA6/ IaDZ7cPP0FAGGbS1rxUKbI/icUk6LKV7Gs5KCVGUkn0wFoqnMM0TqQ4mcFXiO8g= =c/rX -----END PGP SIGNATURE----- ------enig2WTXXJCNJPLDAQHRIJTMU-- From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 02:54:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 0EFBEA78 for ; Mon, 11 Feb 2013 02:54:27 +0000 (UTC) (envelope-from rbsimpsont@gmail.com) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx1.freebsd.org (Postfix) with ESMTP id B2B1E175 for ; Mon, 11 Feb 2013 02:54:26 +0000 (UTC) Received: by mail-vc0-f175.google.com with SMTP id fw7so3537267vcb.34 for ; Sun, 10 Feb 2013 18:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=QD1yN2RTVPrp2I0Eag2bZOns/3g0fzZol2UaYNMgC04=; b=RF/XAoklA+kliP9ksmB+IxSUuygHTx4ZaZ1XmnyVTo2O8Yay1EMmuJWuL18KOzFa1l CGDO7Bg3UW9C96pCLDlsAghLdJStJ7qaFXgDJxfzk9RbCMkLaA6TMMDiSMjP9YA3bhF8 i3cYuGvuUFK2xLiKtUlG9uln1e3xULWOKiZ4jWHe79RpJB5ZCwnUoEhh5owGEmT5xHA4 gOHQ+jWM6i4ues/wcA+DB6yIKBY+fa1Og+LLFeaM2AaDGNSgAoX6iaEe5RoTUFDNEKux EUdF3VOBAGRb4ndABCoUBCObQtuTiatnc1mzW8HH6Dl1nEZRgMcq2thP6PduwCGV24hM gNfw== MIME-Version: 1.0 X-Received: by 10.52.77.40 with SMTP id p8mr14341805vdw.98.1360551259808; Sun, 10 Feb 2013 18:54:19 -0800 (PST) Received: by 10.220.126.200 with HTTP; Sun, 10 Feb 2013 18:54:19 -0800 (PST) Date: Sun, 10 Feb 2013 21:54:19 -0500 Message-ID: Subject: Multi-Path Routing - rn_match function - FreeBSD 9.0 From: Robert Simpson To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 02:54:27 -0000 Hey Guys, I am new to FreeBSD and currently browsing the routing code to understand how routing works. I came across RADIX_MPATH which adds support for MPath. But in the rn_match function which searches for a matching route, there is no logic to handle the Multi-path routing. i.e. always the first matched route will be selected even if multiple paths exists to the same destination. Am I missing something here or is this a bug. Rob From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 07:50:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CA375283 for ; Mon, 11 Feb 2013 07:50:53 +0000 (UTC) (envelope-from melifaro@FreeBSD.org) Received: from mail.ipfw.ru (unknown [IPv6:2a01:4f8:120:6141::2]) by mx1.freebsd.org (Postfix) with ESMTP id 91A11B31 for ; Mon, 11 Feb 2013 07:50:53 +0000 (UTC) Received: from v6.mpls.in ([2a02:978:2::5] helo=ws.su29.net) by mail.ipfw.ru with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76 (FreeBSD)) (envelope-from ) id 1U4oDX-000GUQ-CO; Mon, 11 Feb 2013 11:54:23 +0400 Message-ID: <5118A26C.2050300@FreeBSD.org> Date: Mon, 11 Feb 2013 11:49:00 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:9.0) Gecko/20120121 Thunderbird/9.0 MIME-Version: 1.0 To: h bagade Subject: Re: debug em driver code after applying patch References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 07:50:53 -0000 On 05.02.2013 18:44, h bagade wrote: > Hi all, > > I applied patch on em driver code and I want to check how it is working on > different situations. I need to put some output in different parts of the > code to trace what's going on in different situations. > I've tried to write to files or executing commands(like echo) using system > function, but in these two methods, by adding headers some conflicting > issues happen which I don't know how to resolve! > > I've tried to use it's macros like INIT_DEBUGOUT to print some messages but > it only works on startup, not when the system is running! > > I don't know how to print out messages to debug the code?! Is there anybody > to help me handle it? I really need help. You can use printf or log for some rarely-called cases (see printf(9)). for others you can take a look on ktr(9) API and ktrdump(8). > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 08:42:13 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B59F1F2D; Mon, 11 Feb 2013 08:42:13 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 96B2DD82; Mon, 11 Feb 2013 08:42:12 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,641,1355126400"; d="scan'208";a="19240845" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 11 Feb 2013 00:42:05 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1B8g4VL007517; Mon, 11 Feb 2013 00:42:04 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 00:42:03 -0800 From: "Eggert, Lars" To: Andrey Zonov Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option Thread-Topic: [PATCH] Add a new TCP_IGNOREIDLE socket option Thread-Index: AQHN+Nyo0gmhYvjjiEa9ZKUxU2VFfphWVHgAgAARXYCAFuhUAIAAFkGAgABOyICAAb3EAIACyoSAgADxdICAAFxUAIABcmAA Date: Mon, 11 Feb 2013 08:42:02 +0000 Message-ID: References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> In-Reply-To: <51177818.2090900@FreeBSD.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.114] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <061D769083BF8D4F9DC8DAD2886AC334@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Alfred Perlstein , Randall Stewart , Kevin Oberman , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 08:42:13 -0000 On Feb 10, 2013, at 11:36, Andrey Zonov wrote: > Google made many many TCP tweaks. Increased initial window, small RTO, > enabled ignore after idle and others. They published that, other people > just blindly applied these tunings and the Internet still works. MANY people are experimenting with the changes Google is proposing, in orde= r to evaluate if and how well they work. Sure, some folks may "blindly" app= ly them, but please don't generalize. Lars From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 09:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id AFA4A32F for ; Mon, 11 Feb 2013 09:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 8A27516EB for ; Mon, 11 Feb 2013 09:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1B9e0Wg064040 for ; Mon, 11 Feb 2013 09:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1B9e0V3064037; Mon, 11 Feb 2013 09:40:00 GMT (envelope-from gnats) Date: Mon, 11 Feb 2013 09:40:00 GMT Message-Id: <201302110940.r1B9e0V3064037@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Andrey Simonenko Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Andrey Simonenko List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 09:40:01 -0000 The following reply was made to PR bin/131567; it has been noted by GNATS. From: Andrey Simonenko To: bug-followup@freebsd.org Cc: Subject: Re: bin/131567: Update for regression/sockets/unix_cmsg Date: Mon, 11 Feb 2013 11:38:02 +0200 Correctness of unix_cmsg verified on 7.1-STABLE, 9.1-STABLE and 10-CURRENT. ^^^\ \ Corrected typo in previous message. From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 11:06:48 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5A8662C7 for ; Mon, 11 Feb 2013 11:06:48 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 4C9F61BD2 for ; Mon, 11 Feb 2013 11:06:48 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1BB6mWq081342 for ; Mon, 11 Feb 2013 11:06:48 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BB6lYR081340 for freebsd-net@FreeBSD.org; Mon, 11 Feb 2013 11:06:47 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 11 Feb 2013 11:06:47 GMT Message-Id: <201302111106.r1BB6lYR081340@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:06:48 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/175974 net ppp(8): logic issue o kern/175864 net [re] Intel MB D510MO, onboard ethernet not working aft o kern/175852 net [amd64] [patch] in_cksum_hdr() behaves differently on o kern/175734 net no ethernet detected on system with EG20T PCH chipset o kern/175267 net [pf] [tap] pf + tap keep state problem o kern/175236 net [epair] [gif] epair and gif Devices On Bridge o kern/175182 net [panic] kernel panic on RADIX_MPATH when deleting rout o kern/175153 net [tcp] will there miss a FIN when do TSO? o kern/174959 net [net] [patch] rnh_walktree_from visits spurious nodes o kern/174958 net [net] [patch] rnh_walktree_from makes unreasonable ass o kern/174897 net [route] Interface routes are broken o kern/174851 net [bxe] [patch] UDP checksum offload is wrong in bxe dri o kern/174850 net [bxe] [patch] bxe driver does not receive multicasts o kern/174849 net [bxe] [patch] bxe driver can hang kernel when reset o kern/174822 net [tcp] Page fault in tcp_discardcb under high traffic o kern/174602 net [gif] [ipsec] traceroute issue on gif tunnel with ipse o kern/174535 net [tcp] TCP fast retransmit feature works strange o kern/173475 net [tun] tun(4) stays opened by PID after process is term o kern/173201 net [ixgbe] [patch] Missing / broken ixgbe sysctl's and tu o kern/173137 net [em] em(4) unable to run at gigabit with 9.1-RC2 o kern/173002 net [patch] data type size problem in if_spppsubr.c o kern/172985 net [patch] [ip6] lltable leak when adding and removing IP o kern/172895 net [ixgb] [ixgbe] do not properly determine link-state o kern/172683 net [ip6] Duplicate IPv6 Link Local Addresses o kern/172675 net [netinet] [patch] sysctl_tcp_hc_list (net.inet.tcp.hos o kern/172113 net [panic] [e1000] [patch] 9.1-RC1/amd64 panices in igb(4 o kern/171840 net [ip6] IPv6 packets transmitting only on queue 0 o kern/171838 net [oce] [patch] Possible lock reversal and duplicate loc o kern/171739 net [bce] [panic] bce related kernel panic o kern/171711 net [dummynet] [panic] Kernel panic in dummynet o kern/171532 net [ndis] ndis(4) driver includes 'pccard'-specific code, o kern/171531 net [ndis] undocumented dependency for ndis(4) o kern/171524 net [ipmi] ipmi driver crashes kernel by reboot or shutdow s kern/171508 net [epair] [request] Add the ability to name epair device o kern/171228 net [re] [patch] if_re - eeprom write issues o kern/170701 net [ppp] killl ppp or reboot with active ppp connection c o kern/170267 net [ixgbe] IXGBE_LE32_TO_CPUS is probably an unintentiona o kern/170081 net [fxp] pf/nat/jails not working if checksum offloading o kern/169898 net ifconfig(8) fails to set MTU on multiple interfaces. o kern/169676 net [bge] [hang] system hangs, fully or partially after re o kern/169664 net [bgp] Wrongful replacement of interface connected net o kern/169620 net [ng] [pf] ng_l2tp incoming packet bypass pf firewall o kern/169459 net [ppp] umodem/ppp/3g stopped working after update from o kern/169438 net [ipsec] ipv4-in-ipv6 tunnel mode IPsec does not work p kern/168294 net [ixgbe] [patch] ixgbe driver compiled in kernel has no o kern/168246 net [em] Multiple em(4) not working with qemu o kern/168245 net [arp] [regression] Permanent ARP entry not deleted on o kern/168244 net [arp] [regression] Unable to manually remove permanent o kern/168183 net [bce] bce driver hang system o kern/167947 net [setfib] [patch] arpresolve checks only the default FI o kern/167603 net [ip] IP fragment reassembly's broken: file transfer ov o kern/167500 net [em] [panic] Kernel panics in em driver o kern/167325 net [netinet] [patch] sosend sometimes return EINVAL with o kern/167202 net [igmp]: Sending multiple IGMP packets crashes kernel o kern/167059 net [tcp] [panic] System does panic in in_pcbbind() and ha o kern/166940 net [ipfilter] [panic] Double fault in kern 8.2 o kern/166462 net [gre] gre(4) when using a tunnel source address from c o kern/166372 net [patch] ipfilter drops UDP packets with zero checksum o kern/166285 net [arp] FreeBSD v8.1 REL p8 arp: unknown hardware addres o kern/166255 net [net] [patch] It should be possible to disable "promis o kern/165963 net [panic] [ipf] ipfilter/nat NULL pointer deference o kern/165903 net mbuf leak o kern/165643 net [net] [patch] Missing vnet restores in net/if_ethersub o kern/165622 net [ndis][panic][patch] Unregistered use of FPU in kernel s kern/165562 net [request] add support for Intel i350 in FreeBSD 7.4 o kern/165526 net [bxe] UDP packets checksum calculation whithin if_bxe o kern/165488 net [ppp] [panic] Fatal trap 12 jails and ppp , kernel wit o kern/165305 net [ip6] [request] Feature parity between IP_TOS and IPV6 o kern/165296 net [vlan] [patch] Fix EVL_APPLY_VLID, update EVL_APPLY_PR o kern/165181 net [igb] igb freezes after about 2 weeks of uptime o kern/165174 net [patch] [tap] allow tap(4) to keep its address on clos o kern/165152 net [ip6] Does not work through the issue of ipv6 addresse o kern/164495 net [igb] connect double head igb to switch cause system t o kern/164490 net [pfil] Incorrect IP checksum on pfil pass from ip_outp o kern/164475 net [gre] gre misses RUNNING flag after a reboot o kern/164265 net [netinet] [patch] tcp_lro_rx computes wrong checksum i o kern/163903 net [igb] "igb0:tx(0)","bpf interface lock" v2.2.5 9-STABL o kern/163481 net freebsd do not add itself to ping route packet o kern/162927 net [tun] Modem-PPP error ppp[1538]: tun0: Phase: Clearing o kern/162926 net [ipfilter] Infinite loop in ipfilter with fragmented I o kern/162558 net [dummynet] [panic] seldom dummynet panics o kern/162153 net [em] intel em driver 7.2.4 don't compile o kern/162110 net [igb] [panic] RELENG_9 panics on boot in IGB driver - o kern/162028 net [ixgbe] [patch] misplaced #endif in ixgbe.c o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155420 net [vlan] adding vlan break existent vlan o kern/155177 net [route] [panic] Panic when inject routes in kernel p kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed f kern/142518 net [em] [lagg] Problem on 8.0-STABLE with em and lagg o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph f kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o kern/136618 net [pf][stf] panic on cloning interface without unit numb o kern/135502 net [periodic] Warning message raised by rtfree function i o kern/134583 net [hang] Machine with jail freezes after random amount o o kern/134531 net [route] [panic] kernel crash related to routes/zebra o kern/134157 net [dummynet] dummynet loads cpu for 100% and make a syst o kern/133969 net [dummynet] [panic] Fatal trap 12: page fault while in o kern/133968 net [dummynet] [panic] dummynet kernel panic o kern/133736 net [udp] ip_id not protected ... o kern/133595 net [panic] Kernel Panic at pcpu.h:195 o kern/133572 net [ppp] [hang] incoming PPTP connection hangs the system o kern/133490 net [bpf] [panic] 'kmem_map too small' panic on Dell r900 o kern/133235 net [netinet] [patch] Process SIOCDLIFADDR command incorre f kern/133213 net arp and sshd errors on 7.1-PRERELEASE o kern/133060 net [ipsec] [pfsync] [panic] Kernel panic with ipsec + pfs o kern/132889 net [ndis] [panic] NDIS kernel crash on load BCM4321 AGN d o conf/132851 net [patch] rc.conf(5): allow to setfib(1) for service run o kern/132734 net [ifmib] [panic] panic in net/if_mib.c o kern/132705 net [libwrap] [patch] libwrap - infinite loop if hosts.all o kern/132672 net [ndis] [panic] ndis with rt2860.sys causes kernel pani o kern/132554 net [ipl] There is no ippool start script/ipfilter magic t o kern/132354 net [nat] Getting some packages to ipnat(8) causes crash o kern/132277 net [crypto] [ipsec] poor performance using cryptodevice f o kern/131781 net [ndis] ndis keeps dropping the link o kern/131776 net [wi] driver fails to init o kern/131753 net [altq] [panic] kernel panic in hfsc_dequeue o kern/131601 net [ipfilter] [panic] 7-STABLE panic in nat_finalise (tcp o bin/131567 net [socket] [patch] Update for regression/sockets/unix_cm o bin/131365 net route(8): route add changes interpretation of network f kern/130820 net [ndis] wpa_supplicant(8) returns 'no space on device' o kern/130628 net [nfs] NFS / rpc.lockd deadlock on 7.1-R o conf/130555 net [rc.d] [patch] No good way to set ipfilter variables a o kern/130525 net [ndis] [panic] 64 bit ar5008 ndisgen-erated driver cau o kern/130311 net [wlan_xauth] [panic] hostapd restart causing kernel pa o kern/130109 net [ipfw] Can not set fib for packets originated from loc f kern/130059 net [panic] Leaking 50k mbufs/hour f kern/129719 net [nfs] [panic] Panic during shutdown, tcp_ctloutput: in o kern/129517 net [ipsec] [panic] double fault / stack overflow f kern/129508 net [carp] [panic] Kernel panic with EtherIP (may be relat o kern/129219 net [ppp] Kernel panic when using kernel mode ppp o kern/129197 net [panic] 7.0 IP stack related panic o bin/128954 net ifconfig(8) deletes valid routes o bin/128602 net [an] wpa_supplicant(8) crashes with an(4) o kern/128448 net [nfs] 6.4-RC1 Boot Fails if NFS Hostname cannot be res o bin/128295 net [patch] ifconfig(8) does not print TOE4 or TOE6 capabi o bin/128001 net wpa_supplicant(8), wlan(4), and wi(4) issues o kern/127826 net [iwi] iwi0 driver has reduced performance and connecti o kern/127815 net [gif] [patch] if_gif does not set vlan attributes from o kern/127724 net [rtalloc] rtfree: 0xc5a8f870 has 1 refs f bin/127719 net [arp] arp: Segmentation fault (core dumped) f kern/127528 net [icmp]: icmp socket receives icmp replies not owned by p kern/127360 net [socket] TOE socket options missing from sosetopt() o bin/127192 net routed(8) removes the secondary alias IP of interface f kern/127145 net [wi]: prism (wi) driver crash at bigger traffic o kern/126895 net [patch] [ral] Add antenna selection (marked as TBD) o kern/126874 net [vlan]: Zebra problem if ifconfig vlanX destroy o kern/126695 net rtfree messages and network disruption upon use of if_ o kern/126339 net [ipw] ipw driver drops the connection o kern/126075 net [inet] [patch] internet control accesses beyond end of o bin/125922 net [patch] Deadlock in arp(8) o kern/125920 net [arp] Kernel Routing Table loses Ethernet Link status o kern/125845 net [netinet] [patch] tcp_lro_rx() should make use of hard o kern/125258 net [socket] socket's SO_REUSEADDR option does not work o kern/125239 net [gre] kernel crash when using gre o kern/124341 net [ral] promiscuous mode for wireless device ral0 looses o kern/124225 net [ndis] [patch] ndis network driver sometimes loses net o kern/124160 net [libc] connect(2) function loops indefinitely o kern/124021 net [ip6] [panic] page fault in nd6_output() o kern/123968 net [rum] [panic] rum driver causes kernel panic with WPA. o kern/123892 net [tap] [patch] No buffer space available o kern/123890 net [ppp] [panic] crash & reboot on work with PPP low-spee o kern/123858 net [stf] [patch] stf not usable behind a NAT o kern/123796 net [ipf] FreeBSD 6.1+VPN+ipnat+ipf: port mapping does not o kern/123758 net [panic] panic while restarting net/freenet6 o bin/123633 net ifconfig(8) doesn't set inet and ether address in one o kern/123559 net [iwi] iwi periodically disassociates/associates [regre o bin/123465 net [ip6] route(8): route add -inet6 -interfac o kern/123463 net [ipsec] [panic] repeatable crash related to ipsec-tool o conf/123330 net [nsswitch.conf] Enabling samba wins in nsswitch.conf c o kern/123160 net [ip] Panic and reboot at sysctl kern.polling.enable=0 o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122252 net [ipmi] [bge] IPMI problem with BCM5704 (does not work o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr o kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 443 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 11:10:48 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 079F2B1E for ; Mon, 11 Feb 2013 11:10:48 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 70BB61D7E for ; Mon, 11 Feb 2013 11:10:47 +0000 (UTC) Received: (qmail 26831 invoked from network); 11 Feb 2013 12:28:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Feb 2013 12:28:37 -0000 Message-ID: <5118D1B5.9070409@freebsd.org> Date: Mon, 11 Feb 2013 12:10:45 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Alfred Perlstein Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: <51166019.9040104@mu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:10:48 -0000 On 09.02.2013 15:41, Alfred Perlstein wrote: > However, the end result must be far different than what has occurred so far. > > If the code was deemed unacceptable for general inclusion, then we must find a way to provide a > light framework to accomplish the needs of the community member. We've got pluggable congestion control modules thanks to lstewart. You can implement any non-standard congestion control method by adding your own module. They can be compiled into the kernel or loaded as KLD. I consider implementing this as a CC module the correct approach instead of adding yet another sysctl. Doing a CC module like this is very easy. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 11:13:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id A7910F65 for ; Mon, 11 Feb 2013 11:13:26 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 1E2C21DDA for ; Mon, 11 Feb 2013 11:13:25 +0000 (UTC) Received: (qmail 26629 invoked from network); 11 Feb 2013 12:24:35 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Feb 2013 12:24:35 -0000 Message-ID: <5118D0C4.4050301@freebsd.org> Date: Mon, 11 Feb 2013 12:06:44 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <201302051211.43345.jhb@freebsd.org> <511144FB.50807@freebsd.org> <201302051640.21412.jhb@freebsd.org> In-Reply-To: <201302051640.21412.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Sepherosa Ziehau , freebsd-net@freebsd.org, Bjoern Zeeb X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:13:26 -0000 On 05.02.2013 22:40, John Baldwin wrote: > On Tuesday, February 05, 2013 12:44:27 pm Andre Oppermann wrote: >> I would prefer to encapsulate it into its own not-so-much-congestion-management >> algorithm so you can eventually do other tweaks as well like more aggressive >> loss recovery which would fit your objective as well. Since you have to modify >> your app anyways to do the sockopt call this seems a more complete solution to >> me. At least better than to do a non-portable hack that violates one of the >> most fundamental TCP concepts. > > This is real rich from the guy pushing the increased IW that came from Linux. :) IW10 came from Google and obviously was implemented in Linux first because that is what they use. However, and this is the big difference, they also provided significant real-world data on the effects of their changes. TCPM was very skeptical at first but the data from the experiments has convinced many that it is not harmful first and actually beneficial second. > "Tools not policy" yadda yadda, but I digress. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 11:18:15 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 48AB0EB for ; Mon, 11 Feb 2013 11:18:15 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 993B31E1B for ; Mon, 11 Feb 2013 11:18:14 +0000 (UTC) Received: (qmail 27029 invoked from network); 11 Feb 2013 12:36:05 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 11 Feb 2013 12:36:05 -0000 Message-ID: <5118D375.5000501@freebsd.org> Date: Mon, 11 Feb 2013 12:18:13 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrey Zonov Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> In-Reply-To: <51177818.2090900@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org, Alfred Perlstein , Randall Stewart , Kevin Oberman , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 11:18:15 -0000 On 10.02.2013 11:36, Andrey Zonov wrote: > On 2/10/13 9:05 AM, Kevin Oberman wrote: >> >> This is a subject rather near to my heart, having fought battles with >> congestion back in the dark days of Windows when it essentially >> defaulted to TCPIGNOREIDLE. It was a huge pain, but it was the only >> way Windows did TCP in the early days. It simply did not implement >> slow-start. This was really evil, but in the days when lots of links >> were 56K and T-1 was mostly used for network core links, the Internet, >> small as it was back then, did not melt, though it glowed a >> frightening shade of red fairly often. Today too many systems running >> like this would melt thins very quickly. >> > > Google made many many TCP tweaks. Increased initial window, small RTO, > enabled ignore after idle and others. They published that, other people > just blindly applied these tunings and the Internet still works. In general Google does provide quite a bit of data with their experiments showing that it isn't harmful and that it helps the case. Smaller RTO (1s) has become a RFC so there was very broad consensus in TCPM that is a good thing. We don't have it yet because we were not fully compliant in one case (loss of first segment). I've fixed that a while back and will bring 1s RTO soon to HEAD. I'm pretty sure that Google doesn't ignore idle on their Internet facing servers. They may have proposed a decay mechanism in the past. I'd have to check the TCPM archives for that. -- Andre From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 12:28:11 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3C3D912A; Mon, 11 Feb 2013 12:28:11 +0000 (UTC) (envelope-from pluknet@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 147F8392; Mon, 11 Feb 2013 12:28:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1BCSAiR099239; Mon, 11 Feb 2013 12:28:10 GMT (envelope-from pluknet@freefall.freebsd.org) Received: (from pluknet@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BCSAwF099235; Mon, 11 Feb 2013 12:28:10 GMT (envelope-from pluknet) Date: Mon, 11 Feb 2013 12:28:10 GMT Message-Id: <201302111228.r1BCSAwF099235@freefall.freebsd.org> To: pluknet@FreeBSD.org, freebsd-net@FreeBSD.org, pluknet@FreeBSD.org From: pluknet@FreeBSD.org Subject: Re: bin/131567: [socket] [patch] Update for regression/sockets/unix_cmsg X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 12:28:11 -0000 Synopsis: [socket] [patch] Update for regression/sockets/unix_cmsg Responsible-Changed-From-To: freebsd-net->pluknet Responsible-Changed-By: pluknet Responsible-Changed-When: Mon Feb 11 12:27:51 UTC 2013 Responsible-Changed-Why: Take. http://www.freebsd.org/cgi/query-pr.cgi?pr=131567 From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 14:11:24 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 09CB0C84; Mon, 11 Feb 2013 14:11:24 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id BE83B26B; Mon, 11 Feb 2013 14:11:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1BEBN9N019784; Mon, 11 Feb 2013 14:11:23 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1BEBNgP019780; Mon, 11 Feb 2013 14:11:23 GMT (envelope-from linimon) Date: Mon, 11 Feb 2013 14:11:23 GMT Message-Id: <201302111411.r1BEBNgP019780@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176027: [em] [patch] flow control systcl consistency for em drivers X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 14:11:24 -0000 Old Synopsis: flow control systcl consistency for em drivers New Synopsis: [em] [patch] flow control systcl consistency for em drivers Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Mon Feb 11 14:11:01 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176027 From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 15:44:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 6FE144FC for ; Mon, 11 Feb 2013 15:44:03 +0000 (UTC) (envelope-from tevans.uk@googlemail.com) Received: from mail-ve0-f176.google.com (mail-ve0-f176.google.com [209.85.128.176]) by mx1.freebsd.org (Postfix) with ESMTP id 374889F4 for ; Mon, 11 Feb 2013 15:44:02 +0000 (UTC) Received: by mail-ve0-f176.google.com with SMTP id cz10so5173862veb.21 for ; Mon, 11 Feb 2013 07:44:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=biENlMF1lhGJS0ag8SzxOnCRa51IMC2VhSryw1z/ZrQ=; b=lEkYWKikwYJH2CBpA/r5YLYiK0dxPBXVn8frShLn6rP6wa8ipdRGZn2qurkbUfUOfp S3+dp2Gm1dJ55Glxelwexuzi2bDkWXsAkvSmC1/z4MsLys7xDQDXy2Czpc6Dr34/qjKw mEp0YHU+Inz7oX0pVRwMVDEmvoQpUSsKNPrLmXmBs8gdMflk6Dbel/OYOQWjK0Fe46yz 2Usd/9FbINWJatWo5gBq42trqPpMdm00wyifcgcKStKu+Aa+Em8uvxkd0S1s1pFY8jqv 6OjkuJVZCI30lPENb8AN91csWMBs1yjBXkrHhBzt4WIEJNl47O/okR6PW/arYjc2WgI8 VfsQ== MIME-Version: 1.0 X-Received: by 10.220.228.74 with SMTP id jd10mr19208721vcb.65.1360597442551; Mon, 11 Feb 2013 07:44:02 -0800 (PST) Received: by 10.58.100.147 with HTTP; Mon, 11 Feb 2013 07:44:02 -0800 (PST) In-Reply-To: <8112.1360454540@tristatelogic.com> References: <20130209221107.GA32563@server.rulingia.com> <8112.1360454540@tristatelogic.com> Date: Mon, 11 Feb 2013 15:44:02 +0000 Message-ID: Subject: Re: Question: Why ain't I getting gigabit speed? From: Tom Evans To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 15:44:03 -0000 On Sun, Feb 10, 2013 at 12:02 AM, Ronald F. Guilmette wrote: > > > I want to thank all of the various people who offered help, advice, > and suggestings regarding this problem. It's all really appreciated. > > Since I first posted about this issue, I have diligently tried to > isolate/debug the problem. I swapped the card into a totally > different system, also running FreeBSD, and found the exact same > symptoms. I used other equipment to verify that both my cables > and my Linksys E2000 were not the source of the problem. Lastly, > I brought up the card in the exact same system where I had originally > noted the problem, but under Windows rather than FreeBSD. > > Anyway, after all this testing, I believe that I can now say > definitively that the problem is indeed bad hardware in/on the card. > The card exibits essentially the same symptoms under Windows as it > does under FreeBSD, i.e. running only at 100mbs, rather than the > 1gbs that it should be capable of. > Generally, if your cheap gigabit NIC doesn't connect at gigabit speeds with your cheap gigabit switch, it is negotiation issues. I have identical cheap Intel gigabit NICs (I forget the exact chipset, PCI-e 1x, ~$30 USD) that do not negotiate gigabit on my cheap Linksys switch from Windows, yet happily do so from Linux and FreeBSD, and will always negotiate gigabit from any OS with my HP Procurve. Cheers Tom From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 18:56:05 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C803DE9A; Mon, 11 Feb 2013 18:56:05 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (we-in-x022a.1e100.net [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id E0D1A756; Mon, 11 Feb 2013 18:56:04 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so5064932wey.15 for ; Mon, 11 Feb 2013 10:56:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=yXPpR/wMSfetdIjc8PDfcE0gg4X9OntilrQb8cikqJ4=; b=vhbPBsNDWOcVFyKI58fxUhsVv+zp20TeaYgnNQ2nshOi41rMVVif3EqZGB+KJ8qBZY X9pRMKYCidntqREKXLUS59BD6nqTBOPuuucua2yvtCOh1tu2nuKF62uv96PzbgXsKX1f wBW160PHGt1MjtEo4c+uXpwEOkGew6yr02nFw65N9eIe02RRttfmTOJEjTqO5VIrX3QT QzjPfSSeUhKsYlyYS1WRjCWvjlfHx0REOOGoxGbUQw27axJjcEu1beeozq9np5uDHttL ks7Cavq9Fz45RR1kjiEdSwVd+lnbBjj1bxOlt13k1y7cz4T/ttqnmtnpHr78650sZbwp rIMw== MIME-Version: 1.0 X-Received: by 10.194.161.135 with SMTP id xs7mr26045457wjb.41.1360608963933; Mon, 11 Feb 2013 10:56:03 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Mon, 11 Feb 2013 10:56:03 -0800 (PST) In-Reply-To: <5118D375.5000501@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> <5118D375.5000501@freebsd.org> Date: Mon, 11 Feb 2013 10:56:03 -0800 X-Google-Sender-Auth: UUPIg4uy-GRBnSJlg5xrKj25h3g Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: John Baldwin , Alfred Perlstein , Randall Stewart , Kevin Oberman , net@freebsd.org, Andrey Zonov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 18:56:05 -0000 On 11 February 2013 03:18, Andre Oppermann wrote: > In general Google does provide quite a bit of data with their experiments > showing that it isn't harmful and that it helps the case. > > Smaller RTO (1s) has become a RFC so there was very broad consensus in > TCPM that is a good thing. We don't have it yet because we were not fully > compliant in one case (loss of first segment). I've fixed that a while > back and will bring 1s RTO soon to HEAD. > > I'm pretty sure that Google doesn't ignore idle on their Internet facing > servers. They may have proposed a decay mechanism in the past. I'd have > to check the TCPM archives for that. Argh, the "If google does, it it must be fine" argument. Does Google publish the data for these experiments with the international and local links broken down? Google run a highly distributed infrastructure (this isn't news for anyone, I know) and thus the link distance, RTT, number of hops, etc may not accurately reflect "the internet". It may accurately reflect "the internet from the perspective of being roughly within the same city or state" in a lot of cases. The TCP congestion algorithms aren't just for avoiding congestion over a peering fabric and last-mile ISP infrastructure. The effects of tweaking congestion algorithms for delivery over a local peering infrastructure where you try to run things as un-congested as possible (where congestion is now The ISPs Problem) where you maintain tight control over as much of the network infrastructure as you can is likely going to be very different to the congestion algorithm behaviour needed for some end-node speaking to a variety of end-nodes over a longer, more varying set of international links. You know, what TCP congestion algorithms are also trying to "play fair" with. Please - as much as I applaud Google for what they do, please don't generalise their results to "the greater internet" without looking at the many caveats/assumptions. Adrian From owner-freebsd-net@FreeBSD.ORG Mon Feb 11 21:06:24 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9A1AC480 for ; Mon, 11 Feb 2013 21:06:24 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x231.google.com (we-in-x0231.1e100.net [IPv6:2a00:1450:400c:c03::231]) by mx1.freebsd.org (Postfix) with ESMTP id 3671EE14 for ; Mon, 11 Feb 2013 21:06:24 +0000 (UTC) Received: by mail-we0-f177.google.com with SMTP id d7so5242057wer.22 for ; Mon, 11 Feb 2013 13:06:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:date:x-google-sender-auth:message-id :subject:from:to:content-type; bh=0n8Y+HVOxMo7dbdji2DXBGeZY48LzzPqeoK2n8Fg2P0=; b=yyCFszHi5vTXNQPEaY2OPuD5pSAOdOT8G6H8LfONQYSwKwzX6eCDS2Roous+jT6Gjj V+LAXZixdlALd99tcB/6Ha7vC3fUjqGdOz1OIPPpgDkJFrbyraOLbIxvBbam0mF3PIrT jwqPOVn+StngRkaIFjI21Oi4JeHQr/2gT05a9Mo5wC9yXWZlLDv6Ei/L1y7E47oXjsiy MxK9Z0OvrfOHg00AOTJjfRYQNzx8cW1ICfuK5oMjKcPaHxTirp1jXTgKlyBcolVop5Os HSXz31SaXfnYx+TPDXq3FXlx92HmL+Xe8+2EFMzuK0DJgd2cT9cSqaksZTKv50vMsrCf O7uQ== MIME-Version: 1.0 X-Received: by 10.181.12.103 with SMTP id ep7mr18509931wid.12.1360616783200; Mon, 11 Feb 2013 13:06:23 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Mon, 11 Feb 2013 13:06:23 -0800 (PST) Date: Mon, 11 Feb 2013 13:06:23 -0800 X-Google-Sender-Auth: 3_Uthi0A9k_MQb6Co06bhZS6NjM Message-ID: Subject: Who should be incrementing the ifp error counters? From: Adrian Chadd To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 21:06:24 -0000 Hi all, During my efforts to convert ath(4) and net80211(4) to if_transmit based queues, I've noticed that the error counters aren't being incremented correctly. In the ifq past, the _ENQUEUE macro(s) did this, with a call to IFQ_DROP() if the frame is being dropped. This was done behind the ifq lock so the counters were correctly updated. In the if_transmit() world, this isn't as clear. I know that ath(4) and net82011(4) just aren't updating the if drop counter, so it's not obvious when things are being dropped. so - what's the story with this? Where should the counters be updated? And what kinds of concurrency handling do people think is "right" here for updating said counters? Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 02:44:45 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 70079182; Tue, 12 Feb 2013 02:44:45 +0000 (UTC) (envelope-from seanwbruno@gmail.com) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by mx1.freebsd.org (Postfix) with ESMTP id 357EBD87; Tue, 12 Feb 2013 02:44:44 +0000 (UTC) Received: by mail-da0-f42.google.com with SMTP id z17so3019613dal.1 for ; Mon, 11 Feb 2013 18:44:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:from:reply-to:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=MqHqLNiuLKLdr4cU4Zu1Wwj/PT60ettYviID0Iz/2fY=; b=rFUXWbLhPZ7Iwakvcop/NKL5j+1jgOUhfXWn0EPRU+/x4zrBTvhNLhmblksJhC1FQH qcufWcg17plItZv3kx3isGMXju6PVDsVPP5aNhknUJmFd6cFBYdmV+c/0UVEq+U6kJVP RxwZj0Qtii3gOryT11YJaS1KBykJkCE8FIsOzUJoYhs9T95phrL7PRdXhYTeRXziBbWm lp+GKU8MNRq9fYV9Bzf+20uU01WX2TVNsXpMInKKLsRXnmVnIt8QJrzlJMU2XJEcLk4/ JjvY/f81x584neo0zNtP4DvhfrPu+OTss1dnGWRPdjQ54GqjSsD9aY5DStWCtLW9r3ru lQQg== X-Received: by 10.66.52.1 with SMTP id p1mr33477976pao.22.1360637084524; Mon, 11 Feb 2013 18:44:44 -0800 (PST) Received: from [192.168.1.210] (c-71-202-40-63.hsd1.ca.comcast.net. [71.202.40.63]) by mx.google.com with ESMTPS id bi2sm71011779pab.18.2013.02.11.18.44.42 (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 18:44:43 -0800 (PST) Subject: Re: Intel 82574 issue reported on Slashdot From: Sean Bruno To: Jack Vogel In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 11 Feb 2013 18:44:41 -0800 Message-ID: <1360637081.6605.4.camel@powernoodle> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: FreeBSD stable , "Pieper, Jeffrey E" , FreeBSD Net , "Hearn, James R" , "Vogel, Jack" , "Ronciak, John" , FreeBSD Current X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: sbruno@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 02:44:45 -0000 On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote: > For those that may have run across the story on Slashdot about this NIC, > here is our statement: > > Recently there were a few stories published, based on a blog post by an > end-user, suggesting specific network packets may cause the Intel® 82574L > Gigabit Ethernet Controller to become unresponsive until corrected by a > full platform power cycle. > > Intel was made aware of this issue in September 2012 by the blogs author. > Intel worked with the author as well as the original motherboard > manufacturer to investigate and determine root cause. Intel root caused the > issue to the specific vendor’s mother board design where an incorrect > EEPROM image was programmed during manufacturing. We communicated the > findings and recommended corrections to the motherboard manufacturer. > > It is Intel’s belief that this is an implementation issue isolated to a > specific manufacturer, not a design problem with the Intel 82574L Gigabit > Ethernet controller. Intel has not observed this issue with any > implementations which follow Intel’s published design guidelines. Intel > recommends contacting your motherboard manufacturer if you have continued > concerns or questions whether your products are impacted. > Here is the link: > > http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement > > Any questions or concerns may be sent to me. > > Cheers, > > Jack Thanks for the info. I'm sure there were some *interesting* debugging sessions during this. Sean From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 03:37:04 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 630DDB09; Tue, 12 Feb 2013 03:37:04 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 398B4F94; Tue, 12 Feb 2013 03:37:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1C3b4vt075519; Tue, 12 Feb 2013 03:37:04 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1C3b4j4075515; Tue, 12 Feb 2013 03:37:04 GMT (envelope-from linimon) Date: Tue, 12 Feb 2013 03:37:04 GMT Message-Id: <201302120337.r1C3b4j4075515@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176026: [tcp] [patch] TCP wrappers caused quite a lot of warnings during "make buildworld" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 03:37:04 -0000 Old Synopsis: TCP wrappers caused quite a lot of warnings during "make buildworld" New Synopsis: [tcp] [patch] TCP wrappers caused quite a lot of warnings during "make buildworld" Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Tue Feb 12 03:36:49 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176026 From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 05:44:22 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 36B82A74; Tue, 12 Feb 2013 05:44:22 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 2251B362; Tue, 12 Feb 2013 05:44:21 +0000 (UTC) Received: from Alfreds-MacBook-Pro-9.local (c-67-180-208-218.hsd1.ca.comcast.net [67.180.208.218]) by elvis.mu.org (Postfix) with ESMTPSA id C6A8C1A3C1A; Mon, 11 Feb 2013 21:44:12 -0800 (PST) Message-ID: <5119D6AB.1060603@mu.org> Date: Mon, 11 Feb 2013 21:44:11 -0800 From: Alfred Perlstein User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <5118D1B5.9070409@freebsd.org> In-Reply-To: <5118D1B5.9070409@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 05:44:22 -0000 On 2/11/13 3:10 AM, Andre Oppermann wrote: > On 09.02.2013 15:41, Alfred Perlstein wrote: >> However, the end result must be far different than what has occurred >> so far. >> >> If the code was deemed unacceptable for general inclusion, then we >> must find a way to provide a >> light framework to accomplish the needs of the community member. > > We've got pluggable congestion control modules thanks to lstewart. > > You can implement any non-standard congestion control method by adding > your own module. They can be compiled into the kernel or loaded as KLD. > > I consider implementing this as a CC module the correct approach instead > of adding yet another sysctl. Doing a CC module like this is very easy. > That sounds like a win. -Alfred From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 06:43:51 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 41AAC69F for ; Tue, 12 Feb 2013 06:43:51 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by mx1.freebsd.org (Postfix) with ESMTP id C6B56786 for ; Tue, 12 Feb 2013 06:43:50 +0000 (UTC) Received: by mail-wi0-f182.google.com with SMTP id hi18so3971714wib.15 for ; Mon, 11 Feb 2013 22:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=dp7okq6zR20N9a6Uakpwzhskak7R1czAGBEuU5cHqdM=; b=iJshag0FIXIOAE1P4/ZS2bAjtF0nhrocnwnwu0L7rz5okVe/JfZjIEsEX2d8rNndh/ yH0j5LxI3VFl1bDV2WnJ9kDDEJwQIs3+u9EwLt9eENd7fIjj3cP+aYZ30+jP/oRXnJBk bqkImpYFWBl8T6H3v1t9udtP4SDH0K/KlFtbGRkoxx5LuTfqboZCasdsuYebCyxgpJ4N CQ8qTRSIZbLKLxy1HUUkQsBam0O0tK9lMf7ji4+fz3vawNXUiDxrmpV2VSyicJnlKfeM NULeSB8+KpxrwNJ59rk3zszwOv6BvhVVZwUmwTEmghlWBhPkaaDok/luF6q1e8pjrhud UKOQ== X-Received: by 10.180.92.129 with SMTP id cm1mr919643wib.10.1360651429660; Mon, 11 Feb 2013 22:43:49 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.23.199 with HTTP; Mon, 11 Feb 2013 22:43:29 -0800 (PST) From: h bagade Date: Tue, 12 Feb 2013 10:13:29 +0330 X-Google-Sender-Auth: 2sg361Pm0xGJ_Si20d53K2AUwlM Message-ID: Subject: how to find out if an IP address is assigned statically or dynamically? To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:43:51 -0000 Hi all, I want to know if there is a way to find out if an interface address is assigned by dhcp or statically? For example, any distinctive flag or something like that on ifconfig output! or any other way except processing dhclient leases files? From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 06:47:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 21534754 for ; Tue, 12 Feb 2013 06:47:53 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by mx1.freebsd.org (Postfix) with ESMTP id 9C44B7A9 for ; Tue, 12 Feb 2013 06:47:52 +0000 (UTC) Received: by mail-we0-f173.google.com with SMTP id r5so5443138wey.32 for ; Mon, 11 Feb 2013 22:47:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=kYs1iE9UZtN1hzyZc4gX3AoS81ujwbFmxhCBu7jACoI=; b=q/TdoRURDGDd9/fKXoTg65hJe54Hs7C6BhKV60rezqeUPzQJmGLO3QsuDavpB7b9iQ 0IJ/Iq9UBoNmb+GxK2hPx16IQTCHvNX+Z6jMzppyemvokNZCn/2YcvPvRE2qROjqi6Lh 9lbT3zvv6jt0KDrh4vEuEEupgy+HacFzXVDS1wH4uxrHdT4aTqpzQmR+K4nQa4jNMseR sOxOkgiCcU9ferxAYOu1FQ0sBVPDi/0yI1cMx5PeCVv13taYOZzArBHmTsoCbSvomjcw fHg4yPzUlAxcyrVZpRAA+KLeh1R58tEKvgleJeyDiN8NmV7+l8+7o7mk1Fa8k9QJMdty QFsQ== X-Received: by 10.180.87.170 with SMTP id az10mr969177wib.3.1360651671721; Mon, 11 Feb 2013 22:47:51 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.194.23.199 with HTTP; Mon, 11 Feb 2013 22:47:31 -0800 (PST) In-Reply-To: <6D4FA861-037E-48EA-BE87-70808FB28D82@tamu.edu> References: <20130124195056.GB1410@funkthat.com> <6D4FA861-037E-48EA-BE87-70808FB28D82@tamu.edu> From: h bagade Date: Tue, 12 Feb 2013 10:17:31 +0330 X-Google-Sender-Auth: kreJF5AQzKRJOToNxAsV6degCGQ Message-ID: Subject: Re: how to completely makes an interface down? To: Dave Duchscher Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 06:47:53 -0000 On Sat, Jan 26, 2013 at 6:22 PM, Dave Duchscher wrote: > On Jan 26, 2013, at 7:05 AM, h bagade wrote: > > > I've found a patch which is going to do what I really want: > > http://lists.freebsd.org/pipermail/freebsd-net/2010-December/027196.html > > > > but when I apply it on my freebsd 8.2 with em cards, nothing happens! not > > even sysctl "dev.em.X.down_disables_link", which is supposed to be added > > after applying patch, exists! what wrong with what I've done? > > Not sure. I would make sure that your new kernel is the kernel that is > being used. We use a different kernel configuration file so that a > simple uname command tells us that the right kernel is installed. > > We use that patch here with 8.3 and it works as advertised. I do wish > there was a way to drop the link of the port without kernel mods. > Understandably with the out of band management protocols, the internal > interfaces really like to keep link alive so you can connect to the > system's management console, do wake on lan, etc. > > -- > DaveD > > I gradually apply the patch and it works:) Thanks all. From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 07:30:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 380DAFA0 for ; Tue, 12 Feb 2013 07:30:37 +0000 (UTC) (envelope-from hiren.panchasara@gmail.com) Received: from mail-ee0-f49.google.com (mail-ee0-f49.google.com [74.125.83.49]) by mx1.freebsd.org (Postfix) with ESMTP id A34BE9AF for ; Tue, 12 Feb 2013 07:30:36 +0000 (UTC) Received: by mail-ee0-f49.google.com with SMTP id d4so3539897eek.36 for ; Mon, 11 Feb 2013 23:30:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=tASsUxW4VRY6DfjyCtK+HjBwRnHcc92fbpnARZ+6MT4=; b=WKugf3beMRVFyhQQPXBinmdpGZricKXdb8VXqapALE6pTfHOYFP7pU/ykfkZcEvIvi 5Jvk7pW8OzZJqR8tvZUQEXQLKGCrh6GKYROMqVwlsu9XYpusRg9XEFnq73PvHEkyIoQz dmCmyi01wBsHlCqlJHS032bl4GWiNfaduxj+RjSFwQWhaf0U/+HPHtQi/oVmWwfFwPHL ujrHTys9s7sli0+EhDC70IEfBYhj2fEQ5RiQ71prqJIKpGX7Zwg4ha8GjZPzSWvEqJ1U x93zZ2UYwKGdt9luS/swBP3GyCydASF/PkMQnTvTzD9EozI3jNM5+I44pkjy6kmXiDt2 XdQw== MIME-Version: 1.0 X-Received: by 10.14.219.6 with SMTP id l6mr59174179eep.23.1360654230594; Mon, 11 Feb 2013 23:30:30 -0800 (PST) Received: by 10.14.133.204 with HTTP; Mon, 11 Feb 2013 23:30:30 -0800 (PST) Received: by 10.14.133.204 with HTTP; Mon, 11 Feb 2013 23:30:30 -0800 (PST) In-Reply-To: References: Date: Mon, 11 Feb 2013 23:30:30 -0800 Message-ID: Subject: Re: how to find out if an IP address is assigned statically or dynamically? From: hiren panchasara To: h bagade Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 07:30:37 -0000 On Feb 11, 2013 10:44 PM, "h bagade" wrote: > > Hi all, > > I want to know if there is a way to find out if an interface address is > assigned by dhcp or statically? For example, any distinctive flag or > something like that on ifconfig output! or any other way except processing > dhclient leases files? As per my limited knowledge, no. The only reliable way is to look at /var/db/dhclient.leases. files as you mentioned. Hiren _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 07:49:32 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 381EB3F8 for ; Tue, 12 Feb 2013 07:49:32 +0000 (UTC) (envelope-from jhellenthal@gmail.com) Received: from mail-ia0-x22f.google.com (ia-in-x022f.1e100.net [IPv6:2607:f8b0:4001:c02::22f]) by mx1.freebsd.org (Postfix) with ESMTP id C6FAFA52 for ; Tue, 12 Feb 2013 07:49:31 +0000 (UTC) Received: by mail-ia0-f175.google.com with SMTP id r4so7325441iaj.34 for ; Mon, 11 Feb 2013 23:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=bQdBmnWQzWAVXriGk/iOOLE3MaF3TtLVpfTKDbpqH78=; b=BtIi0VmWHWRu+tGn4iz50jeqRMTjU6BB6GeTisl6zBUa/QVsIctXb6Q7H41mk5ONU4 u9LB/uhyjmyn8u2/qnuW3nkCX6mEr07I6MnwsDVqwBskZhDSBn9GS+ekzMqF3nUG3yF8 y9ZUi8Icfw3Z95H0DUeLwMQO+i4FBLT81fHGLs8CStcz4pocsXBfhrmExfppMs/wBvPl 93pMrp/Yq6r1e+QnnemiLbjvBTWs+v16g5FwWBqpANGcWSVUm4SXzrYquamx215mBdPo NP2PrKD7BveKTuhXwtZadTv3NHJcZcS0WWK88BbbpDYvIR4dzDbpyw1ApMEEmjlImcRO fAUQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataix.net; s=rsa; h=x-received:sender:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=bQdBmnWQzWAVXriGk/iOOLE3MaF3TtLVpfTKDbpqH78=; b=bUEvVgIW4GQK0M4lj9ftJtEkpK393xEfBBZOsDXT1nYHShEGwASYZWLjqa5lfDzeb0 rtnA3Gf5MTkeqOME07D8witn1q9Yy6c+oHR0w1+agJCFeAUKSRoD9hjf2TOTAT1XXoI/ idAB/iN1eovr2oe1rVb3dy0Xc7ZU69SNZvQ3g= X-Received: by 10.50.135.100 with SMTP id pr4mr1467790igb.37.1360655371494; Mon, 11 Feb 2013 23:49:31 -0800 (PST) Received: from DataIX.net (24-231-147-188.dhcp.aldl.mi.charter.com. [24.231.147.188]) by mx.google.com with ESMTPS id qn10sm6043916igc.6.2013.02.11.23.49.28 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 11 Feb 2013 23:49:29 -0800 (PST) Sender: Jason Hellenthal Received: from [192.168.32.64] (sys64.wlan.DataIX.local [192.168.32.64]) (authenticated bits=0) by DataIX.net (8.14.6/8.14.6) with ESMTP id r1C7nPOP007013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 12 Feb 2013 02:49:26 -0500 (EST) (envelope-from jhellenthal@DataIX.net) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <96DC616D-A250-41BC-9A47-4FA6A57B8054@DataIX.net> X-Mailer: iPhone Mail (8C148) From: Jason Hellenthal Subject: Re: how to find out if an IP address is assigned statically or dynamically? Date: Tue, 12 Feb 2013 02:49:16 -0500 To: hiren panchasara Cc: h bagade , "freebsd-net@freebsd.org" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 07:49:32 -0000 Just a OOB thought... But couldn't you adjust a dhclient script to be run up success and assign a d= escription to the interface that the address was dynamically configured by D= HCP. Wouldn't scale well in a large deployment but then again it might for you. BOL --=20 Jason Hellenthal JJH48-ARIN - (2^(N-1)) On Feb 12, 2013, at 2:30, hiren panchasara wrot= e: > On Feb 11, 2013 10:44 PM, "h bagade" wrote: >>=20 >> Hi all, >>=20 >> I want to know if there is a way to find out if an interface address is >> assigned by dhcp or statically? For example, any distinctive flag or >> something like that on ifconfig output! or any other way except processin= g >> dhclient leases files? >=20 > As per my limited knowledge, no. > The only reliable way is to look at > /var/db/dhclient.leases. files as you mentioned. >=20 > Hiren _______________________________________________ >> freebsd-net@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-net >> To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 10:34:01 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9BE84138 for ; Tue, 12 Feb 2013 10:34:01 +0000 (UTC) (envelope-from pradeep.vanparia@gmail.com) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 4269935A for ; Tue, 12 Feb 2013 10:34:01 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id p1so4489005vcq.30 for ; Tue, 12 Feb 2013 02:34:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=0hEglgs0LiXK3Cqzpe38riNBOwwRR/pvShbPxmGCbZE=; b=l+FdWo1ZILWgPX5YQtKQEWAKAVFd68VrVjeqfU8dzLgoeOWo7Eh0X09gtmcckbszh5 03yZPHaYhKAyNDjLvvDUK8X8UiYbJ9JcG3aPnTdT2TLndpg35HrwJbYdYplrT7sb15M/ 4eTWFynlsOnuKtKJ4Ky9/rwx8w8nY/15zS/sGi6/iBec2Iu6Y/5hdqTKKMZQVkQrdApd I8OPhX1ggHuZ8Js6GlbV6MU+Ki/EZqMT4j7LAF4BLm8cZq1WV5ZJaRUeHKJX7yY/8UrT LH4L4XkIa7c7sdu7Y1qKwaY1lR2MgdIvA1YeW4FF39gckr9uvO2cauC0Cdo3EC5nOvSR GwPw== MIME-Version: 1.0 X-Received: by 10.52.66.70 with SMTP id d6mr19926078vdt.30.1360665240334; Tue, 12 Feb 2013 02:34:00 -0800 (PST) Received: by 10.220.28.67 with HTTP; Tue, 12 Feb 2013 02:34:00 -0800 (PST) Date: Tue, 12 Feb 2013 16:04:00 +0530 Message-ID: Subject: Your Review For SCTP. From: pradeep vanparia To: freebsd-net@FreeBSD.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:34:01 -0000 Respected Sir/Madam, With reference of http://lists.freebsd.org/pipermail/freebsd-net/2012-May/032318.html...I like this web-site. I am also doing research on SCTP...So, that i wants to some help from your side, Your help is very important for me. How I can Practically Implement or Check Features of SCTP in Linux or freeBSD OS ? SCTP features like Multilhoming ,MultiStreaming.. Thanks. -- Mr. Pradip G. Vanparia Lecturer Dept. of Computer Sci. & Info. Tech. Shri M. & N. Virani Science College, ATMIYA Grp.of Institutions, Yogidham Gurukul, RAJKOT - 360 005. GUJARAT (INDIA) From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 10:55:42 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A54B6785 for ; Tue, 12 Feb 2013 10:55:42 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by mx1.freebsd.org (Postfix) with ESMTP id 1491D6B4 for ; Tue, 12 Feb 2013 10:55:41 +0000 (UTC) Received: by mail-la0-f50.google.com with SMTP id ec20so6594174lab.23 for ; Tue, 12 Feb 2013 02:55:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:x-enigmail-version:content-type :x-gm-message-state; bh=ezb26d2NnQYG27HS703BJLGhV0F73XKwcY6l3jgOh3c=; b=Y0jifVeJ1sTo8LUGslSHWnuE9rVmU5SYxsBqDtxky8ytoNUnkAAHT69XgZ03rl+bSb sogRsnrGZOKQDENna8p+DXBKMC5F8AYluWHNZIf4AEUYgYvvVSpG89NSc78opol5OCsq QFXMMqbzEIP6n7o1V0PWDME3Hy/dLxwRXaB0+l8Q3toWv+c8rNbUI6wG8w5rTxBDk/p4 09AppmK/+Seo5AovjNyVDOY+X4XMVI06xXerd1xXSy6OURsQjs1+uc3CGvXdC4g5jxi5 RWAQFfgyNNVKn8kXoNXtJ8DAGxjv6SklBugU4aJDq0HoqEoonhTppofwpeYOj6fH30D3 1UFg== X-Received: by 10.152.147.36 with SMTP id th4mr16220697lab.19.1360666540758; Tue, 12 Feb 2013 02:55:40 -0800 (PST) Received: from dhcp170-82-red.yandex.net (dhcp170-82-red.yandex.net. [95.108.170.82]) by mx.google.com with ESMTPS id tm10sm23566128lab.10.2013.02.12.02.55.38 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 02:55:39 -0800 (PST) Sender: Andrey Zonov Message-ID: <511A1FA9.1040606@FreeBSD.org> Date: Tue, 12 Feb 2013 14:55:37 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> <5118D375.5000501@freebsd.org> In-Reply-To: <5118D375.5000501@freebsd.org> X-Enigmail-Version: 1.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="----enig2FDRAVFSOBIOGHUMDXOCI" X-Gm-Message-State: ALoCoQkzcyqHi6CghO4mi+5BqEoG0PlwyaJ824enAUwbhSO0Soa+WYcaBn8WuMd/UTQqY/WMbevn Cc: net@freebsd.org, Alfred Perlstein , Randall Stewart , Kevin Oberman , John Baldwin X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 10:55:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) ------enig2FDRAVFSOBIOGHUMDXOCI Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2/11/13 3:18 PM, Andre Oppermann wrote: >=20 > Smaller RTO (1s) has become a RFC so there was very broad consensus in > TCPM that is a good thing. We don't have it yet because we were not fu= lly > compliant in one case (loss of first segment). I've fixed that a while= > back and will bring 1s RTO soon to HEAD. >=20 They use 300ms at least for me/my link/ISP/etc. --=20 Andrey Zonov ------enig2FDRAVFSOBIOGHUMDXOCI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJRGh+pAAoJEBWLemxX/CvTQdwH/RJHfe8kA0HkganOwDh3N9DN Bb+ZUAy84awewDe+3wLh9SosqoBsN33314oCHcoWalRdgwP77H+JG3/WwZ19CmUM 7ICDTOs4IOYkRUlQD2N8CKsMX2C+ZUwM0sUVu1NvYOYOjzqKHViOk9NGz4g21zpI uarDIQqp+3hGJNPcsRn2N2MEmggAfY6vET7fBs1GBsiYrPUX92Jdz5lf6AMU+IVj i/H0iQDbegEsQ1buStrVCJgaZgndzDLA+QShPDV7hpTpb+QNrokCDmQIqu5rT+/3 OTUsZ9SnplNdcrDZtds1r8tTdReETG3TqpJv1/jV2MHgWWwxV2xFJLLXnYqoBUc= =3qo7 -----END PGP SIGNATURE----- ------enig2FDRAVFSOBIOGHUMDXOCI-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 11:30:03 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4F6F05C2 for ; Tue, 12 Feb 2013 11:30:02 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id ECDB986B for ; Tue, 12 Feb 2013 11:30:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1CBU0lt062734 for ; Tue, 12 Feb 2013 11:30:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1CBU0dC062730; Tue, 12 Feb 2013 11:30:00 GMT (envelope-from gnats) Date: Tue, 12 Feb 2013 11:30:00 GMT Message-Id: <201302121130.r1CBU0dC062730@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: Ralf Wenk Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Ralf Wenk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 11:30:03 -0000 The following reply was made to PR kern/173475; it has been noted by GNATS. From: Ralf Wenk To: Emanuel Haupt Cc: bug-followup@FreeBSD.org Subject: Re: kern/173475: [tun] tun(4) stays opened by PID after process is terminated Date: Tue, 12 Feb 2013 12:27:12 +0100 > Could you please try the following vpnc patch? It tries to work around > this deadlock situation: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/175067 > > However, the underlying problem with if_tun should be looked at > separately in this PR. > > Emanuel Tried today with a newer (r245247) kernel than at the date of the bug report. Without the patch the behavior was as described. With the patch repeated use of vpnc, vpnc-disconnect works again. So this patch is a sufficient workaround. Ralf From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 12:17:16 2013 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 17BB66BD for ; Tue, 12 Feb 2013 12:17:16 +0000 (UTC) (envelope-from Michael.Tuexen@lurchi.franken.de) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by mx1.freebsd.org (Postfix) with ESMTP id A7151AAD for ; Tue, 12 Feb 2013 12:17:15 +0000 (UTC) Received: from [192.168.1.101] (p508FA903.dip.t-dialin.net [80.143.169.3]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 34E5D1C0C069E; Tue, 12 Feb 2013 13:17:13 +0100 (CET) Subject: Re: Your Review For SCTP. Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Michael Tuexen In-Reply-To: Date: Tue, 12 Feb 2013 13:17:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: pradeep vanparia X-Mailer: Apple Mail (2.1283) Cc: freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 12:17:16 -0000 On Feb 12, 2013, at 11:34 AM, pradeep vanparia wrote: > Respected Sir/Madam, >=20 > With reference of > = http://lists.freebsd.org/pipermail/freebsd-net/2012-May/032318.html...I > like this web-site. >=20 >=20 > I am also doing research on SCTP...So, that i wants to some help from = your > side, > Your help is very important for me. >=20 >=20 > How I can Practically Implement or Check Features of SCTP in Linux or > freeBSD OS ? >=20 > SCTP features like Multilhoming ,MultiStreaming.. The SCTP implementations of Linux and FreeBSD support multihoming and = multistreaming. Best regards Michael >=20 >=20 > Thanks. >=20 > --=20 > Mr. Pradip G. Vanparia >=20 > Lecturer > Dept. of Computer Sci. & Info. Tech. > Shri M. & N. Virani Science College, > ATMIYA Grp.of Institutions, > Yogidham Gurukul, > RAJKOT - 360 005. > GUJARAT (INDIA) > _______________________________________________ > 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 From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 13:30:12 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id C01F9215 for ; Tue, 12 Feb 2013 13:30:12 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 34DD0F50 for ; Tue, 12 Feb 2013 13:30:12 +0000 (UTC) Received: (qmail 36993 invoked from network); 12 Feb 2013 14:47:44 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Feb 2013 14:47:44 -0000 Message-ID: <511A43DB.8030400@freebsd.org> Date: Tue, 12 Feb 2013 14:30:03 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andrey Zonov Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> <5118D375.5000501@freebsd.org> <511A1FA9.1040606@FreeBSD.org> In-Reply-To: <511A1FA9.1040606@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , Alfred Perlstein , Randall Stewart , Kevin Oberman , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:30:12 -0000 On 12.02.2013 11:55, Andrey Zonov wrote: > On 2/11/13 3:18 PM, Andre Oppermann wrote: >> >> Smaller RTO (1s) has become a RFC so there was very broad consensus in >> TCPM that is a good thing. We don't have it yet because we were not fully >> compliant in one case (loss of first segment). I've fixed that a while >> back and will bring 1s RTO soon to HEAD. >> > > They use 300ms at least for me/my link/ISP/etc. Let me be more precise: An initial RTO of 1s was published as RFC. This is what I'm referring to. It affects the setup phase of a connection. A separate issue is the minimum RTO during a connection. According to the RFC the RTO during the lifetime of the connection should also not be less than 1s. The RTO being determined based on the RTT measurement done using timestamps or Karn's algorithm. However on fast links this has been shown to be too long to wait for. So FreeBSD decreased the allowed lower bound to hz/33. This is only effective if your RTO was actually calculated to be equal or lower than that. The result is a quicker re-probing and discovery of the current line conditions. Since the RTO was measured to be less-equal than hz/33, the possible negative downside is very limited. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 13:48:59 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CD47AA50 for ; Tue, 12 Feb 2013 13:48:59 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 46E0934B for ; Tue, 12 Feb 2013 13:48:59 +0000 (UTC) Received: (qmail 37176 invoked from network); 12 Feb 2013 15:06:37 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 12 Feb 2013 15:06:37 -0000 Message-ID: <511A4848.3070505@freebsd.org> Date: Tue, 12 Feb 2013 14:48:56 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> <51177818.2090900@FreeBSD.org> <5118D375.5000501@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , Alfred Perlstein , Randall Stewart , Kevin Oberman , net@freebsd.org, Andrey Zonov X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 13:48:59 -0000 On 11.02.2013 19:56, Adrian Chadd wrote: > On 11 February 2013 03:18, Andre Oppermann wrote: > >> In general Google does provide quite a bit of data with their experiments >> showing that it isn't harmful and that it helps the case. >> >> Smaller RTO (1s) has become a RFC so there was very broad consensus in >> TCPM that is a good thing. We don't have it yet because we were not fully >> compliant in one case (loss of first segment). I've fixed that a while >> back and will bring 1s RTO soon to HEAD. >> >> I'm pretty sure that Google doesn't ignore idle on their Internet facing >> servers. They may have proposed a decay mechanism in the past. I'd have >> to check the TCPM archives for that. > > Argh, the "If google does, it it must be fine" argument. Please. You removed what I was replying to. There is no doubt IW10 originated from Google. However Google took it to TCPM and provided measurement data with it. After some forth and back they provided more data which began to convince more people on TCPM. Eventually the proposal was adopted as official TCPM working group draft and likely will become a RFC later this year. If you want to argue against RTO1s (RFC6298) then the lead authors are from ICSI/UC Berkeley. Google did participate in that one by providing additional measurement data. > Does Google publish the data for these experiments with the > international and local links broken down? Yes. Have you followed the evolution and discussion of IW10 on TCPM? > Google run a highly distributed infrastructure (this isn't news for > anyone, I know) and thus the link distance, RTT, number of hops, etc > may not accurately reflect "the internet". It may accurately reflect > "the internet from the perspective of being roughly within the same > city or state" in a lot of cases. > > The TCP congestion algorithms aren't just for avoiding congestion over > a peering fabric and last-mile ISP infrastructure. IW10 is not a congestion control algorithm. It is a change to the initial state of it at the beginning of an connection when not much other data is available. Many years ago the same thing happend with RFC3390 which increased the IW to 3 segments. > The effects of tweaking congestion algorithms for delivery over a > local peering infrastructure where you try to run things as > un-congested as possible (where congestion is now The ISPs Problem) > where you maintain tight control over as much of the network > infrastructure as you can is likely going to be very different to the > congestion algorithm behaviour needed for some end-node speaking to a > variety of end-nodes over a longer, more varying set of international > links. You know, what TCP congestion algorithms are also trying to > "play fair" with. I agree but not relevant to this case. > Please - as much as I applaud Google for what they do, please don't > generalise their results to "the greater internet" without looking at > the many caveats/assumptions. Well, that's exactly what I'm trying to do here. Except not only for ideas sourced from Google but also other places. Like "it's in Linux and the Internet hasn't broken down yet". Without any measurement date whatsoever. -- Andre From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 14:03:15 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id DB980F46 for ; Tue, 12 Feb 2013 14:03:15 +0000 (UTC) (envelope-from mc@hack.org) Received: from ecki.hack.org (ecki.hack.org [IPv6:2001:888:22b3::2]) by mx1.freebsd.org (Postfix) with ESMTP id AB199633 for ; Tue, 12 Feb 2013 14:03:15 +0000 (UTC) Received: from [::1] (helo=totoro.hack.org) by ecki.hack.org with esmtp id 1U5GS2-000PN1-Tp for freebsd-net@freebsd.org; Tue, 12 Feb 2013 15:03:15 +0100 From: Michael Cardell Widerkrantz To: freebsd-net@freebsd.org Subject: Adding NAT-T to openiked on FreeBSD Date: Tue, 12 Feb 2013 15:03:14 +0100 Message-ID: <861ucl634t.fsf@totoro.hack.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.4 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 14:03:15 -0000 Hello, I'm trying to add NAT-traversal support on FreeBSD to the portable version of OpenBSD's IKEv2 daemon, openiked. See http://openiked.org/ for more. My NAT-T branch is called "natt" and lives here: http://github.com/mchackorg/openiked/ It seems to work, but only one way. The receiving node doesn't seem to unpack the ESP from UDP. The IKE dialogue succesfully negotiates security associations and both ends agree to use UDP-ESP. When I try to ping a node on the other end my ICMP packets are succesfully encapsulated as UDP-ESP but seems to be thrown away at the other end. I'm stuck. Does anyone have any idea what's happening here and what I can do about it? The network looks like this: 192.168.0.2 - em0-192.168.0.1 10.0.2.1-em1 - 10.0.2.2 alice NAT box bob The 192.168.0.0/24 network is the private network here. Everything sent from nodes on that network looks like 10.0.2.1 to bob. Here's some output of setkey from ipsec-tools (which knows about NAT-T): alice, 192.168.0.2: # ./setkey -D 192.168.0.2[4500] 10.0.2.2[4500] esp-udp mode=tunnel spi=3488009807(0xcfe6ce4f) reqid=0(0x00000000) E: aes-cbc 07e091ae 7c3ff9ba 62061151 83969ff9 ad95a7dd 1484ef05 bc92393d 6819cd00 A: hmac-sha256 36513976 f54ead88 f9e50769 23a5440b 20cd52a8 a9609d34 d2a0f1d5 243b84bc seq=0x00000000 replay=64 flags=0x00000000 state=mature created: Feb 12 13:58:24 2013 current: Feb 12 13:59:24 2013 diff: 60(s) hard: 10800(s) soft: 9741(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 536870912(bytes) soft: 484257562(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=1794 refcnt=1 10.0.2.2[4500] 192.168.0.2[4500] esp-udp mode=tunnel spi=1821072731(0x6c8b5d5b) reqid=0(0x00000000) E: aes-cbc cc21a55c 4ec81ca4 ea93641a 2ea0db9f 422173a9 b6c22c99 d8f78e3f 2fc7b175 A: hmac-sha256 67b08cc7 3dd0409d 27dfeb18 c4435eb3 72ac32dd b4d084c3 6b13225e f94d92b6 seq=0x00000000 replay=64 flags=0x00000000 state=mature created: Feb 12 13:58:24 2013 current: Feb 12 13:59:24 2013 diff: 60(s) hard: 10800(s) soft: 9698(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 536870912(bytes) soft: 482110078(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=1794 refcnt=1 # ./setkey -DP 10.0.2.0/24[any] 192.168.0.0/24[any] 255 in ipsec esp/tunnel/10.0.2.2-192.168.0.2/use spid=6 seq=1 pid=1795 refcnt=1 192.168.0.0/24[any] 10.0.2.0/24[any] 255 out ipsec esp/tunnel/192.168.0.2-10.0.2.2/require spid=5 seq=0 pid=1795 refcnt=1 bob, 10.0.2.2: # ./setkey -D 10.0.2.2[4500] 10.0.2.1[4500] esp-udp mode=tunnel spi=1821072731(0x6c8b5d5b) reqid=0(0x00000000) E: aes-cbc cc21a55c 4ec81ca4 ea93641a 2ea0db9f 422173a9 b6c22c99 d8f78e3f 2fc7b175 A: hmac-sha256 67b08cc7 3dd0409d 27dfeb18 c4435eb3 72ac32dd b4d084c3 6b13225e f94d92b6 seq=0x00000000 replay=64 flags=0x00000000 state=mature created: Feb 12 13:58:28 2013 current: Feb 12 13:58:49 2013 diff: 21(s) hard: 10800(s) soft: 10054(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 536870912(bytes) soft: 499826819(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=1 pid=6046 refcnt=1 10.0.2.1[4500] 10.0.2.2[4500] esp-udp mode=tunnel spi=3488009807(0xcfe6ce4f) reqid=0(0x00000000) E: aes-cbc 07e091ae 7c3ff9ba 62061151 83969ff9 ad95a7dd 1484ef05 bc92393d 6819cd00 A: hmac-sha256 36513976 f54ead88 f9e50769 23a5440b 20cd52a8 a9609d34 d2a0f1d5 243b84bc seq=0x00000000 replay=64 flags=0x00000000 state=mature created: Feb 12 13:58:28 2013 current: Feb 12 13:58:49 2013 diff: 21(s) hard: 10800(s) soft: 9633(s) last: hard: 0(s) soft: 0(s) current: 0(bytes) hard: 536870912(bytes) soft: 478888853(bytes) allocated: 0 hard: 0 soft: 0 sadb_seq=0 pid=6046 refcnt=1 # ./setkey -DP 192.168.0.0/24[any] 10.0.2.0/24[any] 255 in ipsec esp/tunnel/10.0.2.1-10.0.2.2/use spid=12 seq=1 pid=6052 refcnt=1 10.0.2.0/24[any] 192.168.0.0/24[any] 255 out ipsec esp/tunnel/10.0.2.2-10.0.2.1/require spid=11 seq=0 pid=6052 refcnt=1 Listening on 192.168.0.2 when doing ping from 10.0.2.2: 14:00:21.434961 IP 10.0.2.2.4500 > 192.168.0.2.4500: UDP-encap: ESP(spi=0x6c8b5d5b,seq=0x1), length 136 14:00:22.435662 IP 10.0.2.2.4500 > 192.168.0.2.4500: UDP-encap: ESP(spi=0x6c8b5d5b,seq=0x2), length 136 Listening on 10.0.2.2 when doing ping from 192.168.0.2 (NATted to 10.0.2.1): 14:00:53.932671 IP 10.0.2.1.4500 > 10.0.2.2.4500: UDP-encap: ESP(spi=0xcfe6ce4f,seq=0x1), length 136 14:00:54.942653 IP 10.0.2.1.4500 > 10.0.2.2.4500: UDP-encap: ESP(spi=0xcfe6ce4f,seq=0x2), length 136 I looked through the kernel to find the way packets are unpacked. The packets seem to go this path: sys/netinet/udp_usrreq.c: udp_input() -> udp_append() -> udp4_espdecap() In udp_append() there's some code dealing with UDP encapsulated ESP, so I added a small debug printout: ----------------- 8< ----------------- --- udp_usrreq.c-orig 2013-02-12 14:28:30.000000000 +0100 +++ udp_usrreq.c 2013-02-12 14:28:08.000000000 +0100 @@ -284,6 +284,7 @@ udp_append(struct inpcb *inp, struct ip #ifdef IPSEC_NAT_T up = intoudpcb(inp); KASSERT(up != NULL, ("%s: udpcb NULL", __func__)); + log(LOG_DEBUG, "udp_append in NAT_T. up->u_flags: %d\n", up->u_flags); if (up->u_flags & UF_ESPINUDP_ALL) { /* IPSec UDP encaps. */ n = udp4_espdecap(inp, n, off); if (n == NULL) /* Consumed. */ ----------------- 8< ----------------- When I see UDP-ESP traffic coming in I see this in the log for every UDP-ESP packet received: udp_append in NAT_T. up->u_flags: 0 I was expecting this flag variable to be set. Where should it be set? Any other ideas? -- MC, http://hack.org/mc/ From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 17:32:36 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 52A65FE for ; Tue, 12 Feb 2013 17:32:36 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 11FD0375 for ; Tue, 12 Feb 2013 17:32:35 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U5Jin-0001Tx-Nw for freebsd-net@freebsd.org; Tue, 12 Feb 2013 18:32:45 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:32:45 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:32:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Problems with two interfaces on the same subnet? Date: Tue, 12 Feb 2013 18:32:12 +0100 Lines: 65 Message-ID: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC6E188A6C46F1F31B3AC1DAF" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:32:36 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC6E188A6C46F1F31B3AC1DAF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello, I have a machine with two interfaces, igb2 and igb3 on the same subnet but with different IP addresses, e.g. igb2 has 192.168.1.221, igb3 has 192.168.1.222. Firstly, is there anything which would preclude this from working? As I see it, these are two different MAC addresses and to the outside world should look as two different hosts, right? I currently don't have the right tools to diagnose this, I'm using nas4free which is a 9.1-based "embedded" system lacking tcpdump, so here are some raw observations: * With both NICs connected to the same switch, everything appears to work, but an *upstream* router *seems* to have strange issues which manifest in it replicating the traffic coming from this machine to unrelated ports. This router is an old, unsupported Cisco router which should have long be replaced and no-one here knows how to debug it. The network admin says that he sees that the "Cat4k Mgmt LoPri" counter shows high CPU usage, but cannot help other than that. This also may be due to weirdness in other parts of the network, we don't know if it's caused by my machine. * With both NICs connected to different switches, everything appears to work, BUT, if igb2 cable is disconnected, pings to igb3 simply stop, even though its cable *is* still connected. This sort of looks like incoming and outgoing traffic to the same IP address (that of igb3) are arriving and departing on separate ports, which I could accept as the packets are unrelated on the IP level and the route says that the subnet is reachable only through the first interface, if the kernel does nothing when the first NIC's link goes down. Is this what's going on? The reason why I have two addresses on the same subnet is for poor-man's load-balancing, this is a NFS server and I'd like to use both NICs at the same time, accessed from different client machines. I'm suspiocious that the network equipment I'm using does not support LACP. Is there another way to do it? Would it help to have two different private subnets= ? And the big question on my network admin's mind: would it help to switch to Linux? --------------enigC6E188A6C46F1F31B3AC1DAF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEafJ4ACgkQ/QjVBj3/HSyG/wCeKfNDOwAhmc+FzzVZefHuHtel XDEAni1pm2l/9Tmj6MdKw3TuFPXBknUT =WUG6 -----END PGP SIGNATURE----- --------------enigC6E188A6C46F1F31B3AC1DAF-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 17:38:43 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E69AB55C; Tue, 12 Feb 2013 17:38:42 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 477A23E8; Tue, 12 Feb 2013 17:38:42 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,650,1355126400"; d="scan'208";a="19983793" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 12 Feb 2013 09:38:41 -0800 Received: from vmwexceht01-prd.hq.netapp.com (vmwexceht01-prd.hq.netapp.com [10.106.76.239]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1CHcfZ9025931; Tue, 12 Feb 2013 09:38:41 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 09:38:41 -0800 From: "Eggert, Lars" To: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Thread-Topic: Problems with two interfaces on the same subnet? Thread-Index: AQHOCUb6Tp99D1R3iECoMLZWzmGEXph3AyuA Date: Tue, 12 Feb 2013 17:38:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:38:44 -0000 Hi, On Feb 12, 2013, at 9:32, Ivan Voras wrote: > I have a machine with two interfaces, igb2 and igb3 on the same subnet > but with different IP addresses, e.g. igb2 has 192.168.1.221, igb3 has > 192.168.1.222. Firstly, is there anything which would preclude this from > working? As I see it, these are two different MAC addresses and to the > outside world should look as two different hosts, right? depends on what you mean by "work". There will only be one default route ou= t of the box. > * With both NICs connected to different switches, everything appears to > work, BUT, if igb2 cable is disconnected, pings to igb3 simply stop, > even though its cable *is* still connected. This sounds like your default route is going via igb2. You can make this work with ipfw rules (and I guess also setfib, although I= have not tried that.) Lars From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 17:50:27 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id D73F2CAA for ; Tue, 12 Feb 2013 17:50:27 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 9576C759 for ; Tue, 12 Feb 2013 17:50:27 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U5K0C-0002c4-M1 for freebsd-net@freebsd.org; Tue, 12 Feb 2013 18:50:44 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:50:44 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:50:44 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Date: Tue, 12 Feb 2013 18:50:15 +0100 Lines: 44 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3938A5215C3C699F127A5EC8" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:50:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3938A5215C3C699F127A5EC8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/02/2013 18:38, Eggert, Lars wrote: > This sounds like your default route is going via igb2. Yes, it is. > You can make this work with ipfw rules (and I guess also setfib, althou= gh I have not tried that.) The concept of FIBs looks clean and applicable but setfib works on newly started process, and I would need to do something like apply it to packets coming from an interface. I've found previous posts on "policy routing" with ipfw (http://lists.freebsd.org/pipermail/freebsd-security/2004-April/001839.ht= ml) but this is probably not what I need; I would need that packets generated as a response to incoming packets go to the same interface as the incoming packet. Or are you thinking of hard-coding client addresses in ipfw rules so that packets going to specific IPs go to a specific interface? --------------enig3938A5215C3C699F127A5EC8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEagNcACgkQ/QjVBj3/HSyiXwCgndqGRZqn6V+t6IDHINlUEn1k h/4An2qEiQGMm/82FJqufK1o6MAb9+li =m7Ji -----END PGP SIGNATURE----- --------------enig3938A5215C3C699F127A5EC8-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 17:52:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 1C44CD5C; Tue, 12 Feb 2013 17:52:38 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by mx1.freebsd.org (Postfix) with ESMTP id C5BDB77B; Tue, 12 Feb 2013 17:52:37 +0000 (UTC) Received: by mail-qa0-f45.google.com with SMTP id g10so1786802qah.11 for ; Tue, 12 Feb 2013 09:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Fdqm3xmsxlbH3+nE7gIuzkFFXDiiF5k5yrHQMSgC9ug=; b=GlqhKoRXM2U9TJs5Gvshc7HOYifVB3XSYB9EeHms51bR3R+MnDTJKFNWVzKr8GVZHB 1PhmuQKjabsIx2zxQw2o7/c1mWkbCV38OKlOk9nOEFhdy3ZPWjMlv+tB1qtTz70InAb9 q/cO2vRYHTZStohA/nR4eGqVkznAgSdIZ1SV41lXOhtF5rRAeqpakZjaOdDWATWd2nI5 yOWO9oRpkFmrplTE4mrfNQ//jgHOv7qC9dU6P/nVOGrKEq6/Q8t27cpFKaezKNg0+ufn nGSr18gkZvH3qASMqO2WEpSL9X/0YElUMblsTI+P9nPK1q89F7CB6fBJ5SPhwmqLCO/a BYFg== MIME-Version: 1.0 X-Received: by 10.49.34.146 with SMTP id z18mr8524220qei.29.1360691550834; Tue, 12 Feb 2013 09:52:30 -0800 (PST) Received: by 10.49.106.233 with HTTP; Tue, 12 Feb 2013 09:52:30 -0800 (PST) In-Reply-To: References: Date: Tue, 12 Feb 2013 09:52:30 -0800 Message-ID: Subject: Re: Problems with two interfaces on the same subnet? From: Freddie Cash To: Ivan Voras Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:52:38 -0000 Any reason you can't just use lagg(4) in one of the non-LACP modes? That's bascially designed to do exactly what you want. On Tue, Feb 12, 2013 at 9:50 AM, Ivan Voras wrote: > On 12/02/2013 18:38, Eggert, Lars wrote: > > > This sounds like your default route is going via igb2. > > Yes, it is. > > > You can make this work with ipfw rules (and I guess also setfib, > although I have not tried that.) > > The concept of FIBs looks clean and applicable but setfib works on newly > started process, and I would need to do something like apply it to > packets coming from an interface. > > I've found previous posts on "policy routing" with ipfw > ( > http://lists.freebsd.org/pipermail/freebsd-security/2004-April/001839.html > ) > but this is probably not what I need; I would need that packets > generated as a response to incoming packets go to the same interface as > the incoming packet. Or are you thinking of hard-coding client addresses > in ipfw rules so that packets going to specific IPs go to a specific > interface? > > > -- Freddie Cash fjwcash@gmail.com From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 17:57:20 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id C721CE2F for ; Tue, 12 Feb 2013 17:57:20 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 81D897A4 for ; Tue, 12 Feb 2013 17:57:20 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U5K6s-0002PF-8b for freebsd-net@freebsd.org; Tue, 12 Feb 2013 18:57:38 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:57:38 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 18:57:38 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Date: Tue, 12 Feb 2013 18:57:08 +0100 Lines: 29 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig73A7F4F0410FE2DD76E3C315" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 17:57:20 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig73A7F4F0410FE2DD76E3C315 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/02/2013 18:52, Freddie Cash wrote: > Any reason you can't just use lagg(4) in one of the non-LACP modes? Th= at's > bascially designed to do exactly what you want. No particular reason, I'm just not familiar enough with it. Will e.g. the "loadbalance" mode "just work" ? Should I expect any problems? --------------enig73A7F4F0410FE2DD76E3C315 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEagnQACgkQ/QjVBj3/HSxc+wCgj6BYainu6CuUR37afOpAlICg LMAAn38OLLKDuc7qXM5c0oVBe6WFd2oC =R7gz -----END PGP SIGNATURE----- --------------enig73A7F4F0410FE2DD76E3C315-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 18:06:19 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 624D4FEB for ; Tue, 12 Feb 2013 18:06:19 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 0ACF0806 for ; Tue, 12 Feb 2013 18:06:18 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U5KFX-00070e-Gw for freebsd-net@freebsd.org; Tue, 12 Feb 2013 19:06:35 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 19:06:35 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 19:06:35 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Date: Tue, 12 Feb 2013 19:06:06 +0100 Lines: 37 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig67810A0A7D8F2B4BE790E974" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:06:19 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig67810A0A7D8F2B4BE790E974 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/02/2013 18:57, Ivan Voras wrote: > On 12/02/2013 18:52, Freddie Cash wrote: >> Any reason you can't just use lagg(4) in one of the non-LACP modes? T= hat's >> bascially designed to do exactly what you want. >=20 > No particular reason, I'm just not familiar enough with it. Will e.g. > the "loadbalance" mode "just work" ? Should I expect any problems? Actually, I know next to nothing about link aggregation. How do ARP requests get solved? Would an attached L3-aware switch see the same IP address on two ports? Since "loadbalance" chooses ports based on a hash, it will probably start dropping 50% of the outgoing traffic if one of the two links dies? --------------enig67810A0A7D8F2B4BE790E974 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEahI8ACgkQ/QjVBj3/HSzNsQCffLQPzMKBghXChipOtB8nTa2Q yXQAn06YKDEcfgVTYrhvnLxyOK9cyGhX =QUvX -----END PGP SIGNATURE----- --------------enig67810A0A7D8F2B4BE790E974-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 18:09:55 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 71F5B200 for ; Tue, 12 Feb 2013 18:09:55 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) by mx1.freebsd.org (Postfix) with ESMTP id 06F17829 for ; Tue, 12 Feb 2013 18:09:54 +0000 (UTC) Received: by mail-wi0-f177.google.com with SMTP id hm14so469614wib.4 for ; Tue, 12 Feb 2013 10:09:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=sg/+ESKgxx8AuB/ovcXJ2r85tNUTTcBIRWJuxfGalOM=; b=JAC1JIFgmZ26Sf4wBwNo5kvton87ComN70VlIb6RIARFdowVnJi0347mIa52iJqaED 9H3VDfdL8zIRXZetKXTIeiKy6Gz9Z9AMt9W2JllXavUEoRPaquV9Gax/ev7jjN7X5zuv RL0jEXQF9ilJh8iNKvLG4YYZetPivcA+THbrTGwbEQtdbqjbTy1vziQPRqCkcdrsCH1J YWiDDJRYWoAFJOjcIQ6pDGiL92NcJpXixlZxsxoJHGQR4ZG/Tf2EtKPpJO8qzjuFj1or svMZZVKYUYpimVovWS5DG8H5iTHd794kvNZV3dog64zKWBHSbLVWEqe6oKLhFAY+sbH1 e4aw== X-Received: by 10.194.86.38 with SMTP id m6mr17233122wjz.13.1360692593856; Tue, 12 Feb 2013 10:09:53 -0800 (PST) Received: from dfleuriot-at-hi-media.com ([83.167.62.196]) by mx.google.com with ESMTPS id t7sm31303161wiy.2.2013.02.12.10.09.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 Feb 2013 10:09:52 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Problems with two interfaces on the same subnet? From: Fleuriot Damien In-Reply-To: Date: Tue, 12 Feb 2013 19:09:51 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0FFECF51-FB74-4025-84EC-F83829723CDC@my.gd> References: To: Ivan Voras X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQm/2LnX+zwwfGogw4dUeJOS3ovKkTz4XXa8Eyw3KagVffExQpc1Nptwxs1NcKoTS+tJ5Qq6 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:09:55 -0000 On Feb 12, 2013, at 7:06 PM, Ivan Voras wrote: > On 12/02/2013 18:57, Ivan Voras wrote: >> On 12/02/2013 18:52, Freddie Cash wrote: >>> Any reason you can't just use lagg(4) in one of the non-LACP modes? = That's >>> bascially designed to do exactly what you want. >>=20 >> No particular reason, I'm just not familiar enough with it. Will e.g. >> the "loadbalance" mode "just work" ? Should I expect any problems? >=20 > Actually, I know next to nothing about link aggregation. How do ARP > requests get solved? Would an attached L3-aware switch see the same IP > address on two ports? Since "loadbalance" chooses ports based on a = hash, > it will probably start dropping 50% of the outgoing traffic if one of > the two links dies? >=20 >=20 You need a switch that can work with etherchannels (cisco , laggproto = fec on your box) or LACP. Otherwise I assume your switch is going to get very confused about the = MAC address for your IP moving around from port to port. Very *very* confused. From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 18:10:26 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6F3C62AC; Tue, 12 Feb 2013 18:10:26 +0000 (UTC) (envelope-from lars@netapp.com) Received: from mx12.netapp.com (mx12.netapp.com [216.240.18.77]) by mx1.freebsd.org (Postfix) with ESMTP id 55464842; Tue, 12 Feb 2013 18:10:26 +0000 (UTC) X-IronPort-AV: E=Sophos;i="4.84,650,1355126400"; d="scan'208";a="20002457" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx12-out.netapp.com with ESMTP; 12 Feb 2013 10:10:26 -0800 Received: from vmwexceht05-prd.hq.netapp.com (exchsmtp.hq.netapp.com [10.106.77.35]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id r1CIAPtu007794; Tue, 12 Feb 2013 10:10:26 -0800 (PST) Received: from SACEXCMBX01-PRD.hq.netapp.com ([169.254.2.54]) by vmwexceht05-prd.hq.netapp.com ([10.106.77.35]) with mapi id 14.02.0328.009; Tue, 12 Feb 2013 10:10:25 -0800 From: "Eggert, Lars" To: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Thread-Topic: Problems with two interfaces on the same subnet? Thread-Index: AQHOCUb6Tp99D1R3iECoMLZWzmGEXph3AyuAgAADNoCAAAWpAA== Date: Tue, 12 Feb 2013 18:10:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: text/plain; charset="us-ascii" Content-ID: <990AC28AA5A9AE4FA437F9D6546388BE@tahoe.netapp.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:10:26 -0000 Hi, On Feb 12, 2013, at 9:50, Ivan Voras wrote: >> You can make this work with ipfw rules (and I guess also setfib, althoug= h I have not tried that.) >=20 > The concept of FIBs looks clean and applicable but setfib works on newly > started process, and I would need to do something like apply it to > packets coming from an interface. Assuming your default route is via igb2, you can do something like this: ipfw add fwd ip4 from to = not out (From memory, no guarantees.) Lars= From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 18:18:37 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 90C32444 for ; Tue, 12 Feb 2013 18:18:37 +0000 (UTC) (envelope-from freebsd-net@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 204078A3 for ; Tue, 12 Feb 2013 18:18:36 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U5KRN-0002pg-Et for freebsd-net@freebsd.org; Tue, 12 Feb 2013 19:18:49 +0100 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 19:18:49 +0100 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 12 Feb 2013 19:18:49 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-net@freebsd.org From: Ivan Voras Subject: Re: Problems with two interfaces on the same subnet? Date: Tue, 12 Feb 2013 19:18:17 +0100 Lines: 45 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigBB25EC775143822EB582ED2A" X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:14.0) Gecko/20120812 Thunderbird/14.0 In-Reply-To: X-Enigmail-Version: 1.4.3 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:18:37 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBB25EC775143822EB582ED2A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/02/2013 19:10, Eggert, Lars wrote: > Hi, >=20 > On Feb 12, 2013, at 9:50, Ivan Voras wrote: >>> You can make this work with ipfw rules (and I guess also setfib, alth= ough I have not tried that.) >> >> The concept of FIBs looks clean and applicable but setfib works on new= ly >> started process, and I would need to do something like apply it to >> packets coming from an interface. >=20 > Assuming your default route is via igb2, you can do something like this= : >=20 > ipfw add fwd ip4 from = to not out >=20 > (From memory, no guarantees.) Ok, but both the clients and the server are on the same VLAN and use private, non-routable IP addresses so there is no "upstream router"...? --------------enigBB25EC775143822EB582ED2A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlEah2kACgkQ/QjVBj3/HSxHpACglErHyl42DNAiu5JuGue/6BEh OGgAn09a8XNGvB3dmH2v6KIhc2DMR2zp =DVT2 -----END PGP SIGNATURE----- --------------enigBB25EC775143822EB582ED2A-- From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 18:28:12 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CE8EAA9D for ; Tue, 12 Feb 2013 18:28:12 +0000 (UTC) (envelope-from scott4long@yahoo.com) Received: from nm23-vm1.bullet.mail.ne1.yahoo.com (nm23-vm1.bullet.mail.ne1.yahoo.com [98.138.91.50]) by mx1.freebsd.org (Postfix) with ESMTP id 8452C926 for ; Tue, 12 Feb 2013 18:28:12 +0000 (UTC) Received: from [98.138.226.177] by nm23.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 18:28:05 -0000 Received: from [98.138.84.40] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 18:28:05 -0000 Received: from [127.0.0.1] by smtp108.mail.ne1.yahoo.com with NNFMP; 12 Feb 2013 18:28:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360693685; bh=hblbWX95sR1EnoBTTkhr566grT7IA/S2GN8BuTSkt+0=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Content-Transfer-Encoding:Message-Id:References:To:X-Mailer; b=tlRuLcjJi/Mws8Xqeh1nFCEB6derxEPuLYvp4c3l9yqzzXRQV/rVvMhPbCa3LgHlDafx4ML0/5Q6+erVc4uXTOeHysx7+gOjlQdz3mzuoZk+4ayWeYGSTnDBeXd4JVC59JTftO+w4z2n4ryZ8alnlTQSgjqakmEzpDMCf1YTwPs= X-Yahoo-Newman-Id: 253025.38486.bm@smtp108.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: X8wL7BIVM1lmSxVvGKTSx8s3sk6__j30hbEmThsS2sIYzo6 jkEg4jivdFIXybXyVFkbiDuNOzuvfoPPy_A_Aad897Tt2mm8p6JOKKC2i3uR _0zi7tgglmoKwwGxx96omxL3weM4bdhGCq_fsXC9I.bm1XtalmRoEFBvdQ9v hCpey9vkddd2clCCsiCBT8hX10w20XddR10hq3AfHYjmL7l12VCEAAabrKlk t_we627x8sfZt7gqPSnn_mOlwMGa2NBZ.SsX5DW8n43Hra61.nH6Te.YrQkf XYV.Dz_p7m3FhgLjvlyOTSurc.SED2U.C4vz9wM9Ih2aQ72v21G3Eh2mZsT_ FVnKi818TJPpgW9_L7CjnUWRKYGTpHDXARROvrRAfpldM_eYwzugaDpjIDq5 .uU4fldhbmxvT1M5ATzhdlW8OOB_jeB_9_aQkF5z1G2RdLNuhATg4Z5XIVfH ygyne8_wYGRLA X-Yahoo-SMTP: clhABp.swBB7fs.LwIJpv3jkWgo2NU8- Received: from [10.64.24.202] (scott4long@69.53.237.126 with plain) by smtp108.mail.ne1.yahoo.com with SMTP; 12 Feb 2013 10:28:05 -0800 PST Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Problems with two interfaces on the same subnet? From: Scott Long In-Reply-To: Date: Tue, 12 Feb 2013 11:28:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ivan Voras X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 18:28:12 -0000 On Feb 12, 2013, at 11:06 AM, Ivan Voras wrote: > On 12/02/2013 18:57, Ivan Voras wrote: >> On 12/02/2013 18:52, Freddie Cash wrote: >>> Any reason you can't just use lagg(4) in one of the non-LACP modes? = That's >>> bascially designed to do exactly what you want. >>=20 >> No particular reason, I'm just not familiar enough with it. Will e.g. >> the "loadbalance" mode "just work" ? Should I expect any problems? >=20 > Actually, I know next to nothing about link aggregation. How do ARP > requests get solved? Would an attached L3-aware switch see the same IP > address on two ports? Since "loadbalance" chooses ports based on a = hash, > it will probably start dropping 50% of the outgoing traffic if one of > the two links dies? >=20 >=20 If you use simple load balancing, either via round-robin or hashed = flows, then yes, your switch will see 2 MAC addresses and a single IP. I believe = that in this scheme only one interface will respond to ARP requests, so peer hosts = won't get too confused, and if your switch is only capable of L2, everything will = work ok for transmit. I'm less clear on receive; maybe some L2 switches are smart = enough to detect this situation and balance incoming traffic, otherwise I can't = see how RX traffic to a single MAC could be split to other MACs. If your switch is L3 aware, then yes, the simple load balancing will = confuse it. However, if it's L3 aware then it's likely going to implement = standardize channel bonding, either in the form of legacy Etherchannel/FEC or more modern = LACP/802.3ad. LACP isn't perfect, and it's quite easy for links to physically be up = but logically be down, resulting in blackholed traffic, but it's better than FEC. I have = patched to made the FreeBSD LAGG/LACP code a little more reliable in this area, and I'll = be posting those patching in the coming few days. Scott From owner-freebsd-net@FreeBSD.ORG Tue Feb 12 21:51:48 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 8273EC57 for ; Tue, 12 Feb 2013 21:51:48 +0000 (UTC) (envelope-from jp@tns.cz) Received: from ns2.tns.cz (ns2.tns.cz [77.240.180.242]) by mx1.freebsd.org (Postfix) with ESMTP id 422603E2 for ; Tue, 12 Feb 2013 21:51:47 +0000 (UTC) Received: from Macintosh.local (unknown [77.240.180.51]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ns2.tns.cz (Postfix) with ESMTPSA id 11A2BD7A00F for ; Tue, 12 Feb 2013 22:43:58 +0100 (CET) Message-ID: <511AB7A0.6020506@tns.cz> Date: Tue, 12 Feb 2013 22:44:00 +0100 From: Josef Pojsl User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: freebsd-net@freebsd.org Subject: lacp on lagg interface: same speed, different media X-Enigmail-Version: 1.5 Content-Type: multipart/mixed; boundary="------------050700050103050000090502" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2013 21:51:48 -0000 This is a multi-part message in MIME format. --------------050700050103050000090502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hello list, on a FreeBSD 8.3-RELEASE-p3, I have come across a problem with lacp protocol on a lagg interface. I have aggregated two interfaces with the same speed but slightly different type of media (namely 10Gbase-SR and 10Gbase-LR). There is a Cisco switch on the other side. LACP won't work as my FreeBSD box computes the actor key differently for the two interfaces. This is weird as LACP inists on the same speed but not on the same exact type of media. Cisco has no problem having one aggregated interface Short and the other Long Range. Below, I have attached a tiny patch that changes the actor key computation so that only speed is important, not the exact media type. This patch works for me, LACP is ok with the Cisco box on the other side. Please could someone competent look at the patch and test or evaluate if it can be included in the code base. Thank you. Regards, Josef --------------050700050103050000090502 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="lacp-speed.patch" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="lacp-speed.patch" KioqIHN5cy9uZXQvaWVlZTgwMjNhZF9sYWNwLmMub3JpZwkyMDEzLTAyLTEyIDIxOjAzOjE2 LjAwMDAwMDAwMCArMDEwMAotLS0gc3lzL25ldC9pZWVlODAyM2FkX2xhY3AuYwkyMDEzLTAy LTEyIDIxOjEzOjM5LjAwMDAwMDAwMCArMDEwMAoqKioqKioqKioqKioqKioKKioqIDEwMjgs MTAzNSAqKioqCiAgCQlLQVNTRVJUKElGTV9UWVBFKG1lZGlhKSA9PSBJRk1fRVRIRVIsICgi aW52YWxpZCBtZWRpYSB0eXBlIikpOwogIAkJS0FTU0VSVCgobWVkaWEgJiBJRk1fRkRYKSAh PSAwLCAoImFnZ3JlZ2F0aW5nIEhEWCBpbnRlcmZhY2UiKSk7CiAgCiEgCQkvKiBiaXQgMC4u NDoJSUZNX1NVQlRZUEUgKi8KISAJCWtleSA9IHN1YnR5cGU7CiAgCQkvKiBiaXQgNS4uMTQ6 CShzb21lIGJpdHMgb2YpIGlmX2luZGV4IG9mIGxhZ2cgZGV2aWNlICovCiAgCQlrZXkgfD0g MHg3ZmUwICYgKChzYy0+c2NfaWZwLT5pZl9pbmRleCkgPDwgNSk7CiAgCQkvKiBiaXQgMTU6 CTAgKi8KLS0tIDEwMjgsMTA2MyAtLS0tCiAgCQlLQVNTRVJUKElGTV9UWVBFKG1lZGlhKSA9 PSBJRk1fRVRIRVIsICgiaW52YWxpZCBtZWRpYSB0eXBlIikpOwogIAkJS0FTU0VSVCgobWVk aWEgJiBJRk1fRkRYKSAhPSAwLCAoImFnZ3JlZ2F0aW5nIEhEWCBpbnRlcmZhY2UiKSk7CiAg CiEgCQkvKiBiaXQgMC4uNDoJSUZNX1NVQlRZUEUgbW9kdWxvIHNwZWVkICovCiEgCQlzd2l0 Y2ggKHN1YnR5cGUpIHsKISAJCWNhc2UgSUZNXzEwX1Q6CiEgCQljYXNlIElGTV8xMF8yOgoh IAkJY2FzZSBJRk1fMTBfNToKISAJCWNhc2UgSUZNXzEwX1NUUDoKISAJCWNhc2UgSUZNXzEw X0ZMOgohIAkJCWtleSA9IElGTV8xMF9UOyBicmVhazsKISAJCWNhc2UgSUZNXzEwMF9UWDoK ISAJCWNhc2UgSUZNXzEwMF9GWDoKISAJCWNhc2UgSUZNXzEwMF9UNDoKISAJCWNhc2UgSUZN XzEwMF9WRzoKISAJCWNhc2UgSUZNXzEwMF9UMjoKISAJCQlrZXkgPSBJRk1fMTAwX1RYOyBi cmVhazsKISAJCWNhc2UgSUZNXzEwMDBfU1g6CiEgCQljYXNlIElGTV8xMDAwX0xYOgohIAkJ Y2FzZSBJRk1fMTAwMF9DWDoKISAJCWNhc2UgSUZNXzEwMDBfVDoKISAJCQlrZXkgPSBJRk1f MTAwMF9TWDsgYnJlYWs7CiEgCQljYXNlIElGTV8xMEdfTFI6CiEgCQljYXNlIElGTV8xMEdf U1I6CiEgCQljYXNlIElGTV8xMEdfQ1g0OgohIAkJY2FzZSBJRk1fMTBHX1RXSU5BWDoKISAJ CWNhc2UgSUZNXzEwR19UV0lOQVhfTE9ORzoKISAJCWNhc2UgSUZNXzEwR19MUk06CiEgCQlj YXNlIElGTV8xMEdfVDoKISAJCQlrZXkgPSBJRk1fMTBHX0xSOyBicmVhazsKISAJCWRlZmF1 bHQ6CiEgCQkJa2V5ID0gc3VidHlwZTsKISAJCX0KICAJCS8qIGJpdCA1Li4xNDoJKHNvbWUg Yml0cyBvZikgaWZfaW5kZXggb2YgbGFnZyBkZXZpY2UgKi8KICAJCWtleSB8PSAweDdmZTAg JiAoKHNjLT5zY19pZnAtPmlmX2luZGV4KSA8PCA1KTsKICAJCS8qIGJpdCAxNToJMCAqLwo= --------------050700050103050000090502-- From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 00:00:46 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 7CFDCFDC for ; Wed, 13 Feb 2013 00:00:46 +0000 (UTC) (envelope-from lists@jnielsen.net) Received: from ns1.jnielsen.net (secure.freebsdsolutions.net [69.55.234.48]) by mx1.freebsd.org (Postfix) with ESMTP id 66727C3D for ; Wed, 13 Feb 2013 00:00:45 +0000 (UTC) Received: from [10.10.1.32] (office.betterlinux.com [199.58.199.60]) (authenticated bits=0) by ns1.jnielsen.net (8.14.4/8.14.4) with ESMTP id r1D00Z4W068607 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Feb 2013 19:00:37 -0500 (EST) (envelope-from lists@jnielsen.net) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Question: Why ain't I getting gigabit speed? From: John Nielsen In-Reply-To: <8112.1360454540@tristatelogic.com> Date: Tue, 12 Feb 2013 17:00:36 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8112.1360454540@tristatelogic.com> To: "Ronald F. Guilmette" X-Mailer: Apple Mail (2.1499) X-DCC-sonic.net-Metrics: ns1.jnielsen.net 1156; Body=2 Fuz1=2 Fuz2=2 X-Virus-Scanned: clamav-milter 0.97.5 at ns1.jnielsen.net X-Virus-Status: Clean Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 00:00:46 -0000 On Feb 9, 2013, at 5:02 PM, Ronald F. Guilmette = wrote: > P.S. While I appreciate all the friendly advice people here have = given > me, i.e. to go with a card based around some non-Realtek chip, I have = to > say that up until now I have always and consistantly had -zero- = problems > with the many other Realtek-based 10/100 cards that I have owned and = used. A bit OT, but I would say that this is _because_ of the FreeBSD driver = (rl, also by Bill Paul). Some of the hardware deficiencies documented in = the manpage and in comments in the if_rl.c are almost comical.. From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 01:05:16 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 962DED84 for ; Wed, 13 Feb 2013 01:05:16 +0000 (UTC) (envelope-from mikemacleod@gmail.com) Received: from mail-ia0-x22a.google.com (ia-in-x022a.1e100.net [IPv6:2607:f8b0:4001:c02::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 57516F84 for ; Wed, 13 Feb 2013 01:05:16 +0000 (UTC) Received: by mail-ia0-f170.google.com with SMTP id k20so688647iak.15 for ; Tue, 12 Feb 2013 17:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=SLwPotBl5oTGZI/GxPLCGEGjwTQrRx8ErQBCYkWuQyM=; b=tLuqlManh17TUS0LS55dxbt6PS2mEphTMPuqJBhhY/RVWEMqMfb8n+kQvmKSX5fJhW SjIJ/Rmaze2N+T5sjQcmopkdD21pWWimNMvC/atuwBGGRm7fMYe+OMgNuzj2A4d5wAxI 1ZNrhJO1GJ04+4TfzjVuPILuUhSdOF2W3GzXtRspL9lwz0TW+us70RibK5tKLrGWDgRd PnO0prMUWVB1UPD1VkIY93idIZYWoN5W3z1zdjumCTtaP2DArFKx/aFaMveEpKm/eQQE 7Ppm0OHDLiDVH3NsOd+65KRPz+S/UhoPWx8P5UfvsnZRU1X4+lOpQ/KfZexUXuS2EChu InWQ== X-Received: by 10.50.195.231 with SMTP id ih7mr7632631igc.55.1360717515843; Tue, 12 Feb 2013 17:05:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.93.5 with HTTP; Tue, 12 Feb 2013 17:04:55 -0800 (PST) In-Reply-To: References: <8112.1360454540@tristatelogic.com> From: Michael MacLeod Date: Tue, 12 Feb 2013 20:04:55 -0500 Message-ID: Subject: Re: Question: Why ain't I getting gigabit speed? To: John Nielsen Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 01:05:16 -0000 Since it deserved recognition, here's the bit from if_rl.c that John is referring to: * The RealTek 8139 PCI NIC redefines the meaning of 'low end.' This is * probably the worst PCI ethernet controller ever made, with the possible * exception of the FEAST chip made by SMC. The 8139 supports bus-master * DMA, but it has a terrible interface that nullifies any performance * gains that bus-master DMA usually offers. * * For transmission, the chip offers a series of four TX descriptor * registers. Each transmit frame must be in a contiguous buffer, aligned * on a longword (32-bit) boundary. This means we almost always have to * do mbuf copies in order to transmit a frame, except in the unlikely * case where a) the packet fits into a single mbuf, and b) the packet * is 32-bit aligned within the mbuf's data area. The presence of only * four descriptor registers means that we can never have more than four * packets queued for transmission at any one time. * * Reception is not much better. The driver has to allocate a single large * buffer area (up to 64K in size) into which the chip will DMA received * frames. Because we don't know where within this region received packets * will begin or end, we have no choice but to copy data from the buffer * area into mbufs in order to pass the packets up to the higher protocol * levels. Rock solid driver for a comically bad chipset. Thanks Bill! On Tue, Feb 12, 2013 at 7:00 PM, John Nielsen wrote: > On Feb 9, 2013, at 5:02 PM, Ronald F. Guilmette > wrote: > > > P.S. While I appreciate all the friendly advice people here have given > > me, i.e. to go with a card based around some non-Realtek chip, I have to > > say that up until now I have always and consistantly had -zero- problems > > with the many other Realtek-based 10/100 cards that I have owned and > used. > > A bit OT, but I would say that this is _because_ of the FreeBSD driver > (rl, also by Bill Paul). Some of the hardware deficiencies documented in > the manpage and in comments in the if_rl.c are almost comical.. > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 02:40:33 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E8EF293B for ; Wed, 13 Feb 2013 02:40:33 +0000 (UTC) (envelope-from wblock@wonkity.com) Received: from wonkity.com (wonkity.com [67.158.26.137]) by mx1.freebsd.org (Postfix) with ESMTP id 9D087337 for ; Wed, 13 Feb 2013 02:40:33 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.6/8.14.6) with ESMTP id r1D2eWlW039748; Tue, 12 Feb 2013 19:40:32 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.6/8.14.6/Submit) with ESMTP id r1D2eUsI039745; Tue, 12 Feb 2013 19:40:32 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Tue, 12 Feb 2013 19:40:29 -0700 (MST) From: Warren Block To: John Nielsen Subject: Re: Question: Why ain't I getting gigabit speed? In-Reply-To: Message-ID: References: <8112.1360454540@tristatelogic.com> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (wonkity.com [127.0.0.1]); Tue, 12 Feb 2013 19:40:32 -0700 (MST) Cc: freebsd-net@freebsd.org, "Ronald F. Guilmette" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 02:40:34 -0000 On Tue, 12 Feb 2013, John Nielsen wrote: > On Feb 9, 2013, at 5:02 PM, Ronald F. Guilmette wrote: > >> P.S. While I appreciate all the friendly advice people here have given >> me, i.e. to go with a card based around some non-Realtek chip, I have to >> say that up until now I have always and consistantly had -zero- problems >> with the many other Realtek-based 10/100 cards that I have owned and used. > > A bit OT, but I would say that this is _because_ of the FreeBSD driver > (rl, also by Bill Paul). Some of the hardware deficiencies documented > in the manpage and in comments in the if_rl.c are almost comical.. Yes, although those rl(4) cards are rare now. The newer re(4) cards are better, and built into many motherboards. From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 06:45:38 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4C620F4B for ; Wed, 13 Feb 2013 06:45:38 +0000 (UTC) (envelope-from xenophon+freebsd@irtnog.org) Received: from mx1.irtnog.org (rrcs-24-123-13-61.central.biz.rr.com [24.123.13.61]) by mx1.freebsd.org (Postfix) with ESMTP id 0017ADE2 for ; Wed, 13 Feb 2013 06:45:37 +0000 (UTC) Received: from cinep001bsdgw.irtnog.net (localhost [127.0.0.1]) by mx1.irtnog.org (Postfix) with ESMTP id 6228B1C548 for ; Wed, 13 Feb 2013 01:38:23 -0500 (EST) X-Virus-Scanned: amavisd-new at irtnog.org Received: from mx1.irtnog.org ([127.0.0.1]) by cinep001bsdgw.irtnog.net (mx1.irtnog.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ynm-Czra8FfS for ; Wed, 13 Feb 2013 01:38:16 -0500 (EST) Received: from cinip100ntsbs.irtnog.net (cinip100ntsbs.irtnog.net [10.63.1.100]) by mx1.irtnog.org (Postfix) with ESMTP for ; Wed, 13 Feb 2013 01:38:16 -0500 (EST) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: IPv6 over an IPsec tunnel X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 13 Feb 2013 01:38:13 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPv6 over an IPsec tunnel Thread-Index: Ac4JsnROTrm8ukUmSYyS4H7o53OXvg== From: "xenophon\\+freebsd" To: X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 06:45:38 -0000 I'm trying to run an IPsec tunnel between a Linux router and a FreeBSD router, but the FreeBSD router isn't passing any of the IPv6 traffic (IPv4 works perfectly). I have the following in /etc/ipsec.conf: spdadd 10.1.0.0/21 10.2.2.0/24 any -P out ipsec esp/tunnel/192.0.2.1-192.0.2.2/require ; spdadd 10.2.2.0/24 10.1.0.0/21 any -P in ipsec esp/tunnel/192.0.2.2-192.0.2.1/require ; spdadd 2001:1:1::/48 2001:2:2:2::/64 any -P out ipsec esp/tunnel/192.0.2.1-192.0.2.2/require ; spdadd 2001:2:2:2::/64 2001:1:1::/48 any -P in ipsec esp/tunnel/192.0.2.2-192.0.2.1/require ; When I try to ping an IPv6 host through the tunnel in either direction, I'm seeing the packet on the FreeBSD router's enc0 device, but I get the following error on the FreeBSD router's console: ipsec6_output_tunnel: family mismatched between inner and outer, spi=3D49961579 ip6_output (ipsec): error code 47 I found the error message in src/sys/netipsec/ipsec_output.c (r245225, line 833). I guess that I assumed that one could tunnel IPv6 over an IPv4 IPsec tunnel. Is this not the case? Will I have to encapsulate the IPv6 traffic in an IPIP or GRE tunnel? I don't want to build an IPv6 IPsec tunnel, because I connect to the IPv6 Internet through a tunnel broker. The latency and encapsulation overhead would be too much for my purposes. I noticed a PR by someone who got the same error message: http://www.freebsd.org/cgi/query-pr.cgi?pr=3D147894&cat=3Dkern --=20 I FIGHT FOR THE USERS From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 08:32:43 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 14F02964; Wed, 13 Feb 2013 08:32:43 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 9E6622A8; Wed, 13 Feb 2013 08:32:42 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 644FA7E81E; Wed, 13 Feb 2013 19:25:20 +1100 (EST) Message-ID: <511B4DEF.8000500@freebsd.org> Date: Wed, 13 Feb 2013 19:25:19 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: John Baldwin Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> In-Reply-To: <201301221511.02496.jhb@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 08:32:43 -0000 FYI I've read the whole thread as of this reply and plan to follow up to a few of the other posts separately, but first for my initial thoughts... On 01/23/13 07:11, John Baldwin wrote: > As I mentioned in an earlier thread, I recently had to debug an issue we were > seeing across a link with a high bandwidth-delay product (both high bandwidth > and high RTT). Our specific use case was to use a TCP connection to reliably > forward a latency-sensitive datagram stream across a WAN connection. We would > often see spikes in the latency of individual datagrams. I eventually tracked > this down to the connection entering slow start when it would transmit data > after being idle. The data stream was quite bursty and would often attempt to > transmit a burst of data after being idle for far longer than a retransmit > timeout. Got it. > In 7.x we had worked around this in the past by disabling RFC 3390 and jacking > the slow start window size up via a sysctl. On 8.x this no longer worked. I can't think of, nor have I read any convincing argument why we shouldn't support your use case out of the box. You're not the only user of FreeBSD over dedicated lines who knows what you're doing. We should provide some way to support this use case. We're therefore left with the question of how to implement this. As noted in the "Some questions about the new TCP congestion control code" thread [1], it was always my intention to axe the ss_flightsize variables and replace them with a better mechanism. Andre swung the axe before I did and 10.x is looming so it's a good time to discuss all of this. > The solution I came up with was to add a new socket option to disable idle > handling completely. That is, when an idle connection restarts with this new > option enabled, it keeps its current congestion window and doesn't enter slow > start. rwatson@ mentioned an idea in private discussion which I've also thought about over the years. The real goal here should be to subsume your use case (and others) into a much richer framework for hinting desired behaviour/tradeoff preferences (some aspects of which relate to parts of my PhD work, which will hopefully be coming to a kernel near you in 2013 ;). My main concern with your patch is that I'm a bit uneasy about enshrining a socket option in a public API and documentation that is so specific. I suspect apps probably want to set higher level goals like "low latency *at any cost*" and have the stack opaquely interpret that as "this guy is willing to blow his foot off, so let's disable idle window reset, tweak X, disable Y and hand the man his loaded shotgun". TCP_IGNOREIDLE as currently proposed misses this bigger picture, though doesn't preclude it either. I would also echo Kevin/Grenville's thoughts about keying the socket option's activation off a tunable (sysctl or kernel option is up for discussion, though I'd be leaning towards sysctl) that is disabled by default i.e. only skip after idle window reset if the app sets the option *and* the sysadmin has pulled the "I like me some bursty network" lever. > There are only a few cases where such an option is useful, but if anyone else > thinks this might be useful I'd be happy to add the option to FreeBSD. The idea is useful. I'd just like to discuss the implementation specifics a little further before recommending whether the patch should go in as is to provide a stop gap, or we rework the patch to be a little less specific in readiness for the future work I have in mind. Cheers, Lawrence [1] http://lists.freebsd.org/pipermail/freebsd-net/2013-January/034297.html From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 10:27:24 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 32297B48 for ; Wed, 13 Feb 2013 10:27:24 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id A89A0952 for ; Wed, 13 Feb 2013 10:27:23 +0000 (UTC) Received: (qmail 43691 invoked from network); 13 Feb 2013 11:44:52 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Feb 2013 11:44:52 -0000 Message-ID: <511B6A87.5060000@freebsd.org> Date: Wed, 13 Feb 2013 11:27:19 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> In-Reply-To: <511B4DEF.8000500@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 10:27:24 -0000 On 13.02.2013 09:25, Lawrence Stewart wrote: > FYI I've read the whole thread as of this reply and plan to follow up to > a few of the other posts separately, but first for my initial thoughts... > > On 01/23/13 07:11, John Baldwin wrote: >> As I mentioned in an earlier thread, I recently had to debug an issue we were >> seeing across a link with a high bandwidth-delay product (both high bandwidth >> and high RTT). Our specific use case was to use a TCP connection to reliably >> forward a latency-sensitive datagram stream across a WAN connection. We would >> often see spikes in the latency of individual datagrams. I eventually tracked >> this down to the connection entering slow start when it would transmit data >> after being idle. The data stream was quite bursty and would often attempt to >> transmit a burst of data after being idle for far longer than a retransmit >> timeout. > > Got it. > >> In 7.x we had worked around this in the past by disabling RFC 3390 and jacking >> the slow start window size up via a sysctl. On 8.x this no longer worked. > > I can't think of, nor have I read any convincing argument why we > shouldn't support your use case out of the box. You're not the only user > of FreeBSD over dedicated lines who knows what you're doing. We should > provide some way to support this use case. > > We're therefore left with the question of how to implement this. > > As noted in the "Some questions about the new TCP congestion control > code" thread [1], it was always my intention to axe the ss_flightsize > variables and replace them with a better mechanism. Andre swung the axe > before I did and 10.x is looming so it's a good time to discuss all of this. > >> The solution I came up with was to add a new socket option to disable idle >> handling completely. That is, when an idle connection restarts with this new >> option enabled, it keeps its current congestion window and doesn't enter slow >> start. > > rwatson@ mentioned an idea in private discussion which I've also thought > about over the years. The real goal here should be to subsume your use > case (and others) into a much richer framework for hinting desired > behaviour/tradeoff preferences (some aspects of which relate to parts of > my PhD work, which will hopefully be coming to a kernel near you in 2013 ;). > > My main concern with your patch is that I'm a bit uneasy about > enshrining a socket option in a public API and documentation that is so > specific. I suspect apps probably want to set higher level goals like > "low latency *at any cost*" and have the stack opaquely interpret that > as "this guy is willing to blow his foot off, so let's disable idle > window reset, tweak X, disable Y and hand the man his loaded shotgun". > TCP_IGNOREIDLE as currently proposed misses this bigger picture, though > doesn't preclude it either. > > I would also echo Kevin/Grenville's thoughts about keying the socket > option's activation off a tunable (sysctl or kernel option is up for > discussion, though I'd be leaning towards sysctl) that is disabled by > default i.e. only skip after idle window reset if the app sets the > option *and* the sysadmin has pulled the "I like me some bursty network" > lever. > >> There are only a few cases where such an option is useful, but if anyone else >> thinks this might be useful I'd be happy to add the option to FreeBSD. > > The idea is useful. I'd just like to discuss the implementation > specifics a little further before recommending whether the patch should > go in as is to provide a stop gap, or we rework the patch to be a little > less specific in readiness for the future work I have in mind. Again I'd like to point out that this sort of modification should be implemented as a congestion control module. All the hook points are already there and can readily be used instead of adding more special cases to the generic part of TCP. The CC algorithm can be selected per socket. For such a special CC module it'd get a nice fat warning that it is not suitable for Internet use. Additionally I speculate that for the use-case of John he may also be willing to forgo congestion avoidance and always operate in (ill-named) "slow start" mode. With a special CC module this can easily be tweaked. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 13:46:27 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DDC5E829; Wed, 13 Feb 2013 13:46:27 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 70DC02DB; Wed, 13 Feb 2013 13:46:27 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 84DC47E81E; Thu, 14 Feb 2013 00:46:24 +1100 (EST) Message-ID: <511B9930.8020503@freebsd.org> Date: Thu, 14 Feb 2013 00:46:24 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: George Neville-Neil Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Alfred Perlstein , Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 13:46:27 -0000 On 02/08/13 07:04, George Neville-Neil wrote: > > On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote: > >> On 2/6/13 4:46 AM, John Baldwin wrote: >>> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote: >>>> John: >>>> >>>> A burst at line rate will *often* cause drops. This is because >>>> router queues are at a finite size. Also such a burst (especially >>>> on a long delay bandwidth network) cause your RTT to increase even >>>> if there is no drop which is going to hurt you as well. >>>> >>>> A SHOULD in an RFC says you really really really really need to do it >>>> unless there is some thing that makes you willing to override it. It is >>>> slight wiggle room. >>>> >>>> In this I agree with Andre, we should not be *not* doing it. Otherwise >>>> folks will be turning this on and it is plain wrong. It may be fine >>>> for your network but I would not want to see it in FreeBSD. >>>> >>>> In my testing here at home I have put back into our stack max-burst. This >>>> uses Mark Allman's version (not Kacheong Poon's) where you clamp the cwnd at >>>> no more than 4 packets larger than your flight. All of my testing >>>> high-bw-delay or lan has shown this to improve TCP performance. This >>>> is because it helps you avoid bursting out so many packets that you overflow >>>> a queue. >>>> >>>> In your long-delay bw link if you do burst out too many (and you never >>>> know how many that is since you can not predict how full all those >>>> MPLS queues are or how big they are) you will really hurt yourself even worse. >>>> Note that generally in Cisco routers the default queue size is somewhere between >>>> 100-300 packets depending on the router. >>> Due to the way our application works this never happens, but I am fine with >>> just keeping this patch private. If there are other shops that need this they >>> can always dig the patch up from the archives. >>> >> This is yet another time when I'm sad about how things happen in FreeBSD. >> >> A developer come forward with a non-default option that's very useful for some specific workloads, specifically one that contributes much time and $$$ to the project and the community rejects the patches even though it's been successful in other OSes. >> >> It makes zero sense. >> >> John, can you repost the patch? Maybe there is a way to refactor this somehow so it's like accept filters where we can plug in a hook for TCP? >> >> I am very disappointed, but not surprised. >> > > I take away the complete opposite feeling. This is how we work through these issues. > It's clear from the discussion that this need not be a default in the system, > and is a special case. We had a reasoned discussion of what would be best to do > and at least two experts in TCP weighed in on the effect this change might have. > > Not everything proposed by a developer need go into the tree, in particular since these > discussions are archived we can always revisit this later. > > This is exactly how collaborative development should look, whether or not the patch > is integrated now, next week, next year, or ever. +1 Whilst I would argue that some red herrings have been put forward in this thread, its progression is far from disappointing IMO. This is a sensitive area that requires careful scrutiny, independent of what our peers working on other OSes have decided is best for them. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 14:01:23 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CC511157; Wed, 13 Feb 2013 14:01:23 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id 3B8C03E5; Wed, 13 Feb 2013 14:01:23 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 11C387E824; Thu, 14 Feb 2013 01:01:21 +1100 (EST) Message-ID: <511B9CB0.4090906@freebsd.org> Date: Thu, 14 Feb 2013 01:01:20 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Kevin Oberman Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <50FF06AD.402@networx.ch> <061B4EA5-6A93-48A0-A269-C2C3A3C7E77C@lakerest.net> <201302060746.43736.jhb@freebsd.org> <511292C9.4040307@mu.org> <51166019.9040104@mu.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Alfred Perlstein , Randall Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:01:23 -0000 On 02/10/13 16:05, Kevin Oberman wrote: > On Sat, Feb 9, 2013 at 6:41 AM, Alfred Perlstein wrote: >> On 2/7/13 12:04 PM, George Neville-Neil wrote: >>> >>> On Feb 6, 2013, at 12:28 , Alfred Perlstein wrote: >>> >>>> On 2/6/13 4:46 AM, John Baldwin wrote: >>>>> >>>>> On Wednesday, February 06, 2013 6:27:04 am Randall Stewart wrote: >>>>>> >>>>>> John: >>>>>> >>>>>> A burst at line rate will *often* cause drops. This is because >>>>>> router queues are at a finite size. Also such a burst (especially >>>>>> on a long delay bandwidth network) cause your RTT to increase even >>>>>> if there is no drop which is going to hurt you as well. >>>>>> >>>>>> A SHOULD in an RFC says you really really really really need to do it >>>>>> unless there is some thing that makes you willing to override it. It is >>>>>> slight wiggle room. >>>>>> >>>>>> In this I agree with Andre, we should not be *not* doing it. Otherwise >>>>>> folks will be turning this on and it is plain wrong. It may be fine >>>>>> for your network but I would not want to see it in FreeBSD. >>>>>> >>>>>> In my testing here at home I have put back into our stack max-burst. >>>>>> This >>>>>> uses Mark Allman's version (not Kacheong Poon's) where you clamp the >>>>>> cwnd at >>>>>> no more than 4 packets larger than your flight. All of my testing >>>>>> high-bw-delay or lan has shown this to improve TCP performance. This >>>>>> is because it helps you avoid bursting out so many packets that you >>>>>> overflow >>>>>> a queue. >>>>>> >>>>>> In your long-delay bw link if you do burst out too many (and you never >>>>>> know how many that is since you can not predict how full all those >>>>>> MPLS queues are or how big they are) you will really hurt yourself even >>>>>> worse. >>>>>> Note that generally in Cisco routers the default queue size is >>>>>> somewhere between >>>>>> 100-300 packets depending on the router. >>>>> >>>>> Due to the way our application works this never happens, but I am fine >>>>> with >>>>> just keeping this patch private. If there are other shops that need >>>>> this they >>>>> can always dig the patch up from the archives. >>>>> >>>> This is yet another time when I'm sad about how things happen in FreeBSD. >>>> >>>> A developer come forward with a non-default option that's very useful for >>>> some specific workloads, specifically one that contributes much time and $$$ >>>> to the project and the community rejects the patches even though it's been >>>> successful in other OSes. >>>> >>>> It makes zero sense. >>>> >>>> John, can you repost the patch? Maybe there is a way to refactor this >>>> somehow so it's like accept filters where we can plug in a hook for TCP? >>>> >>>> I am very disappointed, but not surprised. >>>> >>> I take away the complete opposite feeling. This is how we work through >>> these issues. >>> It's clear from the discussion that this need not be a default in the >>> system, >>> and is a special case. We had a reasoned discussion of what would be best >>> to do >>> and at least two experts in TCP weighed in on the effect this change might >>> have. >>> >>> Not everything proposed by a developer need go into the tree, in >>> particular since these >>> discussions are archived we can always revisit this later. >>> >>> This is exactly how collaborative development should look, whether or not >>> the patch >>> is integrated now, next week, next year, or ever. >> >> >> I agree that discussion is great, we have all learned quite a bit from it, >> about TCP and the dangers of adjusting buffering without considerable >> thought. I would not be involved in FreeBSD had this type of discussion and >> information not be discussed on the lists so readily. >> >> However, the end result must be far different than what has occurred so far. >> >> If the code was deemed unacceptable for general inclusion, then we must find >> a way to provide a light framework to accomplish the needs of the community >> member. >> >> Take for instance someone who is starting a company that needs this >> facility. Which OS will they choose? One who has integrated a useful >> feature? Or one who has rejected it and left that code in the mailing list >> archives? >> >> As much as expert opinion is valuable, it must include understanding and >> need of handling special cases and the ability to facilitate those special >> cases for our users and developers. > > This is a subject rather near to my heart, having fought battles with > congestion back in the dark days of Windows when it essentially > defaulted to TCPIGNOREIDLE. It was a huge pain, but it was the only > way Windows did TCP in the early days. It simply did not implement > slow-start. This was really evil, but in the days when lots of links > were 56K and T-1 was mostly used for network core links, the Internet, > small as it was back then, did not melt, though it glowed a > frightening shade of red fairly often. Today too many systems running > like this would melt thins very quickly. > > OTOH, I can certainly see cases, like John's, where it would be very > beneficial. And, yes, Linux has it. (I don't see this a relevant in > any way except as proof tat not enough people have turned it on to > cause serious problems... yet!) It seems a shame to make everyone who > really has a need develop their own patches or dig though old mail to > find John's. > > What I would like to see is a way to have it available, but make it > unlikely to be enabled except in a way that would put up flashing red > warnings and sound sirens to warn people that it is very dangerous and > can be a way to blow off a few of one's own toes. > > One idea that popped into my head (and may be completely ridiculous, > is to make its availability dependent on a kernel option and have > warning in NOTES about it contravening normal and accepted practice > and that it can cause serious problems both for yourself and for > others using the network. Agreed. A sysctl as suggested by Grenville might be sufficient though. Requiring a full kernel recompile seems a bit draconian. > I might also note that almost all higher performance (1G and faster) > networks already have a form of this...TSO. In case you hadn't > noticed, TSO will take a large buffer and transmit it as multiple > segments which are transmitted back to back with NO delay or awareness > of congestion. I can confirm that even this limited case can and does > sometimes result in packet loss when router queues are inadequate to > handle the load. You nailed it - took the words right off my finger tips. Sure, a flow's cwnd can exceed the TSO max chunk size by an order of magnitude, but the fact remains that we live in a bursty world already. As much as I dislike TSO in its current incarnation, it exists for good reason. We need to provide useful tools, thorough documentation and set sensible defaults. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 14:26:41 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 69A4F742; Wed, 13 Feb 2013 14:26:41 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id CB8F4747; Wed, 13 Feb 2013 14:26:40 +0000 (UTC) Received: from lstewart1.loshell.room52.net (ppp59-167-184-191.static.internode.on.net [59.167.184.191]) by lauren.room52.net (Postfix) with ESMTPSA id 091537E81E; Thu, 14 Feb 2013 01:26:39 +1100 (EST) Message-ID: <511BA29E.5050501@freebsd.org> Date: Thu, 14 Feb 2013 01:26:38 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120613 Thunderbird/13.0 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> In-Reply-To: <511B6A87.5060000@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:26:41 -0000 On 02/13/13 21:27, Andre Oppermann wrote: > On 13.02.2013 09:25, Lawrence Stewart wrote: >> FYI I've read the whole thread as of this reply and plan to follow up to >> a few of the other posts separately, but first for my initial thoughts... >> >> On 01/23/13 07:11, John Baldwin wrote: >>> As I mentioned in an earlier thread, I recently had to debug an issue >>> we were >>> seeing across a link with a high bandwidth-delay product (both high >>> bandwidth >>> and high RTT). Our specific use case was to use a TCP connection to >>> reliably >>> forward a latency-sensitive datagram stream across a WAN connection. >>> We would >>> often see spikes in the latency of individual datagrams. I >>> eventually tracked >>> this down to the connection entering slow start when it would >>> transmit data >>> after being idle. The data stream was quite bursty and would often >>> attempt to >>> transmit a burst of data after being idle for far longer than a >>> retransmit >>> timeout. >> >> Got it. >> >>> In 7.x we had worked around this in the past by disabling RFC 3390 >>> and jacking >>> the slow start window size up via a sysctl. On 8.x this no longer >>> worked. >> >> I can't think of, nor have I read any convincing argument why we >> shouldn't support your use case out of the box. You're not the only user >> of FreeBSD over dedicated lines who knows what you're doing. We should >> provide some way to support this use case. >> >> We're therefore left with the question of how to implement this. >> >> As noted in the "Some questions about the new TCP congestion control >> code" thread [1], it was always my intention to axe the ss_flightsize >> variables and replace them with a better mechanism. Andre swung the axe >> before I did and 10.x is looming so it's a good time to discuss all of >> this. >> >>> The solution I came up with was to add a new socket option to disable >>> idle >>> handling completely. That is, when an idle connection restarts with >>> this new >>> option enabled, it keeps its current congestion window and doesn't >>> enter slow >>> start. >> >> rwatson@ mentioned an idea in private discussion which I've also thought >> about over the years. The real goal here should be to subsume your use >> case (and others) into a much richer framework for hinting desired >> behaviour/tradeoff preferences (some aspects of which relate to parts of >> my PhD work, which will hopefully be coming to a kernel near you in >> 2013 ;). >> >> My main concern with your patch is that I'm a bit uneasy about >> enshrining a socket option in a public API and documentation that is so >> specific. I suspect apps probably want to set higher level goals like >> "low latency *at any cost*" and have the stack opaquely interpret that >> as "this guy is willing to blow his foot off, so let's disable idle >> window reset, tweak X, disable Y and hand the man his loaded shotgun". >> TCP_IGNOREIDLE as currently proposed misses this bigger picture, though >> doesn't preclude it either. >> >> I would also echo Kevin/Grenville's thoughts about keying the socket >> option's activation off a tunable (sysctl or kernel option is up for >> discussion, though I'd be leaning towards sysctl) that is disabled by >> default i.e. only skip after idle window reset if the app sets the >> option *and* the sysadmin has pulled the "I like me some bursty network" >> lever. >> >>> There are only a few cases where such an option is useful, but if >>> anyone else >>> thinks this might be useful I'd be happy to add the option to FreeBSD. >> >> The idea is useful. I'd just like to discuss the implementation >> specifics a little further before recommending whether the patch should >> go in as is to provide a stop gap, or we rework the patch to be a little >> less specific in readiness for the future work I have in mind. > > Again I'd like to point out that this sort of modification should > be implemented as a congestion control module. All the hook points > are already there and can readily be used instead of adding more special > cases to the generic part of TCP. The CC algorithm can be selected per > socket. For such a special CC module it'd get a nice fat warning that > it is not suitable for Internet use. As a local hack, sure, a CC module would do the job assuming you were happy to use a single algorithm as the base. John's patch transcends the algorithm in use on a particular connection, so it has wider applicability than a CC module. I would also strongly oppose the inclusion of such a module in FreeBSD proper - it's the wrong way to implement the functionality. The patch as posted is technically appropriate, though I'm interested in discussing whether the public API should be tweaked to capture higher level goals instead e.g. "low delay at all costs" or "maximum throughput". We could initially map "low delay at all costs" to a TCP stack meaning of "disable idle window reset" and expand the meaning later (e.g. relaxing the silly window checks as briefly discussed in the other thread). > Additionally I speculate that for the use-case of John he may also be > willing to forgo congestion avoidance and always operate in (ill-named) > "slow start" mode. With a special CC module this can easily be tweaked. John already has the functionality he needs in this local tree - this discussion is no longer about John per se, but rather about other people who may want the functionality John has implemented. We need to figure out how to provide the functionality in FreeBSD proper, and a CC module is not the answer. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 14:49:08 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 08F21CA6 for ; Wed, 13 Feb 2013 14:49:08 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 5C515807 for ; Wed, 13 Feb 2013 14:49:06 +0000 (UTC) Received: (qmail 44487 invoked from network); 13 Feb 2013 16:06:28 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 13 Feb 2013 16:06:28 -0000 Message-ID: <511BA7D9.3050709@freebsd.org> Date: Wed, 13 Feb 2013 15:48:57 +0100 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Lawrence Stewart Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> In-Reply-To: <511BA29E.5050501@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 14:49:08 -0000 On 13.02.2013 15:26, Lawrence Stewart wrote: > On 02/13/13 21:27, Andre Oppermann wrote: >> On 13.02.2013 09:25, Lawrence Stewart wrote: >>> The idea is useful. I'd just like to discuss the implementation >>> specifics a little further before recommending whether the patch should >>> go in as is to provide a stop gap, or we rework the patch to be a little >>> less specific in readiness for the future work I have in mind. >> >> Again I'd like to point out that this sort of modification should >> be implemented as a congestion control module. All the hook points >> are already there and can readily be used instead of adding more special >> cases to the generic part of TCP. The CC algorithm can be selected per >> socket. For such a special CC module it'd get a nice fat warning that >> it is not suitable for Internet use. > > As a local hack, sure, a CC module would do the job assuming you were > happy to use a single algorithm as the base. John's patch transcends the > algorithm in use on a particular connection, so it has wider > applicability than a CC module. The algorithm is becoming somewhat meaningless when your goal is to have an open pipe and push data as fast as possible without regard to other traffic. NewReno, Cubic and what have you is becoming meaningless. > I would also strongly oppose the inclusion of such a module in FreeBSD > proper - it's the wrong way to implement the functionality. The patch as > posted is technically appropriate, though I'm interested in discussing > whether the public API should be tweaked to capture higher level goals > instead e.g. "low delay at all costs" or "maximum throughput". I strongly disagree. The patch is a hack. From the description John gave on his use-case I read that he would actually take more than just ignoring idle-cwnd-reset. And actually if I were in his situation I would use a very aggressive congestion control algorithm doing away with more than idle-cwnd-reset. > We could initially map "low delay at all costs" to a TCP stack meaning > of "disable idle window reset" and expand the meaning later (e.g. > relaxing the silly window checks as briefly discussed in the other thread). Ugh, if you go that far fork it, obtain a fresh protocol number and don't call it TCP anymore. >> Additionally I speculate that for the use-case of John he may also be >> willing to forgo congestion avoidance and always operate in (ill-named) >> "slow start" mode. With a special CC module this can easily be tweaked. > > John already has the functionality he needs in this local tree - this > discussion is no longer about John per se, but rather about other people > who may want the functionality John has implemented. That's what I'm worried most about. So far no real "other people" have spoken out, only cheering from the sidelines. > We need to figure out how to provide the functionality in FreeBSD > proper, and a CC module is not the answer. I totally disagree. This functionality (removal) is not at all a part of TCP and should not be supported directly. -- Andre From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 16:00:49 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 5EC301D2; Wed, 13 Feb 2013 16:00:49 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 3984BC31; Wed, 13 Feb 2013 16:00:49 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1DG0nIV085726; Wed, 13 Feb 2013 16:00:49 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1DG0nUV085722; Wed, 13 Feb 2013 16:00:49 GMT (envelope-from linimon) Date: Wed, 13 Feb 2013 16:00:49 GMT Message-Id: <201302131600.r1DG0nUV085722@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176097: [lagg] [patch] lagg/lacp broken when aggregated interfaces have same speed but different media type X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:00:49 -0000 Old Synopsis: lagg/lacp broken when aggregated interfaces have same speed but different media type New Synopsis: [lagg] [patch] lagg/lacp broken when aggregated interfaces have same speed but different media type Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Feb 13 16:00:22 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176097 From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 16:28:50 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A4129F5C for ; Wed, 13 Feb 2013 16:28:50 +0000 (UTC) (envelope-from kevin@your.org) Received: from mail.your.org (mail.your.org [IPv6:2001:4978:1:2::cc09:3717]) by mx1.freebsd.org (Postfix) with ESMTP id 7EA39E72 for ; Wed, 13 Feb 2013 16:28:50 +0000 (UTC) Received: from mail.your.org (chi02.mail.your.org [204.9.55.23]) by mail.your.org (Postfix) with ESMTP id EBDCFF06C4E; Wed, 13 Feb 2013 16:28:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s= selector1; bh=TXDjlaVPaeKVppVUmo0k4uvzm9o=; b=3kZh1d2yc6SSl2/Q3I Wse3qnzmNjt6lpe82Ccg+jGNiPTFKT03J58BYkIsf2WE09W+mQsGqkDqvUjEeNdq XVTARtWrJ1EebUGuwHuJtGvb8k802LcRZvKLWNIQLejEXPB7pfGx2M+RT28s6LEd BZoaBwwp+s3zsWTXaL/fN+gMw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=your.org; h=content-type :mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; q=dns; s= selector1; b=HWSQ7IhDX5vOtLAXOafpYFuCUs4Q/zCdeNZsQiPJNNx0UyFhgci jLR24DV/LJ0J8sY4+bSBKApvmxJbqioiIiPIBjaQQ2vMt91vnEIYc0DgWHO/AEqk kNNsMkzVMhZR0QsNYqCBm75ihGyL+1Ep/pU5cfWCSS6+WItK2uHA+3BI= Received: from vpn132.rw1.your.org (vpn132.rw1.your.org [204.9.51.132]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.your.org (Postfix) with ESMTPSA id 8AE3FF06C36; Wed, 13 Feb 2013 16:28:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: lacp on lagg interface: same speed, different media From: Kevin Day In-Reply-To: <511AB7A0.6020506@tns.cz> Date: Wed, 13 Feb 2013 10:28:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <0C4010B3-C317-4510-B277-9BD768DF5344@your.org> References: <511AB7A0.6020506@tns.cz> To: Josef Pojsl X-Mailer: Apple Mail (2.1499) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 16:28:50 -0000 On Feb 12, 2013, at 3:44 PM, Josef Pojsl wrote: > Hello list, >=20 > on a FreeBSD 8.3-RELEASE-p3, I have come across a problem with lacp > protocol on a lagg interface. I have aggregated two interfaces with = the > same speed but slightly different type of media (namely 10Gbase-SR and > 10Gbase-LR). There is a Cisco switch on the other side. >=20 > LACP won't work as my FreeBSD box computes the actor key differently = for > the two interfaces. This is weird as LACP inists on the same speed but > not on the same exact type of media. Cisco has no problem having one > aggregated interface Short and the other Long Range. >=20 > Below, I have attached a tiny patch that changes the actor key > computation so that only speed is important, not the exact media type. > This patch works for me, LACP is ok with the Cisco box on the other > side. Please could someone competent look at the patch and test or > evaluate if it can be included in the code base. Thank you. >=20 I believe this is intentional behavior. My understanding is that 802.3ad = requires that the media types be *identical*. The logic is that if you = advertise multiple ports under the same key, any port on one side can be = physically connected to any port on the other side.=20 I'm not sure how important strict compliance v.s. making it actually = work is here, and I tend to agree that this is overly picky, and I can't = think of anything except seriously contrived instances where this would = matter. I also think most vendors have agreed with this and have = stopped caring about it. (sometimes requiring a knob to be changed) From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 18:37:54 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 9AEBD558; Wed, 13 Feb 2013 18:37:54 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by mx1.freebsd.org (Postfix) with ESMTP id C0C0088B; Wed, 13 Feb 2013 18:37:53 +0000 (UTC) Received: by mail-we0-f181.google.com with SMTP id t44so1258374wey.12 for ; Wed, 13 Feb 2013 10:37:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=F/vkrkgr+YDTI5/tM/T7TO0B639XDYvG4zmOC3S1d8Y=; b=J8HdYiTl2dUCUFxOE4KMETFfbQnjfphl4u3QxindgP7bQuCZJQ4vHCg7VOs/TF2j2p C3kGVxwUL8FivA/BPvWRZ82YVLnENIyRl7flgwLUhpwrNUGVm4JjcAoKlwTseZztENBe MsT16IzJJCOWhSn9lO7USvWZjaviusAUq8q/RA7w9bHS/ivdnm3G62Zle8ceRdtFPN3X daD2NZZ1fEsgdh4YNHUnrf40PbqRgI/qedixlUn50MJJS3P6NNe/c4/ru7EKXJbCdEa6 0fcuCQLwvBJcZ8vjHI1Z8n/t6Z1bIIs1cX0BnSkRZBbwes3zcUIO/CEFL8mGEbH0GURZ 1ljg== MIME-Version: 1.0 X-Received: by 10.194.161.135 with SMTP id xs7mr40180707wjb.41.1360780672062; Wed, 13 Feb 2013 10:37:52 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 13 Feb 2013 10:37:51 -0800 (PST) In-Reply-To: <511B6A87.5060000@freebsd.org> References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> Date: Wed, 13 Feb 2013 10:37:51 -0800 X-Google-Sender-Auth: HOGjc5jmeggVz5EVsGVZYjwM4Tc Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: Lawrence Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:37:54 -0000 On 13 February 2013 02:27, Andre Oppermann wrote: > Again I'd like to point out that this sort of modification should > be implemented as a congestion control module. All the hook points > are already there and can readily be used instead of adding more special > cases to the generic part of TCP. The CC algorithm can be selected per > socket. For such a special CC module it'd get a nice fat warning that > it is not suitable for Internet use. > > Additionally I speculate that for the use-case of John he may also be > willing to forgo congestion avoidance and always operate in (ill-named) > "slow start" mode. With a special CC module this can easily be tweaked. There are some cute things that could be done here - eg, having an L3 route table entry map to a congestion control (like having an MSS in the L3 entry too.) But I'd love to see some modelling / data showing competing congestion control algorithms on the same set of congested pipes. Doubly so on multiple congested pipes (ie, modelling a handful of parallel user<->last-mile<->IX<->various transit feeds with different levels of congestion/RTT<->IX<->last mile<->user connections.) You all know much more about this than I do. :-) Thanks, Adrian From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 18:38:31 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 4E04975B; Wed, 13 Feb 2013 18:38:31 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by mx1.freebsd.org (Postfix) with ESMTP id 6A96A8A3; Wed, 13 Feb 2013 18:38:30 +0000 (UTC) Received: by mail-we0-f170.google.com with SMTP id z53so1339217wey.1 for ; Wed, 13 Feb 2013 10:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=VcqmG0OANTjv1fOOk/9XYtK0U2Dn3MwXdUymEjOAv18=; b=09hKbODsqi4aMwbxJQG7rBZ0u+FGeCGEidS+8/g0jXfg6rNSc6kxaZXNkWEeUH+xCy PwT/LgG0b4v4n5zZLTlzdq+6yuXgyfnirXnDwJLJos9a4z2pGuxvLhxYde9IzBQaH84V RD6i9gmkcWc8qJM7ADFRopq1QYj7SARgXrkAgfne0WfQdVsO7WfnUEZXoPAtiqrscj/Y pmVZxnwOezdg8xPFphAaZ5349+QzAvZoNJp0I9eE2JToEBHdHCPL1q1et759+WmS47ZO 8VkLt+aY46r+2hr92hhp8TN1H46XoNc1DWHhnnNs0YZZyYAMrhTvNdzttioZF+DZUwNQ iyUw== MIME-Version: 1.0 X-Received: by 10.180.84.165 with SMTP id a5mr12093480wiz.6.1360780709563; Wed, 13 Feb 2013 10:38:29 -0800 (PST) Sender: adrian.chadd@gmail.com Received: by 10.216.236.88 with HTTP; Wed, 13 Feb 2013 10:38:29 -0800 (PST) In-Reply-To: References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> Date: Wed, 13 Feb 2013 10:38:29 -0800 X-Google-Sender-Auth: WG1NaxFiAQKSGQMAUcV2AdzryXI Message-ID: Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option From: Adrian Chadd To: Andre Oppermann Content-Type: text/plain; charset=ISO-8859-1 Cc: Lawrence Stewart , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 18:38:31 -0000 .. and I should say, "competing / parallel" congestion algorithms. Ie - how multiple CC's work for/against each other on the same "internet" at the same time. Adrian From owner-freebsd-net@FreeBSD.ORG Wed Feb 13 21:26:02 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 36DCC28C; Wed, 13 Feb 2013 21:26:02 +0000 (UTC) (envelope-from jpaetzel@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 0EA4570; Wed, 13 Feb 2013 21:26:02 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1DLQ1RB045458; Wed, 13 Feb 2013 21:26:01 GMT (envelope-from jpaetzel@freefall.freebsd.org) Received: (from jpaetzel@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1DLQ1bb045454; Wed, 13 Feb 2013 21:26:01 GMT (envelope-from jpaetzel) Date: Wed, 13 Feb 2013 21:26:01 GMT Message-Id: <201302132126.r1DLQ1bb045454@freefall.freebsd.org> To: jpaetzel@FreeBSD.org, freebsd-net@FreeBSD.org, jpaetzel@FreeBSD.org From: jpaetzel@FreeBSD.org Subject: Re: kern/171838: [oce] [patch] Possible lock reversal and duplicate locks as reported by Witness X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 21:26:02 -0000 Synopsis: [oce] [patch] Possible lock reversal and duplicate locks as reported by Witness Responsible-Changed-From-To: freebsd-net->jpaetzel Responsible-Changed-By: jpaetzel Responsible-Changed-When: Wed Feb 13 21:25:24 UTC 2013 Responsible-Changed-Why: I'll take this one. http://www.freebsd.org/cgi/query-pr.cgi?pr=171838 From owner-freebsd-net@FreeBSD.ORG Thu Feb 14 01:36:59 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 8DE9DC20; Thu, 14 Feb 2013 01:36:59 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id EF9BBCF2; Thu, 14 Feb 2013 01:36:58 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 0D5DD7E81E; Thu, 14 Feb 2013 12:36:57 +1100 (EST) Message-ID: <511C3FB8.40506@freebsd.org> Date: Thu, 14 Feb 2013 12:36:56 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Andre Oppermann Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> <511BA29E.5050501@freebsd.org> <511BA7D9.3050709@freebsd.org> In-Reply-To: <511BA7D9.3050709@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 01:36:59 -0000 On 02/14/13 01:48, Andre Oppermann wrote: > On 13.02.2013 15:26, Lawrence Stewart wrote: >> On 02/13/13 21:27, Andre Oppermann wrote: >>> On 13.02.2013 09:25, Lawrence Stewart wrote: >>>> The idea is useful. I'd just like to discuss the implementation >>>> specifics a little further before recommending whether the patch should >>>> go in as is to provide a stop gap, or we rework the patch to be a >>>> little >>>> less specific in readiness for the future work I have in mind. >>> >>> Again I'd like to point out that this sort of modification should >>> be implemented as a congestion control module. All the hook points >>> are already there and can readily be used instead of adding more special >>> cases to the generic part of TCP. The CC algorithm can be selected per >>> socket. For such a special CC module it'd get a nice fat warning that >>> it is not suitable for Internet use. >> >> As a local hack, sure, a CC module would do the job assuming you were >> happy to use a single algorithm as the base. John's patch transcends the >> algorithm in use on a particular connection, so it has wider >> applicability than a CC module. > > The algorithm is becoming somewhat meaningless when your goal is to > have an open pipe and push data as fast as possible without regard > to other traffic. NewReno, Cubic and what have you is becoming > meaningless. But that's not the goal. We're not discussing unbounded or unreactive congestion windows. If a burst causes drops, we still back off. The algorithm does still matter. >> I would also strongly oppose the inclusion of such a module in FreeBSD >> proper - it's the wrong way to implement the functionality. The patch as >> posted is technically appropriate, though I'm interested in discussing >> whether the public API should be tweaked to capture higher level goals >> instead e.g. "low delay at all costs" or "maximum throughput". > > I strongly disagree. The patch is a hack. I agree it's hacky in its current form, but for different reasons to you as outlined in my previous email. You are arguing that idle window resetting is an intrinsic and non negotiable part of TCP. This is demonstrably not true. As long as something doesn't change the wire format, then it is fair game for being tunable. How we make something tunable and what we set as defaults are where we need to be conservative. > From the description John gave on his use-case I read that he would actually take more than just > ignoring idle-cwnd-reset. And actually if I were in his situation I > would use a very aggressive congestion control algorithm doing away with > more than idle-cwnd-reset. Congestion control is only one aspect of what we're discussing. >> We could initially map "low delay at all costs" to a TCP stack meaning >> of "disable idle window reset" and expand the meaning later (e.g. >> relaxing the silly window checks as briefly discussed in the other >> thread). > > Ugh, if you go that far fork it, obtain a fresh protocol number and don't > call it TCP anymore. You're channelling Joe Touch ;) What exactly is TCP? As far as interop is concerned, it's just a wire protocol - as long as I format my headers/segments correctly and ignore options I don't understand, I can communicate with other TCP stacks, many of which implement a different set of TCP features and options. The dynamics of the protocol have evolved significantly over time and continue to do so because of its ubiquity - it flows freely across the public internet and gets used for all manner of things it wasn't initially designed to handle (well). A lot of the dynamics are also controlled by optional parameters. So no, we don't need a new protocol number. We need to provide knobs that allow people to tune TCP dynamics to their particular use case. >>> Additionally I speculate that for the use-case of John he may also be >>> willing to forgo congestion avoidance and always operate in (ill-named) >>> "slow start" mode. With a special CC module this can easily be tweaked. >> >> John already has the functionality he needs in this local tree - this >> discussion is no longer about John per se, but rather about other people >> who may want the functionality John has implemented. > > That's what I'm worried most about. So far no real "other people" have > spoken out, only cheering from the sidelines. We surely don't need them to speak out explicitly - the use case is not obscure enough that I am having difficulty imagining other places it would be useful. >> We need to figure out how to provide the functionality in FreeBSD >> proper, and a CC module is not the answer. > > I totally disagree. This functionality (removal) is not at all a part > of TCP and should not be supported directly. I don't understand how you can argue that idle window resetting is an intrinsic and non negotiable part of TCP. There is no one true set of options and features that is TCP. It is not only one idea. Let's work on providing a rich set of knobs to tune every aspect of our TCP stack's dynamics and operation that don't break wire format, set conservative defaults and document everything thoroughly. Cheers, Lawrence From owner-freebsd-net@FreeBSD.ORG Thu Feb 14 02:01:10 2013 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 04CE712A; Thu, 14 Feb 2013 02:01:10 +0000 (UTC) (envelope-from lstewart@freebsd.org) Received: from lauren.room52.net (lauren.room52.net [210.50.193.198]) by mx1.freebsd.org (Postfix) with ESMTP id BFD6ADC1; Thu, 14 Feb 2013 02:01:09 +0000 (UTC) Received: from lstewart.caia.swin.edu.au (lstewart.caia.swin.edu.au [136.186.229.95]) by lauren.room52.net (Postfix) with ESMTPSA id 4463F7E81E; Thu, 14 Feb 2013 13:01:08 +1100 (EST) Message-ID: <511C4563.7010405@freebsd.org> Date: Thu, 14 Feb 2013 13:01:07 +1100 From: Lawrence Stewart User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130213 Thunderbird/17.0.2 MIME-Version: 1.0 To: Adrian Chadd Subject: Re: [PATCH] Add a new TCP_IGNOREIDLE socket option References: <201301221511.02496.jhb@freebsd.org> <511B4DEF.8000500@freebsd.org> <511B6A87.5060000@freebsd.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=5.0 tests=UNPARSEABLE_RELAY autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on lauren.room52.net Cc: Andre Oppermann , John Baldwin , net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 02:01:10 -0000 On 02/14/13 05:37, Adrian Chadd wrote: > On 13 February 2013 02:27, Andre Oppermann wrote: > >> Again I'd like to point out that this sort of modification should >> be implemented as a congestion control module. All the hook points >> are already there and can readily be used instead of adding more special >> cases to the generic part of TCP. The CC algorithm can be selected per >> socket. For such a special CC module it'd get a nice fat warning that >> it is not suitable for Internet use. >> >> Additionally I speculate that for the use-case of John he may also be >> willing to forgo congestion avoidance and always operate in (ill-named) >> "slow start" mode. With a special CC module this can easily be tweaked. > > There are some cute things that could be done here - eg, having an L3 > route table entry map to a congestion control (like having an MSS in > the L3 entry too.) This is an area I've thought about and would form the basis for an interesting applied research project. On a related tangent, we (CAIA) also have some ongoing research looking at using different CC algorithms per subflow of a multipath TCP connection. > But I'd love to see some modelling / data showing competing congestion > control algorithms on the same set of congested pipes. Doubly so on > multiple congested pipes (ie, modelling a handful of parallel > user<->last-mile<->IX<->various transit feeds with different levels of > congestion/RTT<->IX<->last mile<->user connections.) You all know much > more about this than I do. :-) There is quite a bit of relevant literature out there. You could start with some of the stuff CAIA has had a hand in (e.g. [1]) and follow the citation trail from there... Cheers, Lawrence [1] http://caia.swin.edu.au/urp/newtcp/papers.html From owner-freebsd-net@FreeBSD.ORG Thu Feb 14 21:55:53 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id D88477D1 for ; Thu, 14 Feb 2013 21:55:53 +0000 (UTC) (envelope-from bharavi_oak@yahoo.com) Received: from nm22-vm3.bullet.mail.gq1.yahoo.com (nm22-vm3.bullet.mail.gq1.yahoo.com [98.136.217.66]) by mx1.freebsd.org (Postfix) with ESMTP id 9F358FDB for ; Thu, 14 Feb 2013 21:55:53 +0000 (UTC) Received: from [98.137.12.62] by nm22.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2013 21:55:53 -0000 Received: from [98.137.12.212] by tm7.bullet.mail.gq1.yahoo.com with NNFMP; 14 Feb 2013 21:55:53 -0000 Received: from [127.0.0.1] by omp1020.mail.gq1.yahoo.com with NNFMP; 14 Feb 2013 21:55:53 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 42375.42813.bm@omp1020.mail.gq1.yahoo.com Received: (qmail 39815 invoked by uid 60001); 14 Feb 2013 21:55:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1360878952; bh=KqRtB/itRQP9Bo2waRcG9AlZjnX7ZA2qwfM+MIR485g=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=2crAq4jRGny48M/FH6lZFPh5/ZxrZxL1+9HA9enUpOIyQPbdGN3anGzdDXCN79bOSMrScIl+VKmEgyMdekhCxwWcIEI5MliKYH9uBzEFFzv4KnYSC2pYVtNwm/X9IflPicPhQbU1rOwAYqddpVSxYgRKYgI+VRH8PQybLXQ/Oo0= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:MIME-Version:Content-Type; b=WjfZUwGlebzuyoxJOZXr+rVwnbXBDQjV1ltFncJUSio2shPsmyNmnFnhAuUR5umR67/8oFqrZD5flZM92ERhdc3Gvny2NqSQqXWeeJrBXJ6JlLrUUGQEn1ml1MvJ4hjhp5hryqEbmbLej9m7tV5WwvHhN5gVWNQSqTUo8EYerdI=; X-YMail-OSG: KtjumQ4VM1lOWIph_NLNl7pxoLBeFT3Pb4q6XnB0vMl_S8N RUoTZTvkonKoGa0m.NCyxKBSplJRhSHAIN_4TgQgR_PcJLWvK4iXG7u2eBsp a8UbaPWoaTKd0kKbrDMinBySyyfg_nS18MBsT8b46p1k2NI4xFshw79XBhqP BuKvAtPpRs0aVmT7JhBQoPmNDAXo9RRx2D9tamZlDMGziVX5q5GIInrX2kMX QGGePNM5HtAR6IhAlcnloSaiyI7S2kTpL4atPOEzsf5pGtyolk1sk3aaxkAs Q_RFfgoGZPQxZuhV2zlTodXfdEXmEOqfzfCU.Ex4dk4FHGUS.zP7Wcfn3yff jwOZArt.EbPVWlQJGWdTiRJor9uh89iNAANRlIc.BM8LlBoZTs6Z7exL_Cjq 5ZJrTRGytd940Lr0fbTYoFHXMb2y2TC43WUQXislH4GoZNtFZjkxLwntlvDt 5UoGPkxv7pTAIh34VhKzUgF1bYv0YZCLcPOL0dj3eedUTE31hkcWH_LYwUYF 6TJU- Received: from [137.69.117.57] by web164604.mail.gq1.yahoo.com via HTTP; Thu, 14 Feb 2013 13:55:52 PST X-Rocket-MIMEInfo: 001.001, SGksDQoNCkluIHZsYW5fdW5jb25maWdfbG9ja2VkLCB2bGFuIHRydW5rIGlzIGRlc3Ryb3llZCB2aWEgdHJ1bmtfZGVzdHJveSBmdW5jdGlvbiB3aGljaCBmcmVlcyBoYXNoLCBkZXN0cm95cyB0cnVuayBsb2NrIGFuZCB0aGVuIGZyZWVzIHRydW5rLiBCZWZvcmUgdHJ1bmtfZGVzdHJveSBpcyBjYWxsZWQsIHRydW5rIGxvY2sgaXMgcmVsZWFzZWQgc28gdGhhdCBhIHRocmVhZCBpbiB2bGFuX2lucHV0LCBpZiBhbnksIGNhbiBmaW5pc2ggaXRzIHdvcmsgKGFzIHBlciB0aGUgY29tbWVudCBpbiB0aGUgY29kZSkBMAEBAQE- X-Mailer: YahooMailClassic/15.1.2 YahooMailWebService/0.8.133.508 Message-ID: <1360878952.34332.YahooMailClassic@web164604.mail.gq1.yahoo.com> Date: Thu, 14 Feb 2013 13:55:52 -0800 (PST) From: Bharavi Oak Subject: vlan trunk structure race condition between vlan unconfig and vlan_input To: freebsd-net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2013 21:55:53 -0000 Hi, In vlan_unconfig_locked, vlan trunk is destroyed via trunk_destroy function which frees hash, destroys trunk lock and then frees trunk. Before trunk_destroy is called, trunk lock is released so that a thread in vlan_input, if any, can finish its work (as per the comment in the code). However, we have encountered a condition wherein this release of lock was not enough for the other thread to grab the lock and finish its work. Instead, what happened was that this other thread (doing vlan_input) got the lock when this thread (destroying vlan) had already freed hash inside trunk_destroy. As a result of this, the vlan_input thread got NULL hash (in vlan_gethash) causing panic. In other words, execution of a thread in vlan_input could reach TRUNK_RLOCK when another thread doing vlan unconfig is at any point in its execution; it can be before trunk_destroy or at any point within trunk_destroy. In our case, it caused trunk->hash to be null while trunk was still not null. But it may as well happen that the trunk itself has been freed when the first thread reaches TRUNK_RLOCK. Any way, both cases would cause panic. When trying to solve this, we have started working on the following lines: Bring trunk lock outside of ifvlantrunk structure keeping intact the pointers to it in ifvlan and ifnet structures. So, the reference to trunk lock would not depend on validity of trunk. In trunk destroy, delay freeing hash as much as possible, perhaps by checking if any read waiters are present. However, this would also require any thread doing vlan_input to reach TRUNK_RLOCK latest by this instance. We may also check for validity of hash inside vlan_gethash; but this would add some extra instructions that are not required otherwise. So, can a FreeBSD developer please comment on this problem and the possible way to solve this as mentioned above. Thanks, Bharavi Note that although we encountered this in FreeBSD 7.x, there is no difference in this part of code in FreeBSD 9.x as well. From owner-freebsd-net@FreeBSD.ORG Fri Feb 15 13:57:00 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 6CB42302; Fri, 15 Feb 2013 13:57:00 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 455B7DFF; Fri, 15 Feb 2013 13:57:00 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1FDv0wY011733; Fri, 15 Feb 2013 13:57:00 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1FDv0Uo011729; Fri, 15 Feb 2013 13:57:00 GMT (envelope-from linimon) Date: Fri, 15 Feb 2013 13:57:00 GMT Message-Id: <201302151357.r1FDv0Uo011729@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Subject: Re: kern/176167: [ipsec][lagg] using lagg and ipsec causes immediate panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 13:57:00 -0000 Synopsis: [ipsec][lagg] using lagg and ipsec causes immediate panic Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Fri Feb 15 13:56:52 UTC 2013 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=176167 From owner-freebsd-net@FreeBSD.ORG Fri Feb 15 14:40:01 2013 Return-Path: Delivered-To: freebsd-net@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id BA7CF621 for ; Fri, 15 Feb 2013 14:40:01 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id 94B68BE for ; Fri, 15 Feb 2013 14:40:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r1FEe0TF019727 for ; Fri, 15 Feb 2013 14:40:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r1FEe0jV019723; Fri, 15 Feb 2013 14:40:00 GMT (envelope-from gnats) Date: Fri, 15 Feb 2013 14:40:00 GMT Message-Id: <201302151440.r1FEe0jV019723@freefall.freebsd.org> To: freebsd-net@FreeBSD.org Cc: From: "Andrew A. Khlebutin" Subject: kern/176167: [ipsec][lagg] using lagg and ipsec causes immediate panic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Andrew A. Khlebutin" List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 14:40:01 -0000 The following reply was made to PR kern/176167; it has been noted by GNATS. From: "Andrew A. Khlebutin" To: bug-followup@FreeBSD.org Cc: Subject: kern/176167: [ipsec][lagg] using lagg and ipsec causes immediate panic Date: Fri, 15 Feb 2013 20:31:49 +0600 Hello, The crash is not reproducible on FreeBSD 9.1-RELEASE: FreeBSD smfd-app-1 9.1-RELEASE FreeBSD 9.1-RELEASE #1 r246826: Fri Feb 15 19:49:49 YEKT 2013 root@smfd-app-1:/usr/obj/usr/src/sys/smfd-app amd64 -- SY, Andrew Khlebutin From owner-freebsd-net@FreeBSD.ORG Sat Feb 16 12:55:18 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id B02AB2C7 for ; Sat, 16 Feb 2013 12:55:18 +0000 (UTC) (envelope-from rfg@tristatelogic.com) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 864F7981 for ; Sat, 16 Feb 2013 12:55:17 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 282053B29D for ; Sat, 16 Feb 2013 04:55:09 -0800 (PST) From: "Ronald F. Guilmette" To: freebsd-net@freebsd.org Subject: WTF? RPCPROG_NFS: RPC: Program not registered Date: Sat, 16 Feb 2013 04:55:09 -0800 Message-ID: <1884.1361019309@server1.tristatelogic.com> X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 12:55:18 -0000 I have a 9.1-RELEASE server whose /etc/rc.conf file contains, among other things, the following lines: ifconfig_nfe0="inet 192.168.1.2 netmask 255.255.255.0" # nfs_client_enable="YES" nfs_server_enable="YES" nfs_server_flags="-h 192.168.1.2" mountd_enable="YES" rpcbind_enable="YES" On this server, I also have an /etc/exports file that contains: /home/rfg -network 192.168.1.0 -mask 255.255.255.0 /x -network 192.168.1.0 -mask 255.255.255.0 On this same server, when I do "showmount -e 192.168.1.2" I get the following output: Exports list on 192.168.1.2: /x 192.168.1.0 /home/rfg 192.168.1.0 On this server, when I am root, I attempt to do: mount -t nfs 192.168.1.2:/x /mnt but tnen I just get the following error: [tcp] 192.168.1.2:/x: RPCPROG_NFS: RPC: Program not registered Why? More to the point, what I can do to get rid of this error? I really am stuck. I have no idea what causes this error, nor even how to debug it. I have already google'd the hell out of the problem, and I am still coming up empty. Note also that when the failure occurs there is -nothing- added at that time to /var/log/messages. Reards, rfg P.S. Of course, I don't actually need to mount the exported volume onto the same machine where it physically already resides. I do however wish to mount it (via NFS) onto another system on my LAN, and over on that other system, when I try to mount it, I am getting the exact same *&^%$#@ error. P.P.S. In case anybody should ask, this is the output of rpcinfo 192.168.1.2: program version netid address service owner 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser 100000 4 udp 0.0.0.0.0.111 rpcbind superuser 100000 3 udp 0.0.0.0.0.111 rpcbind superuser 100000 2 udp 0.0.0.0.0.111 rpcbind superuser 100000 4 tcp6 ::.0.111 rpcbind superuser 100000 3 tcp6 ::.0.111 rpcbind superuser 100000 4 udp6 ::.0.111 rpcbind superuser 100000 3 udp6 ::.0.111 rpcbind superuser 100000 4 local /var/run/rpcbind.sock rpcbind superuser 100000 3 local /var/run/rpcbind.sock rpcbind superuser 100000 2 local /var/run/rpcbind.sock rpcbind superuser 100005 1 udp6 ::.3.63 mountd superuser 100005 3 udp6 ::.3.63 mountd superuser 100005 1 tcp6 ::.3.63 mountd superuser 100005 3 tcp6 ::.3.63 mountd superuser 100005 1 udp 0.0.0.0.3.63 mountd superuser 100005 3 udp 0.0.0.0.3.63 mountd superuser 100005 1 tcp 0.0.0.0.3.63 mountd superuser 100005 3 tcp 0.0.0.0.3.63 mountd superuser 100003 2 udp 0.0.0.0.8.1 nfs superuser 100003 3 udp 0.0.0.0.8.1 nfs superuser From owner-freebsd-net@FreeBSD.ORG Sat Feb 16 13:41:07 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 3BCE4F09 for ; Sat, 16 Feb 2013 13:41:07 +0000 (UTC) (envelope-from s.khanchi@gmail.com) Received: from mail-gh0-f171.google.com (mail-gh0-f171.google.com [209.85.160.171]) by mx1.freebsd.org (Postfix) with ESMTP id 00405AE0 for ; Sat, 16 Feb 2013 13:41:06 +0000 (UTC) Received: by mail-gh0-f171.google.com with SMTP id r17so286203ghr.30 for ; Sat, 16 Feb 2013 05:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:from:date:x-google-sender-auth :message-id:subject:to:content-type; bh=LANWjafXg/um1CwFWoSPHL1/KnHbMguz0+0hx4zlh/0=; b=iBWsoi26LAepFEMZxXyNUofcKU9L9jkfV5cVVIuAam/h6UR8V1CEXT68UHvHeRI1u/ Tf11GSIPQfEP63oaMzYhssfMKwmHniTxRf+HQFe7rXdseBCrxq4Pn/SPO5HWVsMTs9is heBhY5WmlSjL624U0qqn9t+VtTUYu8FXufgPp8F6HZ4XpCWWAW1UlL/KvT/yq/k011Y7 zotvMA6NkTJdRW5okoWL1KkbwVKjmI3TBWVs0pqmokK/KYSm/jvIklPhexPLZ+6Utxe6 wV828OFrZhix2Rpg0hBUicbWMyKJ6+UViGxNKaA3UnHzWpJGSGvOhNnLyKs9JFozcQK+ eJVA== X-Received: by 10.236.131.169 with SMTP id m29mr8132710yhi.114.1361022066299; Sat, 16 Feb 2013 05:41:06 -0800 (PST) MIME-Version: 1.0 Sender: s.khanchi@gmail.com Received: by 10.101.143.27 with HTTP; Sat, 16 Feb 2013 05:40:46 -0800 (PST) From: h bagade Date: Sat, 16 Feb 2013 17:10:46 +0330 X-Google-Sender-Auth: VidLhjB1Lzcugedd9OHNs82MmVA Message-ID: Subject: failed to use getifaddrs on geli code To: freebsd-net@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 13:41:07 -0000 Hi all, I need to change the geli code and I want to use "getifaddrs" function inside the code. I make and make install the code and it wasn't any problem at all, but when I want to load the geom_eli.ko module, an error occurred: kldload: can't load /boot/kernel/geom_eli.ko: Exec format error and in /var/log/messages, it stated: link_elf_obj: symbol getifaddrs undefined how can I solve this problem? Any hints or comments are really appreciated From owner-freebsd-net@FreeBSD.ORG Sat Feb 16 15:29:56 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 124A1DBD for ; Sat, 16 Feb 2013 15:29:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-annu.net.uoguelph.ca (esa-annu.mail.uoguelph.ca [131.104.91.36]) by mx1.freebsd.org (Postfix) with ESMTP id D0C1FF0A for ; Sat, 16 Feb 2013 15:29:55 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEABmlH1GDaFvO/2dsb2JhbABFhkm5VIEUc4IfAQEBAwEBAQEgKyALBRYYAgINGQIpAQkmBggHBAEcBIdrBgyqbZF8gSOMTYENNAeCLYETA4hniw2COIEdiDuHAIMlT4EFNQ X-IronPort-AV: E=Sophos;i="4.84,678,1355115600"; d="scan'208";a="14410655" Received: from erie.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.206]) by esa-annu.net.uoguelph.ca with ESMTP; 16 Feb 2013 10:29:54 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 597ECB408C; Sat, 16 Feb 2013 10:29:54 -0500 (EST) Date: Sat, 16 Feb 2013 10:29:54 -0500 (EST) From: Rick Macklem To: "Ronald F. Guilmette" Message-ID: <689563329.3076797.1361028594307.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <1884.1361019309@server1.tristatelogic.com> Subject: Re: WTF? RPCPROG_NFS: RPC: Program not registered MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - FF3.0 (Win)/6.0.10_GA_2692) Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 15:29:56 -0000 Ronald F. Guilmette wrote: > I have a 9.1-RELEASE server whose /etc/rc.conf file contains, among > other > things, the following lines: > > ifconfig_nfe0="inet 192.168.1.2 netmask 255.255.255.0" > # > nfs_client_enable="YES" > nfs_server_enable="YES" > nfs_server_flags="-h 192.168.1.2" Add -t to these flags. It appears that the default is UDP only. > mountd_enable="YES" > rpcbind_enable="YES" > > On this server, I also have an /etc/exports file that contains: > > /home/rfg -network 192.168.1.0 -mask 255.255.255.0 > /x -network 192.168.1.0 -mask 255.255.255.0 > > On this same server, when I do "showmount -e 192.168.1.2" I get the > following > output: > > Exports list on 192.168.1.2: > /x 192.168.1.0 > /home/rfg 192.168.1.0 > > > On this server, when I am root, I attempt to do: > > mount -t nfs 192.168.1.2:/x /mnt > > but tnen I just get the following error: > > [tcp] 192.168.1.2:/x: RPCPROG_NFS: RPC: Program not registered > > Why? > It is trying to mount via TCP and you only have UDP enabled, I think. > More to the point, what I can do to get rid of this error? > I think adding -t to the nfs_server_flags should fix it. > I really am stuck. I have no idea what causes this error, nor even how > to > debug it. I have already google'd the hell out of the problem, and I > am > still coming up empty. > > Note also that when the failure occurs there is -nothing- added at > that > time to /var/log/messages. > > > Reards, > rfg > > > P.S. Of course, I don't actually need to mount the exported volume > onto > the same machine where it physically already resides. I do however > wish > to mount it (via NFS) onto another system on my LAN, and over on that > other > system, when I try to mount it, I am getting the exact same *&^%$#@ > error. > > > P.P.S. In case anybody should ask, this is the output of rpcinfo > 192.168.1.2: > > program version netid address service owner > 100000 4 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 3 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 2 tcp 0.0.0.0.0.111 rpcbind superuser > 100000 4 udp 0.0.0.0.0.111 rpcbind superuser > 100000 3 udp 0.0.0.0.0.111 rpcbind superuser > 100000 2 udp 0.0.0.0.0.111 rpcbind superuser > 100000 4 tcp6 ::.0.111 rpcbind superuser > 100000 3 tcp6 ::.0.111 rpcbind superuser > 100000 4 udp6 ::.0.111 rpcbind superuser > 100000 3 udp6 ::.0.111 rpcbind superuser > 100000 4 local /var/run/rpcbind.sock rpcbind superuser > 100000 3 local /var/run/rpcbind.sock rpcbind superuser > 100000 2 local /var/run/rpcbind.sock rpcbind superuser > 100005 1 udp6 ::.3.63 mountd superuser > 100005 3 udp6 ::.3.63 mountd superuser > 100005 1 tcp6 ::.3.63 mountd superuser > 100005 3 tcp6 ::.3.63 mountd superuser > 100005 1 udp 0.0.0.0.3.63 mountd superuser > 100005 3 udp 0.0.0.0.3.63 mountd superuser > 100005 1 tcp 0.0.0.0.3.63 mountd superuser > 100005 3 tcp 0.0.0.0.3.63 mountd superuser > 100003 2 udp 0.0.0.0.8.1 nfs superuser > 100003 3 udp 0.0.0.0.8.1 nfs superuser > Only udp is here. After adding -t and rebooting, you should see tcp lines as well. At least that`s my guess. Good luck with it, rick > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sat Feb 16 18:54:03 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BD97AA37 for ; Sat, 16 Feb 2013 18:54:03 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by mx1.freebsd.org (Postfix) with ESMTP id 865B38DE for ; Sat, 16 Feb 2013 18:54:03 +0000 (UTC) Received: by mail-da0-f53.google.com with SMTP id w3so1856640dad.26 for ; Sat, 16 Feb 2013 10:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=nHDS96n/0qYiU0aqbIPzFgExVf2h6dQkF0pBDwRehqg=; b=M0sbBA/Q4lZIIQpzL2BQ5VkXi/Wnw++fF9HVENIj4KOmDmK0zyRXF62NiQOLMHBLVK /xDduA0aNqNEHROyshm5qVwLP/Uk0vIBdkpz5iHCTla+WvhMvTOlS8z6SCB3PC1Sk2v1 PwrqPzcnKN4/aiHz/a0vReHIKhRUSguMeOc/mI27jcsDaoOhE1SwBdCPfnyl4WSc9Pfa QcihOIOQYpN4DIWVbb/obPBtS7imhYb+FnoSD1ktmCnc/mKyhvdqR8bIU7Xbd6wGk03Z Cjbfpxmh7jFDweD8oZAYT3J+HKttQlaZRgPFSLhfYXrkMdttINShFLHlOsH0OagcShya 4zwQ== MIME-Version: 1.0 X-Received: by 10.66.81.199 with SMTP id c7mr22984396pay.39.1361040837617; Sat, 16 Feb 2013 10:53:57 -0800 (PST) Received: by 10.67.2.65 with HTTP; Sat, 16 Feb 2013 10:53:57 -0800 (PST) In-Reply-To: References: Date: Sat, 16 Feb 2013 10:53:57 -0800 Message-ID: Subject: Re: failed to use getifaddrs on geli code From: Kevin Oberman To: h bagade Content-Type: text/plain; charset=UTF-8 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2013 18:54:03 -0000 On Sat, Feb 16, 2013 at 5:40 AM, h bagade wrote: > Hi all, > > I need to change the geli code and I want to use "getifaddrs" function > inside the code. I make and make install the code and it wasn't any problem > at all, but when I want to load the geom_eli.ko module, an error occurred: > kldload: can't load /boot/kernel/geom_eli.ko: Exec format error > > and in /var/log/messages, it stated: > link_elf_obj: symbol getifaddrs undefined > > how can I solve this problem? > Any hints or comments are really appreciated One possibility is that your sources from which you built the modified geom_eli module are not the same as were used to build the kernel you are running. -- R. Kevin Oberman, Network Engineer E-mail: kob6558@gmail.com