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
<mmakon...@gmail.com> wrote:
On Tue, Mar 3, 2009 at 9:03 PM, Brooks Davis <bro...@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
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
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
