Can you specify a local IP or Interface to be used on a per NFS mount basis?

Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Ben Greear]

Hello!

Is there any way to specify what local IP address an NFS
client uses to mount an NFS server?

For instance, if I have eth0 with IP 192.168.1.6 and eth1
with IP 192.168.1.7, how can I make sure that a particular
mount point is accessed via 192.168.1.7?

If not NFS..can it be done with SMB?

The current man pages seem to indicate it cannot be done, but
maybe someone knows some kludge to get it working?

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Trond Myklebust]

On Wed, 2006-01-18 at 15:10 -0800, Ben Greear wrote:
> Hello!
> 
> Is there any way to specify what local IP address an NFS
> client uses to mount an NFS server?
> 
> For instance, if I have eth0 with IP 192.168.1.6 and eth1
> with IP 192.168.1.7, how can I make sure that a particular
> mount point is accessed via 192.168.1.7?

NFS doesn't know anything about ip packet routing. That is a networking
issue.

Cheers,
  Trond

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Ben Greear]

Trond Myklebust wrote:
> On Wed, 2006-01-18 at 15:10 -0800, Ben Greear wrote:
> 
>>Hello!
>>
>>Is there any way to specify what local IP address an NFS
>>client uses to mount an NFS server?
>>
>>For instance, if I have eth0 with IP 192.168.1.6 and eth1
>>with IP 192.168.1.7, how can I make sure that a particular
>>mount point is accessed via 192.168.1.7?
> 
> 
> NFS doesn't know anything about ip packet routing. That is a networking
> issue.

When a socket is created, you can optionally bind to local IP, interface and/or
IP-Port.  Somewhere, NFS is opening a socket I assume?  So, is there a way to
ask it to bind?

You can then use this source-IP to convince the routing logic to use a
particular interface (ie, the interface with that IP on it).

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[David S. Miller]

From: Ben Greear <greearb@candelatech.com>
Date: Wed, 18 Jan 2006 18:21:26 -0800

> When a socket is created, you can optionally bind to local IP,
> interface and/or IP-Port.  Somewhere, NFS is opening a socket I
> assume?  So, is there a way to ask it to bind?

Things like net/sunrpc/xprtsock.c:xs_bindresvport() will bind,
but to a specific port.  It leaves the address field all zeros
which makes the kernel pick a default.

net/sunrpc/svcsock.c does something similar, you can get it
to use a particular port but it uses INADDR_ANY for the
address during the bind().

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Trond Myklebust]

On Wed, 2006-01-18 at 18:21 -0800, Ben Greear wrote:

> > NFS doesn't know anything about ip packet routing. That is a networking
> > issue.
> 
> When a socket is created, you can optionally bind to local IP, interface and/or
> IP-Port.  Somewhere, NFS is opening a socket I assume?  So, is there a way to
> ask it to bind?


As David said, the place to fix it is in xs_bindresvport(), but there is
no support for passing this sort of information through the current NFS
binary mount structure. You would have to hack that up yourself.

Cheers,
  Trond

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Ben Greear]

Trond Myklebust wrote:
> On Wed, 2006-01-18 at 18:21 -0800, Ben Greear wrote:
> 
> 
>>>NFS doesn't know anything about ip packet routing. That is a networking
>>>issue.
>>
>>When a socket is created, you can optionally bind to local IP, interface and/or
>>IP-Port.  Somewhere, NFS is opening a socket I assume?  So, is there a way to
>>ask it to bind?
> 
> 
> 
> As David said, the place to fix it is in xs_bindresvport(), but there is
> no support for passing this sort of information through the current NFS
> binary mount structure. You would have to hack that up yourself.

I can think of some horrible hacks to grab info out of a text file based
on the mount point or some other available info...but if I actually
attempted to do it right..would you consider the patch for kernel
inclusion?  Is it OK to modify the binary mount structure?

Ben

> 
> Cheers,
>   Trond
> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Trond Myklebust]

On Wed, 2006-01-18 at 19:28 -0800, Ben Greear wrote:

> > As David said, the place to fix it is in xs_bindresvport(), but there is
> > no support for passing this sort of information through the current NFS
> > binary mount structure. You would have to hack that up yourself.
> 
> I can think of some horrible hacks to grab info out of a text file based
> on the mount point or some other available info...but if I actually
> attempted to do it right..would you consider the patch for kernel
> inclusion?  Is it OK to modify the binary mount structure?

It is possible, yes: the binary structure carries a version number that
allows the kernel to distinguish the various revisions that the userland
mount program supports.

That said, the concensus at the moment appears to be that we should move
towards a text-based mount structure for NFS (like most of the other
filesystems have, and like NFSroot has) so I'd be reluctant to take
patches that define new binary structures.

Cheers,
  Trond

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Ben Greear]

Trond Myklebust wrote:
> On Wed, 2006-01-18 at 19:28 -0800, Ben Greear wrote:
> 
> 
>>>As David said, the place to fix it is in xs_bindresvport(), but there is
>>>no support for passing this sort of information through the current NFS
>>>binary mount structure. You would have to hack that up yourself.
>>
>>I can think of some horrible hacks to grab info out of a text file based
>>on the mount point or some other available info...but if I actually
>>attempted to do it right..would you consider the patch for kernel
>>inclusion?  Is it OK to modify the binary mount structure?
> 
> 
> It is possible, yes: the binary structure carries a version number that
> allows the kernel to distinguish the various revisions that the userland
> mount program supports.
> 
> That said, the concensus at the moment appears to be that we should move
> towards a text-based mount structure for NFS (like most of the other
> filesystems have, and like NFSroot has) so I'd be reluctant to take
> patches that define new binary structures.

Ok.  This patch does extend the binary struct, and to do it really right,
we should probably pass in some sort of in_addr struct instead of the
single 'u32' for the IP address.

So, please just consider this a proof of concept.  That said, with a
patched 'mount' binary (diff available if anyone cares), this does
do exactly what I want:  allows binding an nfs client to a particular
local IP address.

If/when you get the text based interface working, I will try to cook
up an official patch worthy of inclusion if you have not already
done so.

This patch was inspired by a patch sent to me by:  Dimitris Michailidis

Thanks,
Ben


diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -407,6 +407,12 @@ nfs_create_client(struct nfs_server *ser
                                 __FUNCTION__, PTR_ERR(xprt));
                 return (struct rpc_clnt *)xprt;
         }
+
+       if (data->local_ip != 0) {
+               printk("nfs: Configuring local ip address as: 0x%x\n",
+                      data->local_ip);
+       }
+       xprt->local_address = data->local_ip; /* specify local IP address */
         clnt = rpc_create_client(xprt, server->hostname, &nfs_program,
                                  server->rpc_ops->version, data->pseudoflavor);
         if (IS_ERR(clnt)) {
@@ -1663,6 +1669,7 @@ static struct super_block *nfs_get_sb(st
                 deactivate_super(s);
                 return ERR_PTR(error);
         }
+
         s->s_flags |= MS_ACTIVE;
         return s;
  out_rpciod_down:
diff --git a/fs/super.c b/fs/super.c
diff --git a/include/linux/nfs_mount.h b/include/linux/nfs_mount.h
--- a/include/linux/nfs_mount.h
+++ b/include/linux/nfs_mount.h
@@ -20,7 +20,7 @@
   * mount-to-kernel version compatibility.  Some of these aren't used yet
   * but here they are anyway.
   */
-#define NFS_MOUNT_VERSION      6
+#define NFS_MOUNT_VERSION      7
  #define NFS_MAX_CONTEXT_LEN    256

  struct nfs_mount_data {
@@ -43,6 +43,8 @@ struct nfs_mount_data {
         struct nfs3_fh  root;                   /* 4 */
         int             pseudoflavor;           /* 5 */
         char            context[NFS_MAX_CONTEXT_LEN + 1];       /* 6 */
+       char            pad[3];                 /* 7  Align the context above */
+       unsigned int    local_ip;               /* 7 */
  };

  /* bits in the flags field */
diff --git a/include/linux/sunrpc/xprt.h b/include/linux/sunrpc/xprt.h
--- a/include/linux/sunrpc/xprt.h
+++ b/include/linux/sunrpc/xprt.h
@@ -168,7 +168,8 @@ struct rpc_xprt {
                                 reestablish_timeout;
         struct work_struct      connect_worker;
         unsigned short          port;
-
+       u32                     local_address; /* local IP address to bind to */+
         /*
          * Disconnection of idle transports
          */
diff --git a/net/sunrpc/xprtsock.c b/net/sunrpc/xprtsock.c
--- a/net/sunrpc/xprtsock.c
+++ b/net/sunrpc/xprtsock.c
@@ -928,6 +928,8 @@ static int xs_bindresvport(struct rpc_xp
         int err;
         unsigned short port = xprt->port;

+       myaddr.sin_addr.s_addr = xprt->local_address;
+
         do {
                 myaddr.sin_port = htons(port);
                 err = sock->ops->bind(sock, (struct sockaddr *) &myaddr,

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Peter Staubach]

Ben Greear wrote:

> Trond Myklebust wrote:
>
>> On Wed, 2006-01-18 at 19:28 -0800, Ben Greear wrote:
>>
>>
>>>> As David said, the place to fix it is in xs_bindresvport(), but 
>>>> there is
>>>> no support for passing this sort of information through the current 
>>>> NFS
>>>> binary mount structure. You would have to hack that up yourself.
>>>
>>>
>>> I can think of some horrible hacks to grab info out of a text file 
>>> based
>>> on the mount point or some other available info...but if I actually
>>> attempted to do it right..would you consider the patch for kernel
>>> inclusion?  Is it OK to modify the binary mount structure?
>>
>>
>>
>> It is possible, yes: the binary structure carries a version number that
>> allows the kernel to distinguish the various revisions that the userland
>> mount program supports.
>>
>> That said, the concensus at the moment appears to be that we should move
>> towards a text-based mount structure for NFS (like most of the other
>> filesystems have, and like NFSroot has) so I'd be reluctant to take
>> patches that define new binary structures.
>
>
> Ok.  This patch does extend the binary struct, and to do it really right,
> we should probably pass in some sort of in_addr struct instead of the
> single 'u32' for the IP address.
>
> So, please just consider this a proof of concept.  That said, with a
> patched 'mount' binary (diff available if anyone cares), this does
> do exactly what I want:  allows binding an nfs client to a particular
> local IP address.
>
> If/when you get the text based interface working, I will try to cook
> up an official patch worthy of inclusion if you have not already
> done so. 


These changes are very IPv4 specific.  Perhaps they could be constructed 
in a
bit more IP version agnostic fashion?  IPv6 is coming as well as other 
transport
choices, not all of whose addresses will fit into 32 bits.

    Thanx...

       ps

Re: Can you specify a local IP or Interface to be used on a per NFS mount basis?

[Ben Greear]

Peter Staubach wrote:

> These changes are very IPv4 specific.  Perhaps they could be constructed 
> in a
> bit more IP version agnostic fashion?  IPv6 is coming as well as other 
> transport
> choices, not all of whose addresses will fit into 32 bits.

Sure..it'd be best to pass in a generic structure that can hold
ipv4 or v6 address and port.  But, I have no setup to test ipv6,
don't need to specify the port, and this patch can't go in anyway
because Trond doesn't want to change the binary structure....

If we go to a text base API, could just pass it in as "IP:port"
and let the kernel parsing logic decide if it's IPv4, v6 or something
else...  Of course, it sure is nice to leave all the parsing logic
in user-space, but then you're back to a binary API...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com