dhclient sucks
Sam Leffler
sam at errno.com
Thu Jul 28 01:04:13 GMT 2005
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
More information about the freebsd-current
mailing list