Re: dhclient sucks

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