From owner-freebsd-current@FreeBSD.ORG Thu Jul 14 20:10:04 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 C4DC316A41C; Thu, 14 Jul 2005 20:10:04 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC2C43D4C; Thu, 14 Jul 2005 20:10:03 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j6EK9hmO059302; Thu, 14 Jul 2005 15:09:44 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42D6C686.4070407@centtech.com> Date: Thu, 14 Jul 2005 15:09:42 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brooks Davis References: <20050714182136.071B35D07@ptavv.es.net> <20050714192403.H35071@fledge.watson.org> <20050714185851.GE19351@odin.ac.hmc.edu> <1121368125.83653.12.camel@realtime.exit.com> <20050714193037.GF19351@odin.ac.hmc.edu> In-Reply-To: <20050714193037.GF19351@odin.ac.hmc.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/978/Thu Jul 14 06:37:27 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: Robert Watson , freebsd-current@freebsd.org Subject: Re: Problems with OpenBSD dhclient 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: Thu, 14 Jul 2005 20:10:05 -0000 Brooks Davis wrote: > On Thu, Jul 14, 2005 at 12:08:45PM -0700, Frank Mayhar wrote: > >>On Thu, 2005-07-14 at 11:58 -0700, Brooks Davis wrote: >> >>>I'm seeing this as well. I think we're going to need to handle wireless >>>and wired interfaces differently since their links work differently. >> >>I tend to disagree with this view. In general, while wired connections >>may often be more persistent than wireless connections, that's not >>necessarily always true. It's certainly possible to move a system >>between wired connections as well >> >>I think that it makes more sense for the configuration of the two types >>to be the same, anyway, just for consistency. It's the same basic >>problem that is being solved, and if the solution for wireless >>interfaces is reasonably robust, it should work just fine for wired ones >>as well. > > > The problem with attemping to keep them looking the same is that > wireless interfaces have more complex state. We're currently trying to > paper over that, but it isn't really working. With wired interfaces, you > either have a cable with something on it plugged in or you don't (at > least until we get 802.1x support). With wireless interfaces, you can > change association relativly seamlessly so mapping associate/deassociate > to linkup/linkdown as we do now is bogus. In the end, from the user > perspective, there should be no visiable difference between wired and > wireless interfaces unless you try mucking with the devd config or need > to use WPA. Here's what I think would work well in most situations: if an interface (A) changes from down->up, and was not previously configured with dhclient, dhclient should run on it (if set in rc.conf). If another interface (B) is currently down, that has dhclient running on it, then when interface (A) comes up with a valid ip, it should remove the ip info from interface (B). if an interface (A) changes from up->down, and dhclient is running on it, it should not do anything. if an interface (A) changes from down->up, and dhclient is running on it, and no other interfaces are up, it should try to get it's lease, without changing it's current IP setup until it has the new information. If an interface (A) changes from down->up has conflicting IP information with an interface (B) that is down, that dhclient manages, it should remove the IP setup from interface (B), and set routes according to the newly upped interface. If an interface (A) changes from down->up, and there is another interface (B) that is up that dhclient manages, then configure interface (A) only if it will not conflict with the other interface's (B) network. This could be an rc.conf option - to force newly brought up interfaces to override currently up interfaces. Anything I missed? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------