Date: Tue, 02 Aug 2005 16:59:51 +0200 From: Jose Miguel =?ISO-8859-1?Q?Rodr=EDguez_Garc=EDa?= <josemi@freebsd.jazztel.es> To: freebsd-current@FreeBSD.org Subject: [Fwd: Re: dhclient sucks] Message-ID: <1122994791.47716.7.camel@orion.redesjm.local>
next in thread | raw e-mail | index | archive | help
--=-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: <josemi@redesjm.local>
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 <josemi@redesjm.local>
To: Sam Leffler <sam@errno.com>
Cc: Jose M Rodriguez <josemi@freebsd.jazztel.es>,
Mike Jakubik <mikej@rogers.com>, freebsd-current@freebsd.org,
Mateusz =?iso-8859-2?Q?J=EAdrasik?= <imachine@toya.net.pl>,
Peter Wemm <peter@freebsd.org>
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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1122994791.47716.7.camel>