From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 01:08:58 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7794C1065670; Sun, 16 Oct 2011 01:08:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 084518FC0C; Sun, 16 Oct 2011 01:08:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9G18uXN097575; Sun, 16 Oct 2011 03:08:56 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9G18uNS097574; Sun, 16 Oct 2011 03:08:56 +0200 (CEST) (envelope-from marius) Date: Sun, 16 Oct 2011 03:08:56 +0200 From: Marius Strobl To: Damien Fleuriot Message-ID: <20111016010856.GM39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> User-Agent: Mutt/1.4.2.3i Cc: "stable@freebsd.org" , "current@freebsd.org" , "net@freebsd.org" Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:08:58 -0000 On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: > > > On 15 Oct 2011, at 22:56, Marius Strobl wrote: > > > > > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > > rl(4) only 8129 need testing, 8139 don't) please give the following > > patch a try in order to ensure it doesn't break anything? > > for 9/head: > > http://people.freebsd.org/~marius/mii_bitbang.diff > > for 8: > > http://people.freebsd.org/~marius/mii_bitbang.diff8 > > > > Thanks, > > Marius > > > > > While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... > > What do you think the patch might break ? > Basically, if there's something wrong with the patch the driver should fail to attach, if it still does and gets a link all should be fine. Marius From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 01:11:19 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EADCA1065673; Sun, 16 Oct 2011 01:11:18 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id 849FA8FC20; Sun, 16 Oct 2011 01:11:18 +0000 (UTC) Received: by web.npulse.net (Postfix, from userid 143) id 7DDF9DC0C0; Sun, 16 Oct 2011 01:12:10 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web.npulse.net (Postfix) with ESMTP id 0196CDC0B4 for ; Sun, 16 Oct 2011 01:12:07 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 9462C1A4E3C; Sun, 16 Oct 2011 01:09:19 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 9485810657C1; Sun, 16 Oct 2011 01:09:16 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7794C1065670; Sun, 16 Oct 2011 01:08:58 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 084518FC0C; Sun, 16 Oct 2011 01:08:57 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9G18uXN097575; Sun, 16 Oct 2011 03:08:56 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9G18uNS097574; Sun, 16 Oct 2011 03:08:56 +0200 (CEST) (envelope-from marius) Date: Sun, 16 Oct 2011 03:08:56 +0200 From: Marius Strobl To: Damien Fleuriot Message-ID: <20111016010856.GM39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> User-Agent: Mutt/1.4.2.3i X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: "stable@freebsd.org" , "current@freebsd.org" , "net@freebsd.org" Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:11:19 -0000 On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: > > > On 15 Oct 2011, at 22:56, Marius Strobl wrote: > > > > > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > > rl(4) only 8129 need testing, 8139 don't) please give the following > > patch a try in order to ensure it doesn't break anything? > > for 9/head: > > http://people.freebsd.org/~marius/mii_bitbang.diff > > for 8: > > http://people.freebsd.org/~marius/mii_bitbang.diff8 > > > > Thanks, > > Marius > > > > > While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... > > What do you think the patch might break ? > Basically, if there's something wrong with the patch the driver should fail to attach, if it still does and gets a link all should be fine. Marius _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 01:15:23 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C880B106566B for ; Sun, 16 Oct 2011 01:15:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8B76F8FC12 for ; Sun, 16 Oct 2011 01:15:23 +0000 (UTC) Received: by ywm3 with SMTP id 3so521660ywm.13 for ; Sat, 15 Oct 2011 18:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=tzcA/tosQ3X8e/WLLKnw102RDQrolwwxRmA58g2XCUM=; b=nPKllhR1vy5d8uTNFHr88U27tm87qBt5Mk0XVqGPfVxfaxWULzaZjUOf8zme9dcUuZ m23tPVz7LNkHeW9c5ob60xM6Uw3VmfhEEqQEQhLfqzujl+jE0N+DKmW05Osi8P7jJwJd urMHatytSF65tC+5ufPveDt6CBolvSdBgRUeI= MIME-Version: 1.0 Received: by 10.236.174.105 with SMTP id w69mr16104152yhl.32.1318727723033; Sat, 15 Oct 2011 18:15:23 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Sat, 15 Oct 2011 18:15:22 -0700 (PDT) In-Reply-To: <201110152200.p9FM0QUO044812@freefall.freebsd.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> Date: Sun, 16 Oct 2011 09:15:22 +0800 X-Google-Sender-Auth: 0SgY5p2SfFTdocY4JcYPiuGaYn8 Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:15:23 -0000 Hi! Thanks for your diagnosis. I don't have any rum hardware at the moment (and no time to go diving through the code) but that's an excellent set of debugging/diagnosis results you have there. Just look at what the mgmtrate is set to? It should be set to 1mbit for both 11b and 11g. It shouldn't be too difficult to add some debug statements there to print out what the selected management rate is. adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 01:17:09 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7270B106564A; Sun, 16 Oct 2011 01:17:09 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AC8778FC17; Sun, 16 Oct 2011 01:17:08 +0000 (UTC) Received: by wwi18 with SMTP id 18so1646381wwi.31 for ; Sat, 15 Oct 2011 18:17:07 -0700 (PDT) Received: by 10.227.196.211 with SMTP id eh19mr4906657wbb.6.1318725991126; Sat, 15 Oct 2011 17:46:31 -0700 (PDT) Received: from [192.168.0.47] (paris.c-mal.com. [88.170.200.60]) by mx.google.com with ESMTPS id fy13sm22606825wbb.18.2011.10.15.17.46.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Oct 2011 17:46:29 -0700 (PDT) References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> In-Reply-To: <20111015205616.GL39118@alchemy.franken.de> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Sun, 16 Oct 2011 02:46:23 +0200 To: Marius Strobl Cc: "stable@freebsd.org" , "current@freebsd.org" , "net@freebsd.org" Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:17:09 -0000 On 15 Oct 2011, at 22:56, Marius Strobl wrote: >=20 > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > rl(4) only 8129 need testing, 8139 don't) please give the following > patch a try in order to ensure it doesn't break anything? > for 9/head: > http://people.freebsd.org/~marius/mii_bitbang.diff > for 8: > http://people.freebsd.org/~marius/mii_bitbang.diff8 >=20 > Thanks, > Marius >=20 While I don't have any box with this hardware, I'm thinking you might want t= o get a bit more specific about what you want tested... What do you think the patch might break ? From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 01:20:01 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2FD32106566C; Sun, 16 Oct 2011 01:20:01 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Received: from web.npulse.net (web.npulse.net [79.172.194.2]) by mx1.freebsd.org (Postfix) with ESMTP id A41108FC17; Sun, 16 Oct 2011 01:20:00 +0000 (UTC) Received: by web.npulse.net (Postfix, from userid 143) id E5C1CDC0DC; Sun, 16 Oct 2011 01:20:52 +0000 (UTC) Received: from mx2.freebsd.org (mx2.freebsd.org [69.147.83.53]) by web.npulse.net (Postfix) with ESMTP id AC748DC0AE for ; Sun, 16 Oct 2011 01:20:52 +0000 (UTC) Received: from hub.freebsd.org (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 2A4E91A616A; Sun, 16 Oct 2011 01:19:35 +0000 (UTC) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 68B6610656DA; Sun, 16 Oct 2011 01:19:34 +0000 (UTC) (envelope-from owner-freebsd-stable@freebsd.org) Delivered-To: stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7270B106564A; Sun, 16 Oct 2011 01:17:09 +0000 (UTC) (envelope-from ml@my.gd) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id AC8778FC17; Sun, 16 Oct 2011 01:17:08 +0000 (UTC) Received: by wwi18 with SMTP id 18so1646381wwi.31 for ; Sat, 15 Oct 2011 18:17:07 -0700 (PDT) Received: by 10.227.196.211 with SMTP id eh19mr4906657wbb.6.1318725991126; Sat, 15 Oct 2011 17:46:31 -0700 (PDT) Received: from [192.168.0.47] (paris.c-mal.com. [88.170.200.60]) by mx.google.com with ESMTPS id fy13sm22606825wbb.18.2011.10.15.17.46.29 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 15 Oct 2011 17:46:29 -0700 (PDT) References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> In-Reply-To: <20111015205616.GL39118@alchemy.franken.de> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> X-Mailer: iPhone Mail (8J2) From: Damien Fleuriot Date: Sun, 16 Oct 2011 02:46:23 +0200 To: Marius Strobl X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Sender: owner-freebsd-stable@freebsd.org Errors-To: owner-freebsd-stable@freebsd.org Cc: "stable@freebsd.org" , "current@freebsd.org" , "net@freebsd.org" Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 01:20:01 -0000 On 15 Oct 2011, at 22:56, Marius Strobl wrote: >=20 > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > rl(4) only 8129 need testing, 8139 don't) please give the following > patch a try in order to ensure it doesn't break anything? > for 9/head: > http://people.freebsd.org/~marius/mii_bitbang.diff > for 8: > http://people.freebsd.org/~marius/mii_bitbang.diff8 >=20 > Thanks, > Marius >=20 While I don't have any box with this hardware, I'm thinking you might want t= o get a bit more specific about what you want tested... What do you think the patch might break ? _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 04:38:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 10C2E106564A; Sun, 16 Oct 2011 04:38:22 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B45D38FC08; Sun, 16 Oct 2011 04:38:21 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFIUO-0007TD-9D; Sun, 16 Oct 2011 05:38:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=nDneZdgHOH2IkU8LycZKVkBWWMCzDYOT3pOrV275q5U=; b=NLW1ta0AyCncCjHqj8Q84MpZ9SkRSSHVtHuUUIKtH3ngTGz+62OPPTWP+FledLcGIOt1iK/mPe4mGlEWSALnAWcml51gmNtdt7WVdtQSp/qbSvb7JCIDCs+Dl/92A5RfOZ5a/cVTVIarFC8tpXVpkMDqK4Y0J/k5hgBJpTrW99k=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFIUO-0007TA-4D; Sun, 16 Oct 2011 05:38:20 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFIUI-0000U2-Gz; Sun, 16 Oct 2011 05:38:19 +0100 Message-ID: <4E9A5FB6.7040904@pyro.eu.org> Date: Sun, 16 Oct 2011 05:38:14 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 04:38:22 -0000 Hi Adrian, On 16/10/11 02:15, Adrian Chadd wrote: > Just look at what the mgmtrate is set to? It should be set to 1mbit > for both 11b and 11g. I've just managed to test this, but it seems everything was as it should be. An mgmtrate of 2 is chosen (1Mbit), and I've checked from another device that this is how the frame is really transmitted. I notice the malformed beacon frames have some extra junk bytes at the end, too. So the length *and* offset of the beacon header and payload would seem to be wrong. I'll keep adding debug statements until I find out what is changing when 11g mode is enabled. I guess to do with the extra supported rates. Thanks. Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 16:28:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B2241065672; Sun, 16 Oct 2011 16:28:33 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 2A39D8FC13; Sun, 16 Oct 2011 16:28:32 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFTZf-0008E3-QS; Sun, 16 Oct 2011 17:28:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=cSszD9f30xP+4+FHzcBH84TWCYhYq+ng2M3nvnE80Js=; b=tlrYajApnB24hQcXLpj1aN36+3KrhCgTJG//Lcvr21PBQhBgsmicAvqrhgzL3j+1bwxu1iAM5hIwHPLpfl3xAUUHhncgFLJbErjeha1BbF+irEEzs5BorL8xbq7n0E1xf08TLnsOXM5/Uw0zuDOjRTPAIEwMTfXJ+O6ty55fYzE=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFTZf-0008E0-LP; Sun, 16 Oct 2011 17:28:31 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL, TW_XF Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFTZa-0007pH-7z; Sun, 16 Oct 2011 17:28:30 +0100 Message-ID: <4E9B062A.9050408@pyro.eu.org> Date: Sun, 16 Oct 2011 17:28:26 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> In-Reply-To: <4E9A5FB6.7040904@pyro.eu.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:28:33 -0000 Hello again, I've made another observation regarding this bug. It is possible to also trigger it in 11b mode if the ESSID is large enough -- up to 11 chars is okay: > # ifconfig rum0 media DS1 mode 11b mediaopt hostap nwid 0xcccccccccccccccccccccc > 15:51:43.053446 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: beacon, ssid 0xcccccccccccccccccccccc, rates, ds, tim > 0000: 8000 0000 ffff ffff ffff 0019 5bd3 0056 ....������..[�.V > 0010: 0019 5bd3 0056 1000 1602 0000 0000 0000 ..[�.V.......... > 0020: 6400 2100 000b cccc cccc cccc cccc cccc d.!...��������� > 0030: cc01 0482 840b 1603 010d 0504 0001 0000 �............... But with 12 chars or more we see the bug again. This results in a beacon frame pkthdr.len > 88 bytes, plus a 24-byte tx descriptor. The first byte of the frame was 0x80 (beacon subtype) but is now overwritten with 0x00 (turning beacons into association requests). A stray 0xff has also been appended: > # ifconfig rum0 media DS1 mode 11b mediaopt hostap nwid 0xcccccccccccccccccccccccc > 15:51:42.944718 00:19:5b:d3:00:56 > ff:ff:ff:ff:ff:ff, bssid 00:19:5b:d3:00:56: 802.11: association request > 0000: 0000 0000 ffff ffff ffff 0019 5bd3 0056 ....������..[�.V > 0010: 0019 5bd3 0056 200b 7e9c 1401 0000 0000 ..[�.V .~....... > 0020: 6400 2100 000c cccc cccc cccc cccc cccc d.!...��������� > 0030: cccc 0104 8284 0b16 0301 0d05 0400 0100 ��.............. > 0040: ff � Making the ESSID a full 32 bytes long gets even more interesting -- clearly the end of the beacon frame has 'wrapped around' on itself. The first 21 bytes here (ending 0x0504 00010000) are what should be in place of the last 21 bytes of the frame: > 16:03:58.575748 0b:16:03:01:0d:05 > cc:cc:01:04:82:84, bssid 04:00:01:00:00:56: 802.11: type#12 > 0000: cc84 cccc cccc 0104 8284 0b16 0301 0d05 �.����.......... > 0010: 0400 0100 0056 9000 7a81 0c00 0000 0000 .....V..z....... > 0020: 6400 2100 0020 cccc cccc cccc cccc cccc d.!.. ��������� > 0030: cccc cccc cccc cccc cccc cccc cccc cccc ��������������� > 0040: ff86 f702 57b8 e9b6 f1e7 9941 43f5 08a7 �.�.W�����.AC�.� > 0050: d442 5429 d8 �BT) In 11g mode, the longer list of supported rates means that the beacon frame is always at least 90 bytes long even with an empty ESSID, which is why the bug is always noticed there. I am waaay out of my depth now but I feel so close to figuring this out. The beacon frame is read from an MBUF; does this work something like a ring buffer internally? The kernel manual doesn't actually use that word. mtod() is called without m_pullup() so maybe the data in it isn't in a contiguous block? Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 16:38:23 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55888106564A for ; Sun, 16 Oct 2011 16:38:23 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 163A88FC12 for ; Sun, 16 Oct 2011 16:38:22 +0000 (UTC) Received: by ywm3 with SMTP id 3so816232ywm.13 for ; Sun, 16 Oct 2011 09:38:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=JvpO3OcBln9X4F/gMS5bwRBV3e5U5FclE9ShlP3doJs=; b=RbfC4opML395iPwHoAdc4qEt4rpi5WjCcRr+38r7OPClwPAVLjfJn0/yIOM+7d5WJX DK1Ol8G8aPHpc9kIOipJxtJBn4YIbQ+e/BKmU6NgAYH4WLRKdneX/qd1Atu6mSpt2HtN koOdQq82ZPx3fAMjooxCmPRHpwNcJuBttBf40= MIME-Version: 1.0 Received: by 10.236.129.130 with SMTP id h2mr21973379yhi.49.1318783102610; Sun, 16 Oct 2011 09:38:22 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Sun, 16 Oct 2011 09:38:22 -0700 (PDT) In-Reply-To: <201110152200.p9FM0QUO044812@freefall.freebsd.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> Date: Mon, 17 Oct 2011 00:38:22 +0800 X-Google-Sender-Auth: 2kAHsxkN2-oxeKcR_oEYmAS16g8 Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:38:23 -0000 Is this plugged into an i386/amd64, or something that isn't little endian? I just wonder about the endian-ness of that tx/rx descriptor struct.. Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 16:46:49 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23358106564A for ; Sun, 16 Oct 2011 16:46:49 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id D54538FC13 for ; Sun, 16 Oct 2011 16:46:48 +0000 (UTC) Received: by gyd8 with SMTP id 8so3016726gyd.13 for ; Sun, 16 Oct 2011 09:46:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=3XmEqIlG0qbaKJ9jZfnqi+41F/brdOns4BRWqSmlzI0=; b=CgEUTz3PEyYzceAHZ9BvXJqd1fHmFWMB65v20Bv+ooLQdptMblQ2LXEPO8FhmTW7C4 s30WB7bJDh4D+8qiK4JvGQrOCrxYLvcPof1nKZbwNNXmx5l2TuHlv3hhFyH89y8AB9nH xYv/7iTWN0na4d9NZqDZ8hM8TjeeDy5DlO5Qw= MIME-Version: 1.0 Received: by 10.236.186.2 with SMTP id v2mr4990639yhm.83.1318783608180; Sun, 16 Oct 2011 09:46:48 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Sun, 16 Oct 2011 09:46:48 -0700 (PDT) In-Reply-To: <4E9B062A.9050408@pyro.eu.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> Date: Mon, 17 Oct 2011 00:46:48 +0800 X-Google-Sender-Auth: eDsWdUSRcyGTzILXbDpetg4PJDA Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 16:46:49 -0000 I don't think it's the mbuf. It looks like the mbuf allocation is fine. The linux code in compat-wireless: * seems to handle endian-ness a bit better; * does a bunch of different stuff - look at drivers/net/wireless/rt2x00/rt2500usb.c: static void rt2500usb_write_beacon(struct queue_entry *entry, struct txentry_desc *txdesc) ... /* * Disable beaconing while we are reloading the beacon data, * otherwise we might be sending out invalid data. */ rt2500usb_register_read(rt2x00dev, TXRX_CSR19, ®); rt2x00_set_field16(®, TXRX_CSR19_BEACON_GEN, 0); rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg); (assembles beacon here) /* * USB devices cannot blindly pass the skb->len as the * length of the data to usb_fill_bulk_urb. Pass the skb * to the driver to determine what the length should be. */ length = rt2x00dev->ops->lib->get_tx_data_len(entry); .. which does some fruit: static int rt2500usb_get_tx_data_len(struct queue_entry *entry) { int length; /* * The length _must_ be a multiple of 2, * but it must _not_ be a multiple of the USB packet size. */ length = roundup(entry->skb->len, 2); length += (2 * !(length % entry->queue->usb_maxpacket)); return length; } .. and then it does something with a guard byte, and fiddles with some more registers: /* * Second we need to create the guardian byte. * We only need a single byte, so lets recycle * the 'flags' field we are not using for beacons. */ bcn_priv->guardian_data = 0; usb_fill_bulk_urb(bcn_priv->guardian_urb, usb_dev, pipe, &bcn_priv->guardian_data, 1, rt2500usb_beacondone, entry); /* * Send out the guardian byte. */ usb_submit_urb(bcn_priv->guardian_urb, GFP_ATOMIC); /* * Enable beaconing again. */ rt2x00_set_field16(®, TXRX_CSR19_TSF_COUNT, 1); rt2x00_set_field16(®, TXRX_CSR19_TBCN, 1); reg0 = reg; rt2x00_set_field16(®, TXRX_CSR19_BEACON_GEN, 1); /* * Beacon generation will fail initially. * To prevent this we need to change the TXRX_CSR19 * register several times (reg0 is the same as reg * except for TXRX_CSR19_BEACON_GEN, which is 0 in reg0 * and 1 in reg). */ rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg); rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg0); rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg); rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg0); rt2500usb_register_write(rt2x00dev, TXRX_CSR19, reg); In terms of the setup of the PLCP frame information, that's done in rt2x00queue.c, in rt2x00queue_create_tx_descriptor_plcp(). It is likely worthwhile comparing the two drivers to see what's missing/different. Good luck. :) Adrian From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 19:32:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BEF03106564A; Sun, 16 Oct 2011 19:32:59 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 49B6F8FC15; Sun, 16 Oct 2011 19:32:59 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFWS9-0008OA-Tg; Sun, 16 Oct 2011 20:32:57 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=OtJLp/gwCJHn9zQfKX4so5rXyxfWikFadztgazS608Y=; b=jjQfC/ZP0nXj60l3xEo28i6fUZ2tXxBGAH3Ytil4SeIdhAtM33TGG/2ak9QUT/nu7rSKBozklRk3AAbO4XvF1l06d0ru4eBESS1zWRX0SuSPJZRnhVj/A8f8ybU56CPIG8Zm7pMIjkemXCl6IUVZBiGX4LMA5qJTsTcc/kFM7gI=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFWS0-0008O7-Bm; Sun, 16 Oct 2011 20:32:48 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFWRv-0001Ua-2b; Sun, 16 Oct 2011 20:32:47 +0100 Message-ID: <4E9B315A.6030607@pyro.eu.org> Date: Sun, 16 Oct 2011 20:32:42 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 19:32:59 -0000 On 16/10/11 17:46, Adrian Chadd wrote: > I don't think it's the mbuf. It looks like the mbuf allocation is fine. > The linux code in compat-wireless... Hi Adrian! Thanks for your suggestions. Happily I've got it working, and it wasn't nearly that complicated. I'm only using i386 architecture. I looked further into the magic 88-byte threshold after which the bug occurs. It turns out that figure included the 24-byte tx_desc, and up to 64 bytes of beacon frame (header+data). rum_write_multi doesn't seem happy with writing >64 bytes at a time to the MAC register. If I break it up into separate calls (e.g. bytes 0-63, then bytes 64-65, written at the appropriate offset) I see the proper beacon frames being transmitted now. It's working for any length of ESSID from 0-32 bytes so padding, alignment or guard bytes don't appear to be necessary for the beacon frame. (For tx_data, though, there is code to handle that). I'll neaten this up, produce a patch and test some more. Thanks, Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 22:36:17 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 38513106573E; Sun, 16 Oct 2011 22:36:16 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 8F06F8FC0C; Sun, 16 Oct 2011 22:36:16 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9GMaGe1052865; Sun, 16 Oct 2011 22:36:16 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9GMaGg0052861; Sun, 16 Oct 2011 22:36:16 GMT (envelope-from linimon) Date: Sun, 16 Oct 2011 22:36:16 GMT Message-Id: <201110162236.p9GMaGg0052861@freefall.freebsd.org> To: feh@fehcom.de, linimon@FreeBSD.org, gnats-admin@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161708: [re] re0 unknown hardware revision with onboard Realtek 8111E X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 22:36:17 -0000 Old Synopsis: =?utf-8?Q?Re=3A_kern/157444=3A_=CB=87=CB=9B=5Bre=CB=87=CB=9B=5D_?= New Synopsis: [re] re0 unknown hardware revision with onboard Realtek 8111E State-Changed-From-To: open->closed State-Changed-By: linimon State-Changed-When: Sun Oct 16 22:34:54 UTC 2011 State-Changed-Why: Misfiled followup to kern/157444; content migrated. Responsible-Changed-From-To: gnats-admin->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sun Oct 16 22:34:54 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=161708 From owner-freebsd-net@FreeBSD.ORG Sun Oct 16 23:34:04 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5636C106572C; Sun, 16 Oct 2011 23:34:03 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 441228FC13; Sun, 16 Oct 2011 23:34:03 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFaDR-0000NE-V6; Mon, 17 Oct 2011 00:34:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ZG11fQ8C2RifE86Ekr9ngM3mqcJLnvcMrbKoVEVq6pE=; b=ZbxTIw/jdPA8Z2533EwH5tGn4mb4RPdalUCK4KW94Ynthzs54peSr6HvM5BiKkx5R27JHbv8SYBpShw8M21fDan8wbIyFmZTqjD49YNWlWNTuqhxGxog9jJrTlmY6q4FNE71Lr+vuBzM1rHJUJJ1a8p9R6siJhOHcQI2mDJFEnU=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFaDR-0000NB-QE; Mon, 17 Oct 2011 00:34:01 +0100 X-Spam-Status: No, score=-4.1 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL, SARE_OBFU_VALUE Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFaDM-00072A-Ls; Mon, 17 Oct 2011 00:34:01 +0100 Message-ID: <4E9B69E4.8030600@pyro.eu.org> Date: Mon, 17 Oct 2011 00:33:56 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> In-Reply-To: <4E9B315A.6030607@pyro.eu.org> X-Enigmail-Version: 1.0.1 Content-Type: multipart/mixed; boundary="------------090903000206030603090609" Cc: freebsd-net@freebsd.org, henry.hu.sh@gmail.com, nox@jelal.kn-bremen.de Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Oct 2011 23:34:04 -0000 This is a multi-part message in MIME format. --------------090903000206030603090609 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi, I'm attaching patches for the rum device driver in freebsd and openbsd latest CVS. Firstly I am testing this on a couple of openbsd i386 boxes which should see some heavy usage tomorrow, but so far it has fixed host AP beacons during my testing here. This has also helped some devices to connect that had trouble before. After this I should be able to test similarly on freebsd and amd64. Anyone else with rum hardware suffering beacon issues is also welcome to give these a try! Thanks, Regards, -- Steven Chamberlain steven@pyro.eu.org --------------090903000206030603090609 Content-Type: text/x-patch; name="openbsd-rum-hostap-beacon-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="openbsd-rum-hostap-beacon-fix.patch" --- if_rum.c.orig 2011-07-03 16:47:17.000000000 +0100 +++ if_rum.c 2011-10-16 21:10:40.000000000 +0100 @@ -1486,17 +1486,23 @@ { usb_device_request_t req; usbd_status error; + int offset; req.bmRequestType = UT_WRITE_VENDOR_DEVICE; req.bRequest = RT2573_WRITE_MULTI_MAC; USETW(req.wValue, 0); - USETW(req.wIndex, reg); - USETW(req.wLength, len); - error = usbd_do_request(sc->sc_udev, &req, buf); - if (error != 0) { - printf("%s: could not multi write MAC register: %s\n", - sc->sc_dev.dv_xname, usbd_errstr(error)); + /* write at most 64 bytes at a time */ + for (offset = 0; offset < len; offset += 64) { + USETW(req.wIndex, reg + offset); + USETW(req.wLength, MIN(len - offset, 64)); + + error = usbd_do_request(sc->sc_udev, &req, buf + offset); + if (error != 0) { + printf("%s: could not multi write MAC register: %s\n", + sc->sc_dev.dv_xname, usbd_errstr(error)); + return; + } } } --------------090903000206030603090609 Content-Type: text/x-patch; name="freebsd-rum-hostap-beacon-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="freebsd-rum-hostap-beacon-fix.patch" --- if_rum.c.orig 2011-06-24 03:30:02.000000000 +0100 +++ if_rum.c 2011-10-16 21:05:34.000000000 +0100 @@ -1407,20 +1407,25 @@ { struct usb_device_request req; usb_error_t error; + int offset; req.bmRequestType = UT_WRITE_VENDOR_DEVICE; req.bRequest = RT2573_WRITE_MULTI_MAC; USETW(req.wValue, 0); - USETW(req.wIndex, reg); - USETW(req.wLength, len); - error = rum_do_request(sc, &req, buf); - if (error != 0) { - device_printf(sc->sc_dev, - "could not multi write MAC register: %s\n", - usbd_errstr(error)); + /* write at most 64 bytes at a time */ + for (offset = 0; offset < len; offset += 64) { + USETW(req.wIndex, reg + offset); + USETW(req.wLength, MIN(len - offset, 64)); + + error = rum_do_request(sc, &req, buf + offset); + if (error != 0) { + device_printf(sc->sc_dev, + "could not multi write MAC register: %s\n", + usbd_errstr(error)); + return (error); + } } - return (error); } static void --------------090903000206030603090609-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 00:10:06 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C317E1065677 for ; Mon, 17 Oct 2011 00:10:06 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 482E08FC14 for ; Mon, 17 Oct 2011 00:10:05 +0000 (UTC) Received: by wyi40 with SMTP id 40so1528700wyi.13 for ; Sun, 16 Oct 2011 17:10:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=+2AqLsAYh7hUTPDJEa+8jLd/BLS6QspsGqIWZ1vQeB4=; b=ijPahu0rQZ6u0EyDbJKICz+0Tj5C1GYDltHXHVDVfT478CtUiF68z/Cd1vfVuQ+1s0 rSF3TXqqwydxmoU6k75+aySK0mBQHb9Jc/s829WfBOxuI8u4iPSy49yvQRSzwwBk/p7M LwzBJQXPhH6o/BXBGrpKihPiiVdF2K2fbxt5k= Received: by 10.227.196.65 with SMTP id ef1mr6083819wbb.69.1318810205268; Sun, 16 Oct 2011 17:10:05 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id j18sm28003870wbo.6.2011.10.16.17.10.01 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 17:10:03 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 16 Oct 2011 17:08:22 -0700 From: YongHyeon PYUN Date: Sun, 16 Oct 2011 17:08:21 -0700 To: Marius Strobl Message-ID: <20111017000821.GA3338@michelle.cdnetworks.com> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015204739.GJ39118@alchemy.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111015204739.GJ39118@alchemy.franken.de> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org, dave jones Subject: Re: Question about GPIO bitbang MII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:10:06 -0000 On Sat, Oct 15, 2011 at 10:47:39PM +0200, Marius Strobl wrote: > On Fri, Oct 14, 2011 at 01:32:26PM -0700, YongHyeon PYUN wrote: > > On Thu, Oct 13, 2011 at 11:49:03PM +0200, Marius Strobl wrote: > > > On Wed, Oct 12, 2011 at 04:57:07PM -0700, YongHyeon PYUN wrote: > > > > On Wed, Oct 12, 2011 at 10:42:22PM +0200, Marius Strobl wrote: > > > > > On Tue, Oct 11, 2011 at 03:55:31PM -0700, YongHyeon PYUN wrote: > > > > > > On Tue, Oct 11, 2011 at 11:23:18PM +0200, Marius Strobl wrote: > > > > > > > On Mon, Oct 10, 2011 at 12:22:38PM -0700, YongHyeon PYUN wrote: > > > > > > > > On Sun, Oct 09, 2011 at 06:58:38PM +0200, Marius Strobl wrote: > > > > > > > > > On Fri, Oct 07, 2011 at 10:34:58AM +0800, dave jones wrote: > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > Does FreeBSD have gpio bitbang api for MII? If not, any driver in tree using > > > > > > > > > > gpio-bitbang mii that I can refer to? Thanks. > > > > > > > > > > It seems like OpenBSD, NetBSD and Linux have added support to gpio bitbang mii, > > > > > > > > > > and it's useful for porting embedded devices. > > > > > > > > > > > > > > > > > > > > > > > > > > > > If what you are referring to is their mii_bitbang.[c,h] then I've a patch > > > > > > > > > which (im)ports these and converts drivers to take advantage of it here: > > > > > > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > > > > > > > > > > > > > Patch looks good to me. > > > > > > > > What about other drivers(rl(4), bm(4), lge(4), tl(4), nge(4), wb(4) > > > > > > > > and xe(4))? > > > > > > > > > > > > > > > > > > > > > > Meanwhile I've also converted bm(4), just re-fetch the patch. Generally > > > > > > > I've started with the drivers were the corresponding NetBSD one also > > > > > > > uses the common MII bitbang'ing code. As for nge(4), tl(4), wb(4) I'm > > > > > > > aware that these should also be convertible to the common code, I just > > > > > > > didn't get around to it so far. As for lge(4) that driver has some > > > > > > > remnants of MII bitbang'ing but doesn't actually use it AFAICT. I've > > > > > > > > > > > > Ah, I just blindly grepped the string, sorry. > > > > > > > > > > > > > previously missed rl(4) as I was only grepping beneath sys/dev and I > > > > > > > currently can't explain why I missed xe(4), so thanks for mentioning > > > > > > > these. > > > > > > > In my experience MII bitbang'ing is very fragile though and subtle > > > > > > > changes may break it so I don't want to commit these without testing > > > > > > > or in the case of smc(4) where at least the corresponding NetBSD > > > > > > > driver already uses the common code. Unfortunately, I only have > > > > > > > hardware for dc(4), stge(4), xl(4) and somewhere also for rl(4) and > > > > > > > tl(4) and I guess I can nwhitehorn@ regarding testing bm(4). Do you > > > > > > > happen to have hardware to test the remaining drivers, i.e. nge(4), > > > > > > > sis(4), ste(4), wb(4) and xe(4)? > > > > > > > > > > > > > > > > > > > I have access to sis(4) and ste(4). I also have a nge(4) but I'm > > > > > > not able to access to the hardware, at least in US. > > > > > > > > > > > > > > > > It would be great if you could test sis(4) and ste(4). > > > > > > > > > > > > > Ok, will do in this week. > > > > > > > > > > I just noticed that rl(4) only does MII bitbang'ing for the 8129 but I > > > only have a 8139. Do you happen do have the former so you could test the > > > patch with it? > > > > Sorry, I don't have 8129 based controller. > > > > > The patch is now complete as far as I'm willing to convert drivers. What's > > > left is ed(4) and xe(4). The former has several chip specific things > > > interwinded and I'm unsure whether it can be converted to use the common > > > code; I'd at least like to have hardware for the special cases to give > > > that a try. Xe(4) currently doesn't use miibus(4) (but should) so I > > > don't see much point in adding a dependency on miibus(4) just for the > > > bitbang'ing code on it (nor do I for not adding the common code to > > > miibus(4)). > > > > > > > Ok. > > Both sis(4) and ste(4) seem to work without problems. > > Thanks for your work! > > > > Thanks for testing! > While digging for test hardware I found a Intel 21143 based card I > decided to give a try for fun (as dc(4) doesn't use MII bitbang'ing > for these). Unfortunately, it turned out that some dc(4) changes > between 8.2-RELEASE an what's in head broke it in that it no longer > is able to establish a link (the link LED blinks periodically instead > of being lit permanently) ... > After reading this mail, I tried dual port Intel 21143 based controller and it worked as expected(with/without MII bitbang). Can you narrow down which change break your controller? Because there are so many dc(4) variants it would be better to know which controller you have. > Marius > From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 00:24:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 09CC0106564A; Mon, 17 Oct 2011 00:24:00 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 469C18FC1A; Mon, 17 Oct 2011 00:23:57 +0000 (UTC) Received: by wyi40 with SMTP id 40so1535390wyi.13 for ; Sun, 16 Oct 2011 17:23:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:mime-version :content-type:content-disposition:user-agent; bh=k0MQ75+wfg/gHEKQaGpL4aEF95IPCtfSOrUcG30dC/Y=; b=czHzCZyH0HdWGFf4BChDJN6n7h+m89I043ov3u2scRGPUIfGnsyUSzuOSFbX9me4iE NFemW9ZQ9U00hTuNVj6LbAeLVJlf9Qjmg3X/TJO0JX7BYdZEva8VE2Z/WpaVpbhpjl46 eEOiI9kLOmJqv/ec7d2AzBv6f+6o/bie9kpwM= Received: by 10.227.157.18 with SMTP id z18mr5979413wbw.85.1318811036122; Sun, 16 Oct 2011 17:23:56 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id n21sm28059775wbp.2.2011.10.16.17.23.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Oct 2011 17:23:55 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Sun, 16 Oct 2011 17:22:13 -0700 From: YongHyeon PYUN Date: Sun, 16 Oct 2011 17:22:13 -0700 To: freebsd-current@FreeBSD.org Message-ID: <20111017002213.GB3338@michelle.cdnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Call for testers : ALi/ULi M5261/M5263 ethernet controller X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 00:24:00 -0000 Hi, If you have ALi/ULi M5261/M5263 ethernet controller please try the patch at the following URL and let me know how it works. http://people.freebsd.org/~yongari/dc/dc.uli562x.diff The patch was generated against latest HEAD and it should be cleanly applied to latest stable/8 and stable/7. Thanks. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 01:41:35 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C0EFB106564A for ; Mon, 17 Oct 2011 01:41:35 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.213.177]) by mx1.freebsd.org (Postfix) with ESMTP id 7F33E8FC13 for ; Mon, 17 Oct 2011 01:41:35 +0000 (UTC) Received: by yxk36 with SMTP id 36so3212659yxk.8 for ; Sun, 16 Oct 2011 18:41:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=YSIUtXpZJg5Ye0WL5a3W292Ny2oyRTxFK90TPTJE5Jk=; b=xrk4GERRKxTj9wi6g3cZx8l3aD4hnWfI4OwfkarVkrNEG4idfdG6A5skwhaXZgS3o8 r9TkYfdOuNHvs+yRCQuar/mfS1un8xo5KvssTkeQFJEsNAKqjcD3iU1VZhUisMPEeVQM ULdCWLgt0rfW3Qy1o3v6d2XK2Ro6L+nsuGTu8= MIME-Version: 1.0 Received: by 10.236.154.193 with SMTP id h41mr23450618yhk.15.1318815694755; Sun, 16 Oct 2011 18:41:34 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Sun, 16 Oct 2011 18:41:34 -0700 (PDT) In-Reply-To: <4E9B69E4.8030600@pyro.eu.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> <4E9B69E4.8030600@pyro.eu.org> Date: Mon, 17 Oct 2011 09:41:34 +0800 X-Google-Sender-Auth: H123B6D0DIjCCbgD9FH114KY0lg Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, henry.hu.sh@gmail.com, nox@jelal.kn-bremen.de Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 01:41:35 -0000 Hi! Thanks very much for this. I'll make sure it gets into -HEAD. If someone can test out a patch on -9, I'll submit it as a candidate to re@. Would you please create a PR and tell me what the PR number is? I'll then make sure it gets committed. Thanks again! adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 11:07:07 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EED4E1065672 for ; Mon, 17 Oct 2011 11:07:07 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DCC658FC24 for ; Mon, 17 Oct 2011 11:07:07 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HB77U7099291 for ; Mon, 17 Oct 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HB77Ie099289 for freebsd-net@FreeBSD.org; Mon, 17 Oct 2011 11:07:07 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 17 Oct 2011 11:07:07 GMT Message-Id: <201110171107.p9HB77Ie099289@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-net@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-net@FreeBSD.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 11:07:08 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/161381 net [re] RTL8169SC - re0: PHY write failed o kern/161277 net [em] [patch] BMC cannot receive IPMI traffic after loa o kern/160873 net [igb] igb(4) from HEAD fails to build on 7-STABLE o kern/160750 net Intel PRO/1000 connection breaks under load until rebo o kern/160693 net [gif] [em] Multicast packet are not passed from GIF0 t o kern/160420 net [msk] phy write timeout on HP 5310m o kern/160293 net [ieee80211] ppanic] kernel panic during network setup o kern/160206 net [gif] gifX stops working after a while (IPv6 tunnel) o kern/159817 net [udp] write UDPv4: No buffer space available (code=55) o kern/159795 net [tcp] excessive duplicate ACKs and TCP session freezes o kern/159629 net [ipsec] [panic] kernel panic with IPsec in transport m o kern/159621 net [tcp] [panic] panic: soabort: so_count o kern/159603 net [netinet] [patch] in_ifscrubprefix() - network route c o kern/159602 net [netinet] [patch] arp_ifscrub() is called even if IFF_ o kern/159601 net [netinet] [patch] in_scrubprefix() - loopback route re o kern/159294 net [em] em watchdog timeouts o kern/159203 net [wpi] Intel 3945ABG Wireless LAN not support IBSS o kern/158930 net [bpf] BPF element leak in ifp->bpf_if->bif_dlist o kern/158726 net [ip6] [patch] ICMPv6 Router Announcement flooding limi o kern/158694 net [ix] [lagg] ix0 is not working within lagg(4) o kern/158665 net [ip6] [panic] kernel pagefault in in6_setscope() o kern/158635 net [em] TSO breaks BPF packet captures with em driver f kern/157802 net [dummynet] [panic] kernel panic in dummynet o kern/157785 net amd64 + jail + ipfw + natd = very slow outbound traffi o kern/157429 net [re] Realtek RTL8169 doesn't work with re(4) o kern/157418 net [em] em driver lockup during boot on Supermicro X9SCM- o kern/157410 net [ip6] IPv6 Router Advertisements Cause Excessive CPU U o kern/157287 net [re] [panic] INVARIANTS panic (Memory modified after f o kern/157209 net [ip6] [patch] locking error in rip6_input() (sys/netin o kern/157200 net [network.subr] [patch] stf(4) can not communicate betw o kern/157182 net [lagg] lagg interface not working together with epair o kern/156877 net [dummynet] [panic] dummynet move_pkt() null ptr derefe o kern/156667 net [em] em0 fails to init on CURRENT after March 17 o kern/156408 net [vlan] Routing failure when using VLANs vs. Physical e o kern/156328 net [icmp]: host can ping other subnet but no have IP from o kern/156317 net [ip6] Wrong order of IPv6 NS DAD/MLD Report o kern/156283 net [ip6] [patch] nd6_ns_input - rtalloc_mpath does not re o kern/156279 net [if_bridge][divert][ipfw] unable to correctly re-injec o kern/156226 net [lagg]: failover does not announce the failover to swi o kern/156030 net [ip6] [panic] Crash in nd6_dad_start() due to null ptr o kern/155772 net ifconfig(8): ioctl (SIOCAIFADDR): File exists on direc o kern/155680 net [multicast] problems with multicast s kern/155642 net [request] Add driver for Realtek RTL8191SE/RTL8192SE W o kern/155604 net [flowtable] Flowtable excessively caches dest MAC addr o kern/155597 net [panic] Kernel panics with "sbdrop" message o kern/155585 net [tcp] [panic] tcp_output tcp_mtudisc loop until kernel o kern/155420 net [vlan] adding vlan break existent vlan o bin/155365 net [patch] routed(8): if.c in routed fails to compile if o kern/155177 net [route] [panic] Panic when inject routes in kernel o kern/155030 net [igb] igb(4) DEVICE_POLLING does not work with carp(4) o kern/155010 net [msk] ntfs-3g via iscsi using msk driver cause kernel o kern/155004 net [bce] [panic] kernel panic in bce0 driver o kern/154943 net [gif] ifconfig gifX create on existing gifX clears IP s kern/154851 net [request]: Port brcm80211 driver from Linux to FreeBSD o kern/154850 net [netgraph] [patch] ng_ether fails to name nodes when t o kern/154679 net [em] Fatal trap 12: "em1 taskq" only at startup (8.1-R o kern/154600 net [tcp] [panic] Random kernel panics on tcp_output o kern/154557 net [tcp] Freeze tcp-session of the clients, if in the gat o kern/154443 net [if_bridge] Kernel module bridgestp.ko missing after u o kern/154286 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/154255 net [nfs] NFS not responding o kern/154214 net [stf] [panic] Panic when creating stf interface o kern/154185 net race condition in mb_dupcl o kern/154169 net [multicast] [ip6] Node Information Query multicast add o kern/154134 net [ip6] stuck kernel state in LISTEN on ipv6 daemon whic o kern/154091 net [netgraph] [panic] netgraph, unaligned mbuf? o conf/154062 net [vlan] [patch] change to way of auto-generatation of v o kern/153937 net [ral] ralink panics the system (amd64 freeBSDD 8.X) wh o kern/153936 net [ixgbe] [patch] MPRC workaround incorrectly applied to o kern/153816 net [ixgbe] ixgbe doesn't work properly with the Intel 10g o kern/153772 net [ixgbe] [patch] sysctls reference wrong XON/XOFF varia o kern/153497 net [netgraph] netgraph panic due to race conditions o kern/153454 net [patch] [wlan] [urtw] Support ad-hoc and hostap modes o kern/153308 net [em] em interface use 100% cpu o kern/153244 net [em] em(4) fails to send UDP to port 0xffff o kern/152893 net [netgraph] [panic] 8.2-PRERELEASE panic in netgraph o kern/152853 net [em] tftpd (and likely other udp traffic) fails over e o kern/152828 net [em] poor performance on 8.1, 8.2-PRE o kern/152569 net [net]: Multiple ppp connections and routing table prob o kern/152235 net [arp] Permanent local ARP entries are not properly upd o kern/152141 net [vlan] [patch] encapsulate vlan in ng_ether before out o kern/152036 net [libc] getifaddrs(3) returns truncated sockaddrs for n o kern/151690 net [ep] network connectivity won't work until dhclient is o kern/151681 net [nfs] NFS mount via IPv6 leads to hang on client with o kern/151593 net [igb] [panic] Kernel panic when bringing up igb networ o kern/150920 net [ixgbe][igb] Panic when packets are dropped with heade o kern/150557 net [igb] igb0: Watchdog timeout -- resetting o kern/150251 net [patch] [ixgbe] Late cable insertion broken o kern/150249 net [ixgbe] Media type detection broken o bin/150224 net ppp(8) does not reassign static IP after kill -KILL co f kern/149969 net [wlan] [ral] ralink rt2661 fails to maintain connectio o kern/149937 net [ipfilter] [patch] kernel panic in ipfilter IP fragmen o kern/149643 net [rum] device not sending proper beacon frames in ap mo o kern/149609 net [panic] reboot after adding second default route o kern/149117 net [inet] [patch] in_pcbbind: redundant test o kern/149086 net [multicast] Generic multicast join failure in 8.1 o kern/148018 net [flowtable] flowtable crashes on ia64 o kern/147912 net [boot] FreeBSD 8 Beta won't boot on Thinkpad i1300 11 o kern/147894 net [ipsec] IPv6-in-IPv4 does not work inside an ESP-only o kern/147155 net [ip6] setfb not work with ipv6 o kern/146845 net [libc] close(2) returns error 54 (connection reset by f kern/146792 net [flowtable] flowcleaner 100% cpu's core load o kern/146719 net [pf] [panic] PF or dumynet kernel panic o kern/146534 net [icmp6] wrong source address in echo reply o kern/146427 net [mwl] Additional virtual access points don't work on m o kern/146426 net [mwl] 802.11n rates not possible on mwl o kern/146425 net [mwl] mwl dropping all packets during and after high u f kern/146394 net [vlan] IP source address for outgoing connections o bin/146377 net [ppp] [tun] Interface doesn't clear addresses when PPP o kern/146358 net [vlan] wrong destination MAC address o kern/146165 net [wlan] [panic] Setting bssid in adhoc mode causes pani o kern/146082 net [ng_l2tp] a false invaliant check was performed in ng_ o kern/146037 net [panic] mpd + CoA = kernel panic o bin/145934 net [patch] add count option to netstat(1) o kern/145825 net [panic] panic: soabort: so_count o kern/145728 net [lagg] Stops working lagg between two servers. p kern/145600 net TCP/ECN behaves different to CE/CWR than ns2 reference f kern/144917 net [flowtable] [panic] flowtable crashes system [regressi o kern/144882 net MacBookPro =>4.1 does not connect to BSD in hostap wit o kern/144874 net [if_bridge] [patch] if_bridge frees mbuf after pfil ho o conf/144700 net [rc.d] async dhclient breaks stuff for too many people o kern/144616 net [nat] [panic] ip_nat panic FreeBSD 7.2 f kern/144315 net [ipfw] [panic] freebsd 8-stable reboot after add ipfw o kern/144231 net bind/connect/sendto too strict about sockaddr length o kern/143846 net [gif] bringing gif3 tunnel down causes gif0 tunnel to s kern/143673 net [stf] [request] there should be a way to support multi s kern/143666 net [ip6] [request] PMTU black hole detection not implemen o kern/143622 net [pfil] [patch] unlock pfil lock while calling firewall o kern/143593 net [ipsec] When using IPSec, tcpdump doesn't show outgoin o kern/143591 net [ral] RT2561C-based DLink card (DWL-510) fails to work o kern/143208 net [ipsec] [gif] IPSec over gif interface not working o kern/143034 net [panic] system reboots itself in tcp code [regression] o kern/142877 net [hang] network-related repeatable 8.0-STABLE hard hang o kern/142774 net Problem with outgoing connections on interface with mu o kern/142772 net [libc] lla_lookup: new lle malloc failed o kern/142018 net [iwi] [patch] Possibly wrong interpretation of beacon- o kern/141861 net [wi] data garbled with WEP and wi(4) with Prism 2.5 f kern/141741 net Etherlink III NIC won't work after upgrade to FBSD 8, o kern/140742 net rum(4) Two asus-WL167G adapters cannot talk to each ot o kern/140682 net [netgraph] [panic] random panic in netgraph o kern/140634 net [vlan] destroying if_lagg interface with if_vlan membe o kern/140619 net [ifnet] [patch] refine obsolete if_var.h comments desc o kern/140346 net [wlan] High bandwidth use causes loss of wlan connecti o kern/140142 net [ip6] [panic] FreeBSD 7.2-amd64 panic w/IPv6 o kern/140066 net [bwi] install report for 8.0 RC 2 (multiple problems) o kern/139565 net [ipfilter] ipfilter ioctl SIOCDELST broken o kern/139387 net [ipsec] Wrong lenth of PF_KEY messages in promiscuous o bin/139346 net [patch] arp(8) add option to remove static entries lis o kern/139268 net [if_bridge] [patch] allow if_bridge to forward just VL p kern/139204 net [arp] DHCP server replies rejected, ARP entry lost bef o kern/139117 net [lagg] + wlan boot timing (EBUSY) o kern/139058 net [ipfilter] mbuf cluster leak on FreeBSD 7.2 o kern/138850 net [dummynet] dummynet doesn't work correctly on a bridge o kern/138782 net [panic] sbflush_internal: cc 0 || mb 0xffffff004127b00 o kern/138688 net [rum] possibly broken on 8 Beta 4 amd64: able to wpa a o kern/138678 net [lo] FreeBSD does not assign linklocal address to loop o kern/138620 net [lagg] [patch] lagg port bpf-writes blocked o kern/138407 net [gre] gre(4) interface does not come up after reboot o kern/138332 net [tun] [lor] ifconfig tun0 destroy causes LOR if_adata/ o kern/138266 net [panic] kernel panic when udp benchmark test used as r o kern/138177 net [ipfilter] FreeBSD crashing repeatedly in ip_nat.c:257 f kern/138029 net [bpf] [panic] periodically kernel panic and reboot o kern/137881 net [netgraph] [panic] ng_pppoe fatal trap 12 p bin/137841 net [patch] wpa_supplicant(8) cannot verify SHA256 signed p kern/137776 net [rum] panic in rum(4) driver on 8.0-BETA2 o bin/137641 net ifconfig(8): various problems with "vlan_device.vlan_i o kern/137392 net [ip] [panic] crash in ip_nat.c line 2577 o kern/137372 net [ral] FreeBSD doesn't support wireless interface from o kern/137089 net [lagg] lagg falsely triggers IPv6 duplicate address de o bin/136994 net [patch] ifconfig(8) print carp mac address o kern/136911 net [netgraph] [panic] system panic on kldload ng_bpf.ko t o bin/136661 net [patch] ndp(8) ignores -f option 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 f kern/123045 net [ng_mppc] ng_mppc_decompress - disabling node o kern/122989 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/122954 net [lagg] IPv6 EUI64 incorrectly chosen for lagg devices f kern/122780 net [lagg] tcpdump on lagg interface during high pps wedge o kern/122685 net It is not visible passing packets in tcpdump(1) o kern/122319 net [wi] imposible to enable ad-hoc demo mode with Orinoco o kern/122290 net [netgraph] [panic] Netgraph related "kmem_map too smal o kern/122033 net [ral] [lor] Lock order reversal in ral0 at bootup ieee o bin/121895 net [patch] rtsol(8)/rtsold(8) doesn't handle managed netw s kern/121774 net [swi] [panic] 6.3 kernel panic in swi1: net o kern/121555 net [panic] Fatal trap 12: current process = 12 (swi1: net o kern/121443 net [gif] [lor] icmp6_input/nd6_lookup o kern/121437 net [vlan] Routing to layer-2 address does not work on VLA o bin/121359 net [patch] [security] ppp(8): fix local stack overflow in o kern/121257 net [tcp] TSO + natd -> slow outgoing tcp traffic o kern/121181 net [panic] Fatal trap 3: breakpoint instruction fault whi o kern/120966 net [rum] kernel panic with if_rum and WPA encryption o kern/120566 net [request]: ifconfig(8) make order of arguments more fr o kern/120304 net [netgraph] [patch] netgraph source assumes 32-bit time o kern/120266 net [udp] [panic] gnugk causes kernel panic when closing U o bin/120060 net routed(8) deletes link-level routes in the presence of o kern/119945 net [rum] [panic] rum device in hostap mode, cause kernel o kern/119791 net [nfs] UDP NFS mount of aliased IP addresses from a Sol o kern/119617 net [nfs] nfs error on wpa network when reseting/shutdown f kern/119516 net [ip6] [panic] _mtx_lock_sleep: recursed on non-recursi o kern/119432 net [arp] route add -host -iface causes arp e o kern/119225 net [wi] 7.0-RC1 no carrier with Prism 2.5 wifi card [regr o kern/118727 net [netgraph] [patch] [request] add new ng_pf module o kern/117423 net [vlan] Duplicate IP on different interfaces o bin/117339 net [patch] route(8): loading routing management commands o kern/117271 net [tap] OpenVPN TAP uses 99% CPU on releng_6 when if_tap o bin/116643 net [patch] [request] fstat(1): add INET/INET6 socket deta o kern/116185 net [iwi] if_iwi driver leads system to reboot o kern/115239 net [ipnat] panic with 'kmem_map too small' using ipnat o kern/115019 net [netgraph] ng_ether upper hook packet flow stops on ad o kern/115002 net [wi] if_wi timeout. failed allocation (busy bit). ifco o kern/114915 net [patch] [pcn] pcn (sys/pci/if_pcn.c) ethernet driver f o kern/113432 net [ucom] WARNING: attempt to net_add_domain(netgraph) af o kern/112722 net [ipsec] [udp] IP v4 udp fragmented packet reject o kern/112686 net [patm] patm driver freezes System (FreeBSD 6.2-p4) i38 o bin/112557 net [patch] ppp(8) lock file should not use symlink name o kern/112528 net [nfs] NFS over TCP under load hangs with "impossible p o kern/111537 net [inet6] [patch] ip6_input() treats mbuf cluster wrong o kern/111457 net [ral] ral(4) freeze o kern/110284 net [if_ethersubr] Invalid Assumption in SIOCSIFADDR in et o kern/110249 net [kernel] [regression] [patch] setsockopt() error regre o kern/109470 net [wi] Orinoco Classic Gold PC Card Can't Channel Hop o bin/108895 net pppd(8): PPPoE dead connections on 6.2 [regression] o kern/107944 net [wi] [patch] Forget to unlock mutex-locks o conf/107035 net [patch] bridge(8): bridge interface given in rc.conf n o kern/106444 net [netgraph] [panic] Kernel Panic on Binding to an ip to o kern/106438 net [ipf] ipfilter: keep state does not seem to allow repl o kern/106316 net [dummynet] dummynet with multipass ipfw drops packets o kern/105945 net Address can disappear from network interface s kern/105943 net Network stack may modify read-only mbuf chain copies o bin/105925 net problems with ifconfig(8) and vlan(4) [regression] o kern/104851 net [inet6] [patch] On link routes not configured when usi o kern/104751 net [netgraph] kernel panic, when getting info about my tr o kern/103191 net Unpredictable reboot o kern/103135 net [ipsec] ipsec with ipfw divert (not NAT) encodes a pac o kern/102540 net [netgraph] [patch] supporting vlan(4) by ng_fec(4) o conf/102502 net [netgraph] [patch] ifconfig name does't rename netgrap o kern/102035 net [plip] plip networking disables parallel port printing o kern/101948 net [ipf] [panic] Kernel Panic Trap No 12 Page Fault - cau o kern/100709 net [libc] getaddrinfo(3) should return TTL info o kern/100519 net [netisr] suggestion to fix suboptimal network polling o kern/98978 net [ipf] [patch] ipfilter drops OOW packets under 6.1-Rel o kern/98597 net [inet6] Bug in FreeBSD 6.1 IPv6 link-local DAD procedu o bin/98218 net wpa_supplicant(8) blacklist not working o kern/97306 net [netgraph] NG_L2TP locks after connection with failed o conf/97014 net [gif] gifconfig_gif? in rc.conf does not recognize IPv f kern/96268 net [socket] TCP socket performance drops by 3000% if pack o kern/95519 net [ral] ral0 could not map mbuf o kern/95288 net [pppd] [tty] [panic] if_ppp panic in sys/kern/tty_subr o kern/95277 net [netinet] [patch] IP Encapsulation mask_match() return o kern/95267 net packet drops periodically appear f kern/93378 net [tcp] Slow data transfer in Postfix and Cyrus IMAP (wo o kern/93019 net [ppp] ppp and tunX problems: no traffic after restarti o kern/92880 net [libc] [patch] almost rewritten inet_network(3) functi s kern/92279 net [dc] Core faults everytime I reboot, possible NIC issu o kern/91859 net [ndis] if_ndis does not work with Asus WL-138 s kern/91777 net [ipf] [patch] wrong behaviour with skip rule inside an o kern/91364 net [ral] [wep] WF-511 RT2500 Card PCI and WEP o kern/91311 net [aue] aue interface hanging s kern/90086 net [hang] 5.4p8 on supermicro P8SCT hangs during boot if o kern/87521 net [ipf] [panic] using ipfilter "auth" keyword leads to k o kern/87421 net [netgraph] [panic]: ng_ether + ng_eiface + if_bridge s kern/86920 net [ndis] ifconfig: SIOCS80211: Invalid argument [regress o kern/86871 net [tcp] [patch] allocation logic for PCBs in TIME_WAIT s o kern/86427 net [lor] Deadlock with FASTIPSEC and nat o kern/86103 net [ipf] Illegal NAT Traversal in IPFilter o kern/85780 net 'panic: bogus refcnt 0' in routing/ipv6 o bin/85445 net ifconfig(8): deprecated keyword to ifconfig inoperativ p kern/85320 net [gre] [patch] possible depletion of kernel stack in ip o bin/82975 net route change does not parse classfull network as given o kern/82881 net [netgraph] [panic] ng_fec(4) causes kernel panic after o kern/82468 net Using 64MB tcp send/recv buffers, trafficflow stops, i o bin/82185 net [patch] ndp(8) can delete the incorrect entry o kern/81095 net IPsec connection stops working if associated network i o kern/78968 net FreeBSD freezes on mbufs exhaustion (network interface o kern/78090 net [ipf] ipf filtering on bridged packets doesn't work if o kern/77341 net [ip6] problems with IPV6 implementation o kern/77273 net [ipf] ipfilter breaks ipv6 statefull filtering on 5.3 s kern/77195 net [ipf] [patch] ipfilter ioctl SIOCGNATL does not match o kern/75873 net Usability problem with non-RFC-compliant IP spoof prot s kern/75407 net [an] an(4): no carrier after short time a kern/71474 net [route] route lookup does not skip interfaces marked d o kern/71469 net default route to internet magically disappears with mu o kern/70904 net [ipf] ipfilter ipnat problem with h323 proxy support o kern/68889 net [panic] m_copym, length > size of mbuf chain o kern/66225 net [netgraph] [patch] extend ng_eiface(4) control message o kern/65616 net IPSEC can't detunnel GRE packets after real ESP encryp s kern/60293 net [patch] FreeBSD arp poison patch a kern/56233 net IPsec tunnel (ESP) over IPv6: MTU computation is wrong s bin/41647 net ifconfig(8) doesn't accept lladdr along with inet addr s kern/39937 net ipstealth issue a kern/38554 net [patch] changing interface ipaddress doesn't seem to w o kern/34665 net [ipf] [hang] ipfilter rcmd proxy "hangs". o kern/31940 net ip queue length too short for >500kpps o kern/31647 net [libc] socket calls can return undocumented EINVAL o kern/30186 net [libc] getaddrinfo(3) does not handle incorrect servna o kern/27474 net [ipf] [ppp] Interactive use of user PPP and ipfilter c f kern/24959 net [patch] proper TCP_NOPUSH/TCP_CORK compatibility o conf/23063 net [arp] [patch] for static ARP tables in rc.network o kern/21998 net [socket] [patch] ident only for outgoing connections o kern/5877 net [socket] sb_cc counts control data as well as data dat 377 problems total. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 13:13:19 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9660A106566B for ; Mon, 17 Oct 2011 13:13:19 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id 540358FC1E for ; Mon, 17 Oct 2011 13:13:19 +0000 (UTC) Received: by gyd8 with SMTP id 8so3815299gyd.13 for ; Mon, 17 Oct 2011 06:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=X3G/5PEPviYw+3AuVrzZZ35HBH9aoja/6DqLtBQ5NGA=; b=I1VcGTPSMNSmDQDgckTIiSVjtto/UjNhhA91qgEFzuRTczhoxeIjR9rfcF5QvJObuw sRjw4PcOQb6JFItmOY7UhXVdsYpbDit7nH+S7CaL6RpOppVZT1xJl9lO4upaxItiuCDG TBm1Y00VBClu4PB5K3WOgIDl3uYY+5yhZcflw= MIME-Version: 1.0 Received: by 10.236.178.41 with SMTP id e29mr25792855yhm.117.1318857198586; Mon, 17 Oct 2011 06:13:18 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Mon, 17 Oct 2011 06:13:18 -0700 (PDT) In-Reply-To: <4E9B315A.6030607@pyro.eu.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> Date: Mon, 17 Oct 2011 21:13:18 +0800 X-Google-Sender-Auth: Gn88XrkBeknoXuFIeJbVKwyXogM Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:13:19 -0000 Hi, I've committed this to -HEAD in r226465. I'll MFC this to -9 and -8 in the next 3 or so days, re@ approval pending. Thanks, adrian From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 13:23:55 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 55F89106564A; Mon, 17 Oct 2011 13:23:55 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 0281B8FC08; Mon, 17 Oct 2011 13:23:55 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFnAX-0001HI-O0; Mon, 17 Oct 2011 14:23:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4KsPzrqEshQ3LW81+uIe0nLskU4/oZhhMsf6vK5JsQw=; b=B9i3M6bR5KY/Qjg7uqokRLWNr48pG55tgFk7EM9VOayEb1QhL8Oc87inY/yGFQFPpMnQe7IlhuOl4eZQxFe/rM0OdgoCNxcNwgK9Dl09odMFNFoSQpNlW1tuuSIxW8+vbkSldAZyCRMf+4vD7faTYFhmLR2nZRAAg8eMevCmjOA=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RFnAX-0001HF-Jo; Mon, 17 Oct 2011 14:23:53 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RFnAS-0004IJ-GF; Mon, 17 Oct 2011 14:23:52 +0100 Message-ID: <4E9C2C64.5030007@pyro.eu.org> Date: Mon, 17 Oct 2011 14:23:48 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 13:23:55 -0000 On 17/10/11 14:13, Adrian Chadd wrote: > I've committed this to -HEAD in r226465. > I'll MFC this to -9 and -8 in the next 3 or so days, re@ approval pending. Argh... there were a couple of issues someone pointed out to me off-list that you may not have seen: On 17/10/11 01:16, Gang 'Henry' Hu wrote: > There are some minor problems: > > + error = rum_do_request(sc, &req, buf + offset); > > At this line, you should cast buf to (char*), since buf is (void*) > which cannot be used in calculation... > > And you should also return 0 at the end of the function, else there > would be no return value.... I was going to get back to you with a slightly revised freebsd patch to fix those before you committed. Otherwise, Henry said it has fixed the problem for him (in 8.2-STABLE). Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 14:28:22 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C5FF106566B for ; Mon, 17 Oct 2011 14:28:22 +0000 (UTC) (envelope-from fodillemlinkarim@gmail.com) Received: from mail-qy0-f182.google.com (mail-qy0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 02D7B8FC0A for ; Mon, 17 Oct 2011 14:28:21 +0000 (UTC) Received: by qyg14 with SMTP id 14so2255460qyg.13 for ; Mon, 17 Oct 2011 07:28:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=BGHnYtcwTt8SthrnGfez7eFdyfofEK0OwdQ2QoK3VRs=; b=abkbaudcLAv9AUD6Th8s48m+mz+OE3Ik+zX10x44+8x4ghxAMVtQHzhqEM/MaonBM4 vaVp/YRQInDvyUu+YGN2kumr3NN6ZSSq5UTOXHW7+9FjeuTyR7jK3H5ULfdtl1bByBTv yy//ok8KziOoqTyNmVU1yYxIiB5p3UweW3MyU= Received: by 10.229.227.84 with SMTP id iz20mr389934qcb.164.1318861701093; Mon, 17 Oct 2011 07:28:21 -0700 (PDT) Received: from [192.168.1.71] ([208.85.112.101]) by mx.google.com with ESMTPS id eg7sm12314500qab.2.2011.10.17.07.28.18 (version=SSLv3 cipher=OTHER); Mon, 17 Oct 2011 07:28:19 -0700 (PDT) Message-ID: <4E9C3B7F.8090700@gmail.com> Date: Mon, 17 Oct 2011 10:28:15 -0400 From: Karim User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15 MIME-Version: 1.0 To: pyunyh@gmail.com References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> <20111012192730.GB9138@michelle.cdnetworks.com> In-Reply-To: <20111012192730.GB9138@michelle.cdnetworks.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops [solved!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 14:28:22 -0000 Hi, On 11-10-12 03:27 PM, YongHyeon PYUN wrote: > On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: >> Hi, >> On 11-10-12 01:03 PM, YongHyeon PYUN wrote: >>> On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > [...] > >>> Hmm, that indicates driver lost established link. msk(4) will >>> detect this condition and stop RX/TX MACs until it knows PHY >>> re-established a link. This may be the reason why you see occasional >>> packet drops. However I don't know why PHY loses established link >>> in the middle of working. >>> >> Yes, I am convinced this lost of link is related to the packet drops as >> well. At this point we can safely discard cabling issues or router >> issues (physical ones that is) since the same happens on a different >> network with different cables. >>>> From the code in e1000phy_status: >>>> >>>> static void >>>> e1000phy_status(struct mii_softc *sc) >>>> { >>>> struct mii_data *mii = sc->mii_pdata; >>>> int bmcr, bmsr, ssr; >>>> >>>> mii->mii_media_status = IFM_AVALID; >>>> mii->mii_media_active = IFM_ETHER; >>>> >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >>>> bmcr = PHY_READ(sc, E1000_CR); >>>> ssr = PHY_READ(sc, E1000_SSR); >>>> >>>> if (bmsr& E1000_SR_LINK_STATUS) >>>> mii->mii_media_status |= IFM_ACTIVE; >>>> >>>> >>>> I can see the bmsr& E1000_SR_LINK_STATUS check failing when the problem >>>> occurs. As a side note why are we ORing the same call twice isn't the >>>> same thing as calling it once: >>>> >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); >>>> >>> The E1000_SR_LINK_STATUS bit is latched low so it should be read >>> twice. If you want to read once use E1000_SSR_LINK bit of >>> E1000_SSR register but I remember that bit was not reliable on some >>> PHY models. >> Thanks for the explanation and the alternative. The ssr register seems >> to give me the right bit (E1000_SSR_LINK) but it also gives me an extra >> bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit >> would be/means? >> > I guess it's related with advanced power saving. It would indicate > current Energy detect status in PHY POV. > Generally Marvell's PHY will enter into automatic power saving mode > when it does not see any energy signal on the link. I don't know > exact time when it enters into that mode but it would take less > than 10 seconds if PHY do not see energy signal from link partner > once it initiated auto-negotiation. > However, e1000phy(4) always disables energy detect feature in > e1000phy_reset() so it wouldn't affect your issue, I guess. > > One interesting thing is that 0x100 of E1000_SSR register indicates > energy detect status is in "Sleep mode" which means it didn't > detect energy signal(i.e. lost link). I'm not sure whether this bit > report correct status when energy detect feature is disabled > though. > > Can you check whether your switch supports energy detect feature? > Or if your switch support EEE feature, try disabling it. > >>> By chance, does your back-ported driver include r222219? >>> If yes, did you cold boot after applying the change? >>> Warm boot does have effect. >> I do have this patch in the back-ported driver and due to several >> reasons I didn't cold boot the appliance. We will give that a try and see. >> > Ok, let me know whether that makes any difference or not. > >> To be more precises I have included msk patches up to r222516. >> >> Thanks! > [...] > _______________________________________________ > 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" After a weekend of test I can confirm the problem is gone with the back ported msk driver from FreeBSD 9 and a little bit of patching. Apart from the packet drops I also had various report from my snmp trap daemon. It was reporting the interface was going inactive and for a while I though the packet drop and inactivity reports were linked. It turned out there was a small race condition between the various polling components in msk_mediastatus() that was confusing the snmp daemon while the packet drops got solved by the back port. The race can be easily solved with the following patch: @@ -995,9 +996,11 @@ msk_mediastatus(struct ifnet *ifp, struct ifmediareq *ifmr) mii = device_get_softc(sc_if->msk_miibus); mii_pollstat(mii); - MSK_IF_UNLOCK(sc_if); + ifmr->ifm_active = mii->mii_media_active; ifmr->ifm_status = mii->mii_media_status; + + MSK_IF_UNLOCK(sc_if); } Without moving down the msk lock its possible for one thread to see its mii_media_status reset to IFM_AVALID in e1000phy_status() right before the assignment to ifmr->ifm_status. This resulted in false reports about interface inactivity in rare occasions between a kernel based probe and the snmp trap daemon. Thanks to everyone that chipped in to help, Karim. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 15:29:57 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D901E106566C for ; Mon, 17 Oct 2011 15:29:57 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 9858D8FC14 for ; Mon, 17 Oct 2011 15:29:57 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 08:29:56 -0700 From: Ben Hutchings To: freebsd-net@freebsd.org In-Reply-To: <1317309906.2743.9.camel@bwh-desktop> References: <1317309906.2743.9.camel@bwh-desktop> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Mon, 17 Oct 2011 16:29:54 +0100 Message-ID: <1318865394.2784.4.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2011 15:29:56.0447 (UTC) FILETIME=[9FDCA6F0:01CC8CE1] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18454.005 X-TM-AS-Result: No--8.580000-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 15:29:57 -0000 This is the fix/workaround I used: --- a/netinet/tcp_output.c +++ b/netinet/tcp_output.c @@ -1062,9 +1062,7 @@ * The TCP pseudo header checksum is always provided. * XXX: Fixme: This is currently not the case for IPv6. */ - if (tso) { - KASSERT(len > tp->t_maxopd - optlen, - ("%s: len <= tso_segsz", __func__)); + if (tso && len > tp->t_maxopd - optlen) { m->m_pkthdr.csum_flags |= CSUM_TSO; m->m_pkthdr.tso_segsz = tp->t_maxopd - optlen; } --- END --- But the correct thing to do may be to change the calculation of t_maxopd (untested): --- a/netinet/tcp_input.c +++ b/netinet/tcp_input.c @@ -3087,7 +3087,7 @@ tcp_mss_update(struct tcpcb *tp, int offer, struct hc_metrics_lite *metricptr, int *mtuflags) { - int mss; + int mss, ts_len; u_long maxmtu; struct inpcb *inp = tp->t_inpcb; struct hc_metrics_lite metrics; @@ -3212,22 +3212,17 @@ mss = max(mss, 64); /* - * maxopd stores the maximum length of data AND options - * in a segment; maxseg is the amount of data in a normal - * segment. We need to store this value (maxopd) apart - * from maxseg, because now every segment carries options - * and thus we normally have somewhat less data in segments. - */ - tp->t_maxopd = mss; - - /* * origoffer==-1 indicates that no segments were received yet. * In this case we just guess. */ if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP && (origoffer == -1 || (tp->t_flags & TF_RCVD_TSTMP) == TF_RCVD_TSTMP)) - mss -= TCPOLEN_TSTAMP_APPA; + ts_len = TCPOLEN_TSTAMP_APPA; + else + ts_len = 0; + + mss -= ts_len; #if (MCLBYTES & (MCLBYTES - 1)) == 0 if (mss > MCLBYTES) @@ -3237,6 +3232,15 @@ mss = mss / MCLBYTES * MCLBYTES; #endif tp->t_maxseg = mss; + + /* + * maxopd stores the maximum length of data AND options + * in a segment; maxseg is the amount of data in a normal + * segment. We need to store this value (maxopd) apart + * from maxseg, because now every segment carries options + * and thus we normally have somewhat less data in segments. + */ + tp->t_maxopd = mss + ts_len; } void --- END --- Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 16:00:24 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 71BE7106564A for ; Mon, 17 Oct 2011 16:00:24 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 3E6D28FC12 for ; Mon, 17 Oct 2011 16:00:24 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HG0O88070747 for ; Mon, 17 Oct 2011 16:00:24 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HG0OJ6070746; Mon, 17 Oct 2011 16:00:24 GMT (envelope-from gnats) Date: Mon, 17 Oct 2011 16:00:24 GMT Message-Id: <201110171600.p9HG0OJ6070746@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:00:24 -0000 The following reply was made to PR kern/155604; it has been noted by GNATS. From: Gleb Smirnoff To: Steve Polyack Cc: bug-followup@FreeBSD.org Subject: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic Date: Mon, 17 Oct 2011 19:59:42 +0400 Steve, looks like this bug is fixed in 8.2 and later versions of FreeBSD. Can I close the PR? -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 16:09:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F312106566B for ; Mon, 17 Oct 2011 16:09:51 +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 E6F7E8FC08 for ; Mon, 17 Oct 2011 16:09:50 +0000 (UTC) Received: (qmail 83853 invoked from network); 17 Oct 2011 14:50:09 -0000 Received: from localhost (HELO [127.0.0.1]) ([127.0.0.1]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 17 Oct 2011 14:50:09 -0000 Message-ID: <4E9C534D.4090405@freebsd.org> Date: Mon, 17 Oct 2011 18:09:49 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: Ben Hutchings References: <1317309906.2743.9.camel@bwh-desktop> <1318865394.2784.4.camel@bwh-desktop> In-Reply-To: <1318865394.2784.4.camel@bwh-desktop> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:09:51 -0000 On 17.10.2011 17:29, Ben Hutchings wrote: > This is the fix/workaround I used: Thanks for the fix. I'll review it and put it into FreeBSD maybe in a slightly different form. -- Andre > --- a/netinet/tcp_output.c > +++ b/netinet/tcp_output.c > @@ -1062,9 +1062,7 @@ > * The TCP pseudo header checksum is always provided. > * XXX: Fixme: This is currently not the case for IPv6. > */ > - if (tso) { > - KASSERT(len> tp->t_maxopd - optlen, > - ("%s: len<= tso_segsz", __func__)); > + if (tso&& len> tp->t_maxopd - optlen) { > m->m_pkthdr.csum_flags |= CSUM_TSO; > m->m_pkthdr.tso_segsz = tp->t_maxopd - optlen; > } > --- END --- > > But the correct thing to do may be to change the calculation of t_maxopd > (untested): > > --- a/netinet/tcp_input.c > +++ b/netinet/tcp_input.c > @@ -3087,7 +3087,7 @@ > tcp_mss_update(struct tcpcb *tp, int offer, > struct hc_metrics_lite *metricptr, int *mtuflags) > { > - int mss; > + int mss, ts_len; > u_long maxmtu; > struct inpcb *inp = tp->t_inpcb; > struct hc_metrics_lite metrics; > @@ -3212,22 +3212,17 @@ > mss = max(mss, 64); > > /* > - * maxopd stores the maximum length of data AND options > - * in a segment; maxseg is the amount of data in a normal > - * segment. We need to store this value (maxopd) apart > - * from maxseg, because now every segment carries options > - * and thus we normally have somewhat less data in segments. > - */ > - tp->t_maxopd = mss; > - > - /* > * origoffer==-1 indicates that no segments were received yet. > * In this case we just guess. > */ > if ((tp->t_flags& (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP&& > (origoffer == -1 || > (tp->t_flags& TF_RCVD_TSTMP) == TF_RCVD_TSTMP)) > - mss -= TCPOLEN_TSTAMP_APPA; > + ts_len = TCPOLEN_TSTAMP_APPA; > + else > + ts_len = 0; > + > + mss -= ts_len; > > #if (MCLBYTES& (MCLBYTES - 1)) == 0 > if (mss> MCLBYTES) > @@ -3237,6 +3232,15 @@ > mss = mss / MCLBYTES * MCLBYTES; > #endif > tp->t_maxseg = mss; > + > + /* > + * maxopd stores the maximum length of data AND options > + * in a segment; maxseg is the amount of data in a normal > + * segment. We need to store this value (maxopd) apart > + * from maxseg, because now every segment carries options > + * and thus we normally have somewhat less data in segments. > + */ > + tp->t_maxopd = mss + ts_len; > } > > void > --- END --- > > Ben. > From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 16:50:13 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A3AEF106564A for ; Mon, 17 Oct 2011 16:50:13 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9285A8FC18 for ; Mon, 17 Oct 2011 16:50:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HGoD27019589 for ; Mon, 17 Oct 2011 16:50:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HGoDLv019588; Mon, 17 Oct 2011 16:50:13 GMT (envelope-from gnats) Date: Mon, 17 Oct 2011 16:50:13 GMT Message-Id: <201110171650.p9HGoDLv019588@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Steve Polyack Cc: Subject: Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steve Polyack List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 16:50:13 -0000 The following reply was made to PR kern/155604; it has been noted by GNATS. From: Steve Polyack To: Gleb Smirnoff Cc: bug-followup@FreeBSD.org Subject: Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic Date: Mon, 17 Oct 2011 12:04:35 -0400 On 10/17/2011 11:59 AM, Gleb Smirnoff wrote: > Steve, > > looks like this bug is fixed in 8.2 and later versions of FreeBSD. > Can I close the PR? > IMHO, the fix is merely a workaround (disabling FLOWTABLE by default in the kernel configuration). If a user turns flowtable on, they will still encounter the same problem as I described. We don't have a reason to turn the flowtable feature back on, so it doesn't really affect us either way. I'll leave it up to you as to whether you want to close it or have someone take a deeper look. Thanks for checking, -- http://www.intermedix.com Steve Polyack, System Engineer T: 412-422-3463 x4026 spolyack@collaborativefusion.com The information contained in this message is confidential and may be privileged and/or protected under law. If you received this message in error, please notify us immediately by forwarding a copy to karen.collier@intermedix.com and then deleting the original message and any attachments. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 17:10:50 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BED60106566B for ; Mon, 17 Oct 2011 17:10:50 +0000 (UTC) (envelope-from hoomanfazaeli@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 7D62C8FC15 for ; Mon, 17 Oct 2011 17:10:48 +0000 (UTC) Received: by ggeq3 with SMTP id q3so4147686gge.13 for ; Mon, 17 Oct 2011 10:10:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type; bh=nO06ejtXIIK++OonnvWXOzdKg85zhpHRoW42pPWEhc8=; b=t7HKUwERKAxFdTZdhoUcEwYBQi6miYzFbirxwQCoJhhYoZZjnUvekmM4FQ74vrIdY5 5voOZqTLaQVJ6iPlIvsNaxJ0FDKXFkmo043PxeWhYhIQ1Hv17jWsGmWzY8hTjgi2gdUb Z44RtWvpf9l+aGXEWP47rkOx2sLuMzx2bioIM= Received: by 10.223.85.139 with SMTP id o11mr25601731fal.0.1318871447946; Mon, 17 Oct 2011 10:10:47 -0700 (PDT) Received: from [127.0.0.1] ([84.241.57.181]) by mx.google.com with ESMTPS id b16sm15602758fao.7.2011.10.17.10.10.45 (version=SSLv3 cipher=OTHER); Mon, 17 Oct 2011 10:10:47 -0700 (PDT) Message-ID: <4E9C6190.4030404@gmail.com> Date: Mon, 17 Oct 2011 20:40:40 +0330 From: Hooman Fazaeli User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.23) Gecko/20110920 Thunderbird/3.1.15 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , Jack Vogel Content-Type: multipart/mixed; boundary="------------050903060701080907090208" Cc: Subject: misplaced #endif in ixgbe X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:10:50 -0000 This is a multi-part message in MIME format. --------------050903060701080907090208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit A misplaced #endif in ixgbe_ioctl() causes all sorts of problems when INET and INET6 are undefined. Pls. see the attached patch. --------------050903060701080907090208 Content-Type: text/plain; name="ixgbe.c.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ixgbe.c.diff" --- ixgbe.c.orig 2011-10-17 20:37:17.000000000 +0330 +++ ixgbe.c 2011-10-17 20:38:40.000000000 +0330 @@ -898,8 +898,8 @@ arp_ifinit(ifp, ifa); } else error = ether_ioctl(ifp, command, data); - break; #endif + break; case SIOCSIFMTU: IOCTL_DEBUGOUT("ioctl: SIOCSIFMTU (Set Interface MTU)"); if (ifr->ifr_mtu > IXGBE_MAX_FRAME_SIZE - ETHER_HDR_LEN) { --------------050903060701080907090208-- From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 17:50:11 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2E059106566C for ; Mon, 17 Oct 2011 17:50:11 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D3C88FC0C for ; Mon, 17 Oct 2011 17:50:11 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9HHoAjv074845 for ; Mon, 17 Oct 2011 17:50:10 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9HHoAoX074844; Mon, 17 Oct 2011 17:50:10 GMT (envelope-from gnats) Date: Mon, 17 Oct 2011 17:50:10 GMT Message-Id: <201110171750.p9HHoAoX074844@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Gleb Smirnoff Cc: Subject: Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Gleb Smirnoff List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:50:11 -0000 The following reply was made to PR kern/155604; it has been noted by GNATS. From: Gleb Smirnoff To: Steve Polyack Cc: bug-followup@FreeBSD.org Subject: Re: kern/155604: [flowtable] Flowtable excessively caches dest MAC addresses for outgoing traffic Date: Mon, 17 Oct 2011 21:45:56 +0400 On Mon, Oct 17, 2011 at 12:04:35PM -0400, Steve Polyack wrote: S> > looks like this bug is fixed in 8.2 and later versions of FreeBSD. S> > Can I close the PR? S> > S> IMHO, the fix is merely a workaround (disabling FLOWTABLE by default in S> the kernel configuration). If a user turns flowtable on, they will S> still encounter the same problem as I described. S> S> We don't have a reason to turn the flowtable feature back on, so it S> doesn't really affect us either way. I'll leave it up to you as to S> whether you want to close it or have someone take a deeper look. You misunderstood me. I meant that the problem is no longer present with flowtable turned on. I have just tried to reproduce your problem on 8.2 and on head, and failed. I've found some reports in my private emails that claim that problem is only present only in 8.0 and 8.1. However, I haven't find the actual fix in commitlogs. -- Totus tuus, Glebius. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 17:51:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CEA87106566B for ; Mon, 17 Oct 2011 17:51:40 +0000 (UTC) (envelope-from pyunyh@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 526DD8FC16 for ; Mon, 17 Oct 2011 17:51:39 +0000 (UTC) Received: by wyi40 with SMTP id 40so2557544wyi.13 for ; Mon, 17 Oct 2011 10:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:date:to:cc:subject:message-id:reply-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=QSOfqkm0jXhAlfDJzCSZBCmoLtmtHuhbzugDyhKLirE=; b=Y9QypJMip0rZSh+pjHpCW86bEP/TBsx8WB4BkVBhBqIdcABuNHVVbk1dLp0H9YfdYj ayx4GKcoh5DjsJLBhXvGSyi+XXFseToqV043ZMDCjy/Y2aZZHNHm9uF2xf3i9/xcBjAA mLk7EtTC2YZ/kQ5HgYBYUTrjz4J0uAiMio748= Received: by 10.216.160.83 with SMTP id t61mr120221wek.77.1318873898995; Mon, 17 Oct 2011 10:51:38 -0700 (PDT) Received: from pyunyh@gmail.com ([174.35.1.224]) by mx.google.com with ESMTPS id q30sm16628576wbn.17.2011.10.17.10.51.35 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 17 Oct 2011 10:51:37 -0700 (PDT) Received: by pyunyh@gmail.com (sSMTP sendmail emulation); Mon, 17 Oct 2011 10:49:55 -0700 From: YongHyeon PYUN Date: Mon, 17 Oct 2011 10:49:55 -0700 To: Karim Message-ID: <20111017174955.GA3509@michelle.cdnetworks.com> References: <4E94637A.5090607@gmail.com> <20111011171029.GA5661@michelle.cdnetworks.com> <4E959F06.6040906@gmail.com> <20111012170347.GA9138@michelle.cdnetworks.com> <4E95DDEB.1090500@gmail.com> <20111012192730.GB9138@michelle.cdnetworks.com> <4E9C3B7F.8090700@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4E9C3B7F.8090700@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: if_msk.c link negotiation / packet drops [solved!] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pyunyh@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 17:51:40 -0000 On Mon, Oct 17, 2011 at 10:28:15AM -0400, Karim wrote: > Hi, > > On 11-10-12 03:27 PM, YongHyeon PYUN wrote: > >On Wed, Oct 12, 2011 at 02:35:23PM -0400, Karim wrote: > >>Hi, > >>On 11-10-12 01:03 PM, YongHyeon PYUN wrote: > >>>On Wed, Oct 12, 2011 at 10:07:02AM -0400, Karim wrote: > >[...] > > > >>>Hmm, that indicates driver lost established link. msk(4) will > >>>detect this condition and stop RX/TX MACs until it knows PHY > >>>re-established a link. This may be the reason why you see occasional > >>>packet drops. However I don't know why PHY loses established link > >>>in the middle of working. > >>> > >>Yes, I am convinced this lost of link is related to the packet drops as > >>well. At this point we can safely discard cabling issues or router > >>issues (physical ones that is) since the same happens on a different > >>network with different cables. > >>>> From the code in e1000phy_status: > >>>> > >>>>static void > >>>>e1000phy_status(struct mii_softc *sc) > >>>>{ > >>>> struct mii_data *mii = sc->mii_pdata; > >>>> int bmcr, bmsr, ssr; > >>>> > >>>> mii->mii_media_status = IFM_AVALID; > >>>> mii->mii_media_active = IFM_ETHER; > >>>> > >>>> bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >>>> bmcr = PHY_READ(sc, E1000_CR); > >>>> ssr = PHY_READ(sc, E1000_SSR); > >>>> > >>>> if (bmsr& E1000_SR_LINK_STATUS) > >>>> mii->mii_media_status |= IFM_ACTIVE; > >>>> > >>>> > >>>>I can see the bmsr& E1000_SR_LINK_STATUS check failing when the > >>>>problem > >>>>occurs. As a side note why are we ORing the same call twice isn't the > >>>>same thing as calling it once: > >>>> > >>>>bmsr = PHY_READ(sc, E1000_SR) | PHY_READ(sc, E1000_SR); > >>>> > >>>The E1000_SR_LINK_STATUS bit is latched low so it should be read > >>>twice. If you want to read once use E1000_SSR_LINK bit of > >>>E1000_SSR register but I remember that bit was not reliable on some > >>>PHY models. > >>Thanks for the explanation and the alternative. The ssr register seems > >>to give me the right bit (E1000_SSR_LINK) but it also gives me an extra > >>bit 0x0100 that is not defined in e1000phyreg.h. Any idea what that bit > >>would be/means? > >> > >I guess it's related with advanced power saving. It would indicate > >current Energy detect status in PHY POV. > >Generally Marvell's PHY will enter into automatic power saving mode > >when it does not see any energy signal on the link. I don't know > >exact time when it enters into that mode but it would take less > >than 10 seconds if PHY do not see energy signal from link partner > >once it initiated auto-negotiation. > >However, e1000phy(4) always disables energy detect feature in > >e1000phy_reset() so it wouldn't affect your issue, I guess. > > > >One interesting thing is that 0x100 of E1000_SSR register indicates > >energy detect status is in "Sleep mode" which means it didn't > >detect energy signal(i.e. lost link). I'm not sure whether this bit > >report correct status when energy detect feature is disabled > >though. > > > >Can you check whether your switch supports energy detect feature? > >Or if your switch support EEE feature, try disabling it. > > > >>>By chance, does your back-ported driver include r222219? > >>>If yes, did you cold boot after applying the change? > >>>Warm boot does have effect. > >>I do have this patch in the back-ported driver and due to several > >>reasons I didn't cold boot the appliance. We will give that a try and see. > >> > >Ok, let me know whether that makes any difference or not. > > > >>To be more precises I have included msk patches up to r222516. > >> > >>Thanks! > >[...] > >_______________________________________________ > >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" > After a weekend of test I can confirm the problem is gone with the back > ported msk driver from FreeBSD 9 and a little bit of patching. > > Apart from the packet drops I also had various report from my snmp trap > daemon. It was reporting the interface was going inactive and for a > while I though the packet drop and inactivity reports were linked. It > turned out there was a small race condition between the various polling > components in msk_mediastatus() that was confusing the snmp daemon while > the packet drops got solved by the back port. The race can be easily > solved with the following patch: > > > @@ -995,9 +996,11 @@ msk_mediastatus(struct ifnet *ifp, struct > ifmediareq *ifmr) > mii = device_get_softc(sc_if->msk_miibus); > > mii_pollstat(mii); > - MSK_IF_UNLOCK(sc_if); > + > ifmr->ifm_active = mii->mii_media_active; > ifmr->ifm_status = mii->mii_media_status; > + > + MSK_IF_UNLOCK(sc_if); > } > > Without moving down the msk lock its possible for one thread to see its > mii_media_status reset to IFM_AVALID in e1000phy_status() right before > the assignment to ifmr->ifm_status. This resulted in false reports about > interface inactivity in rare occasions between a kernel based probe and > the snmp trap daemon. This may happen when user application issues multiple SIOCGIFMEDIA ioctls without waiting for the completion of previous ioctl request. On second thought, I think it would be better to close the race because it's hard to predict how user application behaves. Thanks for pointing out. I'll handle this. > > Thanks to everyone that chipped in to help, > > Karim. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 23:28:59 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28FE91065674 for ; Mon, 17 Oct 2011 23:28:59 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (exchange.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 09FFF8FC18 for ; Mon, 17 Oct 2011 23:28:58 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 17 Oct 2011 16:28:58 -0700 From: Ben Hutchings To: Andre Oppermann In-Reply-To: <4E9C534D.4090405@freebsd.org> References: <1317309906.2743.9.camel@bwh-desktop> <1318865394.2784.4.camel@bwh-desktop> <4E9C534D.4090405@freebsd.org> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Tue, 18 Oct 2011 00:28:55 +0100 Message-ID: <1318894136.2784.76.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2011 23:28:58.0650 (UTC) FILETIME=[8B8CC7A0:01CC8D24] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18454.005 X-TM-AS-Result: No--17.023300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: freebsd-net@freebsd.org Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:28:59 -0000 On Mon, 2011-10-17 at 18:09 +0200, Andre Oppermann wrote: > On 17.10.2011 17:29, Ben Hutchings wrote: > > This is the fix/workaround I used: > > Thanks for the fix. I'll review it and put it into FreeBSD maybe in > a slightly different form. Which one? One is tested but maybe not right; the other looks right but is not tested! Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Mon Oct 17 23:59:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F205B1065672; Mon, 17 Oct 2011 23:59:54 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id A8A898FC23; Mon, 17 Oct 2011 23:59:54 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 7528825D3892; Mon, 17 Oct 2011 23:59:53 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id A3D6ABD3C4D; Mon, 17 Oct 2011 23:59:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id vJTxq09qkyt3; Mon, 17 Oct 2011 23:59:51 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id AFA5BBD3C37; Mon, 17 Oct 2011 23:59:51 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <1318894136.2784.76.camel@bwh-desktop> Date: Mon, 17 Oct 2011 23:59:50 +0000 Content-Transfer-Encoding: 7bit Message-Id: <68546593-B3E1-44D8-B512-4FD99B90D989@lists.zabbadoz.net> References: <1317309906.2743.9.camel@bwh-desktop> <1318865394.2784.4.camel@bwh-desktop> <4E9C534D.4090405@freebsd.org> <1318894136.2784.76.camel@bwh-desktop> To: Ben Hutchings X-Mailer: Apple Mail (2.1084) Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 23:59:55 -0000 On 17. Oct 2011, at 23:28 , Ben Hutchings wrote: > On Mon, 2011-10-17 at 18:09 +0200, Andre Oppermann wrote: >> On 17.10.2011 17:29, Ben Hutchings wrote: >>> This is the fix/workaround I used: >> >> Thanks for the fix. I'll review it and put it into FreeBSD maybe in >> a slightly different form. > > Which one? One is tested but maybe not right; the other looks right but > is not tested! and here's the real question -- was it always broken or did a commit during the last years introduce the problem? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 03:36:41 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C5689106566C; Tue, 18 Oct 2011 03:36:41 +0000 (UTC) (envelope-from steven@pyro.eu.org) Received: from falkenstein-1.sn.de.cluster.ok24.net (maidenhead-1.wnm.uk.cluster.ok24.net [IPv6:2002:4e2f:2f89:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 716088FC08; Tue, 18 Oct 2011 03:36:41 +0000 (UTC) Received: from maidenhead-1.wnm.uk.cluster.ok24.net ([10.1.0.1] helo=falkenstein-1.sn.de.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RG0Tn-0002LM-L8; Tue, 18 Oct 2011 04:36:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=simple/simple; d=pyro.eu.org; s=10.2011; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=lrmqcfxYmBPZX1NxCmbUIXXVVNFYDW1UpHAkRHV/eBc=; b=ist71bhAdu1EXXumFdCAVr9f39uxd9gPB5ANOw0LK6XRoGsd9JGxnKZTsmmVE9xvGG10+OhGnuWO4gDs6qWQlJpuPTI1spWdTamEthfEswvY4CJgBYRjpAIzAmrZfxGBncE1svbhurbYg5mfEG7QjZfq08v3YhmjRJ0EC73XVIc=; Received: from 188-220-33-66.zone11.bethere.co.uk ([188.220.33.66] helo=guisborough-1.rcc.uk.cluster.ok24.net) by falkenstein-1.sn.de.cluster.ok24.net with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1RG0Tn-0002LJ-Gb; Tue, 18 Oct 2011 04:36:39 +0100 X-Spam-Status: No, score=-4.4 required=2.0 tests=ALL_TRUSTED, AWL, BAYES_00, DKIM_POLICY_SIGNALL Received: from [192.168.0.110] (helo=[192.168.0.9]) by guisborough-1.rcc.uk.cluster.ok24.net with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1RG0Ti-00056t-4H; Tue, 18 Oct 2011 04:36:38 +0100 Message-ID: <4E9CF441.5060103@pyro.eu.org> Date: Tue, 18 Oct 2011 04:36:33 +0100 From: Steven Chamberlain User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20111006 Icedove/3.0.11 MIME-Version: 1.0 To: Adrian Chadd References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> <4E9C2C64.5030007@pyro.eu.org> In-Reply-To: <4E9C2C64.5030007@pyro.eu.org> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 03:36:41 -0000 Hi Adrian, I see that revision 226467 by bz already fixed the compiler warnings. I've now built and tested this on freebsd-8 amd64. The same bugfix has been working throughout the day on a couple of openbsd i386 boxes with rum hardware too. I guess the PR number you asked me for yesterday is just kern/149643 ? Many thanks for getting this into -HEAD. Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 03:40:10 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 022A4106564A for ; Tue, 18 Oct 2011 03:40:10 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id E62D98FC0C for ; Tue, 18 Oct 2011 03:40:09 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I3e9WI034222 for ; Tue, 18 Oct 2011 03:40:09 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I3e9EN034219; Tue, 18 Oct 2011 03:40:09 GMT (envelope-from gnats) Date: Tue, 18 Oct 2011 03:40:09 GMT Message-Id: <201110180340.p9I3e9EN034219@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Steven Chamberlain Cc: Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Steven Chamberlain List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 03:40:10 -0000 The following reply was made to PR kern/149643; it has been noted by GNATS. From: Steven Chamberlain To: Adrian Chadd Cc: freebsd-net@freebsd.org, bug-followup@FreeBSD.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode Date: Tue, 18 Oct 2011 04:36:33 +0100 Hi Adrian, I see that revision 226467 by bz already fixed the compiler warnings. I've now built and tested this on freebsd-8 amd64. The same bugfix has been working throughout the day on a couple of openbsd i386 boxes with rum hardware too. I guess the PR number you asked me for yesterday is just kern/149643 ? Many thanks for getting this into -HEAD. Regards, -- Steven Chamberlain steven@pyro.eu.org From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 03:45:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7EA8B106566C for ; Tue, 18 Oct 2011 03:45:00 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3AD3B8FC13 for ; Tue, 18 Oct 2011 03:44:59 +0000 (UTC) Received: by ggeq3 with SMTP id q3so207500gge.13 for ; Mon, 17 Oct 2011 20:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=P3YHjSmfiZfqquF2u07qYoPrKy80FPU+ZbWqdv+sZ4g=; b=KaPGV4qrbifk0DXikjDtreWNaZeiNRqnd5O0Z2IGZa2YUKfn5GfenrWU0bUcF9VKZY dTLwHa+xNt147zk44lPBPWQAjv2bqtpd8gl79mi1hBixZWTpG3YaS9bW7T+3vQ9dsxea n2h+wOzPqqG5M5YiDNa/PoH9WIVPRCCqwOETA= MIME-Version: 1.0 Received: by 10.236.175.195 with SMTP id z43mr604443yhl.66.1318909499468; Mon, 17 Oct 2011 20:44:59 -0700 (PDT) Sender: adrian.chadd@gmail.com Received: by 10.236.95.147 with HTTP; Mon, 17 Oct 2011 20:44:59 -0700 (PDT) In-Reply-To: <4E9CF441.5060103@pyro.eu.org> References: <201110152200.p9FM0QUO044812@freefall.freebsd.org> <4E9A5FB6.7040904@pyro.eu.org> <4E9B062A.9050408@pyro.eu.org> <4E9B315A.6030607@pyro.eu.org> <4E9C2C64.5030007@pyro.eu.org> <4E9CF441.5060103@pyro.eu.org> Date: Tue, 18 Oct 2011 11:44:59 +0800 X-Google-Sender-Auth: uoVkgxrSo6TVkizsQc03pcj8SaA Message-ID: From: Adrian Chadd To: Steven Chamberlain Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 03:45:00 -0000 On 18 October 2011 11:36, Steven Chamberlain wrote: > Hi Adrian, > > I see that revision 226467 by bz already fixed the compiler warnings. > I've now built and tested this on freebsd-8 amd64. Sweet. I'll just assume at this point that it'll work on FreeBSD-9 and aim to get it into the tree in the next few days. > The same bugfix has been working throughout the day on a couple of > openbsd i386 boxes with rum hardware too. Great news :) I'm sure the OpenBSD guys will appreciate being sent a bugfix as well. Just make sure you mention it came from FreeBSD. :) > I guess the PR number you asked me for yesterday is just kern/149643 ? I'll check it out, thanks! :) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 03:49:51 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1498D106564A; Tue, 18 Oct 2011 03:49:51 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DEA7C8FC08; Tue, 18 Oct 2011 03:49:50 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I3noR9043070; Tue, 18 Oct 2011 03:49:50 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I3noYs043066; Tue, 18 Oct 2011 03:49:50 GMT (envelope-from linimon) Date: Tue, 18 Oct 2011 03:49:50 GMT Message-Id: <201110180349.p9I3noYs043066@freefall.freebsd.org> To: onwahe@gmail.com, linimon@FreeBSD.org, freebsd-net@FreeBSD.org, qingli@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/159602: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 03:49:51 -0000 Synopsis: [netinet] [patch] arp_ifscrub() is called even if IFF_NOARP flag is set State-Changed-From-To: open->patched State-Changed-By: linimon State-Changed-When: Tue Oct 18 03:49:20 UTC 2011 State-Changed-Why: Merged to 9, but I don't know if it is mergeable to 7 or 8. Responsible-Changed-From-To: freebsd-net->qingli Responsible-Changed-By: linimon Responsible-Changed-When: Tue Oct 18 03:49:20 UTC 2011 Responsible-Changed-Why: http://www.freebsd.org/cgi/query-pr.cgi?pr=159602 From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 04:20:12 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 98F4C106566B for ; Tue, 18 Oct 2011 04:20:12 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 88CBE8FC19 for ; Tue, 18 Oct 2011 04:20:12 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I4KCEX070612 for ; Tue, 18 Oct 2011 04:20:12 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I4KC70070611; Tue, 18 Oct 2011 04:20:12 GMT (envelope-from gnats) Date: Tue, 18 Oct 2011 04:20:12 GMT Message-Id: <201110180420.p9I4KC70070611@freefall.freebsd.org> To: freebsd-net@FreeBSD.org From: Adrian Chadd Cc: Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Adrian Chadd List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 04:20:13 -0000 The following reply was made to PR kern/149643; it has been noted by GNATS. From: Adrian Chadd To: Steven Chamberlain Cc: freebsd-net@freebsd.org, bug-followup@freebsd.org Subject: Re: kern/149643: [rum] device not sending proper beacon frames in ap mode Date: Tue, 18 Oct 2011 11:44:59 +0800 On 18 October 2011 11:36, Steven Chamberlain wrote: > Hi Adrian, > > I see that revision 226467 by bz already fixed the compiler warnings. > I've now built and tested this on freebsd-8 amd64. Sweet. I'll just assume at this point that it'll work on FreeBSD-9 and aim to get it into the tree in the next few days. > The same bugfix has been working throughout the day on a couple of > openbsd i386 boxes with rum hardware too. Great news :) I'm sure the OpenBSD guys will appreciate being sent a bugfix as well. Just make sure you mention it came from FreeBSD. :) > I guess the PR number you asked me for yesterday is just kern/149643 ? I'll check it out, thanks! :) Adrian From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 08:15:42 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C64E2106566C; Tue, 18 Oct 2011 08:15:42 +0000 (UTC) (envelope-from glebius@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 9DE2D8FC19; Tue, 18 Oct 2011 08:15:42 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9I8FgGT024761; Tue, 18 Oct 2011 08:15:42 GMT (envelope-from glebius@freefall.freebsd.org) Received: (from glebius@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9I8Fgf8024757; Tue, 18 Oct 2011 08:15:42 GMT (envelope-from glebius) Date: Tue, 18 Oct 2011 08:15:42 GMT Message-Id: <201110180815.p9I8Fgf8024757@freefall.freebsd.org> To: emz@norma.perm.ru, glebius@FreeBSD.org, freebsd-net@FreeBSD.org From: glebius@FreeBSD.org Cc: Subject: Re: kern/144572: [carp] CARP preemption mode traffic partially goes to backup node X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 08:15:42 -0000 Synopsis: [carp] CARP preemption mode traffic partially goes to backup node State-Changed-From-To: closed->open State-Changed-By: glebius State-Changed-When: Tue Oct 18 08:15:18 UTC 2011 State-Changed-Why: Submitter claims (via irc) that email problem is fixed. http://www.freebsd.org/cgi/query-pr.cgi?pr=144572 From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 11:05:24 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 20CE9106564A for ; Tue, 18 Oct 2011 11:05:24 +0000 (UTC) (envelope-from andrew@ort-service.com) Received: from ort-service.com (ort-service.com [91.202.243.197]) by mx1.freebsd.org (Postfix) with ESMTP id 976A58FC0A for ; Tue, 18 Oct 2011 11:05:23 +0000 (UTC) Received: from [172.16.2.35] (beef64.ort [172.16.2.35]) (authenticated bits=0) by ort-service.com (8.14.1/8.14.1) with ESMTP id p9I9v1FA011024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 18 Oct 2011 12:57:03 +0300 From: andrew bliznak To: freebsd-net@freebsd.org In-Reply-To: <20111016010856.GM39118@alchemy.franken.de> References: <20111009165838.GA19886@alchemy.franken.de> <20111010192238.GC1781@michelle.cdnetworks.com> <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> <20111016010856.GM39118@alchemy.franken.de> Content-Type: text/plain; charset="us-ascii" Organization: "Ort" LTD. Date: Tue, 18 Oct 2011 12:57:01 +0300 Message-ID: <1318931821.55578.2.camel@beef64> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 11:05:24 -0000 On Sun, 2011-10-16 at 03:08 +0200, Marius Strobl wrote: > On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: > > > > > > On 15 Oct 2011, at 22:56, Marius Strobl wrote: > > > > > > > > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > > > rl(4) only 8129 need testing, 8139 don't) please give the following > > > patch a try in order to ensure it doesn't break anything? > > > for 9/head: > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > for 8: > > > http://people.freebsd.org/~marius/mii_bitbang.diff8 > > > > > > Thanks, > > > Marius > > > > > > > > > While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... > > > > What do you think the patch might break ? > > > > Basically, if there's something wrong with the patch the driver should > fail to attach, if it still does and gets a link all should be fine. > > Marius > run OK on FreeBSD 10.0-CURRENT #22 r226300M nge0: port 0xd800-0xd8ff mem 0xdffff000-0xdfffffff irq 22 at device 2.0 on pci1 miibus0: on nge0 nsgphy0: PHY 1 on miibus0 none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto nge0: Ethernet address: 00:30:4f:1e:e4:49 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 16:46:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E2F6106566B for ; Tue, 18 Oct 2011 16:46:00 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id E03BC8FC14 for ; Tue, 18 Oct 2011 16:45:59 +0000 (UTC) Received: by wwi18 with SMTP id 18so1136975wwi.31 for ; Tue, 18 Oct 2011 09:45:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=kGShnbTBkMwtTl+QW7lnTP2E/SvbsKaFloDoXUhEZCk=; b=KXTJuRsuWB6gWreswmkxqNNrtbuxby0fzA7/Ih9JGesQsUukXTp8mFIF4UF1klKisz u1TdxczHipcBgQYRXVVhI5AGSJIZII7ZVkJb7YMjZeiCXLiMZ0l6dsiRT5fnqqhRg37Z sO8kJf8xn2dekw57+de0hv7IB15rCivfhKSDg= MIME-Version: 1.0 Received: by 10.227.24.1 with SMTP id t1mr1093407wbb.107.1318956358848; Tue, 18 Oct 2011 09:45:58 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Tue, 18 Oct 2011 09:45:58 -0700 (PDT) Date: Tue, 18 Oct 2011 12:45:58 -0400 Message-ID: From: Ryan Stone To: freebsd-net Content-Type: text/plain; charset=ISO-8859-1 Subject: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 16:46:00 -0000 ether_demux currently assumes that all vlan-tagged packets that it sees have had the vlan stripped out and the M_VLAN tag is set, so it never checks the ether type for a vlan. However ng_ether_rcv_upper currently does not guarantee that this is the case(and there may be other code paths where this is also true). Does anybody have any strong feelings as to where the fix should go? Making ether_demux handle it is guaranteed to catch all cases but it does add a bit more overhead to check for a vlan tag at each stage. From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 17:55:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A196F106564A; Tue, 18 Oct 2011 17:55:53 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 75AB58FC0A; Tue, 18 Oct 2011 17:55:53 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 2491546B0A; Tue, 18 Oct 2011 13:55:53 -0400 (EDT) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id A35C58A02E; Tue, 18 Oct 2011 13:55:52 -0400 (EDT) From: John Baldwin To: freebsd-net@freebsd.org Date: Tue, 18 Oct 2011 13:04:16 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110617; KDE/4.5.5; amd64; ; ) References: <1318018310.27029.10.camel@hitfishpass-lx.corp.yahoo.com> <20111011181219.GB5661@michelle.cdnetworks.com> <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> In-Reply-To: <1318362745.2724.22.camel@hitfishpass-lx.corp.yahoo.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201110181304.16746.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.6 (bigwig.baldwin.cx); Tue, 18 Oct 2011 13:55:52 -0400 (EDT) Cc: "pyunyh@gmail.com" , David Christensen , Pyun YongHyeon , Sean Bruno , "davidch@freebsd.org" Subject: Re: bce(4) with IPMI X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:55:53 -0000 On Tuesday, October 11, 2011 3:52:25 pm Sean Bruno wrote: > In addition, the IPMI driver attaches to "something" and I can poke at > it via ipmitool. So, from the driver perspective, the attempt to detect > MFW enabled doesn't work as the chipset still thinks that its "on". The ipmi driver attaching to the BMC is independent. You can have the BMC active even though it's network channel is unavailable, so I wouldn't count on that datapoint being meaningful. -- John Baldwin From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 17:59:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 33176106566C for ; Tue, 18 Oct 2011 17:59:18 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id A3D5E8FC17 for ; Tue, 18 Oct 2011 17:59:17 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.4/8.14.4/ALCHEMY.FRANKEN.DE) with ESMTP id p9IHxGFM016507; Tue, 18 Oct 2011 19:59:16 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.4/8.14.4/Submit) id p9IHxFLg016506; Tue, 18 Oct 2011 19:59:15 +0200 (CEST) (envelope-from marius) Date: Tue, 18 Oct 2011 19:59:15 +0200 From: Marius Strobl To: andrew bliznak Message-ID: <20111018175915.GA16477@alchemy.franken.de> References: <20111011212318.GC81376@alchemy.franken.de> <20111011225531.GD5661@michelle.cdnetworks.com> <20111012204222.GC39118@alchemy.franken.de> <20111012235707.GD9138@michelle.cdnetworks.com> <20111013214903.GH39118@alchemy.franken.de> <20111014203226.GA16192@michelle.cdnetworks.com> <20111015205616.GL39118@alchemy.franken.de> <5E65282B-DBCB-4143-93DE-3501A0D72E22@my.gd> <20111016010856.GM39118@alchemy.franken.de> <1318931821.55578.2.camel@beef64> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1318931821.55578.2.camel@beef64> User-Agent: Mutt/1.4.2.3i Cc: freebsd-net@freebsd.org Subject: Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 17:59:18 -0000 On Tue, Oct 18, 2011 at 12:57:01PM +0300, andrew bliznak wrote: > On Sun, 2011-10-16 at 03:08 +0200, Marius Strobl wrote: > > On Sun, Oct 16, 2011 at 02:46:23AM +0200, Damien Fleuriot wrote: > > > > > > > > > On 15 Oct 2011, at 22:56, Marius Strobl wrote: > > > > > > > > > > > Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for > > > > rl(4) only 8129 need testing, 8139 don't) please give the following > > > > patch a try in order to ensure it doesn't break anything? > > > > for 9/head: > > > > http://people.freebsd.org/~marius/mii_bitbang.diff > > > > for 8: > > > > http://people.freebsd.org/~marius/mii_bitbang.diff8 > > > > > > > > Thanks, > > > > Marius > > > > > > > > > > > > > While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... > > > > > > What do you think the patch might break ? > > > > > > > Basically, if there's something wrong with the patch the driver should > > fail to attach, if it still does and gets a link all should be fine. > > > > Marius > > > > run OK on FreeBSD 10.0-CURRENT #22 r226300M > > > nge0: port 0xd800-0xd8ff mem > 0xdffff000-0xdfffffff irq 22 at device 2.0 on pci1 > miibus0: on nge0 > nsgphy0: PHY 1 on miibus0 > none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, > 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto > nge0: Ethernet address: 00:30:4f:1e:e4:49 > Thanks! Marius From owner-freebsd-net@FreeBSD.ORG Tue Oct 18 23:38:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5ABA71065672 for ; Tue, 18 Oct 2011 23:38:14 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id D8D6E8FC13 for ; Tue, 18 Oct 2011 23:38:13 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so1813296bkb.13 for ; Tue, 18 Oct 2011 16:38:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=5ZfQHrWgVA4t4nWMik3Q16GTz9JOWvMTUmaJED9uh98=; b=GZdDjNQTyw72UlhL3F0C0CCAsHtwe9K0TnfRyAWt6+5MqWWZIJ0MWH4KGe4lBMGXuU JIpOOq2aXtybZckRcukkC2wRJFZn0MwaS44LzAwx4DL1Y8cSX1zksdqIcCy9oqgMJZ2q CIMMn9kIfi2uDXd43mAMs0ppKwbrufu4zPF44= Received: by 10.204.140.22 with SMTP id g22mr3212084bku.69.1318981092684; Tue, 18 Oct 2011 16:38:12 -0700 (PDT) Received: from rimwks1x64 ([92.124.38.98]) by mx.google.com with ESMTPS id x3sm3893709bkn.1.2011.10.18.16.38.10 (version=SSLv3 cipher=OTHER); Tue, 18 Oct 2011 16:38:11 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Ryan Stone'" , "'freebsd-net'" References: In-Reply-To: Date: Wed, 19 Oct 2011 08:38:07 +0900 Message-ID: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyNtXR/2l2GbRq1QrOBFYJhsbV7zQAOXGRQ Content-Language: ru Cc: Subject: RE: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Oct 2011 23:38:14 -0000 > ether_demux currently assumes that all vlan-tagged packets that it > sees have had the vlan stripped out and the M_VLAN tag is set, so it > never checks the ether type for a vlan. However ng_ether_rcv_upper > currently does not guarantee that this is the case(and there may be > other code paths where this is also true). Does anybody have any > strong feelings as to where the fix should go? Making ether_demux > handle it is guaranteed to catch all cases but it does add a bit more > overhead to check for a vlan tag at each stage. In what cases vlan-tagged packet can be received by ng_ether_rcv_upper ? Another side of vlan and netgraph implementation problem is in: PR = 152141 http://lists.freebsd.org/pipermail/freebsd-net/2011-February/027964.html Tagget packet -> ether_input --> (M_VLANTAG set) --> ng_ether.lower --> ng_bridge --> ng_ether.lower --> ether_output_frame --> ifp->if_transmit Untagged packet may be transmitted. ng_ether.lower and ether_output_frame does not check: is M_VLANTAG = handled by iface driver IMHO ether_output_frame should do this check. /* * If underlying interface can not do VLAN tag insertion itself * then attach a packet tag that holds it. */ if ((m->m_flags & M_VLANTAG) && (ifp->if_capenable & IFCAP_VLAN_HWTAGGING) =3D=3D 0) { m =3D ether_vlanencap(m, m->m_pkthdr.ether_vtag); if (m =3D=3D NULL) { ifp->if_oerrors++; return (ENOBUFS); } m->m_flags &=3D ~M_VLANTAG; } (from if_bridge.c) =A0 -- Rozhuk Ivan From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 02:36:05 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4954C106564A for ; Wed, 19 Oct 2011 02:36:05 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f50.google.com (mail-ww0-f50.google.com [74.125.82.50]) by mx1.freebsd.org (Postfix) with ESMTP id CF8938FC12 for ; Wed, 19 Oct 2011 02:36:04 +0000 (UTC) Received: by wwi18 with SMTP id 18so1759583wwi.31 for ; Tue, 18 Oct 2011 19:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IAn2ISIypFH8rFbCohK2c/j+tBB+KpcycXo6aJjJQ1s=; b=hq3C6eAQ3hjsZkPZAh5h5NooCyPuFTlCx7BEoVixyw6hflzVZ7kxP5Li0Iz2uUGBgO c9g3g4jWccf6yiFS5tczam0EgqC9E3JPjcNdTozq5OymdI0ZpaZvuH4i3GEu+CTnaJfl 76MKnqGPETuyndHvObykAh8xso18bztOI2BfY= MIME-Version: 1.0 Received: by 10.227.24.1 with SMTP id t1mr1740963wbb.107.1318991763751; Tue, 18 Oct 2011 19:36:03 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Tue, 18 Oct 2011 19:36:03 -0700 (PDT) In-Reply-To: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> Date: Tue, 18 Oct 2011 22:36:03 -0400 Message-ID: From: Ryan Stone To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 02:36:05 -0000 2011/10/18 : > In what cases vlan-tagged packet can be received by ng_ether_rcv_upper ? If another node attaches to an ng_ether node's upper hook and sends a vlan tagged packet to the hook. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 06:18:17 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5FECD1065672 for ; Wed, 19 Oct 2011 06:18:17 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id DC00E8FC16 for ; Wed, 19 Oct 2011 06:18:16 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so2212271bkb.13 for ; Tue, 18 Oct 2011 23:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=Q5rx7J6maFwQBuZO7FQlcAFp05LsWJAGZoY0cPC4gWw=; b=v2WQSoQMSYcvjcqD4TnS79xArr2lcLRXibGK/pVwqS5t4YFKu12g0pQgqoneLmYTSt hgJW5t3wIphYrXlASes8nlGbfc55Bp9jHyXEgHNGr6LJ32H0ncZ1V0yjNQIzx9sd10vR fO5z1juK/P2hxN/tnXyFk6FxrBww2pKzwXue0= Received: by 10.204.152.68 with SMTP id f4mr2817811bkw.59.1319005095836; Tue, 18 Oct 2011 23:18:15 -0700 (PDT) Received: from rimwks1x64 ([92.124.38.98]) by mx.google.com with ESMTPS id fb9sm4627289bkc.4.2011.10.18.23.18.13 (version=SSLv3 cipher=OTHER); Tue, 18 Oct 2011 23:18:14 -0700 (PDT) From: rozhuk.im@gmail.com To: "'Ryan Stone'" References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> In-Reply-To: Date: Wed, 19 Oct 2011 15:18:11 +0900 Message-ID: <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyOB9gyMGrJbbyeS9mjupXoxjvzjgAHXD5w Content-Language: ru Cc: 'freebsd-net' Subject: RE: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 06:18:17 -0000 > > In what cases vlan-tagged packet can be received by > ng_ether_rcv_upper ? >=20 > If another node attaches to an ng_ether node's upper hook and sends a > vlan tagged packet to the hook. This may be a wrong configuration or QinQ: packet may have M_VLAN tag is set and still vlan-tagged (ether_type =3D VLAN) -- Rozhuk Ivan =A0=20 From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 14:36:38 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6F998106564A for ; Wed, 19 Oct 2011 14:36:38 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 084BA8FC22 for ; Wed, 19 Oct 2011 14:36:37 +0000 (UTC) Received: by wyi40 with SMTP id 40so2302581wyi.13 for ; Wed, 19 Oct 2011 07:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=88SSNcJbtxXSZeoa/skFJsGOWCAxkEReeUhKvbnVFz0=; b=xvYPRcY5g3TskPw0p5+vqX+R9szGsS3k9Wlz3apjX7xRp6lkxDPNvibVtKP25e8bXy FIZ9cPIStTh/SuKXVliSJhCp8ljpL5AFz2YjcASkMAyos62LHJaA0VHimx0BnSbImp7C Apx9nR1rAl6INGGHfkkXwjBsyxJ+ECuitcxus= MIME-Version: 1.0 Received: by 10.227.127.205 with SMTP id h13mr2679274wbs.92.1319034997032; Wed, 19 Oct 2011 07:36:37 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Wed, 19 Oct 2011 07:36:36 -0700 (PDT) In-Reply-To: <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> Date: Wed, 19 Oct 2011 10:36:36 -0400 Message-ID: From: Ryan Stone To: Rozhuk.IM@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-net Subject: Re: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 14:36:38 -0000 2011/10/19 : > This may be a wrong configuration or QinQ: packet may have M_VLAN tag is > set and still vlan-tagged (ether_type = VLAN) It is not QinQ in my case. The interface that the upper hook exports is that you send it a valid ethernet frame and it passes that frame up the stack. A vlan-tagged frame is a valid frame so I don't see why it should not be handled correctly. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 16:33:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E21551065670 for ; Wed, 19 Oct 2011 16:33:14 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 1E5C68FC19 for ; Wed, 19 Oct 2011 16:33:13 +0000 (UTC) Received: (qmail 53615 invoked by uid 1000); 19 Oct 2011 16:33:10 -0000 Date: Wed, 19 Oct 2011 12:33:10 -0400 From: Larry Baird To: freebsd-net@freebsd.org Message-ID: <20111019163310.GA52555@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: qingli@freebsd.orf Subject: Possible bug in recent L2 modifications to in.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:33:15 -0000 The code associated with revision 225947 for modifing in.c seems suspect. Code from revision has: const char *sa, *mask, *addr, *lim; int len; sa = (const char *)rt_key(rt); mask = (const char *)rt_mask(rt); addr = (const char *)l3addr; len = ((const struct sockaddr_in *)l3addr)->sin_len; lim = addr + len; for ( ; addr < lim; sa++, mask++, addr++) { if ((*sa ^ *addr) & *mask) { #ifdef DIAGNOSTIC log(LOG_INFO, "IPv4 address: \"%s\" is not on th e network\n", inet_ntoa(((const struct sockaddr_in *)l3add r)->sin_addr)); #endif RTFREE_LOCKED(rt); return (EINVAL); } } It compares all bytes of sockaddr_in structure against mask instead of just address. Would following code be more correct? const char *sa, *mask, *addr, *lim; int len; sa = (const char *)rt_key(rt); mask = (const char *)rt_mask(rt); addr = (const char *)&(((const struct sockaddr_in *)l3addr)->sin_addr); len = ((const struct sockaddr_in *)l3addr)->sin_len; lim = (const char *)l3addr + len; for ( ; addr < lim; sa++, mask++, addr++) { if ((*sa ^ *addr) & *mask) { #ifdef DIAGNOSTIC log(LOG_INFO, "IPv4 address: \"%s\" is not on th e network\n", inet_ntoa(((const struct sockaddr_in *)l3add r)->sin_addr)); #endif RTFREE_LOCKED(rt); return (EINVAL); } } -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 16:40:51 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DF5021065670 for ; Wed, 19 Oct 2011 16:40:51 +0000 (UTC) (envelope-from lab@gta.com) Received: from mailgate.gta.com (mailgate.gta.com [199.120.225.20]) by mx1.freebsd.org (Postfix) with SMTP id 7BC758FC0A for ; Wed, 19 Oct 2011 16:40:51 +0000 (UTC) Received: (qmail 54917 invoked by uid 1000); 19 Oct 2011 16:40:50 -0000 Date: Wed, 19 Oct 2011 12:40:50 -0400 From: Larry Baird To: freebsd-net@freebsd.org Message-ID: <20111019164050.GA54299@gta.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Subject: Possible bug in recent L2 modifications to in.c X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 16:40:52 -0000 The code associated with revision 225947 for modifing in.c seems suspect. Code from revision has: const char *sa, *mask, *addr, *lim; int len; sa = (const char *)rt_key(rt); mask = (const char *)rt_mask(rt); addr = (const char *)l3addr; len = ((const struct sockaddr_in *)l3addr)->sin_len; lim = addr + len; for ( ; addr < lim; sa++, mask++, addr++) { if ((*sa ^ *addr) & *mask) { #ifdef DIAGNOSTIC log(LOG_INFO, "IPv4 address: \"%s\" is not on th e network\n", inet_ntoa(((const struct sockaddr_in *)l3add r)->sin_addr)); #endif RTFREE_LOCKED(rt); return (EINVAL); } } It compares all bytes of sockaddr_in structure against mask instead of just address. Would following code be more correct? const char *sa, *mask, *addr, *lim; int len; sa = (const char *)rt_key(rt); mask = (const char *)rt_mask(rt); addr = (const char *)&(((const struct sockaddr_in *)l3addr)->sin_addr); len = ((const struct sockaddr_in *)l3addr)->sin_len; lim = (const char *)l3addr + len; for ( ; addr < lim; sa++, mask++, addr++) { if ((*sa ^ *addr) & *mask) { #ifdef DIAGNOSTIC log(LOG_INFO, "IPv4 address: \"%s\" is not on th e network\n", inet_ntoa(((const struct sockaddr_in *)l3add r)->sin_addr)); #endif RTFREE_LOCKED(rt); return (EINVAL); } } -- ------------------------------------------------------------------------ Larry Baird | http://www.gta.com Global Technology Associates, Inc. | Orlando, FL Email: lab@gta.com | TEL 407-380-0220, FAX 407-380-6080 From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 19:12:40 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B1B6106566B; Wed, 19 Oct 2011 19:12:40 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 360E18FC24; Wed, 19 Oct 2011 19:12:39 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 19 Oct 2011 12:12:39 -0700 From: Ben Hutchings To: "Bjoern A. Zeeb" In-Reply-To: <68546593-B3E1-44D8-B512-4FD99B90D989@lists.zabbadoz.net> References: <1317309906.2743.9.camel@bwh-desktop> <1318865394.2784.4.camel@bwh-desktop> <4E9C534D.4090405@freebsd.org> <1318894136.2784.76.camel@bwh-desktop> <68546593-B3E1-44D8-B512-4FD99B90D989@lists.zabbadoz.net> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Wed, 19 Oct 2011 20:12:30 +0100 Message-ID: <1319051550.2829.34.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2011 19:12:39.0415 (UTC) FILETIME=[11A34070:01CC8E93] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18458.005 X-TM-AS-Result: No--21.361400-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: freebsd-net@freebsd.org, Andre Oppermann Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:12:40 -0000 On Mon, 2011-10-17 at 23:59 +0000, Bjoern A. Zeeb wrote: > On 17. Oct 2011, at 23:28 , Ben Hutchings wrote: > > > On Mon, 2011-10-17 at 18:09 +0200, Andre Oppermann wrote: > >> On 17.10.2011 17:29, Ben Hutchings wrote: > >>> This is the fix/workaround I used: > >> > >> Thanks for the fix. I'll review it and put it into FreeBSD maybe in > >> a slightly different form. > > > > Which one? One is tested but maybe not right; the other looks right but > > is not tested! > > and here's the real question -- was it always broken or did a commit during > the last years introduce the problem? t_maxopd > t_maxseg has always been possible since t_maxopd was added: http://svnweb.freebsd.org/base?view=revision&revision=6247 http://svnweb.freebsd.org/base?view=revision&revision=6283 The commit introducing TSO support was: http://svnweb.freebsd.org/base?view=revision&revision=162110 and that already had the problem that TSO may be selected for an mbuf that only requires one segment if t_maxopd > t_maxseg. The assertion that failed was added in: http://svnweb.freebsd.org/base?view=revision&revision=211317 As to which of these is the real bug, I cannot say. The commit message for the last change hopefully provides a clue for those more familiar with this TCP implementation. Ben. -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 19:31:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A4CEF106564A for ; Wed, 19 Oct 2011 19:31:00 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 3ECE18FC08 for ; Wed, 19 Oct 2011 19:30:59 +0000 (UTC) Received: by wyi40 with SMTP id 40so2715628wyi.13 for ; Wed, 19 Oct 2011 12:30:59 -0700 (PDT) Received: by 10.227.6.223 with SMTP id a31mr2905928wba.112.1319052659169; Wed, 19 Oct 2011 12:30:59 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Wed, 19 Oct 2011 12:30:39 -0700 (PDT) In-Reply-To: References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> From: Juli Mallett Date: Wed, 19 Oct 2011 12:30:39 -0700 X-Google-Sender-Auth: 5zc-ZJ6OJhdiRKGfqI85qja1p0Y Message-ID: To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , Rozhuk.IM@gmail.com Subject: Re: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 19:31:00 -0000 On Wed, Oct 19, 2011 at 07:36, Ryan Stone wrote: > 2011/10/19 =C2=A0: >> This may be a wrong configuration or QinQ: packet may have M_VLAN tag is >> set and still vlan-tagged (ether_type =3D VLAN) > > It is not QinQ in my case. =C2=A0The interface that the upper hook export= s > is that you send it a valid ethernet frame and it passes that frame up > the stack. =C2=A0A vlan-tagged frame is a valid frame so I don't see why = it > should not be handled correctly. Why should the requirements for the Netgraph path be any different to the non-Netgraph path? If drivers must ensure that frames that reach ether_demux have had their VLAN tags stripped, so should Netgraph things that act like drivers. So why don't you move that logic into ether_demux from the ether_input path, or have Netgraph use the ether_input path? From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 21:47:25 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 434FE1065670; Wed, 19 Oct 2011 21:47:25 +0000 (UTC) (envelope-from rysto32@gmail.com) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by mx1.freebsd.org (Postfix) with ESMTP id 57E1D8FC18; Wed, 19 Oct 2011 21:47:24 +0000 (UTC) Received: by wwn22 with SMTP id 22so6990204wwn.1 for ; Wed, 19 Oct 2011 14:47:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=OxalIvk4+tZ8m1MvCWRki5JOGuV4Mt+m6AUgDUZc3T4=; b=INYQjdlQXVcsCCLHsM8MNVrbqElhxfzqkYqe4H7O1VFzVZxg2bbcw7fh24gguZMy3d 5LMbsHVAOWTkOioYktA9umSwJmJmtKX5FfpRboAZTMjKxxDJTHhP+zlHA5yUGtNwhbQ/ ffQwt2qwZy3ah0ZPzrUb6WOIZK02+RCkNKGiM= MIME-Version: 1.0 Received: by 10.227.127.205 with SMTP id h13mr3172149wbs.92.1319060843315; Wed, 19 Oct 2011 14:47:23 -0700 (PDT) Received: by 10.180.96.104 with HTTP; Wed, 19 Oct 2011 14:47:23 -0700 (PDT) In-Reply-To: References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> Date: Wed, 19 Oct 2011 17:47:23 -0400 Message-ID: From: Ryan Stone To: Juli Mallett Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , Rozhuk.IM@gmail.com Subject: Re: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:47:25 -0000 On Wed, Oct 19, 2011 at 3:30 PM, Juli Mallett wrote: > Why should the requirements for the Netgraph path be any different to > the non-Netgraph path? =A0If drivers must ensure that frames that reach > ether_demux have had their VLAN tags stripped, so should Netgraph > things that act like drivers. =A0So why don't you move that logic into > ether_demux from the ether_input path, or have Netgraph use the > ether_input path? Netgraph can't use the ether_input path because ether_input passes the packet to the lower hook. It also passes the packet to things like carp or if_bridge if necessary. I'm not sure whether it is intended behaviour that the upper hook bypasses carp and if_bridge. if_bridge also depends on the vlan stripping behaviour, so vlan stripping cannot be moved to ether_demux without re-implementing it in bridge_input. From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 21:57:55 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 730291065678 for ; Wed, 19 Oct 2011 21:57:55 +0000 (UTC) (envelope-from gnn@neville-neil.com) Received: from vps.hungerhost.com (vps.hungerhost.com [216.38.53.176]) by mx1.freebsd.org (Postfix) with ESMTP id 4613A8FC12 for ; Wed, 19 Oct 2011 21:57:54 +0000 (UTC) Received: from [209.249.190.124] (helo=gnnmac.hudson-trading.com) by vps.hungerhost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1RGccl-00034G-6M for net@freebsd.org; Wed, 19 Oct 2011 16:20:27 -0400 From: George Neville-Neil Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 19 Oct 2011 16:20:27 -0400 Message-Id: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> To: net@freebsd.org Mime-Version: 1.0 (Apple Message framework v1251.1) X-Mailer: Apple Mail (2.1251.1) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.hungerhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - neville-neil.com Cc: Subject: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 21:57:55 -0000 Howdy, I've been trying to debug CARP problems of late. I noticed that our = tcpdump didn't have CARP support. I took and fixed some code from OpenBSD so that our tcpdump = can work with=20 CARP. Unlike OpenBSD you have to specify -T carp to read carp packets. = In their version you specify -T VRRP, because they don't like VRRP. I decided that we = should go with what most of the industry cares about rather than what OpenBSD cares = about. Patch is here: http://people.freebsd.org/~gnn/tcpdump-carp.diff Technical comments welcome. Best, George From owner-freebsd-net@FreeBSD.ORG Wed Oct 19 22:18:34 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7CB161065670 for ; Wed, 19 Oct 2011 22:18:34 +0000 (UTC) (envelope-from juli@clockworksquid.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id 127318FC08 for ; Wed, 19 Oct 2011 22:18:33 +0000 (UTC) Received: by wyi40 with SMTP id 40so2902569wyi.13 for ; Wed, 19 Oct 2011 15:18:33 -0700 (PDT) Received: by 10.227.179.76 with SMTP id bp12mr541999wbb.82.1319062713071; Wed, 19 Oct 2011 15:18:33 -0700 (PDT) MIME-Version: 1.0 Sender: juli@clockworksquid.com Received: by 10.227.199.140 with HTTP; Wed, 19 Oct 2011 15:18:13 -0700 (PDT) In-Reply-To: References: <4e9e0de3.4364cc0a.38b5.ffffc94f@mx.google.com> <4e9e6ba6.c972cd0a.3d45.ffffd504@mx.google.com> From: Juli Mallett Date: Wed, 19 Oct 2011 15:18:13 -0700 X-Google-Sender-Auth: 11fJXDqusxF2MC4jhxOAnkWFGSE Message-ID: To: Ryan Stone Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-net , Rozhuk.IM@gmail.com Subject: Re: ether_demux does not handle frames with embedded vlan tags X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2011 22:18:34 -0000 On Wed, Oct 19, 2011 at 14:47, Ryan Stone wrote: > On Wed, Oct 19, 2011 at 3:30 PM, Juli Mallett wrot= e: >> Why should the requirements for the Netgraph path be any different to >> the non-Netgraph path? =C2=A0If drivers must ensure that frames that rea= ch >> ether_demux have had their VLAN tags stripped, so should Netgraph >> things that act like drivers. =C2=A0So why don't you move that logic int= o >> ether_demux from the ether_input path, or have Netgraph use the >> ether_input path? > > Netgraph can't use the ether_input path because ether_input passes the > packet to the lower hook. =C2=A0It also passes the packet to things like > carp or if_bridge if necessary. =C2=A0I'm not sure whether it is intended > behaviour that the upper hook bypasses carp and if_bridge. > > if_bridge also depends on the vlan stripping behaviour, so vlan > stripping cannot be moved to ether_demux without re-implementing it in > bridge_input. This seems like a good argument for a flag like M_SKIPFIREWALL (or whatever it's called these days) that says that the packet was injected by an upper layer (in general, not just netgraph), which in the netgraph case could skip the lower filter. That would be considerably more consistent with how other Ethernet devices work, which would be an improvement over the current short-circuit to ether_demux. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 07:30:56 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC2C81065670 for ; Thu, 20 Oct 2011 07:30:56 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-gy0-f182.google.com (mail-gy0-f182.google.com [209.85.160.182]) by mx1.freebsd.org (Postfix) with ESMTP id A95B78FC12 for ; Thu, 20 Oct 2011 07:30:56 +0000 (UTC) Received: by gyd8 with SMTP id 8so3199262gyd.13 for ; Thu, 20 Oct 2011 00:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type:content-transfer-encoding; bh=XQ1herTmGpvKUNFlTsz6yFxACpGtJzSaTO3mCtcQCio=; b=gF8BsWQzOzcC8xkf1RLni6X6VkiTDJJejThgOOTqW2oad8qnyoDyqzhhfvSCChioW9 TyUbqdkaUQXhkTvFb4NnFfxTo59U9TfOq7NMp/0uVmaMmqhhQJ/zdqoxDGtho2rLyUI2 ZEzLteh4rgdSPfop5XnUJLAIIfQNtGdrnap/o= Received: by 10.150.131.21 with SMTP id e21mr3173701ybd.24.1319094353157; Thu, 20 Oct 2011 00:05:53 -0700 (PDT) Received: from [192.168.123.103] ([190.48.225.169]) by mx.google.com with ESMTPS id v5sm10105656anf.3.2011.10.20.00.05.49 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 00:05:52 -0700 (PDT) Sender: Fernando Gont Message-ID: <4E9FAFCD.3080908@gont.com.ar> Date: Thu, 20 Oct 2011 02:21:17 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: FreeBSD Net X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: IPv6 Redirects & local destinations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:30:57 -0000 Folks, While doing some testing, it seems that FreeBSD ignores ICMPv6 Redirects when both the Redirect Destination and the Redirect Target are the same (i.e., the destination is supposed to be on-link). OTOH, Redirects are processed as expected when the Redirect Target is different from the Redirect Destination. Should I report this as a bug, or is this (non-rfc-compliant) behavior intentional? (If so, what's the rationale?) Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 07:51:42 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6D0C91065670 for ; Thu, 20 Oct 2011 07:51:42 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 51B758FC08 for ; Thu, 20 Oct 2011 07:51:42 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9K7f9pU020667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Oct 2011 00:41:10 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Thu, 20 Oct 2011 00:41:04 -0700 From: "Li, Qing" To: "egrosbein@rdtc.ru" , Larry Baird Thread-Topic: kern/161805 - patch is on its way Thread-Index: AcyO+5i/LEwq1Q7DRu2HE/5M7jXqqw== Date: Thu, 20 Oct 2011 07:41:03 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "net@freebsd.org" Subject: kern/161805 - patch is on its way X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 07:51:42 -0000 Hi,=20 I believe I have identified the root cause based on the data provided by La= rry Baird, but I am=20 still verifying the patch against the mpd5 code. In a nutshell, the host ro= ute installed by mpd5 appears to be missing a flag resulting in the crash. In the meantime, please try the following fix and let me know if it also wo= rk for you. http://people.freebsd.org/~qingli/in.c.diff Thanks, -- Qing From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 09:03:17 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0AAB71065675; Thu, 20 Oct 2011 09:03:17 +0000 (UTC) (envelope-from egrosbein@rdtc.ru) Received: from eg.sd.rdtc.ru (eg.sd.rdtc.ru [IPv6:2a03:3100:c:13::5]) by mx1.freebsd.org (Postfix) with ESMTP id 610048FC13; Thu, 20 Oct 2011 09:03:16 +0000 (UTC) Received: from eg.sd.rdtc.ru (localhost [127.0.0.1]) by eg.sd.rdtc.ru (8.14.5/8.14.5) with ESMTP id p9K935ga017909; Thu, 20 Oct 2011 16:03:05 +0700 (NOVT) (envelope-from egrosbein@rdtc.ru) Message-ID: <4E9FE3C4.6020107@rdtc.ru> Date: Thu, 20 Oct 2011 16:03:00 +0700 From: Eugene Grosbein User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; ru-RU; rv:1.9.2.13) Gecko/20110112 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Li, Qing" References: In-Reply-To: Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 8bit Cc: Larry Baird , bug-followup@freebsd.org, "net@freebsd.org" Subject: Re: kern/161805 - patch is on its way X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 09:03:17 -0000 20.10.2011 14:41, Li, Qing ÐÉÛÅÔ: > Hi, > > I believe I have identified the root cause based on the data provided by Larry Baird, but I am > still verifying the patch against the mpd5 code. In a nutshell, the host route installed by mpd5 > appears to be missing a flag resulting in the crash. > > In the meantime, please try the following fix and let me know if it also work for you. > > http://people.freebsd.org/~qingli/in.c.diff > > Thanks, > > -- Qing Thank you for quick responce. This patch works, no more panics and proxyarp works too. Eugene Grosbein From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 12:19:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EC65A106564A for ; Thu, 20 Oct 2011 12:19:27 +0000 (UTC) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from mx1.sbone.de (mx1.sbone.de [IPv6:2a01:4f8:130:3ffc::401:25]) by mx1.freebsd.org (Postfix) with ESMTP id 7C9B18FC17 for ; Thu, 20 Oct 2011 12:19:27 +0000 (UTC) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id DF15E25D3810; Thu, 20 Oct 2011 12:19:25 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 0CDD5BD3C54; Thu, 20 Oct 2011 12:19:25 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id 1EZ3SlFJd59f; Thu, 20 Oct 2011 12:19:24 +0000 (UTC) Received: from orange-en1.sbone.de (orange-en1.sbone.de [IPv6:fde9:577b:c1a9:31:cabc:c8ff:fecf:e8e3]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 0E7EEBD3C2C; Thu, 20 Oct 2011 12:19:23 +0000 (UTC) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: "Bjoern A. Zeeb" In-Reply-To: <4E9FAFCD.3080908@gont.com.ar> Date: Thu, 20 Oct 2011 12:19:22 +0000 Content-Transfer-Encoding: 7bit Message-Id: References: <4E9FAFCD.3080908@gont.com.ar> To: Fernando Gont X-Mailer: Apple Mail (2.1084) Cc: FreeBSD Net Subject: Re: IPv6 Redirects & local destinations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 12:19:28 -0000 On 20. Oct 2011, at 05:21 , Fernando Gont wrote: > Folks, > > While doing some testing, it seems that FreeBSD ignores ICMPv6 Redirects > when both the Redirect Destination and the Redirect Target are the same > (i.e., the destination is supposed to be on-link). > > OTOH, Redirects are processed as expected when the Redirect Target is > different from the Redirect Destination. What does it log if you turn on the following sysctl net.inet6.icmp6.nd6_debug=1 and reproduce? > > Should I report this as a bug, or is this (non-rfc-compliant) behavior > intentional? (If so, what's the rationale?) It's kern/152791, isn't it? -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 14:02:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A1B771065674 for ; Thu, 20 Oct 2011 14:02:11 +0000 (UTC) (envelope-from "") Received: from carbon.ruby-lang.org (carbon.ruby-lang.org [221.186.184.68]) by mx1.freebsd.org (Postfix) with ESMTP id 70DEA8FC15 for ; Thu, 20 Oct 2011 14:02:11 +0000 (UTC) Received: from beryllium.ruby-lang.org (beryllium.ruby-lang.org [127.0.0.1]) by carbon.ruby-lang.org (Postfix) with ESMTP id 986C53C229612 for ; Thu, 20 Oct 2011 22:41:25 +0900 (JST) Date: Thu, 20 Oct 2011 22:41:25 +0900 From: ruby-core-admin@ruby-lang.org To: freebsd-net@freebsd.org Message-Id: <201110202241.FMLAAA7914.ruby-core@ruby-lang.org> References: <20111020134122.5FA7E3C2294F6@carbon.ruby-lang.org> X-MLServer: fml [fml 4.0.3 release (20011202/4.0.3)] X-ML-Info: If you have a question, please contact ruby-core-admin@ruby-lang.org; Subject: Subscribe request result (ruby-core ML) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ruby-core-ctl@ruby-lang.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 14:02:11 -0000 Hi, I am the fml mailing list manager for . Hmm, you may be not a member. 1. Your mail may come from a bad address which is not registered in this mailing list 2. Your mail has a syntax error. If you would like to subscribe this mailing list subscribe YOUR NAME For example subscribe Hayakawa Aoi Hi, I am the fml ML manager for the ML . --ruby-core@ruby-lang.org, Be Seeing You! ************************************************************ If you have any questions or problems, please contact ruby-core-admin@ruby-lang.org ************************************************************ From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 15:15:08 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E979A106566B for ; Thu, 20 Oct 2011 15:15:08 +0000 (UTC) (envelope-from dan@dan.emsphone.com) Received: from email2.allantgroup.com (email2.emsphone.com [199.67.51.116]) by mx1.freebsd.org (Postfix) with ESMTP id 892F68FC16 for ; Thu, 20 Oct 2011 15:15:08 +0000 (UTC) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by email2.allantgroup.com (8.14.4/8.14.4) with ESMTP id p9KErkUR009622 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Oct 2011 09:53:47 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (smmsp@localhost [127.0.0.1]) by dan.emsphone.com (8.14.5/8.14.5) with ESMTP id p9KErk0F084524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Oct 2011 09:53:46 -0500 (CDT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.14.5/8.14.5/Submit) id p9KErk8x084393; Thu, 20 Oct 2011 09:53:46 -0500 (CDT) (envelope-from dan) Date: Thu, 20 Oct 2011 09:53:46 -0500 From: Dan Nelson To: George Neville-Neil Message-ID: <20111020145346.GA86426@dan.emsphone.com> References: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="5mCyUwZo2JvN/JJP" Content-Disposition: inline In-Reply-To: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> X-OS: FreeBSD 8.2-STABLE User-Agent: Mutt/1.5.21 (2010-09-15) X-Virus-Scanned: clamav-milter 0.97.2 at email2.allantgroup.com X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.6 (email2.allantgroup.com [199.67.51.78]); Thu, 20 Oct 2011 09:53:47 -0500 (CDT) X-Scanned-By: MIMEDefang 2.68 on 199.67.51.78 Cc: net@freebsd.org Subject: Re: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 15:15:09 -0000 --5mCyUwZo2JvN/JJP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In the last episode (Oct 19), George Neville-Neil said: > I've been trying to debug CARP problems of late. I noticed that our > tcpdump didn't have CARP support. I took and fixed some code from OpenBSD > so that our tcpdump can work with CARP. Unlike OpenBSD you have to > specify -T carp to read carp packets. In their version you specify -T > VRRP, because they don't like VRRP. I decided that we should go with what > most of the industry cares about rather than what OpenBSD cares about. > > Patch is here: http://people.freebsd.org/~gnn/tcpdump-carp.diff > > Technical comments welcome. Here's the patch I've been using. I include a rendering of the packet format in the comments (since the CARP packet is otherwise completely undocumented), and also examine the packet to decide whether to print it as CARP or VRRP. CARP hardcodes a 7 in the AuthLen field, so it'll get the packet type right unless you happen to use VRRP with 7 IP addresses. -- Dan Nelson dnelson@allantgroup.com --5mCyUwZo2JvN/JJP Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="carp.diff" Index: print-vrrp.c =================================================================== --- print-vrrp.c (revision 226523) +++ print-vrrp.c (working copy) @@ -62,6 +62,33 @@ static const char rcsid[] _U_ = * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ * | Authentication Data (2) | * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * + * + * The CARP header layout is as follows. The distinguishing feature + * seems to be that the AuthLen field is always 7: + * + * 0 1 2 3 + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * |Version| Type | VirtualHostID | AdvSkew | AuthLen == 7 | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | Demote | AdvBase | Checksum | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | Counter (1) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | Counter (2) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | SHA-1 HMAC (1) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | SHA-1 HMAC (2) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | SHA-1 HMAC (3) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | SHA-1 HMAC (4) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * | SHA-1 HMAC (5) | + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + * */ /* Type */ @@ -85,6 +112,9 @@ static const struct tok auth2str[] = { }; void +carp_print(register const u_char *bp, register u_int len, int ttl); + +void vrrp_print(register const u_char *bp, register u_int len, int ttl) { int version, type, auth_type; @@ -93,6 +123,13 @@ vrrp_print(register const u_char *bp, register u_i TCHECK(bp[0]); version = (bp[0] & 0xf0) >> 4; type = bp[0] & 0x0f; + + if ((bp[3] == 7) && (version == 2) && (type == 1)) + { + carp_print(bp, len, ttl); + return; + } + type_s = tok2str(type2str, "unknown type (%u)", type); printf("VRRPv%u, %s", version, type_s); if (ttl != 255) @@ -139,3 +176,30 @@ vrrp_print(register const u_char *bp, register u_i trunc: printf("[|vrrp]"); } + +void +carp_print(register const u_char *bp, register u_int len, int ttl) +{ + int version, type, auth_type; + const char *type_s; + + TCHECK(bp[0]); + version = (bp[0] & 0xf0) >> 4; + type = bp[0] & 0x0f; + type_s = tok2str(type2str, "unknown type (%u)", type); + printf("CARPv%u, %s", version, type_s); + if (ttl != 255) + printf(", (ttl %u)", ttl); + if (version != 2 || type != VRRP_TYPE_ADVERTISEMENT) + return; + TCHECK(bp[2]); + printf(", vhid %u, advskew %u", bp[1], bp[2]); + TCHECK(bp[5]); + printf(", advbase %us", bp[5]); + TCHECK(bp[15]); + printf(", counter %llu", EXTRACT_64BITS(&bp[8])); + + return; +trunc: + printf("[|carp]"); +} --5mCyUwZo2JvN/JJP-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 16:07:18 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B9B1106564A for ; Thu, 20 Oct 2011 16:07:18 +0000 (UTC) (envelope-from fernando.gont.netbook.win@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 476448FC0C for ; Thu, 20 Oct 2011 16:07:17 +0000 (UTC) Received: by yxn16 with SMTP id 16so3774559yxn.13 for ; Thu, 20 Oct 2011 09:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; bh=0c8KoNISwYLsmoEbEkCUz0TbkLxFPmw/jOYvE/hyyqs=; b=UxgoS+sS8MoZkoAKGQCFBBg5X9OTT/+gyPmSe8qIqxt8LjJ3Xm1VeoENDd+l0BNIgE yAS/rO1bXbLSd/d7emvy1tA92WGYJoTMrAAQzkMl3DpApvaoRa2S1GJQOpLfbnRsD/qa ikBdgrPzrZJCr0Y+8YzBZnbX6OmZ8f3rHsBh0= Received: by 10.236.72.167 with SMTP id t27mr16455246yhd.127.1319126837648; Thu, 20 Oct 2011 09:07:17 -0700 (PDT) Received: from [192.168.123.103] ([190.48.225.169]) by mx.google.com with ESMTPS id m37sm27031782anq.11.2011.10.20.09.07.14 (version=SSLv3 cipher=OTHER); Thu, 20 Oct 2011 09:07:16 -0700 (PDT) Sender: Fernando Gont Message-ID: <4EA04712.3060705@gont.com.ar> Date: Thu, 20 Oct 2011 13:06:42 -0300 From: Fernando Gont User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Thunderbird/3.1.15 MIME-Version: 1.0 To: "Bjoern A. Zeeb" References: <4E9FAFCD.3080908@gont.com.ar> In-Reply-To: X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: FreeBSD Net Subject: Re: IPv6 Redirects & local destinations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:07:18 -0000 Hi, Bjoern, Thanks so much for your prompt response! PLease find my comments inline... On 10/20/2011 09:19 AM, Bjoern A. Zeeb wrote: >> While doing some testing, it seems that FreeBSD ignores ICMPv6 Redirects >> when both the Redirect Destination and the Redirect Target are the same >> (i.e., the destination is supposed to be on-link). >> >> OTOH, Redirects are processed as expected when the Redirect Target is >> different from the Redirect Destination. > > What does it log if you turn on the following sysctl > net.inet6.icmp6.nd6_debug=1 > and reproduce? Nothing. However, the problem seems to be this: While an entry is added in the Neighbor Cache, no host-route is added to the routing table. Hence the corresponding entry in the Neighbor Cache is never used. >> Should I report this as a bug, or is this (non-rfc-compliant) behavior >> intentional? (If so, what's the rationale?) > > It's kern/152791, isn't it? Yep, it seems it is. -- The fix would be that when an ICMPv6 Redirect is received with RD Target == RD Destination, not only is an entry created in the Neighbor Cache, but a host-route is also created in the routing table. Thanks! Best regards, -- Fernando Gont e-mail: fernando@gont.com.ar || fgont@acm.org PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 16:15:09 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4F190106564A for ; Thu, 20 Oct 2011 16:15:03 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id C4B1B8FC13 for ; Thu, 20 Oct 2011 16:15:01 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9KGEvmv016912 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 20 Oct 2011 09:14:57 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Thu, 20 Oct 2011 09:14:51 -0700 From: "Li, Qing" To: Fernando Gont , "Bjoern A. Zeeb" Thread-Topic: IPv6 Redirects & local destinations Thread-Index: AQHMjyKeMD++W67mAkeAu5yzVI2TXpWF25YA//+LVFg= Date: Thu, 20 Oct 2011 16:14:51 +0000 Message-ID: References: <4E9FAFCD.3080908@gont.com.ar> , <4EA04712.3060705@gont.com.ar> In-Reply-To: <4EA04712.3060705@gont.com.ar> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: FreeBSD Net Subject: RE: IPv6 Redirects & local destinations X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:15:09 -0000 This failure showed up in the IPv6 Ready Logo test suites and I am fixing i= t.=0A= =0A= I already made a checkin recently on this front, and more is coming.=0A= =0A= http://svnweb.freebsd.org/base?view=3Drevision&revision=3D226451=0A= =0A= I will be posting the test results soon so we know where we are.=0A= =0A= =0A= --Qing=0A= =0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Fernando Gont [fernando@gont.com.ar]=0A= Sent: Thursday, October 20, 2011 9:06 AM=0A= To: Bjoern A. Zeeb=0A= Cc: FreeBSD Net=0A= Subject: Re: IPv6 Redirects & local destinations=0A= =0A= Hi, Bjoern,=0A= =0A= Thanks so much for your prompt response! PLease find my comments inline...= =0A= =0A= On 10/20/2011 09:19 AM, Bjoern A. Zeeb wrote:=0A= >> While doing some testing, it seems that FreeBSD ignores ICMPv6 Redirects= =0A= >> when both the Redirect Destination and the Redirect Target are the same= =0A= >> (i.e., the destination is supposed to be on-link).=0A= >>=0A= >> OTOH, Redirects are processed as expected when the Redirect Target is=0A= >> different from the Redirect Destination.=0A= >=0A= > What does it log if you turn on the following sysctl=0A= > net.inet6.icmp6.nd6_debug=3D1=0A= > and reproduce?=0A= =0A= Nothing. However, the problem seems to be this: While an entry is added=0A= in the Neighbor Cache, no host-route is added to the routing table.=0A= Hence the corresponding entry in the Neighbor Cache is never used.=0A= =0A= =0A= =0A= >> Should I report this as a bug, or is this (non-rfc-compliant) behavior= =0A= >> intentional? (If so, what's the rationale?)=0A= >=0A= > It's kern/152791, isn't it?=0A= =0A= Yep, it seems it is. -- The fix would be that when an ICMPv6 Redirect is=0A= received with RD Target =3D=3D RD Destination, not only is an entry create= d=0A= in the Neighbor Cache, but a host-route is also created in the routing=0A= table.=0A= =0A= Thanks!=0A= =0A= Best regards,=0A= --=0A= Fernando Gont=0A= e-mail: fernando@gont.com.ar || fgont@acm.org=0A= PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1=0A= =0A= =0A= =0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 16:32:33 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4C7331065675; Thu, 20 Oct 2011 16:32:33 +0000 (UTC) (envelope-from bhutchings@solarflare.com) Received: from exchange.solarflare.com (mail.solarflare.com [216.237.3.220]) by mx1.freebsd.org (Postfix) with ESMTP id 2ABFC8FC19; Thu, 20 Oct 2011 16:32:32 +0000 (UTC) Received: from [10.17.20.137] ([10.17.20.137]) by exchange.solarflare.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 09:32:32 -0700 From: Ben Hutchings To: Andre Oppermann In-Reply-To: <1318894136.2784.76.camel@bwh-desktop> References: <1317309906.2743.9.camel@bwh-desktop> <1318865394.2784.4.camel@bwh-desktop> <4E9C534D.4090405@freebsd.org> <1318894136.2784.76.camel@bwh-desktop> Content-Type: text/plain; charset="UTF-8" Organization: Solarflare Communications Date: Thu, 20 Oct 2011 17:32:29 +0100 Message-ID: <1319128350.3147.6.camel@bwh-desktop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 (2.32.2-1.fc14) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Oct 2011 16:32:32.0698 (UTC) FILETIME=[DE0051A0:01CC8F45] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18460.005 X-TM-AS-Result: No--21.510700-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: freebsd-net@freebsd.org Subject: Re: TSO broken with jumbo MTU X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:32:33 -0000 On Tue, 2011-10-18 at 00:28 +0100, Ben Hutchings wrote: > On Mon, 2011-10-17 at 18:09 +0200, Andre Oppermann wrote: > > On 17.10.2011 17:29, Ben Hutchings wrote: > > > This is the fix/workaround I used: > > > > Thanks for the fix. I'll review it and put it into FreeBSD maybe in > > a slightly different form. > > Which one? One is tested but maybe not right; the other looks right but > is not tested! I have now run the same test that originally triggered the assertion failure, with the 'right' change, and it passes. The test script performed various interface reconfiguration (including MTU changes) and link state changes with TCP and UDP flows active through the interface, over a period of 12 hours. For reference, the 'right' change is: --- a/netinet/tcp_input.c +++ b/netinet/tcp_input.c @@ -3087,7 +3087,7 @@ tcp_mss_update(struct tcpcb *tp, int offer, struct hc_metrics_lite *metricptr, int *mtuflags) { - int mss; + int mss, ts_len; u_long maxmtu; struct inpcb *inp = tp->t_inpcb; struct hc_metrics_lite metrics; @@ -3212,22 +3212,17 @@ mss = max(mss, 64); /* - * maxopd stores the maximum length of data AND options - * in a segment; maxseg is the amount of data in a normal - * segment. We need to store this value (maxopd) apart - * from maxseg, because now every segment carries options - * and thus we normally have somewhat less data in segments. - */ - tp->t_maxopd = mss; - - /* * origoffer==-1 indicates that no segments were received yet. * In this case we just guess. */ if ((tp->t_flags & (TF_REQ_TSTMP|TF_NOOPT)) == TF_REQ_TSTMP && (origoffer == -1 || (tp->t_flags & TF_RCVD_TSTMP) == TF_RCVD_TSTMP)) - mss -= TCPOLEN_TSTAMP_APPA; + ts_len = TCPOLEN_TSTAMP_APPA; + else + ts_len = 0; + + mss -= ts_len; #if (MCLBYTES & (MCLBYTES - 1)) == 0 if (mss > MCLBYTES) @@ -3237,6 +3232,15 @@ mss = mss / MCLBYTES * MCLBYTES; #endif tp->t_maxseg = mss; + + /* + * maxopd stores the maximum length of data AND options + * in a segment; maxseg is the amount of data in a normal + * segment. We need to store this value (maxopd) apart + * from maxseg, because now every segment carries options + * and thus we normally have somewhat less data in segments. + */ + tp->t_maxopd = mss + ts_len; } void --- END --- -- Ben Hutchings, Staff Engineer, Solarflare Not speaking for my employer; that's the marketing department's job. They asked us to note that Solarflare product names are trademarked. From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 16:37:54 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 385FC106566C for ; Thu, 20 Oct 2011 16:37:54 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by mx1.freebsd.org (Postfix) with ESMTP id 132CE8FC0A for ; Thu, 20 Oct 2011 16:37:53 +0000 (UTC) Received: by pzk4 with SMTP id 4so16130238pzk.3 for ; Thu, 20 Oct 2011 09:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=xPxUmvP/f5M792byAbcEr5doyvy4PI25gXjLnvMWKC0=; b=R9BVDot7O6OHMFOeiF+/na8tiAptc+sdBJeCSYzGOLCELtX7KI+XYJpvgG+1UjK1cd P7z8J3f1A333tmHxtVke1zKCpGxlj/Dt+eBZijJZbihQ+0mLbwg6OdiysaQSDdpycY0d ZYqLyAfIjnZOtWoWdP0gpNRdu6S4XRjPolCQs= MIME-Version: 1.0 Received: by 10.68.208.229 with SMTP id mh5mr21197939pbc.124.1319127164568; Thu, 20 Oct 2011 09:12:44 -0700 (PDT) Received: by 10.68.40.199 with HTTP; Thu, 20 Oct 2011 09:12:44 -0700 (PDT) In-Reply-To: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> References: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> Date: Thu, 20 Oct 2011 12:12:44 -0400 Message-ID: From: Kevin Wilcox To: George Neville-Neil Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 16:37:54 -0000 On 19 October 2011 16:20, George Neville-Neil wrote: > I've been trying to debug CARP problems of late. I noticed that our tcpdu= mp didn't have CARP > support. =C2=A0I took and fixed some code from OpenBSD so that our tcpdum= p can work with > CARP. =C2=A0Unlike OpenBSD you have to specify -T carp to read carp packe= ts. =C2=A0In their version > you specify -T VRRP, because they don't like VRRP. =C2=A0I decided that w= e should go with > what most of the industry cares about rather than what OpenBSD cares abou= t. Additionally, Daniel Hartmeier posted a significant patch to freebsd-questions@ for pf+tcpdump earlier this year that added support for the pfsync device. I've been using it in production on firewalls with 125k pps average to track NAT translations for a /17 and it's been of endless utility since pf doesn't offer the translation logging you see on some commercial devices. kmw From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 18:40:34 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 553A11065679 for ; Thu, 20 Oct 2011 18:40:34 +0000 (UTC) (envelope-from lacombar@gmail.com) Received: from mail-wy0-f182.google.com (mail-wy0-f182.google.com [74.125.82.182]) by mx1.freebsd.org (Postfix) with ESMTP id DA7268FC1B for ; Thu, 20 Oct 2011 18:40:33 +0000 (UTC) Received: by wyi40 with SMTP id 40so4129532wyi.13 for ; Thu, 20 Oct 2011 11:40:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=D80cLT0aJJg0mvRqdw/chiJPOMB858Qkh3jsTVbr4SA=; b=UYKE0gdstKEmCvjFnPblZC83N1SZz6u8JR+bFagwFC2bvjYg6Y2clLztnS4nHLRyQw td36SzbXJSul38X4E8SdZqzNAvsBYC3DcifFxVrmF2K36IzOr5f5/fpZ9aqmd00mZtcc QdtHiEChLUNtY6Cs9E1iFZfKEhcwG4wFOVEYg= MIME-Version: 1.0 Received: by 10.227.4.74 with SMTP id 10mr314540wbq.49.1319136032629; Thu, 20 Oct 2011 11:40:32 -0700 (PDT) Received: by 10.180.103.198 with HTTP; Thu, 20 Oct 2011 11:40:32 -0700 (PDT) In-Reply-To: References: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> Date: Thu, 20 Oct 2011 14:40:32 -0400 Message-ID: From: Arnaud Lacombe To: Kevin Wilcox Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: net@freebsd.org Subject: Re: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 18:40:34 -0000 Hi, On Thu, Oct 20, 2011 at 12:12 PM, Kevin Wilcox wro= te: > On 19 October 2011 16:20, George Neville-Neil wrot= e: > >> I've been trying to debug CARP problems of late. I noticed that our tcpd= ump didn't have CARP >> support. =A0I took and fixed some code from OpenBSD so that our tcpdump = can work with >> CARP. =A0Unlike OpenBSD you have to specify -T carp to read carp packets= . =A0In their version >> you specify -T VRRP, because they don't like VRRP. =A0I decided that we = should go with >> what most of the industry cares about rather than what OpenBSD cares abo= ut. > > Additionally, Daniel Hartmeier posted a significant patch to > freebsd-questions@ for pf+tcpdump earlier this year that added support > for the pfsync device. I've been using it in production on firewalls > with 125k pps average to track NAT translations for a /17 and it's > been of endless utility since pf doesn't offer the translation logging > you see on some commercial devices. > any URL about the patch in question ? I cannot find anything in the recent archives of freebsd-questions@ Thanks, - Arnaud From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 22:11:25 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E2281065670 for ; Thu, 20 Oct 2011 22:11:25 +0000 (UTC) (envelope-from peterjeremy@acm.org) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id A664A8FC14 for ; Thu, 20 Oct 2011 22:11:24 +0000 (UTC) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9KJjnss017836 for ; Fri, 21 Oct 2011 06:45:49 +1100 Received: from server.vk2pj.dyndns.org (c220-239-116-103.belrs4.nsw.optusnet.com.au [220.239.116.103]) by mail11.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id p9KJjjHK022292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Oct 2011 06:45:46 +1100 X-Bogosity: Ham, spamicity=0.000000 Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1]) by server.vk2pj.dyndns.org (8.14.5/8.14.4) with ESMTP id p9KJjiZo043590; Fri, 21 Oct 2011 06:45:44 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.14.5/8.14.4/Submit) id p9KJjhL2043589; Fri, 21 Oct 2011 06:45:43 +1100 (EST) (envelope-from peter) Date: Fri, 21 Oct 2011 06:45:42 +1100 From: Peter Jeremy To: George Neville-Neil Message-ID: <20111020194542.GA43559@server.vk2pj.dyndns.org> References: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> X-PGP-Key: http://members.optusnet.com.au/peterjeremy/pubkey.asc User-Agent: Mutt/1.5.21 (2010-09-15) Cc: net@freebsd.org Subject: Re: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 22:11:25 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2011-Oct-19 16:20:27 -0400, George Neville-Neil w= rote: >I've been trying to debug CARP problems of late. I noticed that our >tcpdump didn't have CARP support. bin/124825 includes patches to cover both pfsync & CARP. I have patched 8.x but can't recall if the patches still apply to 9.x/10.x. --=20 Peter Jeremy --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iEYEARECAAYFAk6gemYACgkQ/opHv/APuId9pwCgo0T06y9kvktVUsoWnaF9/+bZ WjUAn2szONf0VyQqT/9tSP9Rl8HMUlEr =nKDR -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-net@FreeBSD.ORG Thu Oct 20 22:48:14 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 62531106564A for ; Thu, 20 Oct 2011 22:48:14 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 23C928FC08 for ; Thu, 20 Oct 2011 22:48:13 +0000 (UTC) Received: by ggnq2 with SMTP id q2so2562554ggn.13 for ; Thu, 20 Oct 2011 15:48:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RmJbeWzCAnCyfmiv7sSJU8kd2OG/Rl2QToqypDG1v+Q=; b=C++knDUxASEVnSjkyD1xudOyfQy8xzsNDr0Ahn4LySUx3YE+Tm1wBZLxBpkzBin2+Q sXimzSPsPgkfpvQXpsAz8NcvbSiEiQSDiOQHNgBgciDPnUGpLNhxW/9YJM9WWl3PZpB+ 7IXSaPrD9erf/J6ocjG5+xZDSVpyHC+HUsjbk= MIME-Version: 1.0 Received: by 10.68.208.229 with SMTP id mh5mr23147867pbc.124.1319150892974; Thu, 20 Oct 2011 15:48:12 -0700 (PDT) Received: by 10.68.40.199 with HTTP; Thu, 20 Oct 2011 15:48:12 -0700 (PDT) In-Reply-To: References: <00C1A678-1654-40D2-9ADD-1857C2ECCA04@neville-neil.com> Date: Thu, 20 Oct 2011 18:48:12 -0400 Message-ID: From: Kevin Wilcox To: Arnaud Lacombe Content-Type: text/plain; charset=UTF-8 Cc: net@freebsd.org Subject: Re: Patch to enable our tcpdump to handle CARP X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Oct 2011 22:48:14 -0000 On 20 October 2011 14:40, Arnaud Lacombe wrote: > any URL about the patch in question ? I cannot find anything in the > recent archives of freebsd-questions@ Hi Arnaud, my apologies, it was to freebsd-pf@ http://www.mail-archive.com/freebsd-pf@freebsd.org/msg04979.html kmw From owner-freebsd-net@FreeBSD.ORG Fri Oct 21 23:55:27 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9F1001065673 for ; Fri, 21 Oct 2011 23:55:27 +0000 (UTC) (envelope-from prvs=1275951b39=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 2D6128FC0C for ; Fri, 21 Oct 2011 23:55:26 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 00:44:14 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 00:44:14 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50015726281.msg for ; Sat, 22 Oct 2011 00:44:13 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1275951b39=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> From: "Steven Hartland" To: Date: Sat, 22 Oct 2011 00:44:07 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Subject: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Oct 2011 23:55:27 -0000 After a HD failure we moved an IP of one of our DNS servers to some new hardware. Now we are seeing some very strange behaviour on a number of machines when talking to the ip which was moved. Specifically it seems both icmp and tcp work just fine but udp doesn't. I've just done a trace from one such box and to my horror the tcpdump shows icmp and udp traffic for the same IP going to different mac's. icmp is going to the right mac and is working fine but udp is going to the wrong mac and isn't (as you would expect) In /var/log/messages there are arp messages which show the ip moving from -> to the correct macs but it seems like something somewhere is caching the resolution. arp -a also show's the correct result and arp -d -a doesn't help. So the question how on earth is udp resolving the mac to something different than icmp and tcp? To complicate matters even further some machines are working intermittently and the traces show the udp some times going to the right place and some times not. In all tests we're using just a dig with a specified server. The machines involved are all running 8.2-RELEASE on amd64 Any help would be most appreciated as its causing chaos due to the IP that moved being our DNS servers and hence things are randomly stalling left right and center :( Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:10:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE6091065673 for ; Sat, 22 Oct 2011 00:10:13 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 968D38FC0C for ; Sat, 22 Oct 2011 00:10:13 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9M0AC2S024896 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Oct 2011 17:10:12 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 21 Oct 2011 17:10:06 -0700 From: "Li, Qing" To: Steven Hartland , "freebsd-net@freebsd.org" Thread-Topic: very strange arp problem after ip move - icmp works udp doesn't Thread-Index: AQHMkE0IYispNC6ALEmWKT0Fg7UO35WHfPDP Date: Sat, 22 Oct 2011 00:10:05 +0000 Message-ID: References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> In-Reply-To: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Subject: RE: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:10:14 -0000 You don't have the flowtable component enabled, do you ?=0A= =0A= --Qing=0A= =0A= ________________________________________=0A= From: owner-freebsd-net@freebsd.org [owner-freebsd-net@freebsd.org] on beha= lf of Steven Hartland [killing@multiplay.co.uk]=0A= Sent: Friday, October 21, 2011 4:44 PM=0A= To: freebsd-net@freebsd.org=0A= Subject: very strange arp problem after ip move - icmp works udp doesn't=0A= =0A= After a HD failure we moved an IP of one of our DNS=0A= servers to some new hardware.=0A= =0A= Now we are seeing some very strange behaviour on a number=0A= of machines when talking to the ip which was moved.=0A= =0A= Specifically it seems both icmp and tcp work just fine=0A= but udp doesn't.=0A= =0A= I've just done a trace from one such box and to my horror=0A= the tcpdump shows icmp and udp traffic for the same=0A= IP going to different mac's.=0A= =0A= icmp is going to the right mac and is working fine=0A= but udp is going to the wrong mac and isn't (as you=0A= would expect)=0A= =0A= In /var/log/messages there are arp messages=0A= which show the ip moving from -> to the correct macs=0A= but it seems like something somewhere is caching=0A= the resolution.=0A= =0A= arp -a also show's the correct result and arp -d -a doesn't=0A= help.=0A= =0A= So the question how on earth is udp resolving the mac=0A= to something different than icmp and tcp?=0A= =0A= To complicate matters even further some machines are=0A= working intermittently and the traces show the udp=0A= some times going to the right place and some times=0A= not.=0A= =0A= In all tests we're using just a dig with a specified=0A= server.=0A= =0A= The machines involved are all running 8.2-RELEASE on=0A= amd64=0A= =0A= Any help would be most appreciated as its causing chaos=0A= due to the IP that moved being our DNS servers and hence=0A= things are randomly stalling left right and center :(=0A= =0A= Regards=0A= Steve=0A= =0A= =0A= =0A= =0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= This e.mail is private and confidential between Multiplay (UK) Ltd. and the= person or entity to whom it is addressed. In the event of misdirection, th= e recipient is prohibited from using, copying, printing or otherwise dissem= inating it or any information contained in it.=0A= =0A= In the event of misdirection, illegible or incomplete transmission please t= elephone +44 845 868 1337=0A= or return the E.mail to postmaster@multiplay.co.uk.=0A= =0A= _______________________________________________=0A= freebsd-net@freebsd.org mailing list=0A= http://lists.freebsd.org/mailman/listinfo/freebsd-net=0A= To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"=0A= From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:29:11 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D07F7106566B for ; Sat, 22 Oct 2011 00:29:11 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 97D068FC12 for ; Sat, 22 Oct 2011 00:29:11 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9M0TB58028683 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Oct 2011 17:29:11 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 21 Oct 2011 17:29:05 -0700 From: "Li, Qing" To: Steven Hartland Thread-Topic: very strange arp problem after ip move - icmp works udp doesn't Thread-Index: AQHMkE0IYispNC6ALEmWKT0Fg7UO35WHfPDPgAAEIX2AAAGLzw== Date: Sat, 22 Oct 2011 00:29:05 +0000 Message-ID: <78997A42-95E7-4DF4-890C-BBDFE1CE4B03@bluecoat.com> References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: Re: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:29:11 -0000 Looks like it's enabled. Shut it off and check again please -- Qing On Oct 21, 2011, at 5:23 PM, "Steven Hartland" wr= ote: > We've not enabled it specifically but we may be:- > sysctl -a |grep flowtable net.inet.ip.output_flowtable_size: 32768 > net.inet.flowtable.stats: net.inet.flowtable.nmbflows: 197632 > net.inet.flowtable.tcp_expire: 86400 > net.inet.flowtable.fin_wait_expire: 600 > net.inet.flowtable.udp_expire: 300 > net.inet.flowtable.syn_expire: 300 > net.inet.flowtable.enable: 1 > net.inet.flowtable.debug: 0 >=20 > This mean yes? >=20 > ----- Original Message ----- From: "Li, Qing" > To: "Steven Hartland" ; > Sent: Saturday, October 22, 2011 1:10 AM > Subject: RE: very strange arp problem after ip move - icmp works udp does= n't >=20 >=20 > You don't have the flowtable component enabled, do you ? >=20 > --Qing >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > This e.mail is private and confidential between Multiplay (UK) Ltd. and t= he person or entity to whom it is addressed. In the event of misdirection, = the recipient is prohibited from using, copying, printing or otherwise diss= eminating it or any information contained in it.=20 > In the event of misdirection, illegible or incomplete transmission please= telephone +44 845 868 1337 > or return the E.mail to postmaster@multiplay.co.uk. >=20 From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:34:29 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4D7B51065670 for ; Sat, 22 Oct 2011 00:34:29 +0000 (UTC) (envelope-from prvs=1276cd47a5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id D4FD78FC15 for ; Sat, 22 Oct 2011 00:34:28 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 01:23:15 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 01:23:15 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50015726861.msg for ; Sat, 22 Oct 2011 01:23:14 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1276cd47a5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Li, Qing" , References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> Date: Sat, 22 Oct 2011 01:23:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: Subject: Re: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:34:29 -0000 We've not enabled it specifically but we may be:- sysctl -a |grep flowtable net.inet.ip.output_flowtable_size: 32768 net.inet.flowtable.stats: net.inet.flowtable.nmbflows: 197632 net.inet.flowtable.tcp_expire: 86400 net.inet.flowtable.fin_wait_expire: 600 net.inet.flowtable.udp_expire: 300 net.inet.flowtable.syn_expire: 300 net.inet.flowtable.enable: 1 net.inet.flowtable.debug: 0 This mean yes? ----- Original Message ----- From: "Li, Qing" To: "Steven Hartland" ; Sent: Saturday, October 22, 2011 1:10 AM Subject: RE: very strange arp problem after ip move - icmp works udp doesn't You don't have the flowtable component enabled, do you ? --Qing ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:41:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17740106566C for ; Sat, 22 Oct 2011 00:41:53 +0000 (UTC) (envelope-from prvs=1276cd47a5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 96A668FC0A for ; Sat, 22 Oct 2011 00:41:52 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 01:41:51 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 01:41:51 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50015726993.msg for ; Sat, 22 Oct 2011 01:41:50 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1276cd47a5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: <4D86495397B9404D80C693302B6438F6@multiplay.co.uk> From: "Steven Hartland" To: "Li, Qing" References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> , <78997A42-95E7-4DF4-890C-BBDFE1CE4B03@bluecoat.com> Date: Sat, 22 Oct 2011 01:41:40 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-net@freebsd.org Subject: Re: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:41:53 -0000 Many many thanks! sysctl net.inet.flowtable.enable=0 instantly fixed the issue :) Thought I was going to have to reboot all the machines to fix there for a while, which wouldn't have been fun. Seems like the flow table is pretty broken then with respect changing arp entries, at least in 8.2-RELEASE :( Regards Steve ----- Original Message ----- From: "Li, Qing" Looks like it's enabled. Shut it off and check again please ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 00:53:02 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3EB301065679 for ; Sat, 22 Oct 2011 00:53:02 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1-6.sentex.ca [IPv6:2607:f3e0:0:1::12]) by mx1.freebsd.org (Postfix) with ESMTP id F34668FC08 for ; Sat, 22 Oct 2011 00:53:01 +0000 (UTC) Received: from [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a] (saphire3.sentex.ca [IPv6:2607:f3e0:0:4:f025:8813:7603:7e4a]) by smarthost1.sentex.ca (8.14.5/8.14.4) with ESMTP id p9M0r0im062474; Fri, 21 Oct 2011 20:53:00 -0400 (EDT) (envelope-from mike@sentex.net) Message-ID: <4EA213E3.4040406@sentex.net> Date: Fri, 21 Oct 2011 20:52:51 -0400 From: Mike Tancsa Organization: Sentex Communications User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Steven Hartland References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> , <78997A42-95E7-4DF4-890C-BBDFE1CE4B03@bluecoat.com> <4D86495397B9404D80C693302B6438F6@multiplay.co.uk> In-Reply-To: <4D86495397B9404D80C693302B6438F6@multiplay.co.uk> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.71 on IPv6:2607:f3e0:0:1::12 Cc: freebsd-net@freebsd.org Subject: Re: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 00:53:02 -0000 On 10/21/2011 8:41 PM, Steven Hartland wrote: > > Seems like the flow table is pretty broken then with respect > changing arp entries, at least in 8.2-RELEASE :( Its been removed from the default kernel back in April Author: bz Date: Sat Apr 9 12:04:35 2011 New Revision: 220486 URL: http://svn.freebsd.org/changeset/base/220486 Log: MFC r219775: For now remove options FLOWTABLE from the remaining GENERIC kernel configurations and make it opt-in for those who want it. LINT will still build it. While it may be a perfect win in some scenarios, it still troubles users (see PRs) in general cases. In addition we are still allocating resources even if disabled by sysctl and still leak arp/nd6 entries in case of interface destruction. Discussed with: qingli (2010-11-24, just never executed) Discussed with: juli (OCTEON1) PR: kern/148018, kern/155604, kern/144917, kern/146792 ---Mike -- ------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 01:29:32 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11437106567A for ; Sat, 22 Oct 2011 01:29:32 +0000 (UTC) (envelope-from prvs=1276cd47a5=killing@multiplay.co.uk) Received: from mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) by mx1.freebsd.org (Postfix) with ESMTP id 907778FC17 for ; Sat, 22 Oct 2011 01:29:31 +0000 (UTC) X-MDAV-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 02:29:21 +0100 X-Spam-Processed: mail1.multiplay.co.uk, Sat, 22 Oct 2011 02:29:21 +0100 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on mail1.multiplay.co.uk X-Spam-Level: X-Spam-Status: No, score=-5.0 required=6.0 tests=USER_IN_WHITELIST shortcircuit=ham autolearn=disabled version=3.2.5 Received: from r2d2 ([188.220.16.49]) by mail1.multiplay.co.uk (mail1.multiplay.co.uk [85.236.96.23]) (MDaemon PRO v10.0.4) with ESMTP id md50015727426.msg for ; Sat, 22 Oct 2011 02:29:21 +0100 X-MDRemoteIP: 188.220.16.49 X-Return-Path: prvs=1276cd47a5=killing@multiplay.co.uk X-Envelope-From: killing@multiplay.co.uk X-MDaemon-Deliver-To: freebsd-net@freebsd.org Message-ID: From: "Steven Hartland" To: "Mike Tancsa" References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> , <78997A42-95E7-4DF4-890C-BBDFE1CE4B03@bluecoat.com><4D86495397B9404D80C693302B6438F6@multiplay.co.uk> <4EA213E3.4040406@sentex.net> Date: Sat, 22 Oct 2011 02:29:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6109 Cc: freebsd-net@freebsd.org Subject: Re: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 01:29:32 -0000 ----- Original Message ----- From: "Mike Tancsa" >> Seems like the flow table is pretty broken then with respect >> changing arp entries, at least in 8.2-RELEASE :( > > Its been removed from the default kernel back in April > > Author: bz > Date: Sat Apr 9 12:04:35 2011 > New Revision: 220486 > URL: http://svn.freebsd.org/changeset/base/220486 > > Log: > MFC r219775: > > For now remove options FLOWTABLE from the remaining GENERIC kernel > configurations and make it opt-in for those who want it. LINT will > still build it. > > While it may be a perfect win in some scenarios, it still troubles users > (see PRs) in general cases. In addition we are still allocating > resources > even if disabled by sysctl and still leak arp/nd6 entries in case of > interface destruction. > > Discussed with: qingli (2010-11-24, just never executed) > Discussed with: juli (OCTEON1) > PR: kern/148018, kern/155604, kern/144917, kern/146792 Yep found that, but it was post 8.2 so don't have it here and tbh if its that broken that an IP move doesn't work it could also do with some serious warning if enabled, otherwise some unsuspecting sole is going to end up in a similar situation to us tonight, scratching their heads thing WTF!!! Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster@multiplay.co.uk. From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 03:01:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FAC11065674 for ; Sat, 22 Oct 2011 03:01:54 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id 1D5D78FC08 for ; Sat, 22 Oct 2011 03:01:53 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9M31r0U006976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Oct 2011 20:01:53 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 21 Oct 2011 20:01:49 -0700 From: "Li, Qing" To: Steven Hartland Thread-Topic: very strange arp problem after ip move - icmp works udp doesn't Thread-Index: AQHMkFoAYispNC6ALEmWKT0Fg7UO35WHrC1r Date: Sat, 22 Oct 2011 03:01:48 +0000 Message-ID: References: <02FFC9CF360C4E2F81B00B653DE1584E@multiplay.co.uk> , <78997A42-95E7-4DF4-890C-BBDFE1CE4B03@bluecoat.com><4D86495397B9404D80C693302B6438F6@multiplay.co.uk> <4EA213E3.4040406@sentex.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "freebsd-net@freebsd.org" Subject: RE: very strange arp problem after ip move - icmp works udp doesn't X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 03:01:54 -0000 >=0A= > Yep found that, but it was post 8.2 so don't have it here and tbh if its= =0A= > that broken that an IP move doesn't work it could also do with some=0A= > serious warning if enabled, otherwise some unsuspecting sole is going=0A= > to end up in a similar situation to us tonight, scratching their heads=0A= > thing WTF!!!=0A= >=0A= =0A= Agreed. These issues will be addressed soon.=0A= =0A= Thanks,=0A= =0A= -- Qing=0A= From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 06:40:30 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id BCCDA106564A for ; Sat, 22 Oct 2011 06:40:30 +0000 (UTC) (envelope-from qing.li@bluecoat.com) Received: from whisker.bluecoat.com (whisker.bluecoat.com [216.52.23.28]) by mx1.freebsd.org (Postfix) with ESMTP id A2EDA8FC15 for ; Sat, 22 Oct 2011 06:40:30 +0000 (UTC) Received: from PWSVL-EXCHTS-01.internal.cacheflow.com ([10.2.2.122]) by whisker.bluecoat.com (8.14.2/8.14.2) with ESMTP id p9M6eTa7029837 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 21 Oct 2011 23:40:29 -0700 (PDT) Received: from PWSVL-EXCMBX-01.internal.cacheflow.com ([fe80::15bc:12e2:4676:340f]) by PWSVL-EXCHTS-01.internal.cacheflow.com ([fe80::5c50:e2ba:8115:4223%20]) with mapi id 14.01.0289.001; Fri, 21 Oct 2011 23:40:24 -0700 From: "Li, Qing" To: "freebsd-net@freebsd.org" Thread-Topic: patch for route deletion issue Thread-Index: AcyQhXKAYQMDJ5ntTdmcPFcZhEQWlA== Date: Sat, 22 Oct 2011 06:40:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [216.52.23.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: patch for route deletion issue X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 06:40:30 -0000 The host-id/interface-id can have a specific value and is properly masked o= ut when=20 adding a prefix route. As in route add -net 192.103.54.9/24 10.9.44.1 =20 OR for IPv6 route add -inet6 -net 2001:db8:1::1/48 2001:418:1800::1 The problem is when deleting the route, simply changing the command keyword from "add" to "delete" does not work. In other words, route delete -net 192.103.54.9/24 10.9.44.1 =20 OR for IPv6 route delete -inet6 -net 2001:db8:1::1/48 2001:418:1800::1 will return a route-not-found error. However, issue the command with the ho= st-id or interface-id cleared works, as in: route add -inet 192.103.54.0/24 10.9.44.1 OR for IPv6 route delete -inet6 -net 2001:db8:1::/48 2001:418:1800::1 The failure has been observed on 7.x, 8.x, 9.x and -current. The route command behavior should be consistent between "add" and "delete". In addition, providing the proper prefix value can be a bit of work dependi= ng on the prefix length. The patch that fixes the described issue sits in=20 http://people.freebsd.org/~qingli/route.c.diff Please apply this patch and report issues if any. I intend to commit the patch in a few days. Thanks, -- Qing From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 09:07:05 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 956CE106566B; Sat, 22 Oct 2011 09:07:05 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.dawidek.net (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id 511778FC0C; Sat, 22 Oct 2011 09:07:05 +0000 (UTC) Received: from localhost (89-73-195-149.dynamic.chello.pl [89.73.195.149]) by mail.dawidek.net (Postfix) with ESMTPSA id 342EE20D; Sat, 22 Oct 2011 10:50:15 +0200 (CEST) Date: Sat, 22 Oct 2011 10:49:32 +0200 From: Pawel Jakub Dawidek To: freebsd-current@FreeBSD.org Message-ID: <20111022084931.GD1697@garage.freebsd.pl> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VMt1DrMGOVs3KQwf" Content-Disposition: inline X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@FreeBSD.org Subject: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 09:07:05 -0000 --VMt1DrMGOVs3KQwf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable The panic message says: panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt 3718269252= rcv_adv 3718268291 I only have picture of the backtrace: http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --VMt1DrMGOVs3KQwf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk6ig5sACgkQForvXbEpPzRg5QCdGkUg4m/tNG2yKRcwr7qcEd6d yVcAn0T7wql9e5oz1ApEAK1odmZRE6J2 =YRqA -----END PGP SIGNATURE----- --VMt1DrMGOVs3KQwf-- From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 12:38:00 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 77EFA1065673 for ; Sat, 22 Oct 2011 12:38:00 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id A4BC58FC13 for ; Sat, 22 Oct 2011 12:37:59 +0000 (UTC) Received: (qmail 2977 invoked from network); 22 Oct 2011 12:11:17 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Oct 2011 12:11:17 -0000 Date: Sat, 22 Oct 2011 14:11:17 +0200 (CEST) Message-Id: <20111022.141117.74664953.sthaug@nethelp.no> To: freebsd-stable@freebsd.org, freebsd-net@freebsd.org From: sthaug@nethelp.no X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: Subject: How to set interface description containing space in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 12:38:00 -0000 FreeBSD 8.x (well, at least 8.2) has the very nice feature of letting you set an interface *description* (just like you can on any Juniper/ Cisco/whatever router). This decription can contain spaces - so I can do for instance: xxx# ifconfig bge1 descr "abc def" xxx# ifconfig bge1 bge1: flags=8843 metric 0 mtu 1500 description: abc def options=8009b ether 00:13:72:20:b4:6f media: Ethernet autoselect (1000baseT ) status: active and we see that the decription includes a space. The question is - how can I include a description containing one or more spaces in rc.conf? The straighforward attempt, ifconfig_bge1="up descr abc def" doesn't work - "abc" and "def" are given as separate parameters to the ifconfig command, resulting in "abc" being used and "def" regarded as an extra parameter: xxx# /etc/rc.d/netif start bge1 ifconfig: def: bad value I have tried several variants, ifconfig_bge1="up descr abc\ def" ifconfig_bge1="up descr abc\\ def" ifconfig_bge1="up descr 'abc def'" ifconfig_bge1="up descr \"abc def\"" ifconfig_bge1="up descr abc_def" but none have the desired result. Can anybody shed a light on this? Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 13:08:46 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D0685106566B for ; Sat, 22 Oct 2011 13:08:46 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by mx1.freebsd.org (Postfix) with ESMTP id 928FB8FC15 for ; Sat, 22 Oct 2011 13:08:46 +0000 (UTC) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta14.westchester.pa.mail.comcast.net with comcast id no831h0061ei1Bg5EovXzF; Sat, 22 Oct 2011 12:55:31 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta24.westchester.pa.mail.comcast.net with comcast id novW1h0151t3BNj3kovWl4; Sat, 22 Oct 2011 12:55:31 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 00C2C102C1C; Sat, 22 Oct 2011 05:55:28 -0700 (PDT) Date: Sat, 22 Oct 2011 05:55:28 -0700 From: Jeremy Chadwick To: sthaug@nethelp.no Message-ID: <20111022125528.GA12452@icarus.home.lan> References: <20111022.141117.74664953.sthaug@nethelp.no> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111022.141117.74664953.sthaug@nethelp.no> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to set interface description containing space in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 13:08:47 -0000 On Sat, Oct 22, 2011 at 02:11:17PM +0200, sthaug@nethelp.no wrote: > FreeBSD 8.x (well, at least 8.2) has the very nice feature of letting > you set an interface *description* (just like you can on any Juniper/ > Cisco/whatever router). This decription can contain spaces - so I can > do for instance: > > xxx# ifconfig bge1 descr "abc def" > > xxx# ifconfig bge1 > bge1: flags=8843 metric 0 mtu 1500 > description: abc def > options=8009b > ether 00:13:72:20:b4:6f > media: Ethernet autoselect (1000baseT ) > status: active > > and we see that the decription includes a space. The question is - how > can I include a description containing one or more spaces in rc.conf? > > The straighforward attempt, > > ifconfig_bge1="up descr abc def" > > doesn't work - "abc" and "def" are given as separate parameters to the > ifconfig command, resulting in "abc" being used and "def" regarded as > an extra parameter: > > xxx# /etc/rc.d/netif start bge1 > ifconfig: def: bad value > > I have tried several variants, > > ifconfig_bge1="up descr abc\ def" > ifconfig_bge1="up descr abc\\ def" > ifconfig_bge1="up descr 'abc def'" > ifconfig_bge1="up descr \"abc def\"" > ifconfig_bge1="up descr abc_def" > > but none have the desired result. Can anybody shed a light on this? I have 100% success using apostrophes, as so: ifconfig_em1="... descr 'snakes and crumpets'" The "..." part of the string is just to indicate other stuff can go there, presumably. My em1 interface isn't actually in use (no IP configured, etc.). Result after running /etc/rc.d/netif start: em1: flags=8843 metric 0 mtu 1500 description: snakes and crumpets options=219b ether 00:30:48:d2:22:d1 media: Ethernet autoselect status: no carrier This is on RELENG_8 dated 2011/09/28. If you want me to test it on my em0 interface (which is what actually has an IP configured, etc.) and do a full reboot, I can do that. Let me know. So there may have been some rc.d framework changes that address your problem. Are you running -RELEASE? If so those fixes probably aren't available. In an ideal world, we should really have ifconfig_XXX_descr rc.conf bits to make for an easier-to-read rc.conf file. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 13:15:53 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 380051065670 for ; Sat, 22 Oct 2011 13:15:53 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from qmta01.emeryville.ca.mail.comcast.net (qmta01.emeryville.ca.mail.comcast.net [76.96.30.16]) by mx1.freebsd.org (Postfix) with ESMTP id 1FDA18FC15 for ; Sat, 22 Oct 2011 13:15:53 +0000 (UTC) Received: from omta09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by qmta01.emeryville.ca.mail.comcast.net with comcast id np1N1h0010S2fkCA1p2b7t; Sat, 22 Oct 2011 13:02:35 +0000 Received: from koitsu.dyndns.org ([67.180.84.87]) by omta09.emeryville.ca.mail.comcast.net with comcast id np2p1h00h1t3BNj8Vp2pHG; Sat, 22 Oct 2011 13:02:50 +0000 Received: by icarus.home.lan (Postfix, from userid 1000) id 8C979102C1C; Sat, 22 Oct 2011 06:02:41 -0700 (PDT) Date: Sat, 22 Oct 2011 06:02:41 -0700 From: Jeremy Chadwick To: sthaug@nethelp.no Message-ID: <20111022130241.GA12632@icarus.home.lan> References: <20111022.141117.74664953.sthaug@nethelp.no> <20111022125528.GA12452@icarus.home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111022125528.GA12452@icarus.home.lan> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to set interface description containing space in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 13:15:53 -0000 On Sat, Oct 22, 2011 at 05:55:28AM -0700, Jeremy Chadwick wrote: > On Sat, Oct 22, 2011 at 02:11:17PM +0200, sthaug@nethelp.no wrote: > > FreeBSD 8.x (well, at least 8.2) has the very nice feature of letting > > you set an interface *description* (just like you can on any Juniper/ > > Cisco/whatever router). This decription can contain spaces - so I can > > do for instance: > > > > xxx# ifconfig bge1 descr "abc def" > > > > xxx# ifconfig bge1 > > bge1: flags=8843 metric 0 mtu 1500 > > description: abc def > > options=8009b > > ether 00:13:72:20:b4:6f > > media: Ethernet autoselect (1000baseT ) > > status: active > > > > and we see that the decription includes a space. The question is - how > > can I include a description containing one or more spaces in rc.conf? > > > > The straighforward attempt, > > > > ifconfig_bge1="up descr abc def" > > > > doesn't work - "abc" and "def" are given as separate parameters to the > > ifconfig command, resulting in "abc" being used and "def" regarded as > > an extra parameter: > > > > xxx# /etc/rc.d/netif start bge1 > > ifconfig: def: bad value > > > > I have tried several variants, > > > > ifconfig_bge1="up descr abc\ def" > > ifconfig_bge1="up descr abc\\ def" > > ifconfig_bge1="up descr 'abc def'" > > ifconfig_bge1="up descr \"abc def\"" > > ifconfig_bge1="up descr abc_def" > > > > but none have the desired result. Can anybody shed a light on this? > > I have 100% success using apostrophes, as so: > > ifconfig_em1="... descr 'snakes and crumpets'" > > The "..." part of the string is just to indicate other stuff can go > there, presumably. My em1 interface isn't actually in use (no IP > configured, etc.). > > Result after running /etc/rc.d/netif start: > > em1: flags=8843 metric 0 mtu 1500 > description: snakes and crumpets > options=219b > ether 00:30:48:d2:22:d1 > media: Ethernet autoselect > status: no carrier > > This is on RELENG_8 dated 2011/09/28. > > If you want me to test it on my em0 interface (which is what actually has > an IP configured, etc.) and do a full reboot, I can do that. Let me > know. > > So there may have been some rc.d framework changes that address your > problem. Are you running -RELEASE? If so those fixes probably aren't > available. And here's the commit that fixed it (src/etc/network.subr, which is /etc/network.subr): http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/network.subr#rev1.195.2.12 http://www.freebsd.org/cgi/query-pr.cgi?pr=156675 So your choices are: 1. Run RELENG_8 (8.2-STABLE) or higher, 2. Wait for 8.3-RELEASE, 3. Hand-hack /etc/network.subr to address this, which you will lose every time you run mergemaster (I strongly recommend you do not do this; breakage in network.subr could be very bad for you). I still think we should have ifconfig_XXX_descr though, just because having super long ifconfig_XXX lines in rc.conf is sometimes tedious and difficult to read. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, US | | Making life hard for others since 1977. PGP 4BD6C0CB | From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 13:24:07 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B0CDA10656D1 for ; Sat, 22 Oct 2011 13:24:07 +0000 (UTC) (envelope-from sthaug@nethelp.no) Received: from bizet.nethelp.no (bizet.nethelp.no [195.1.209.33]) by mx1.freebsd.org (Postfix) with SMTP id F108A8FC14 for ; Sat, 22 Oct 2011 13:24:06 +0000 (UTC) Received: (qmail 5499 invoked from network); 22 Oct 2011 13:24:05 -0000 Received: from bizet.nethelp.no (HELO localhost) (195.1.209.33) by bizet.nethelp.no with SMTP; 22 Oct 2011 13:24:05 -0000 Date: Sat, 22 Oct 2011 15:24:05 +0200 (CEST) Message-Id: <20111022.152405.41725270.sthaug@nethelp.no> To: freebsd@jdc.parodius.com From: sthaug@nethelp.no In-Reply-To: <20111022130241.GA12632@icarus.home.lan> References: <20111022.141117.74664953.sthaug@nethelp.no> <20111022125528.GA12452@icarus.home.lan> <20111022130241.GA12632@icarus.home.lan> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org Subject: Re: How to set interface description containing space in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 13:24:07 -0000 > > So there may have been some rc.d framework changes that address your > > problem. Are you running -RELEASE? If so those fixes probably aren't > > available. > > And here's the commit that fixed it (src/etc/network.subr, which is > /etc/network.subr): > > http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/network.subr#rev1.195.2.12 > http://www.freebsd.org/cgi/query-pr.cgi?pr=156675 Yup, thank you for verifying this! I see now that it works on an 8.2-STABLE box with sources from October 4, while it doesn't work on one from early June. Problem solved. Steinar Haug, Nethelp consulting, sthaug@nethelp.no From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 15:24:54 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7BAB106566C for ; Sat, 22 Oct 2011 15:24:54 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id A74208FC13 for ; Sat, 22 Oct 2011 15:24:54 +0000 (UTC) Received: by yxt33 with SMTP id 33so1081851yxt.13 for ; Sat, 22 Oct 2011 08:24:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version:content-type; bh=q7wCy1iSuiEMg5Na0oBqNc0apcWtTqa0lJU2SK0T+YM=; b=HAS5d81ecWljLTubCy2mS7xxEv1FmLd91XvoQjZjEzWWNesublhmQyZXXDbpBU+07E 17BmYcH+DoqmN4JbwVEar5G09uKQSghiRrP4zl0rhV7Ys1zk22gUBE9W6XMRdwQKUNU+ 50BEvMsN2WVtRb/tVrdtLwrTqsM1TdPCY/84g= Received: by 10.68.74.132 with SMTP id t4mr6934130pbv.130.1319295542777; Sat, 22 Oct 2011 07:59:02 -0700 (PDT) Received: from c-24-6-49-154.hsd1.ca.comcast.net (c-24-6-49-154.hsd1.ca.comcast.net. [24.6.49.154]) by mx.google.com with ESMTPS id v8sm43227795pbf.8.2011.10.22.07.59.00 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 22 Oct 2011 07:59:01 -0700 (PDT) Date: Sat, 22 Oct 2011 07:58:59 -0700 (PDT) From: Garrett Cooper To: Pawel Jakub Dawidek In-Reply-To: <20111022084931.GD1697@garage.freebsd.pl> Message-ID: References: <20111022084931.GD1697@garage.freebsd.pl> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-net@freebsd.org, freebsd-current@freebsd.org Subject: Re: 9.0-RC1 panic in tcp_input: negative winow. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 15:24:55 -0000 On Sat, 22 Oct 2011, Pawel Jakub Dawidek wrote: > The panic message says: > > panic: tcp_input negative window: tp 0xfffffe007763e000 rcv_nxt 3718269252 rcv_adv 3718268291 > > I only have picture of the backtrace: > > http://people.freebsd.org/~pjd/misc/panic_negative_window.jpg I've seen that issue once before in the r222XYZ days -- it's a problem that's been around since the TCP / IP code has been refactored in FreeBSD. Thanks, -Garrett From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 16:06:57 2011 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 077F2106564A; Sat, 22 Oct 2011 16:06:57 +0000 (UTC) (envelope-from linimon@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D3CA58FC18; Sat, 22 Oct 2011 16:06:56 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p9MG6ujk096046; Sat, 22 Oct 2011 16:06:56 GMT (envelope-from linimon@freefall.freebsd.org) Received: (from linimon@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p9MG6uaR096042; Sat, 22 Oct 2011 16:06:56 GMT (envelope-from linimon) Date: Sat, 22 Oct 2011 16:06:56 GMT Message-Id: <201110221606.p9MG6uaR096042@freefall.freebsd.org> To: linimon@FreeBSD.org, freebsd-bugs@FreeBSD.org, freebsd-net@FreeBSD.org From: linimon@FreeBSD.org Cc: Subject: Re: kern/161899: [route] Repeating RTM_MISS packets causing high CPU load for ntpd X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 16:06:57 -0000 Old Synopsis: Repeating RTM_MISS packets causing high CPU load for ntpd New Synopsis: [route] Repeating RTM_MISS packets causing high CPU load for ntpd Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Sat Oct 22 16:05:57 UTC 2011 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=161899 From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 18:55:16 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 9D288106564A; Sat, 22 Oct 2011 18:55:16 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 172-17-198-245.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 627A2153EE6; Sat, 22 Oct 2011 18:55:16 +0000 (UTC) Message-ID: <4EA31194.6060008@FreeBSD.org> Date: Sat, 22 Oct 2011 11:55:16 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:7.0.1) Gecko/20111001 Thunderbird/7.0.1 MIME-Version: 1.0 To: Jeremy Chadwick References: <20111022.141117.74664953.sthaug@nethelp.no> <20111022125528.GA12452@icarus.home.lan> <20111022130241.GA12632@icarus.home.lan> In-Reply-To: <20111022130241.GA12632@icarus.home.lan> X-Enigmail-Version: undefined OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, freebsd-stable@freebsd.org, sthaug@nethelp.no Subject: Re: How to set interface description containing space in 8.x X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 18:55:16 -0000 On 10/22/2011 06:02, Jeremy Chadwick wrote: > 3. Hand-hack /etc/network.subr to address this, which you will lose > every time you run mergemaster I'm not sure why you'd say that. By design mergemaster checks the $FreeBSD Id string in the installed file and if it's the same as the one in the temproot then it deletes the temproot version and moves on. That behavior was primarily designed to accommodate configuration files, but it works just as well for everything else mergemaster deals with. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-net@FreeBSD.ORG Sat Oct 22 20:22:14 2011 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 79A86106566C for ; Sat, 22 Oct 2011 20:22:14 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 01CC98FC16 for ; Sat, 22 Oct 2011 20:22:13 +0000 (UTC) Received: by bkbzu17 with SMTP id zu17so8213309bkb.13 for ; Sat, 22 Oct 2011 13:22:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=reply-to:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=rPolrrrzVyP0xgJeLrKzgfUNZOdoh1VeizQkSxii12g=; b=RrQp/jGnMsvu36+Rc0otg4JjHlDhiL6Cs4940YhmmdtiN58q+IbkleQt0W8ALswjxJ ZfJ0v2QvRQVqu17arOAy2q5Vp7NxqJ4lDeo8fljzsplcTQ6jDYfqmlINucRHLjI9fG/n MsQFXXA9NrBWhj9NtX/1ZNW++Qr8A82DOuxA8= Received: by 10.204.136.152 with SMTP id r24mr13548205bkt.5.1319314932821; Sat, 22 Oct 2011 13:22:12 -0700 (PDT) Received: from rimwks1x64 ([178.184.63.13]) by mx.google.com with ESMTPS id k6sm17904368bkv.8.2011.10.22.13.22.10 (version=SSLv3 cipher=OTHER); Sat, 22 Oct 2011 13:22:11 -0700 (PDT) From: rozhuk.im@gmail.com To: , References: <4e988844.1025cc0a.1e88.ffffb4b9@mx.google.com> In-Reply-To: <4e988844.1025cc0a.1e88.ffffb4b9@mx.google.com> Date: Sun, 23 Oct 2011 05:22:08 +0900 Message-ID: <4ea325f3.4693cc0a.45c2.6fc5@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcyKpGSMDXecgPCYSLqJMoGmDrfX0QGUtgEA Content-Language: ru Cc: Subject: RE: QinQ support: implement details - need help! X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rozhuk.IM@gmail.com List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Oct 2011 20:22:14 -0000 http://www.freebsd.org/cgi/query-pr.cgi?pr=3D161908 All done. IEEE 802.1Q + IEEE 802.1p IEEE 802.1ad (IEEE 802.1QinQ) - if two ng_vlan node + ethernet_type for VLAN encapsulation is tunable, default is: 0x8100 (33024) + PCP (Priority Code Point) and CFI (Canonical Format Indicator) for = VLAN encapsulation is tunable per VID + VLAN filter can be deleted by VID + tunable encapsulation: on - do 802.1Q encapsulation, off - set = M_VLANTAG and ether_vtag * improved encapsulation/decapsulation code * "vlan" changed to "vid" in "addfilter" and "gettable" messages * many other changes =A0 -- Rozhuk Ivan =A0=20 > -----Original Message----- > From: rozhuk.im@gmail.com [mailto:rozhuk.im@gmail.com] > Sent: Saturday, October 15, 2011 4:07 AM > To: freebsd-net@freebsd.org > Cc: Rozhuk.IM@gmail.com > Subject: QinQ support: implement details - need help! >=20 >=20 > ... > IEEE 802.1ad (802.1QinQ) specifies architecture and bridge protocols = to > provide separate instances of the MAC services to multiple independent > users > of a Bridged Local Area Network in a manner that does not require > cooperation among the users, and requires a minimum of cooperation > between > the users and the provider of the MAC service. >=20 > The idea is to provide, for example, the possibility for customers to > run > their own VLANs inside service provider's provided VLAN. This way the > service provider can just configure one VLAN for the customer and > customer > can then treat that VLAN as if it was a trunk. > ... > http://en.wikipedia.org/wiki/802.1ad >=20 >=20 >=20 > "Customer" VLAN - ether_type: 0x8100 > Stored in: > struct pkthdr { > ... > union { > u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan tag */ > u_int16_t vt_nrecs; /* # of IGMPv3 records in this chain > */ > } PH_vt; > SLIST_HEAD(packet_tags, m_tag) tags; /* list of packet tags */ > }; > #define ether_vtag PH_vt.vt_vtag >=20 >=20 >=20 > "Service Provider" VLAN - ether_type: 0x88a8/0x8100/0x9100 > How I can store it in packet? > How to store tag for QinQinQ? >=20 >=20 >=20 >=20 >=20 >=20 > VLAN tags store implementation (IMHO) >=20 >=20 > Ethernet packet: > | Dst_MAC | Src_MAC | 802.1Q_Tag2 | 802.1Q_Tag1 | 802.1Q_Tag0 | > Ether_type/size | Payload | >=20 > 802.1Q Tag0 =3D "Customer" VLAN - ether_type: 0x8100, stored in > pkthdr.PH_vt.vt_vtag (now) (IEEE 802.1Q) > 802.1Q Tag1 =3D "Service Provider" / MetroTag... (IEEE 802.1ad) > 802.1Q Tag2 =3D SomeTag... (QinQinQ) >=20 >=20 > I found part of old code in /usr/src/sys/dev/mxge/if_mxge.c: > ... > /* save the tag */ > #ifdef MXGE_NEW_VLAN_API > m->m_pkthdr.ether_vtag =3D ntohs(evl->evl_tag); > #else > { > struct m_tag *mtag; > mtag =3D m_tag_alloc(MTAG_VLAN, MTAG_VLAN_TAG, sizeof(u_int), > M_NOWAIT); > if (mtag =3D=3D NULL) > return; > VLAN_TAG_VALUE(mtag) =3D ntohs(evl->evl_tag); > m_tag_prepend(m, mtag); > } >=20 > #endif > m->m_flags |=3D M_VLANTAG; > ... >=20 >=20 > 1. Compact scheme: > #define MTAG_VLAN_T0 1035328035 /* m_tag_cookie */ > #define MTAG_VLAN_T1 (MTAG_VLAN_T0 + 1) > #define MTAG_VLAN_T2 (MTAG_VLAN_T1 + 1) > #define MTAG_VLAN_T3 (MTAG_VLAN_T2 + 1) >=20 > Store vt_vtag in m_tag_id > ng_vlan / if_vlan will use for tag/untag one of MTAG_VLAN_Tx > m_tag_cookie > and tunable ether_type for vlan encapsulation: > lower <-> ng_vlan(MTAG_VLAN_T0) <-> ng_vlan(MTAG_VLAN_T1) <-> > ng_vlan(MTAG_VLAN_T2) <-> upper >=20 >=20 > 2. OpenBSD compatible > #ifdef > #define MTAG_VLAN MTAG_ABI_COMPAT /* cookie */ > #define MTAG_VLAN_TAG0 1035328035 > #else > #define MTAG_VLAN 1035328035 /* m_tag_cookie */ > #define MTAG_VLAN_TAG0 0 /* tag of VLAN interface */ > #endif >=20 > #define MTAG_VLAN_TAG1 (MTAG_VLAN_TAG0 + 1) > #define MTAG_VLAN_TAG2 (MTAG_VLAN_TAG1 + 1) > #define MTAG_VLAN_TAG3 (MTAG_VLAN_TAG2 + 1) >=20 > struct mv_tag { > struct m_tag tag; > u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan > tag */ > }; >=20 > ng_vlan / if_vlan will use for tag/untag one of MTAG_VLAN_TAGx = m_tag_id > and > tunable ether_type for vlan encapsulation: > lower <-> ng_vlan(MTAG_VLAN_TAG0) <-> ng_vlan(MTAG_VLAN_TAG1) <-> > ng_vlan(MTAG_VLAN_TAG2) <-> upper >=20 >=20 > 3. Extended > Same as 2, but >=20 > struct mv_tag { > struct m_tag tag; > u_int16_t vt_vtag; /* Ethernet 802.1p+q vlan > tag */ > u_int16_t ether_type; /* Ethernet type for TAG */ > }; >=20 >=20 >=20 > Major question is: > were store 802.1Q Tag0 =3D "Customer" VLAN (ether_type: 0x8100, IEEE > 802.1Q): > in pkthdr.PH_vt.vt_vtag or in struct m_tag? >=20 >=20 > ng_vlan modifications (I can make): > + tunable ether_type for vlan encapsulation > + tunable on/off encapsulation (to prevent network adapter > encapsulation) > + tunable m_tag identifier for VLAN tag > ...??? >=20 >=20 >=20 > Any comments before I start? >=20 >=20 >=20 > PS: Trick: > kern.ipc.max_linkhdr should be increased via sysctl: > 20 - 1 VLAN tag (.Q) > 24 - 2 VLAN tags (QinQ) > 28 - 3 VLAN tags (QinQinQ) > 32 - 4 VLAN tags (...) >=20 >=20 >=20 > -- > Rozhuk Ivan >=20 >=20