From owner-freebsd-net@FreeBSD.ORG Fri Nov 4 16:17:51 2005 Return-Path: X-Original-To: freebsd-net@freebsd.org Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9AD6E16A420; Fri, 4 Nov 2005 16:17:51 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua (tigra.ip.net.ua [82.193.96.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5861343D6B; Fri, 4 Nov 2005 16:17:47 +0000 (GMT) (envelope-from ru@ip.net.ua) Received: from localhost (rocky.ip.net.ua [82.193.96.2]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jA4GHj7u078896; Fri, 4 Nov 2005 18:17:45 +0200 (EET) (envelope-from ru@ip.net.ua) Received: from tigra.ip.net.ua ([82.193.96.10]) by localhost (rocky.ipnet [82.193.96.2]) (amavisd-new, port 10024) with LMTP id 42868-04-2; Fri, 4 Nov 2005 18:17:41 +0200 (EET) Received: from heffalump.ip.net.ua (heffalump.ip.net.ua [82.193.96.213]) by tigra.ip.net.ua (8.12.11/8.12.11) with ESMTP id jA4GHBwt078862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Nov 2005 18:17:12 +0200 (EET) (envelope-from ru@ip.net.ua) Received: (from ru@localhost) by heffalump.ip.net.ua (8.13.4/8.13.4) id jA4GHGms095350; Fri, 4 Nov 2005 18:17:16 +0200 (EET) (envelope-from ru) Date: Fri, 4 Nov 2005 18:17:16 +0200 From: Ruslan Ermilov To: Julian Elischer Message-ID: <20051104161715.GY63539@ip.net.ua> References: <20051102193617.1013be88.molter@tin.it> <20051103145144.GM63539@ip.net.ua> <436A5275.5060807@elischer.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3C3ZMpwu25Mtx3MN" Content-Disposition: inline In-Reply-To: <436A5275.5060807@elischer.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new at ip.net.ua Cc: freebsd-net@freebsd.org, Bill Paul Subject: Re: troubles with ng_fec on -current 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, 04 Nov 2005 16:17:51 -0000 --3C3ZMpwu25Mtx3MN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 03, 2005 at 10:09:57AM -0800, Julian Elischer wrote: >=20 > >> =20 > >> > >Looks like a bug. The ng_fec code uses the MAC address of the first > >real interface as the MAC address for the virtual and all other ports > >in the bundle, but it lacks a call to ifp->if_init() to actually > >reprogram the hardware MAC filter. Please try this patch: > >=20 > > > I thought it was supposed to put them in promsc. mode. >=20 No it's not. The ng_fec reprograms MAC addresses of all ports like I said above. I've committed some fixes to the driver to make it resistent to some scenarios Bill didn't plan, like adding/removing a port from the running bundle, or bringing the fec interface up and runnign before any ports were ever added, etc. The old code should work if you follow the undocumented intended sequence of steps: 1. Create a fec node, but don't bring fec0 up yet. 2. Add ports to the bundle. 3. Add address to the fec0 interface which will automatically bring it up and cycle down/up all physical interfaces causing the hardware mac filter reprogramming. But if you bring the fec0 up before adding ports to configuration, weird things happen: adding only one port and attempting to use the bundle will panic, and adding the correct number of ports (2 or 4) will miss the hardware MAC filters reconfiguration. One of the fixes was to disallow bringing the fec interface to a running state when the number of ports in the bundle is wrong (neither 2 nor 4, previously it would also allow 0). With this fix, after adding 2 or 4 ports to the bundle and only then you can bring the fec interface up, and it will cause reprogramming of hardware MAC filters of physical interfaces constituting the bundle. Now and before the hardware MAC filters were reprogrammed as soon as the fec interface was brought up, as the side effect of cycling IFF_UP of physical interfaces, though the link-level addresses are reprogrammed earlier, when the port is added to the bundle. I don't like this behavior, so I'll probably commit my if_setlladdr() code too. Cheers, --=20 Ruslan Ermilov ru@FreeBSD.org FreeBSD committer --3C3ZMpwu25Mtx3MN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (FreeBSD) iD8DBQFDa4mLqRfpzJluFF4RAiMhAJ0UK61HRdjhWQdoCRv5Q6zICEHGZQCeOVZW rd/gYPqvcrAHvsm0ul4e1bA= =QF8Y -----END PGP SIGNATURE----- --3C3ZMpwu25Mtx3MN--