getting a callback ip address for nfsv4 client

[Max Laier]

On Monday 30 March 2009 23:50:20 Julian Elischer wrote:
> 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);
>
> It's important that the address you use be an address that is in the
> same 'security domain' as the client..
>
> The best way to do that is to find an address that is on the interface
> that will be used to send the packet out.
>
> So you want to do a route lookup so use rtalloc or friends
> (see route.c).
>
> you want to use the same code that is used in ip_output  (or is it
> {udp/tcp}_output?) to fidn the local address when teh user specifies
> INADDR_ANY.

Mostly, but it's a bit more complicated than that.  Basically you do a normal 
source address selection (i.e. your callback address is the address you'd use 
as source when talking to that server), but you might want to specify more 
restrictions.  e.g. you might not want to use temporary IPv6 addresses etc.  
RFC 5014 suggests a userland API for source address selection (which we don't 
implement, yet).  There are good guidelines for default behavior in there, as 
well - and they also apply to IPv4 (eventhough the title suggests otherwise).

I'm CC'ing Bjoern who has done some work regarding source address selection 
recently - IIRC.

> > 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.

-- 
/"\  Best regards,                      | mlaier at freebsd.org
\ /  Max Laier                          | ICQ #67774661
 X   http://pf4freebsd.love2party.net/  | mlaier at EFnet
/ \  ASCII Ribbon Campaign              | Against HTML Mail and News