Re: dhclient sucks

David Gilbert wrote:
>>>>>>"Doug" == Doug Barton <dougb_at_FreeBSD.org> writes:
> 
> 
> Doug> Scott Long wrote:
> 
>>>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.
> 
> 
> Doug> It's not at all clear to me how the ISC license prevented us
> Doug> from easily changing anything. There may have been other
> Doug> compelling reasons to change code, but I would need this one
> Doug> explained in more detail to be convinced.
> 
> I've been privately grousing about the dhclient change for some time,
> but since someone else started the thread, here are my observations.
> 
> The ISC dhclient would probe multiple interfaces simultaneously.  The
> new one waits for some amount o ftime on my hardwire ethernet (rarely
> used) before probing my wireless.  The result is a longer startup.

Not sure where you come up with this.

The ISC client checked the interface state at startup and past that time 
polled for changes.  The polling interval was, I believe, something like 
30 seconds; probably more.

The current dhclient code checks the interface state at startup and past 
that depends on messages from the kernel to effect changes.  No polling 
so virtually instantaneous response to interface state changes.

This is especially important in a wireless environment when roaming 
between ap's where polling can miss ap changes (the old code didn't 
check the bssid so would not notice a change until the lease needed to 
be renewed or other events occurred).

The problem(s) we are having now are mainly:

1. device drivers not reliably producing link state changes.
2. link state bouncing is causing dhclient to bounce along with it; 
normally this wouldn't be a big deal because of the way dhclient works 
but due to some other bugs it's a problem.

I used the event-driven mechanism to add fast roaming support to 
dhclient on an ap change.  It worked great until recently.  I've yet to 
figure out exactly why but have been overwhelmed with other work and 
haven't devoted a lot of time to the problem.  Brooks and I are also 
talking about adding debounce code to deal with bogus drivers.  In other 
systems this is done in the kernel (e.g. Windows drivers do debouncing 
of wireless state changes) and we're trying to decide if we should do 
likewise or do it in dhclient.

> 
> Since the changes to the wireless code, the ISC dhclient would notice
> a change in the state of the wireless (new ssid, for instance) and
> quickly sync up.  The new dhclient sometimes does, but more often than
> not requires that I "ifconfig ath0 ssid foo" ... which is annoying.
> With the old ISC client, leaving the ssid blank was sufficient.

Please provide details of what does not work.  I cannot diagnose 
anything given what you've said.  The 80211watch program from 
tools/tools/ath is invaluable in understanding what dhclient is doing.

> 
> An extention of this is that randomly, after some long amount of time
> online (often a day or two), ath0 seems to disassociate with the only
> local access point in my home and reqire I ifconfig a bunch of times.
> This may or may not be a dhclient thing --- but I tend to think it's
> related ... if for no other reason than it started occuring at the
> same time as the dhclient was checked in.

Nothing to do with dhclient and again you've provvided no useful 
information.  If you're using ath look at athstats; it'll show you for 
example beacon misses.  I suspect your problem with not reassociating 
was fixed yesterday.

> 
> Are there plans to fix the gaping functionality holes in dhclient, or
> can we get the isc client back?

I've yet to see any gaping holes.  I see bugs but other than brooks 
fixing problems I mostly see people carping.  If you want the isc code 
back go get it.  I personally want to fix what we have.

	Sam