Date: Mon, 11 Feb 2008 10:19:14 -0600 From: Brooks Davis <brooks@freebsd.org> To: Robert Jenssen <robertjenssen@ozemail.com.au> Cc: net@freebsd.org Subject: Re: dhclient conflict between /sbin/devd and /etc/rc.d/netif ? Message-ID: <20080211161914.GC69153@lor.one-eyed-alien.net> In-Reply-To: <200802111851.58155.robertjenssen@ozemail.com.au> References: <200802111137.21550.robertjenssen@ozemail.com.au> <20080211010626.GA69153@lor.one-eyed-alien.net> <200802111851.58155.robertjenssen@ozemail.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
--s9fJI615cBHmzTOP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Feb 11, 2008 at 06:51:58PM +1100, Robert Jenssen wrote:
> Hi Brooks and all,
>=20
> On Mon, 11 Feb 2008 12:06:26 pm you wrote:
> > On Mon, Feb 11, 2008 at 11:37:21AM +1100, Robert Jenssen wrote:
> > > Hi,
> > > Every so often I have trouble connecting rt2560 based PCI wireless ne=
twork=20
> > > card to my wireless router/access point. Typically I get:
> > >=20
> > > # sudo /etc/rc.d/netif restart ral0
> > > Starting wpa_supplicant.
> > > ral0: no link .............. giving up
> > > ral0: flags=3D8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 m=
tu 1500
> > > ether 00:11:50:63:cd:47
> > > media: IEEE 802.11 Wireless Ethernet autoselect (DS/1Mbps)
> > > status: no carrier
> > >=20
> > > Even though there seems to be plenty of signal power:
> > >=20
> > > # sudo ifconfig ral0 list scan
> > > SSID BSSID CHAN RATE S:N INT CAPS
> > > xxxxxxx... 00:xx:xx:xx:xx:xx 10 54M -74:-95 100 EPS WPA
> > >=20
> > > Recently I noticed that sometimes, after the above "netif restart" fa=
ils,=20
> the=20
> > > ral0 interface "automagically" comes up anyway. Then dhclient is owne=
d=20
> > > by /sbin/devd. The default devd.conf starts dhclient for both etherne=
t and=20
> > > PCI-cardbus devices. Is it a good idea for both /sbin/devd=20
> > > and /etc/rc.d/netif to start a dhclient on ral0 at about the same tim=
e?=20
>=20
> In the "magical" case above what I think is happening is that the dhclien=
t=20
> startup from /etc/rc.d/netif called by rc fails. Later /etc/rc.d/netif is=
=20
> called again from /etc/pccard_ether:pccard_ether_start() by /sbin/devd. T=
hat=20
> call succeeds.=20
As long as the interface is in the "up" state, /etc/pccard_ether will ignore
the interface. I'm fairly sure we don't configure interfaces twice, though
it's probably worth verifying that that's the case.
> The rc system uses rcorder to determine the order in which to run the rc=
=20
> scripts. On my system rcorder shows devd fairly early in the list. The=20
> devd.conf file calls a number of rc scripts. So far as I can see /sbin/de=
vd=20
> doesn't check that these are called in the order listed by rcorder. Is th=
is a=20
> problem?=20
Not generally, though it's vaguely possible there are still problems around.
The general idea is that all scripts devd should always be safe to call.
> I have disabled devd (set the moused port explicitly in rc.conf) and done=
some=20
> simple tests on /usr/src/sbin/dhclient.c. In particular, at line 365 main=
()=20
> allows a hard-coded maximum of 10 seconds for the call to=20
> interface_link_status() to succeed. I changed this to 20 seconds with a p=
rint=20
> out and ran /etc/rc.d/netif restart a few times with rc_debug=3D"YES". Th=
e=20
> results were
> 15 15 5 5 5 5 5 15 15 5 5 5 5 5 21(timed out!) 5 5 and 5 seconds. Presuma=
bly=20
> the (10n+5) seconds is a magic number inside my wireless card or router. =
I'm=20
> going to set the hardcoded value to 25 seconds. Would it be possible for =
you=20
> to commit a similar change?
Sorry, no chance. It's too long for most people already.
> ("diff -C 5" to show the sleep()s!). Rather than dhclient.c timing 10 sec=
onds=20
> and calling exit(), as shown above, shouldn't the dhclient.conf "timeout"=
=20
> configuration item cover this situation? I see that PR bin/98577 wants th=
is=20
> hardcoded timeout reduced or made adjustable via dhclient.conf.
Some sort of link-timeout parameter might be acceptable as a new configurat=
ion
option.
-- Brooks
P.S. Your interface appears to be getting an address. Don't you have anyth=
ing
better to worry about? :-)
--s9fJI615cBHmzTOP
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (FreeBSD)
iD8DBQFHsHWBXY6L6fI4GtQRAt1gAJ4tVsfJu9VnJpScFNTenCzo7rqSmwCfdZVy
OxLrab0zKjF7iIykTo9ZqOM=
=NiRE
-----END PGP SIGNATURE-----
--s9fJI615cBHmzTOP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080211161914.GC69153>