From owner-freebsd-current@FreeBSD.ORG Thu Jul 28 01:04:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDED916A41F; Thu, 28 Jul 2005 01:04:12 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61DB843D58; Thu, 28 Jul 2005 01:04:12 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j6S149ms074883 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 27 Jul 2005 18:04:09 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42E82F2E.9030505@errno.com> Date: Wed, 27 Jul 2005 18:04:46 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Gilbert 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> <42E71F77.6010705@FreeBSD.org> <17127.41923.312257.159166@canoe.dclg.ca> In-Reply-To: <17127.41923.312257.159166@canoe.dclg.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Mike Jakubik , Doug Barton , Peter Wemm , freebsd-current@freebsd.org Subject: Re: dhclient sucks X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jul 2005 01:04:13 -0000 David Gilbert wrote: >>>>>>"Doug" == Doug Barton 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