From owner-freebsd-current@FreeBSD.ORG Fri Oct 28 18:04:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2102016A41F; Fri, 28 Oct 2005 18:04:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7D9343D45; Fri, 28 Oct 2005 18:04:21 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j9SI4KxK020327; Fri, 28 Oct 2005 11:04:20 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j9SI4KZT020326; Fri, 28 Oct 2005 11:04:20 -0700 Date: Fri, 28 Oct 2005 11:04:20 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20051028180420.GA17096@odin.ac.hmc.edu> References: <41473.192.216.27.32.1129818223.squirrel@192.216.27.32> <200510271602.33839.mistry.7@osu.edu> <20051027201403.GA14080@odin.ac.hmc.edu> <200510281357.05802.jhb@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="wRRV7LY7NUeQGEoC" Content-Disposition: inline In-Reply-To: <200510281357.05802.jhb@freebsd.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Tom McLaughlin Subject: Re: kern/87506 : [PATCH] Fix alias support on vr interfaces X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Oct 2005 18:04:22 -0000 --wRRV7LY7NUeQGEoC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 28, 2005 at 01:57:04PM -0400, John Baldwin wrote: > On Thursday 27 October 2005 04:14 pm, Brooks Davis wrote: > > On Thu, Oct 27, 2005 at 04:02:26PM -0400, Anish Mistry wrote: > > > On Thursday 20 October 2005 05:29 pm, Brooks Davis wrote: > > > > On Thu, Oct 20, 2005 at 04:51:21PM -0400, John Baldwin wrote: > > > > > On Thursday 20 October 2005 02:27 pm, Anish Mistry wrote: > > > > > > On Thursday 20 October 2005 11:15 am, John Baldwin wrote: > > > > > > > On Thursday 20 October 2005 10:23 am, Tom McLaughlin wrote: > > > > > > > > Hi, would someone be available to look at kern PR 87506? I > > > > > > > > found the problem while building a jail on my 6.0-RC1 box. > > > > > > > > When setting an alias on a vr device with ifconfig the > > > > > > > > alias address replaces the initial address of the device. > > > > > > > > marcus@ took a look at the problem for me and provided the > > > > > > > > patch for the vr interface which I tested and it resolved > > > > > > > > the problem. Without the patch I can't create a jail that > > > > > > > > is network accessible. > > > > > > > > > > > > > > > > Marcus also notes in the PR that the rl, sis, ti, and tl > > > > > > > > may also be affected by this bug. If anyone has any other > > > > > > > > questions or needs someone to test any changes to the patch > > > > > > > > just let me know. I only have vr interfaces on my FreeBSD > > > > > > > > machines though. Thanks. > > > > > > > > > > > > > > > > Tom > > > > > > > > > > > > > > I'm not sure that fix is really the right fix. The patch > > > > > > > just makes vr(4) ignore changes to if_flags while the driver > > > > > > > is up. Probably there is a bug in vr(4)'s handling of alias > > > > > > > addresses. I did just reproduce this on my laptop's rl(4) > > > > > > > interface though. I'll see if I can't figure out what is > > > > > > > happening. > > > > > > > > > > > > I'm also seeing this too along with the following. > > > > > > > > > > > > I'm not sure if this is related, but I'm seeing the following > > > > > > on RELENG_6 and CURRENT, but and older RELENG_5 as of ~2 months > > > > > > ago doesn't show this problem. > > > > > > I'm trying to setup my workstation with a normal DHCP'd address > > > > > > and an alias IP for a jail running on the system, but the alias > > > > > > setting wipes out all the other addresses on the interface. > > > > > > in /etc/rc.conf: > > > > > > ifconfig_rl0=3D"DHCP" > > > > > > ifconfig_rl0_alias0=3D"inet 192.168.1.10 netmask 255.255.255.25= 5" > > > > > > > > > > > > I've checked the rc boot order (on RELENG_6 and CURRENT) and it > > > > > > seems correct: > > > > > > netif > > > > > > dhclient > > > > > > netif > > > > > > > > > > > > I narrowed it down to: > > > > > > dhclient rl0 > > > > > > ifconfig rl0 inet 192.168.1.11 netmask 0xffffffff alias > > > > > > [dhclient prints a message here saying connection closed and > > > > > > exiting] > > > > > > > > > > > > All of the other addresses on the card are removed. > > > > > > I'm also seeing this on dc. So thinking it to be a problem in > > > > > > ifconfig I copied over the version from my RELENG_5 box, and > > > > > > that did the same thing...so this seems to be present several > > > > > > of the network drivers in RELENG_6/CURRENT. > > > > > > > > > > Yes, it seems to be an issue with dhclient. If I turn dhclient > > > > > off and manually configure my NIC then the alias works fine: > > > > > rl0: flags=3D8843 mtu 1500 > > > > > options=3D8 > > > > > inet6 fe80::290:f5ff:fe0e:c8e5%rl0 prefixlen 64 scopeid > > > > > 0x2 inet 10.50.41.234 netmask 0xfffffe00 broadcast 10.50.41.255 > > > > > inet 10.50.41.101 netmask 0xffffffff broadcast 10.50.41.101 ether > > > > > 00:90:f5:0e:c8:e5 > > > > > media: Ethernet autoselect (100baseTX ) > > > > > status: active > > > > > > > > I believe the problem is that adding an address to a NIC causes a > > > > call to ifp->if_init() which resets the media and triggers a > > > > LINK_DOWN event in all too many cases. Using if_init here is > > > > rather like driving finishing nails with a sledge hammer. > > > > > > Has there been any resolution of this issue? Since 6.0 is just around > > > the corner. > > > > No. It's going to require non-trivial changes to the design of drivers > > and eventually some changes to the driver API to really fix this so it's > > really too late in the game. > > > > I think we need to document the lack of support for this configuration > > and move on. Frankly, it's a configuration I see no compelling reason > > to support. If you are setting alises, you should know what your > > address is so you don't need dhcp. I'm aware there are other reasons to > > want dhcp, but I personally put this sort of thing in the "that would be > > nice" category. We should try to fix it, but it's no where near the top > > of my list. >=20 > Actually, I think the best fix would be to add some de-bounce logic to=20 > dhclient so that when it gets a link down state, it waits a second before= =20 > acting on it, and if it gets a link up event before the second expires it= =20 > just cancels the pending link down action. That change would probably go= a=20 > long way to fixing several people's problems with spurious link state=20 > changes. True. Dhclient should however complain loudly if it happens with any kind of frequency. Note that one second probably won't cut it with many gigabit nics. :( -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --wRRV7LY7NUeQGEoC Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDYmgkXY6L6fI4GtQRApYZAKDWzDz17uuHvkDlyxnWPvUIib/xwQCgxC9/ 2fgkzGX2nvQx9TgOuafEBjc= =qw0g -----END PGP SIGNATURE----- --wRRV7LY7NUeQGEoC--