Re: Cannot mount via NFS

On Fri, 25 Jun 2004 19:09:49 +0000, Andrei Ivanov wrote:

> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
> wrote:
>> On Fri, 25 Jun 2004 02:04:31 +0000, Andrei Ivanov wrote:
>>>> mount clntudp_create: RPC: Port mapper failure - RPC: Timed out [...]
>>>
>>> Before running showmount/rpcinfo on the client host, start "tcpdump -n
>>> udp" on both client and server. If you won't see inbound RPC (111/udp)
>>> packets on server, then check iptables/ipchains (both with "-L -n"
>>> options) on both sides to check whether there is something relevant in
>>> there.
>
> I'm sory for mis-guiding you :-( It should have been 'tcp' instead of
> 'udp', or just 'port sunrpc'.
>
> Open two terminals on client and one on server.
>
> client1# rpcinfo -p server
> client2# tcpdump -n port sunrpc
> server1# tcpdump -n port sunrpc

[snip expected output]

I did the three commands you listed above, and I see the expected output
on the client, but I see nothing on the server. If I reverse the two, I
can see everything on both systems (i.e., when I "rpcinfo -p client" from
the server and tcpdump on both).

The client can ping the server and vice versa, but for some reason the
client cannot see the server via RPC. The server can, however, see the
client via RPC. I have been looking a lot at this problem, and it seems as
though somehow the "route" command may be involved. Do you think this is
somehow a problem of the client not having the correct route to the
server? I know so very little about this that any help would be
appreciated.

Thanks,

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.

On Fri, 25 Jun 2004 13:42:59 -0700, Jeff Krimmel wrote:

> On Fri, 25 Jun 2004 19:09:49 +0000, Andrei Ivanov wrote:
>
>> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
>> wrote:
>>> On Fri, 25 Jun 2004 02:04:31 +0000, Andrei Ivanov wrote:
>>>>> mount clntudp_create: RPC: Port mapper failure - RPC: Timed out [...]
>>>>
>>>> Before running showmount/rpcinfo on the client host, start "tcpdump -n
>>>> udp" on both client and server. If you won't see inbound RPC (111/udp)
>>>> packets on server, then check iptables/ipchains (both with "-L -n"
>>>> options) on both sides to check whether there is something relevant in
>>>> there.
>>
>> I'm sory for mis-guiding you :-( It should have been 'tcp' instead of
>> 'udp', or just 'port sunrpc'.
>>
>> Open two terminals on client and one on server.
>>
>> client1# rpcinfo -p server
>> client2# tcpdump -n port sunrpc
>> server1# tcpdump -n port sunrpc
>
> [snip expected output]
>
> I did the three commands you listed above, and I see the expected output
> on the client, but I see nothing on the server. If I reverse the two, I
> can see everything on both systems (i.e., when I "rpcinfo -p client" from
> the server and tcpdump on both).
>
> The client can ping the server and vice versa, but for some reason the
> client cannot see the server via RPC. The server can, however, see the
> client via RPC. I have been looking a lot at this problem, and it seems as
> though somehow the "route" command may be involved. Do you think this is
> somehow a problem of the client not having the correct route to the
> server? I know so very little about this that any help would be
> appreciated.

And I suppose I should mention that the client in this case already has an
existing NFS connection to a different server, and the server in this case
is already successfully acting as an NFS server to different clients. So,
the proper NFS services are definitely running from both sides.

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.

In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com> wrote:
> I did the three commands you listed above, and I see the expected output
> on the client, but I see nothing on the server.

Do you mean that you see both packets going *from* client to server,
and packets going in opposite direction, from server *to* client?
If so, check MAC addresses on the server (ifconfig) and on the
client (arp -a). I guess you'll see different MACs for server's
IP address.

--
andrei

On Fri, 25 Jun 2004 21:35:51 +0000, Andrei Ivanov wrote:

> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
> wrote:
>> I did the three commands you listed above, and I see the expected
>> output on the client, but I see nothing on the server.
>
> Do you mean that you see both packets going *from* client to server, and
> packets going in opposite direction, from server *to* client? If so,
> check MAC addresses on the server (ifconfig) and on the client (arp -a).
> I guess you'll see different MACs for server's IP address.

I can see the client sending packets toward the server, but I see nothing
on the server.

I have done some more reading, and it looks like my problem might be
related to the two network interfaces I have set up on the server. The
server is an NFS server already but only on a second network interface. I
am trying to mount an NFS partition via the server's first network
interface. Is it possible for an NFS server to be set up on only one of
the two interfaces? If so, how can I get the server to act as an NFS
server on _both_ of its network interfaces?

Thanks,

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.

In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com> wrote:
> On Fri, 25 Jun 2004 21:35:51 +0000, Andrei Ivanov wrote:
>>> I did the three commands you listed above, and I see the expected
>>> output on the client, but I see nothing on the server.
>>
>> Do you mean that you see both packets going *from* client to server, and
>> packets going in opposite direction, from server *to* client? If so,
>> check MAC addresses on the server (ifconfig) and on the client (arp -a).
>> I guess you'll see different MACs for server's IP address.
>
> I can see the client sending packets toward the server, but I see nothing
> on the server.

You did not answer my question.

--
andrei

On Fri, 25 Jun 2004 22:43:21 +0000, Andrei Ivanov wrote:

> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
> wrote:
>> On Fri, 25 Jun 2004 21:35:51 +0000, Andrei Ivanov wrote:
>>>> I did the three commands you listed above, and I see the expected
>>>> output on the client, but I see nothing on the server.
>>>
>>> Do you mean that you see both packets going *from* client to server,
>>> and packets going in opposite direction, from server *to* client? If
>>> so, check MAC addresses on the server (ifconfig) and on the client
>>> (arp -a). I guess you'll see different MACs for server's IP address.
>>
>> I can see the client sending packets toward the server, but I see
>> nothing on the server.
>
> You did not answer my question.

Okay, I'll try again. You asked:

"Do you mean that you see both packets going *from* client to server, and
packets going in opposite direction, from server *to* client?"

My answer is:

I see the packets going *from* the client to the server, but I do _not_
see packets going in the opposite direction, from the server *to* the
client.

Let me know if that's not what you were asking. As for the "arp -a"
command on the client, the server is not listed in the output. Is there a
way for the RPC service to run on _both_ eth0 and eth1 on the server? It
seems to be running fine on eth1 (which is a private network), but I
cannot contact the server from this particular client via RPC (which uses
the server's eth0).

Thanks,

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.

In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com> wrote:
> On Fri, 25 Jun 2004 22:43:21 +0000, Andrei Ivanov wrote:
>>>> Do you mean that you see both packets going *from* client to server,
>>>> and packets going in opposite direction, from server *to* client? If
>>>> so, check MAC addresses on the server (ifconfig) and on the client
>>>> (arp -a). I guess you'll see different MACs for server's IP address.
>>>
>>> I can see the client sending packets toward the server, but I see
>>> nothing on the server.
>>
>> You did not answer my question.
>
> Okay, I'll try again. You asked:
>
> "Do you mean that you see both packets going *from* client to server, and
> packets going in opposite direction, from server *to* client?"
>
> My answer is:
>
> I see the packets going *from* the client to the server, but I do _not_
> see packets going in the opposite direction, from the server *to* the
> client.

I.e. you've seen just 1st (SYN) packet, not the whole sequence, which
was shown in my example. Right?

> Let me know if that's not what you were asking. As for the "arp -a"
> command on the client, the server is not listed in the output. Is there a
> way for the RPC service to run on _both_ eth0 and eth1 on the server? It
> seems to be running fine on eth1 (which is a private network), but I
> cannot contact the server from this particular client via RPC (which uses
> the server's eth0).

What's between server and client? If there is router in there, are you
sure that there are no ACL entries, affecting communication between two?

Perhaps both computers are connected to some switch, or switches. Are
you sure that there are no ACL entries on the switch(es), which might
affect communication between client and server?

Output of "ifconfig -a" and "netstat -rn" might be helpfull as well.

--
andrei

On Fri, 25 Jun 2004 23:08:35 +0000, Andrei Ivanov wrote:

> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
> wrote:

[...]

>> Okay, I'll try again. You asked:
>>
>> "Do you mean that you see both packets going *from* client to server,
>> and packets going in opposite direction, from server *to* client?"
>>
>> My answer is:
>>
>> I see the packets going *from* the client to the server, but I do _not_
>> see packets going in the opposite direction, from the server *to* the
>> client.
>
> I.e. you've seen just 1st (SYN) packet, not the whole sequence, which
> was shown in my example. Right?

On the client I see

================================================== ===================
tcpdump: listening on eth0
16:18:30.467561 client.980 > server.sunrpc: S 3997891255:3997891255(0) win
5840 <mss 1460,sackOK,timestamp 36820869 0,nop,wscale 0> (DF)
16:18:33.460708 client.980 > server.sunrpc: S 3997891255:3997891255(0) win
5840 <mss 1460,sackOK,timestamp 36821169 0,nop,wscale 0> (DF)
16:18:36.570802 client.822 > server.sunrpc: udp 56 (DF) 16:18:36.571114
client.sunrpc > server.822: udp 28 (DF) 16:18:39.460706 client.980 >
server.sunrpc: S 3997891255:3997891255(0) win 5840 <mss
1460,sackOK,timestamp 36821769 0,nop,wscale 0> (DF)
16:18:51.460707 client.980 > server.sunrpc: S 3997891255:3997891255(0) win
5840 <mss 1460,sackOK,timestamp 36822969 0,nop,wscale 0> (DF)
================================================== ===================

On the server I see

==========================
tcpdump: listening on eth0
==========================

[...]

> What's between server and client? If there is router in there, are you
> sure that there are no ACL entries, affecting communication between two?
>
> Perhaps both computers are connected to some switch, or switches. Are
> you sure that there are no ACL entries on the switch(es), which might
> affect communication between client and server?
>
> Output of "ifconfig -a" and "netstat -rn" might be helpfull as well.

I don't know what an ACL entry is, but I don't see anything using
"ifconfig -a" or "netstat -rn" that would lead me to believe anything is
blocking connections between the two. The two can ping each other, so at
least that much is allowed. Neither one shows up explicitly in the other's
routing table, though.

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.

Jeff Krimmel <madscientist03abc@hotmail.com> writes:

]On Fri, 25 Jun 2004 21:35:51 +0000, Andrei Ivanov wrote:

]> In comp.os.linux.networking Jeff Krimmel <madscientist03abc@hotmail.com>
]> wrote:
]>> I did the three commands you listed above, and I see the expected
]>> output on the client, but I see nothing on the server.
]>
]> Do you mean that you see both packets going *from* client to server, and
]> packets going in opposite direction, from server *to* client? If so,
]> check MAC addresses on the server (ifconfig) and on the client (arp -a).
]> I guess you'll see different MACs for server's IP address.

]I can see the client sending packets toward the server, but I see nothing
]on the server.

]I have done some more reading, and it looks like my problem might be
]related to the two network interfaces I have set up on the server. The
]server is an NFS server already but only on a second network interface. I
]am trying to mount an NFS partition via the server's first network
]interface. Is it possible for an NFS server to be set up on only one of
]the two interfaces? If so, how can I get the server to act as an NFS
]server on _both_ of its network interfaces?

nfs does not care about network interfaces-- it cares about ip addresses.
The routing takes care of the interface.

Just make sure that you give permission in /etc/exports and that your
firewall allows it to happen.

On Fri, 25 Jun 2004 23:43:10 +0000, Bill Unruh wrote:

> Jeff Krimmel <madscientist03abc@hotmail.com> writes:

[...]

> ]I have done some more reading, and it looks like my problem might be
> ]related to the two network interfaces I have set up on the server. The
> ]server is an NFS server already but only on a second network interface. I
> ]am trying to mount an NFS partition via the server's first network
> ]interface. Is it possible for an NFS server to be set up on only one of
> ]the two interfaces? If so, how can I get the server to act as an NFS
> ]server on _both_ of its network interfaces?
>
> nfs does not care about network interfaces-- it cares about ip addresses.
> The routing takes care of the interface.
>
> Just make sure that you give permission in /etc/exports and that your
> firewall allows it to happen.

That's good to know, and it's also the frustrating part. Neither machine
has a firewall up. The export permissions in /etc/exports are set up
appropriately. The server I am trying to connect to is already an NFS
server for another set of clients on its other ethernet interface. The
client I am using is already an NFS client connecting to a different
server (with a single ethernet interface).

All of the "rpcinfo -p" and "showmount -e" commands I try on the server
from the client return RPC errors. When I do these commands from the
server's other clients (that are using the server's other ethernet
interface), they all work fine. So, RPC is set up and working on both of
these machines, it's just not working between them. I can ping one from
the other, I can ssh from one to the other, and I can do just about
anything else that would imply a solid connection exists between the two.
The RPC services just aren't jiving between the two for whatever reason.
I think it has to do with portmapper on the server only paying attention
to it's private ethernet interface and not looking at the ethernet
interface I'm trying to connect to. But, absolutely any other ideas would
be of help; I'm pretty lost.

Jeff

--
Add an underscore between 'd' and 's' and remove the first three
letters of the alphabet for email.