Date: Sun, 05 Apr 2009 21:26:09 -0700 From: Julian Elischer <julian@elischer.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Rick Macklem <rmacklem@uoguelph.ca>, freebsd-arch@freebsd.org Subject: Re: getting a callback ip address for nfsv4 client Message-ID: <49D98461.4000002@elischer.org> In-Reply-To: <alpine.BSF.2.00.0904051826550.12639@fledge.watson.org> References: <Pine.GSO.4.63.0903301733120.17182@muncher.cs.uoguelph.ca> <alpine.BSF.2.00.0904051826550.12639@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert Watson wrote:
> On Mon, 30 Mar 2009, Rick Macklem wrote:
>
>> Well, since the last one turned out to be too easy, here's one I think
>> is a little tougher...
>>
>> The nfsv4 client needs to know an ip address for the machine, that can
>> be used by servers to do callbacks on the client. I currently use the
>> following, which I know isn't correct, but usually works ok:
>>
>> loopb = htonl(INADDR_LOOPBACK);
>> TAILQ_FOREACH(ia, &in_ifaddrhead, ia_link) {
>> if (IA_SIN(ia)->sin_addr.s_addr != loopb)
>> return (&(IA_SIN(ia)->sin_addr.s_addr));
>> }
>> return (NULL);
>>
>> Now, I could just make it a constant set by an rc script (argument to
>> the callback daemon or a sysctl variable), but that's a bother for
>> laptops using dhcp and similar. I think allowing an argument to the
>> callback daemon is a good fallback, but it would be nice if it didn't
>> normally have to be set for things to work ok.
>>
>> Any ideas on how to do this?
>>
>> Thanks in advance for any help, rick ps: Part of the reason that the
>> above loop doesn't seem to be good
>> enough is that it requires "options VIMAGE_GLOBALS" to build.
>
> 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.
>
> (Obviously, kernel versions of the above...)
we ended up with him doing "whatever the connect code would have done"
since as he is in fact inside the kernel, he can just do the same..
>
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-arch@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49D98461.4000002>