From owner-freebsd-current@FreeBSD.ORG Tue Aug 2 14:59:58 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 95AD316A41F for ; Tue, 2 Aug 2005 14:59:58 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from smtp02.jazztel.es (smtp02.jazztel.es [62.14.3.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 110F043D49 for ; Tue, 2 Aug 2005 14:59:54 +0000 (GMT) (envelope-from josemi@freebsd.jazztel.es) Received: from [127.0.0.1] (helo=localhost) by smtp02.jazztel.es with esmtp (Exim 4.43) id 1DzyFd-000315-VG for freebsd-current@FreeBSD.org; Tue, 02 Aug 2005 17:00:18 +0200 Received: from smtp02.jazztel.es ([127.0.0.1]) by localhost (lorca [127.0.0.1]) (amavisd-new, port 10034) with ESMTP id 10883-08 for ; Tue, 2 Aug 2005 17:00:17 +0200 (CEST) Received: from [212.106.209.144] (helo=bcnppp.jazztel.es) by smtp02.jazztel.es with esmtpa (Exim 4.43) id 1DzyFd-00030s-2B for freebsd-current@FreeBSD.org; Tue, 02 Aug 2005 17:00:17 +0200 Received: from redesjm.local (orion.redesjm.local [192.168.254.16]) by bcnppp.jazztel.es (8.13.4/8.13.4) with ESMTP id j72ExmD3002439 for ; Tue, 2 Aug 2005 16:59:48 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) Received: (from josemi@localhost) by redesjm.local (8.13.4/8.13.4/Submit) id j72Expin062911 for freebsd-current@FreeBSD.org; Tue, 2 Aug 2005 16:59:51 +0200 (CEST) (envelope-from josemi@freebsd.jazztel.es) X-Authentication-Warning: orion.redesjm.local: josemi set sender to josemi@freebsd.jazztel.es using -f From: Jose Miguel =?ISO-8859-1?Q?Rodr=EDguez_Garc=EDa?= To: freebsd-current@FreeBSD.org Content-Type: multipart/mixed; boundary="=-yM+rakkB8fcsOwbpHJCA" Date: Tue, 02 Aug 2005 16:59:51 +0200 Message-Id: <1122994791.47716.7.camel@orion.redesjm.local> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-7; AVE: 6.31.1.0; VDF: 6.31.1.0; host: antares.redesjm.local) X-Virus-Scanned: amavisd-new at jazztel.es Cc: Subject: [Fwd: 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: Tue, 02 Aug 2005 14:59:58 -0000 --=-yM+rakkB8fcsOwbpHJCA Content-Type: text/plain Content-Transfer-Encoding: 7bit Seems that this may be lose due to local mail problems --=-yM+rakkB8fcsOwbpHJCA Content-Disposition: inline Content-Description: Mensaje reenviado - Re: dhclient sucks Content-Type: message/rfc822 Return-Path: Received: from orion.redesjm.local (orion.redesjm.local [192.168.254.16]) by bcnppp.jazztel.es (8.13.3/8.13.3) with ESMTP id j6SBtnaQ013107; Thu, 28 Jul 2005 13:55:53 +0200 (CEST) (envelope-from josemi@redesjm.local) Subject: Re: dhclient sucks From: Jose M Rodriguez To: Sam Leffler Cc: Jose M Rodriguez , Mike Jakubik , freebsd-current@freebsd.org, Mateusz =?iso-8859-2?Q?J=EAdrasik?= , Peter Wemm In-Reply-To: <42E82BB9.8030404@errno.com> 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> <42E82BB9.8030404@errno.com> Content-Type: text/plain; charset=iso8859-1 Date: Thu, 28 Jul 2005 13:55:31 +0200 Message-Id: <1122551731.785.15.camel@orion.redesjm.local> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-AntiVirus: checked by AntiVir Milter (version: 1.1.0-7; AVE: 6.31.1.0; VDF: 6.31.1.0; host: antares.redesjm.local) El mié, 27-07-2005 a las 17:50 -0700, Sam Leffler escribió: > 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. > No. The RFC doesn't do any asumption to the local interface behavior. But: - It take an strong ownership concept. - Signals the protocol as the way to get a release the IPs. Also, I can't remenber this behavior until recently after using DHCP along several OS. > 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. > Agree on that. I think that one daemon instance per if without the complexity of the ISC code is the way. > 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. > I still think this was be inserted at the begin of the RELENG_7. You can't test all the config we have out there. I think having 3/4 moth to release for public test for this kind of changes. Most of us really run some kind of -CURRENT. > Sam About fast roaming on a wireless network, I think you only need: - a running daemon per if (without going down/up on media changes). - a way to force a rebind in any moment (a HUP signal seems a good candidate). - a wrapper launch from devd to fire the HUP signal on link up events (maybe safe detect daemon not running and launch it). -- josemi --=-yM+rakkB8fcsOwbpHJCA--