Date: Fri, 1 Jul 2005 17:52:49 -0700 From: "Darren Pilgrim" <dmp@bitfreak.org> To: "'Brooks Davis'" <brooks@one-eyed-alien.net> Cc: current@freebsd.org Subject: RE: dhclient/wpa_supplicant patch Message-ID: <000801c57ea0$5fedbc10$0b2a15ac@SMILEY> In-Reply-To: <20050630050758.GA13861@odin.ac.hmc.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Brooks Davis [mailto:brooks@one-eyed-alien.net]=20 > Sent: Wednesday, June 29, 2005 10:08 PM > To: Brooks Davis > Cc: Darren Pilgrim; current@freebsd.org > Subject: Re: dhclient/wpa_supplicant patch >=20 >=20 > On Wed, Jun 29, 2005 at 12:23:38AM -0700, Brooks Davis wrote: > > On Tue, Jun 28, 2005 at 10:54:15PM -0700, Darren Pilgrim wrote: > > > From: Brooks Davis > > > >=20 > > > > --- rc.d/wpa_supplicant Tue Jun 28 22:24:18 2005 > > > > +++ rc.d/wpa_supplicant Tue Jun 28 18:51:32 2005 > > > <...> > > > > +if ! wpaif $ifn; then > > > > + return 1 > > > > +fi > > >=20 > > > I think it would be better if the dhcpif/wpaif test is contained=20 > > > within netif. It has to exist in netif because its job is to=20 > > > determine how to configure the interface. The dhclient and=20 > > > wpa_supplicant scripts should be "dumb" single-task scripts to=20 > > > start/stop their respective clients. > > >=20 > > > By putting the dhcpif/wpaif test in the dhclient/wpa_supplicant=20 > > > scripts, not only is it redundant, it makes it impossible=20 > to use the=20 > > > scripts manually with an interface that isn't configured in=20 > > > /etc/rc.conf with the DHCP or WPA magic words. Such manual=20 > > > operations are useful in testing, temporary interfaces and custom=20 > > > profile-based configurations where it's not possible/practical to=20 > > > have a configuration line in /etc/rc.conf beforehand. > >=20 > > Good point. The test is already in ifconfig_up/down so it's not=20 > > needed in wpa_supplicant or dhclient. >=20 > Upon further reflection, the wpa_supplicant case was removed=20 > before commit, but I've kept the dhclient case because the=20 > code to start a new dhclient via devd when link is detected=20 > relies on rc.d/dhclient only working on appropriate=20 > interfaces. An option to skip this test when called with=20 > forcestart/forcestart seems like a reasionable compromise in=20 > keeping with rc.subr's design. I don't have time to work=20 > that out at the moment, but would be happy to look at patches. I have to wonder at the value of trying to start dhclient like that. Now that netif will operate on anything with an ifconfig line in /etc/rc.conf, is there any reason why having devd simply call `netif start $device-name` on attach wouldn't work? Either way, I'll provide patches.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000801c57ea0$5fedbc10$0b2a15ac>