From owner-freebsd-net@freebsd.org Thu Feb 28 09:17:03 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9F695152379B for ; Thu, 28 Feb 2019 09:17:03 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail.allbsd.org (mx-int.allbsd.org [IPv6:2001:2f0:104:e002::7]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.allbsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4EFC88786 for ; Thu, 28 Feb 2019 09:17:02 +0000 (UTC) (envelope-from hrs@FreeBSD.org) Received: from mail-d.allbsd.org (p2452109-ipngn10801funabasi.chiba.ocn.ne.jp [180.13.106.109]) (authenticated bits=56) by mail.allbsd.org (8.15.2/8.15.2) with ESMTPSA id x1S9GYtq077433 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) (Client CN "/CN=mail.allbsd.org", Issuer "/C=US/O=Let's+20Encrypt/CN=Let's+20Encrypt+20Authority+20X3"); Thu, 28 Feb 2019 18:16:47 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from alph.d.allbsd.org (alph.allbsd.org [192.168.0.10]) by mail-d.allbsd.org (8.15.2/8.15.2) with ESMTPS id x1S9GYYI026769 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Feb 2019 18:16:34 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [[UNIX: localhost]]) (authenticated bits=0) by alph.d.allbsd.org (8.15.2/8.15.2) with ESMTPA id x1S9GGGq026766; Thu, 28 Feb 2019 18:16:18 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 28 Feb 2019 18:15:39 +0900 (JST) Message-Id: <20190228.181539.867694221978174531.hrs@allbsd.org> To: rmacklem@uoguelph.ca Cc: freebsd-net@freebsd.org Subject: Re: correct IP# for NFS kernel upcall to userland daemon 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.8 on Emacs 25.3 Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Feb_28_18_15_39_2019_501)--" Content-Transfer-Encoding: 7bit X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-4.6.2 (mail.allbsd.org [133.31.130.41]); Thu, 28 Feb 2019 18:16:52 +0900 (JST) X-Spam-Status: No, score=-97.4 required=13.0 tests=CONTENT_TYPE_PRESENT, QENCPTR1,UNPARSEABLE_RELAY,URIBL_SC2_SURBL,URIBL_XS_SURBL, USER_IN_WHITELIST autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mx.allbsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Feb 2019 09:17:03 -0000 ----Security_Multipart(Thu_Feb_28_18_15_39_2019_501)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Rick Macklem wrote in : rm> In this case, I am concerned that the daemon will not be able to start up under rm> conditions where the DNS service isn't yet functional. (This problem can mostly rm> be avoided by specifying "localhost" in /etc/hosts and configuring the system to rm> use that file before DNS, but I still don't like having this dependency on DNS for rm> the daemon starting up.) rm> Note that the upcall will work for any IP# that refers to the local machine and it rm> does not need to be the one specified for "localhost" in the DNS. rm> rm> So, do you think I should do a lookup for "localhost" at daemon startup or use rm> a hardwired "127.0.0.1/::1"? I do not think using INADDR_LOOPBACK or IN6ADDR_LOOPBACK_INIT is harmful for this purpose. A properly configured lo0 should be a reasonable assumption. However, I still think using a loopback address in AF_INET or AF_INET6 for local communication is not a good idea when AF_LOCAL works. A properly configured file system is easier than lo0 in many cases. An unnamed pair of connected sockets which can be created by socketpair(2) would be ideal for this purpose, but IIRC there is no handy way to send one across kernel and userland... -- Hiroki ----Security_Multipart(Thu_Feb_28_18_15_39_2019_501)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iEYEABECAAYFAlx3prsACgkQTyzT2CeTzy3/TQCdHxGWCJDzdx3K0BoUzGM71i4C 4ykAn1GpO3CJTBAYdA1ZA9E45y2Caafk =Tqxt -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Feb_28_18_15_39_2019_501)----