From owner-svn-src-all@FreeBSD.ORG Fri Aug 17 18:10:03 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3FC9E106564A for ; Fri, 17 Aug 2012 18:10:03 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta11.emeryville.ca.mail.comcast.net (qmta11.emeryville.ca.mail.comcast.net [76.96.27.211]) by mx1.freebsd.org (Postfix) with ESMTP id 19EA28FC16 for ; Fri, 17 Aug 2012 18:10:03 +0000 (UTC) Received: from omta14.emeryville.ca.mail.comcast.net ([76.96.30.60]) by qmta11.emeryville.ca.mail.comcast.net with comcast id ntAC1j00H1HpZEsABu9xga; Fri, 17 Aug 2012 18:09:57 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta14.emeryville.ca.mail.comcast.net with comcast id nu9w1j0054NgCEG8au9wUW; Fri, 17 Aug 2012 18:09:57 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7HI9s2A018268; Fri, 17 Aug 2012 12:09:54 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: John Baldwin In-Reply-To: <201208171331.10655.jhb@freebsd.org> References: <201208171553.q7HFrhuf090457@svn.freebsd.org> <1345222934.27688.110.camel@revolution.hippie.lan> <201208171331.10655.jhb@freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Fri, 17 Aug 2012 12:09:54 -0600 Message-ID: <1345226994.27688.129.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r239356 - head/sbin/dhclient X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Aug 2012 18:10:03 -0000 On Fri, 2012-08-17 at 13:31 -0400, John Baldwin wrote: > On Friday, August 17, 2012 1:02:14 pm Ian Lepore wrote: > > On Fri, 2012-08-17 at 15:53 +0000, John Baldwin wrote: > > > Author: jhb > > > Date: Fri Aug 17 15:53:43 2012 > > > New Revision: 239356 > > > URL: http://svn.freebsd.org/changeset/base/239356 > > > > > > Log: > > > Fix dhclient to properly exit and teardown the configured lease when > > > link is lost. devd will start a new dhclient instance when link is > > > restored. > > > > > > PR: bin/166656 > > > Submitted by: Peter Jeremy (mostly) > > > Reviewed by: brooks (earlier version from Peter) > > > MFC after: 1 month > > > > > > Modified: > > > head/sbin/dhclient/dhclient.c > > > > > > Modified: head/sbin/dhclient/dhclient.c > > > ============================================================================== > > > --- head/sbin/dhclient/dhclient.c Fri Aug 17 14:22:56 2012 (r239355) > > > +++ head/sbin/dhclient/dhclient.c Fri Aug 17 15:53:43 2012 (r239356) > > > @@ -278,6 +278,11 @@ routehandler(struct protocol *p) > > > ifi->name); > > > goto die; > > > } > > > + if (!interface_link_status(ifi->name)) { > > > + warning("Interface %s is down, dhclient exiting", > > > + ifi->name); > > > + goto die; > > > + } > > > break; > > > case RTM_IFANNOUNCE: > > > ifan = (struct if_announcemsghdr *)rtm; > > > @@ -316,6 +321,8 @@ routehandler(struct protocol *p) > > > > > > die: > > > script_init("FAIL", NULL); > > > + if (ifi->client->active) > > > + script_write_params("old_", ifi->client->active); > > > if (ifi->client->alias) > > > script_write_params("alias_", ifi->client->alias); > > > script_go(); > > > > I think the attached patch should give the same result without needing > > to create/destroy a socket to check the link status every time a routing > > info message arrives. I've actually had this patch in my head for > > several years, I just hadn't gotten around to submitting it yet. > > Hmm, OpenBSD does check that, but they also seem to verify it via SIOCGMEDIA > as well. Do we think this is as reliable? In the kernel we only seem to > honor this if the NIC explicitly supports the capability: > > #define RT_LINK_IS_UP(ifp) (!((ifp)->if_capabilities & IFCAP_LINKSTATE) \ > || (ifp)->if_link_state == LINK_STATE_UP) > > Also, I don't think routing info messages are all that common of an event are they? > I actually don't know how common routing info messages are; the ways I use freebsd don't include a lot of heavy network usage. The IFCAP_LINKSTATE question is interesting. The #define comment for it says "the runtime link state is dynamic." The RT_LINK_IS_UP() macro is interesting too, in that it appears to assume that the link must be up if it isn't dynamic. I think that means the more-correct way than I posted would be a test such as if (!RT_LINK_IS_UP(&ifm->ifm_data)) It looks like IFCAP_LINKSTATE is added to if_capabilities by miibus_attach() and a few specific NIC drivers (presumably ones that don't use standard MII attachements to their PHYs). I would hope all that adds up to the concept that any network driver in control of links that can come and go will either automatically do the right thing by using the miibus code, or by using its own equivelent code when mii isn't appropriate, or the driver is buggy. Hopefully there aren't any in the last category. :) -- Ian