From owner-freebsd-rc@FreeBSD.ORG Tue Dec 27 19:44:48 2011 Return-Path: Delivered-To: freebsd-rc@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7D2BD106566C; Tue, 27 Dec 2011 19:44:48 +0000 (UTC) (envelope-from rea@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 0D6C08FC13; Tue, 27 Dec 2011 19:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=codelabs.ru; s=two; h=Sender:In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date; bh=786jwvtJ2vYVzRQEeGCLptroDlZ2gzx3Aboq2ExkpoE=; b=AWtbt/Yovmgt4tCUufTNxSQ2FoNc0V+ZZz6yfimKUPrBli7Drm6dNujzMKvA796x+1ipZo5F673YvHwG7KGwcHjtYJtweOQkxNdwKBy9QU2vCW9Od5sAz3m4HyKew1Oqc42jInHFIyaVWdmV+A4wCN/5cM7ujr1/pl95dxjOOXvkaZlSAyiCirM6Cu/rDw38LNDo9GMLLZrHmUY+A69KmPqbWYxZvn/29LtPebX4h1uGl7aqETSzoxNJ/7iRwyg/PpVaeGWCJzL5aGPuFMwR5pe91r7MQQy6pTEK7iFFEHiKUkhCG7H2Q3tKC0z7jpBSwgXpaJo759s+ECdIS3+dtw==; Received: from shadow.codelabs.ru (ppp91-77-186-141.pppoe.mtu-net.ru [91.77.186.141]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1Rfcx4-000A7N-GK; Tue, 27 Dec 2011 22:44:46 +0300 Date: Tue, 27 Dec 2011 23:44:40 +0400 From: Eygene Ryabinkin To: Doug Barton , bz@freebsd.org Message-ID: References: <4EF99DBC.6020204@FreeBSD.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <4EF99DBC.6020204@FreeBSD.org> Sender: rea@codelabs.ru X-Mailman-Approved-At: Tue, 27 Dec 2011 19:58:25 +0000 Cc: Pyun Yong-Hyeon , Brooks Davis , freebsd-rc@FreeBSD.ORG, Garrett Cooper , Gleb Smirnoff , Dag-Erling Smorgrav , d@delphij.net, Xin LI Subject: Re: Annoying ERROR: 'wlan0' is not a DHCP-enabled interface X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 19:44:48 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Note for Bjoern: you can skip some parts of this mail, the real question is near the bottom of the letter. In a nutshell, Doug wants to arm the devd machinery that looks for IFUP events to do IPv6 autoconfiguration as addition to the current invocation of a DHCP client, but I have some questions about IPv6 autoconfiguration that I can't answer myself. Tue, Dec 27, 2011 at 02:28:12AM -0800, Doug Barton wrote: > Ok, you've convinced me that this approach isn't viable. That's why > I asked for review before committing it. Thanks for looking at it in > more detail. By the way, it seems that your approach won't work at all for DHCP-enabled interfaces that aren't set to the synchronous DHCP mode (rc.conf knob synchronous_dhclient, default value is "NO"): netif has the following code: {{{ if dhcpif $1; then if [ $_cfg -ne 0 ] ; then ifconfig $1 up fi if syncdhcpif $1; then /etc/rc.d/dhclient start $1 fi _cfg=3D0 fi }}} So, it relies on the devd to invoke dhclient when interface will be up and configured. I imagine that its mostly for the WiFi interfaces that should associate themselves with the AP or other host, up the encryption and do other stuff that takes time. DHCP client should start only after these negotiations will be complete and the link will really be up. Thus, DHCP-enabled interfaces should react to the linkup events by anything that ends up calling dhclient, not netif. I was just thinking of how can one implement the wrapper script for doing DHCP and IPv6 autoconfiguration that you want to implement and my initial thoughts were that we can use a simple one-shot invocation of netif {{{ if dhcpif $ifn || ipv6_autoconfif $ifn; then service netif quietstart $ifn fi }}} but this won't work for DHCP. On the topic of IPv6 autoconfiguration. The need of restart of the DHCP client upon linkdown/linkup event is simple: dhclient uses bpf(4) and it dies when link goes down. So it needs to be restarted. Since I have no IPv6 machines to test on and IPv6 will (hopefully) come to my realm only next year, I can't test my assertions 'bout it, since I have no practical experience with it. Thus I can be wrong in all my IPv6-related sayings. =46rom the other hand, reading RFC 2462, ftp://ftp.ripe.net/rfc/rfc2462.txt and crawling over the ifconfig, netif and other stuff, I have a strong impression that interface flags AUTO_LINKLOCAL and ACCEPT_RTADV (that, respectively, judge if the link local address should be automatically generated and if router advertisments should be processed) are persistent in respect to the link flaps. Moreover, manual page for rtsold(8) says {{{ o The interface is up after a temporary interface failure. rtsold detects such failures by periodically probing to see if the status= of the interface is active or not. Note that some network cards and drivers do not allow the extraction of link state. In such cases, rtsold cannot detect the change of the interface status. }}} so the thing that generates router solicitations is more-or-less persistent and doesn't die on link down events. Thus, it may be well so that only the initial linkup event is the one that will really initiate IPv6 autoconfiguration and all other linkup events won't really need such a processing. I am CC'ing bz@freebsd.org, since he is the person who is known to mess with IPv6 in FreeBSD a lot. Bjoern, could you, please, say if IPv6-autoconfigured interfaces react to the linkdown/linkup events in a way that they will require some reconfiguration after the flap to autoconfigure themselves again. Of course, if there are other IPv6 wizards nearby, they are welcome to educate me on this topic. Thanks. --=20 Eygene Ryabinkin ,,,^..^,,, [ Life's unfair - but root password helps! | codelabs.ru ] [ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ] --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iF4EAREIAAYFAk76ICgACgkQFq+eroFS7PuIOAD5ATJCFsboqq1paiuJnZ9WvKtL 1eP2UlYQnM27wZfb+fcA/Auvta258XTENhNgJdguOelpEAvSk+c0n2ePs9onIY5r =7aZX -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q--