The rc.d mess strikes back
sam at freebsd.org
Sun Mar 8 11:39:34 PDT 2009
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
>>>> <mmakonnen at gmail.com> wrote:
>>>>> On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis <brooks at freebsd.org> 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
>>> 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.
More information about the freebsd-current