From owner-freebsd-current@FreeBSD.ORG Thu Jul 28 00:49:34 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 3961E16A41F; Thu, 28 Jul 2005 00:49:34 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6FD343D5C; Thu, 28 Jul 2005 00:49:32 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6S0nOms074817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2005 17:49:26 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E82BB9.8030404@errno.com> Date: Wed, 27 Jul 2005 17:50:01 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jose M Rodriguez References: <42E583F9.3070703@rogers.com> <200507261853.07513.peter@wemm.org> <1242.172.16.0.199.1122429678.squirrel@172.16.0.1> <200507271215.14369.doconnor@gsoft.com.au> <42E6F5EA.7030801@samsco.org> <1122446707.76777.11.camel@orion.redesjm.local> In-Reply-To: <1122446707.76777.11.camel@orion.redesjm.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Mike Jakubik , freebsd-current@freebsd.org, =?UTF-8?B?TWF0ZXVzeiBKxJlkcmFzaWs=?= , Peter Wemm Subject: Re: dhclient sucks 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, 28 Jul 2005 00:49:34 -0000 Jose M Rodriguez wrote: > El mar, 26-07-2005 a las 20:48 -0600, Scott Long escribió: > >>Daniel O'Connor wrote: >> >>>On Wednesday 27 July 2005 11:31, Mike Jakubik wrote: >>> >>> >>>>On Tue, July 26, 2005 9:53 pm, Peter Wemm said: >>>> >>>> >>>>>I'd love to know which items in dhclient.conf allow you to disable the >>>>>default route handling and the resolv.conf handling.. >>>> >>>>supersede { [option declaration] [, ... option declaration] } >>>> >>>>Ex, I use "supersede domain-name-servers 127.0.0.1;" to set my own name >>>>server. >>> >>> >>>That just means you have to hardcode your resolver and default route into >>>dhclient.conf - there is no "Don't touch this setting on my computer even if >>>the DHCP server tells you to" flag in the config file I believe. >>> >> >>Part of the point of going to the new codebase was to free us from being >>locked into vendor sources that we couldn't easily change. If there is >>a need for a new option, please code it up and commit it! >> > > > The main problem is that OpenBSD dhclient doesn't operate under std DHCP > concepts/guidelines. > > a dhclient daemon must not alter IPs on media changes, only if they > can't rebind the assigned IP in time. Can you point out where this is set forth in the RFC? If so this means fast roaming on a wireless network using dhcp is not supported. I believe you are misunderstanding things because you see the results of bugs and not the intent of the code. > > ALso, ISC dhcp operation, which may seems simple, it's more complex that > a quick look may point. I'm not sure what point you're making here. The 3.0 ISC dhcp client code was difficult to work with in many ways and following a design path that I believe was not good. I have worked with the ISC dhcp code for many years including porting it to Windows and cannibalizing it for inclusion in vmware. I think I understand pretty well what's in the code. I pushed to get this different code into the system because it was easier to work with and did just what we needed and not more. This has many benefits including being more reliable, secure, and maintainable. I ran with this code for _many_ months w/o seeing _any_ issues. The problems we've been seeing were not expected (I anticipated some problems) but are mainly due to dhclient depending on reliable information from other parts of the system and that information is not forthcoming (e.g. link state change notices from drivers). > > I'll be really happy if this kind of infraestructure changes are not > done at the end of development cycles. As I stated I was running the code for many months w/o any issues. It was brought into the tree more than a month prior to release w/ the understanding that the only real way to get feedback from the user community is to get it out for people to use. In the past day or two brooks has fixed several problems and we are committed to making it stable for the release. Sam