[Fwd: Re: dhclient sucks]

Seems that this may be lose due to local mail problems

attached mail follows:

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