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
<[email protected]> wrote:
On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis <[email protected]> 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)?
There may well be something better to wait
or a need for a longer timeout in some environments. It's also quite
possible that we have an ordering problem and need to move some more
things after defaultroute or move the checks to a different location.
-- Brooks
Cheers.
--
Mike Makonnen | GPG-KEY: http://people.freebsd.org/~mtm/mtm.asc
mtm @ FreeBSD.Org | AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55
FreeBSD | http://www.freebsd.org
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "[email protected]"
