From owner-freebsd-arch@FreeBSD.ORG Sun Apr 5 19:27:46 2009 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D4D97106564A; Sun, 5 Apr 2009 19:27:46 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailhub.cs.uoguelph.ca (mailhub.cs.uoguelph.ca [131.104.94.205]) by mx1.freebsd.org (Postfix) with ESMTP id 39C0B8FC15; Sun, 5 Apr 2009 19:27:45 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from muncher.cs.uoguelph.ca (muncher.cs.uoguelph.ca [131.104.91.102]) by mailhub.cs.uoguelph.ca (8.13.1/8.13.1) with ESMTP id n35JRi0s016713; Sun, 5 Apr 2009 15:27:45 -0400 Received: from localhost (rmacklem@localhost) by muncher.cs.uoguelph.ca (8.11.7p3+Sun/8.11.6) with ESMTP id n35JXrw10954; Sun, 5 Apr 2009 15:33:53 -0400 (EDT) X-Authentication-Warning: muncher.cs.uoguelph.ca: rmacklem owned process doing -bs Date: Sun, 5 Apr 2009 15:33:53 -0400 (EDT) From: Rick Macklem X-X-Sender: rmacklem@muncher.cs.uoguelph.ca To: Robert Watson In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Scanned-By: MIMEDefang 2.63 on 131.104.94.205 Cc: freebsd-arch@FreeBSD.org Subject: Re: getting a callback ip address for nfsv4 client X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Apr 2009 19:27:47 -0000 On Sun, 5 Apr 2009, Robert Watson wrote: > > One possibility is to connect() a socket to the server address, then call > getsockaddr() to query what address the network stack is using. If the > connection completed, then the address could at least send packets to the > server, even if it isn't reachable from the server. > I used rtalloc1() and then rt_ifa->ifa_addr, which seems adequate, as recommended by a couple of helpful folks. (I didn't bother to try and filter through weird cases like the temporary ipv6 addresses, as one person mentioned.) I put in a sysctl variable, so that this can be overridden. (I think that's pretty much what the connect() would end up doing, although I'm a tcp/ip midget, so I could be wayy wronnggg:-) If it doesn't work, it's not a big tragedy, since a non-functioning callback path just implies "don't issue delegations to the client". rick