From owner-freebsd-net@FreeBSD.ORG Wed May 25 02:38:52 2011 Return-Path: Delivered-To: freebsd-net@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 611D1106564A for ; Wed, 25 May 2011 02:38:52 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.vlsi.ee.noda.tus.ac.jp (sekine00.ee.noda.sut.ac.jp [133.31.107.40]) by mx1.freebsd.org (Postfix) with ESMTP id D83748FC0C for ; Wed, 25 May 2011 02:38:51 +0000 (UTC) Received: from alph.allbsd.org (p2237-ipbf904funabasi.chiba.ocn.ne.jp [122.26.37.237]) (user=hrs mech=DIGEST-MD5 bits=128) by mail.vlsi.ee.noda.tus.ac.jp (8.14.4/8.14.4) with ESMTP id p4P2cdBN043463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 May 2011 11:38:50 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.allbsd.org (8.14.4/8.14.4) with ESMTP id p4P2cT80082960; Wed, 25 May 2011 11:38:29 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Wed, 25 May 2011 11:38:24 +0900 (JST) Message-Id: <20110525.113824.427376659208697618.hrs@allbsd.org> To: mrmullemeck@gmail.com From: Hiroki Sato In-Reply-To: References: X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Wed_May_25_11_38_24_2011_588)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.5 (mail.vlsi.ee.noda.tus.ac.jp [133.31.107.40]); Wed, 25 May 2011 11:38:50 +0900 (JST) X-Spam-Status: No, score=6.4 required=14.0 tests=BAYES_50, CONTENT_TYPE_PRESENT, RCVD_IN_CHINA, RCVD_IN_CHINA_KR, RCVD_IN_PBL, RCVD_IN_RP_RNBL, RCVD_IN_TAIWAN, SPF_SOFTFAIL,X_MAILER_PRESENT autolearn=no version=3.3.1 X-Spam-Level: ****** X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.vlsi.ee.noda.tus.ac.jp Cc: freebsd-net@FreeBSD.org Subject: Re: rtsol set IFF_UP when started - why? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2011 02:38:52 -0000 ----Security_Multipart(Wed_May_25_11_38_24_2011_588)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit MrMulleMeck wrote in : mr> When rtsol(d) starts, it check the interface status (flags). If flags mr> are not (IFF_UP|IFF_RUNNING) rtsol concludes the interface is "not mr> active". However, immediately after this, rtsol will activate/set the mr> IFF_UP flag (if not set) causing DAD to start. Let say that the link mr> is not ready yet (but in a short period of time) when rtsold starts, mr> wouldn't this cause DAD to believe that the address is OK (no response mr> since RS messages are actually never sent over the wire)? DAD code assumes a link is ready when IFF_UP && IFF_DRV_RUNNING. In the case that a link is actually down even if IFF_DRV_RUNNING, DAD probing messages will be sent and can be lost. mr> What is the rationale (if any) for rtsol to set the IFF_UP flag? It mr> seems that rtsold will wait anyway for DAD later on? Simply because rtsol needs to activate the specified interface if it is down. As explained above, DAD code in the kernel will wait for IFF_DRV_RUNNING after IFF_UP. -- Hiroki ----Security_Multipart(Wed_May_25_11_38_24_2011_588)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEABECAAYFAk3ca6AACgkQTyzT2CeTzy0BqgCdH9kQUGSZ4I5CbruTaHrDigX9 /1oAn0BDZwbOvdghMXTwNNG18eZKr1wh =0+ON -----END PGP SIGNATURE----- ----Security_Multipart(Wed_May_25_11_38_24_2011_588)----