In article <199512070153.SAA03194@casual1.enci.ucalgary.ca> Gord Matzigkeit <gord@enci.ucalgary.ca> writes:
>
>This may or may not be related...
>
>I've noticed that NetBSD/pmax 1.1 doesn't like mounting NFS from
>machines that are not on the local network (i.e. through a router).
>
>To others on the net: is this a NQNFS "feature", or a problem with
>NetBSD/pmax?  I'm mounting from an AIX 3.2 machine.
>
>I can reproduce the problem by using "gw:/export/engg" as the mount
>device.  The problem goes away if I use "gw-gate2:/export/engg".
>
>My machines are on:
>
>136.159.113.xxx, a class-C subnet.
>
>gw resolves to 136.159.1.112
>gw-gate2 resolves to 136.159.113.1, and is the default route.
>
>So, somehow, the NFS code doesn't like going through a router, even if
>the machine itself physically lives on the same subnet.
>
>I hope this helps you a bit...
>

I was puzzled for a while by that behavior; it has nothing to do
with remote networks and it is a bad artifact of the behavior
of the dual-homed host.

Here's what's going on:

NetBSD 136.159.113.xxx sends mountd rpc request to gw 136.159.1.112.
gw replies through to the rpc through 136.159.113.1, because of 
routing. NetBSD sees that, and decides that if the other machine wants
to talk to me through 136.159.113.1, then I'll use that, and it
proceeds to send another rpc to gw, but through 136.159.113.1 this time.
Unfortunately, there is noone listening there, so you get stuck.

This needs to be fixed. I did not send-pr it, because I thought that
NetBSD was really being smart doing this and it is the other machine's
fault. After thinking about it some more, there is no easy way to fix
that on the other machine so that it works properly.

christos