From owner-freebsd-usb@FreeBSD.ORG Sun Mar 8 18:39:34 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 020891065740; Sun, 8 Mar 2009 18:39:34 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from ebb.errno.com (ebb.errno.com [69.12.149.25]) by mx1.freebsd.org (Postfix) with ESMTP id AF2BA8FC0A; Sun, 8 Mar 2009 18:39:33 +0000 (UTC) (envelope-from sam@freebsd.org) Received: from trouble.errno.com (trouble.errno.com [10.0.0.248]) (authenticated bits=0) by ebb.errno.com (8.13.6/8.12.6) with ESMTP id n28IdShG012302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 8 Mar 2009 11:39:28 -0700 (PDT) (envelope-from sam@freebsd.org) Message-ID: <49B410E0.4030803@freebsd.org> Date: Sun, 08 Mar 2009 11:39:28 -0700 From: Sam Leffler Organization: FreeBSD Project User-Agent: Thunderbird 2.0.0.18 (X11/20081209) MIME-Version: 1.0 To: Brooks Davis References: <2fd864e0903020512i22b2c31fg487aaf37fed6398b@mail.gmail.com> <20090302.132522.-432836388.imp@bsdimp.com> <20090302233215.GA53763@duncan.reilly.home> <20090302.181513.1973603215.imp@bsdimp.com> <584bfc3f0903030833k70405609q7e2d3b28c8cf4c29@mail.gmail.com> <20090303180307.GA11134@lor.one-eyed-alien.net> <584bfc3f0903032212x25831c5bi35d9b637c1896e1d@mail.gmail.com> <7d6fde3d0903040004y1fcbb086i355cd0113717620b@mail.gmail.com> <20090304164953.GB1209@lor.one-eyed-alien.net> <49B397A4.8090508@gmail.com> <20090308180934.GA9147@lor.one-eyed-alien.net> In-Reply-To: <20090308180934.GA9147@lor.one-eyed-alien.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-DCC-sonic.net-Metrics: ebb.errno.com; whitelist Cc: andrew-freebsd@areilly.bpc-users.org, astrodog@gmail.com, Mike Makonnen , usb@freebsd.org, freebsd-current@freebsd.org, Garrett Cooper Subject: Re: The rc.d mess strikes back X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Mar 2009 18:39:34 -0000 Brooks Davis wrote: > On Sun, Mar 08, 2009 at 01:02:12PM +0300, Mike Makonnen wrote: > >> Brooks Davis wrote: >> >>> On Wed, Mar 04, 2009 at 12:04:06AM -0800, Garrett Cooper wrote: >>> >>>> On Tue, Mar 3, 2009 at 10:12 PM, Mike Telahun Makonnen >>>> wrote: >>>> >>>>> On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis wrote: >>>>> >>>>>> I don't have much time to debug this, but I've not had problems with >>>>>> services starting too early on the systems I've been running with async >>>>>> dhcp. ?If there is a problem with the wait process we need to actually >>>>>> debug it. ?If the wait for a route/running interface isn't sufficent we >>>>>> should try to figure out what is. ?Synchronous dhcp sucks and yeilds >>>>>> justifed user complaints so it would be nice to kill it off. ?I switched >>>>>> the default because it worked for me and I hoped that people would help >>>>>> find and fix edge cases. >>>>>> >>>>> Can you elaborate why synchronous DHCP sucks ? >>>>> >>>> The only reason I could see is bringup time. Am I correct in this assumption? >>>> >>> If you use synchronous DHCP then every interface that wants to try to >>> get a DHCP address if it has link needs to run through the full link >>> timeout at boot. On a laptop this is annoying and generally pointless. >>> >> Ok, I just turned synchronous dhclient on locally and I see what you >> mean. >> >> >>> The changes to defaultroute to wait for a default route to be set mean >>> that you consolidate the wait in one location and you don't waste time >>> starting dhclient on interfaces until a link exists (or an association >>> is made for wlan devices). >>> >> OK, so that means that it's not just waiting for the default route, but >> it's also waiting for the link on any DHCP interfaces to come up as >> well. That's what confused me. When it's plugged in my NIC's link is >> always up by the time rc.d gets to the default route, so I didn't see >> the point in waiting the extra 30sec when it wasn't plugged in. The >> comments also seemed to imply that we should be checking whether the >> link is up. >> >> Anyways, given that synchronous dhclient re-introduces the same problem >> I was trying to fix in the first place I'll just back the whole thing out >> until we can come up with a better fix. Do you mind if I change the timeout >> to 15sec. (instead of 30s)? >> > > 15 is probably a bit short in practice for wpa networks. Someone a > while back suggested that there's some reason (perhaps spanning tree, > but I can't remember) why it it should be closer to 50sec for maximum > reliability. One thing I've thought of adding is changing the sleeps to > "read -t1", checking for a non-timeout result and adding "Press return > to skip". Another option would be for each interface to set a minimum > timeout based on it's type such as having WPA interfaces set it to 30 > and others set it to 15. > wpa is typically not the issue unless wpa-eapol is involved (in which case you need to negotiate with a backend authentication server). wpa typically takes <100ms to handshake and plumb keys once you have an association. The more time consuming aspects of setting up a wireless connection are scanning (if dual-band and not done intelligently) and how fast the dhcp server is (I have observed 15-30 sec lag on some large corporate nets). One thing I don't understand is why we poll at all given that we can listen to the routing socket and figure out exactly what we need. This would require a new app but that's easy (just mod something like wlanwatch or route). We'd still need to decide how to handle the timeout and/or how to deal with interrupting the process. Sam