Re: Please try knfsd-981014

Peter Benie (pjb1008@cam.ac.uk)
Fri, 16 Oct 1998 18:11:23 +0100


Steven N. Hirsch writes ("Re: Please try knfsd-981014"):
> kmountd is still behaving itself, after two days of pounding. However,
> wildcard matching of clients still fails in an odd manner if the client
> uses Berkeley amd. If I specifically do a kexportfs client:/dir, the
> mount succeeds. Otherwise, these just pile up in the server log:
>
> Oct 15 21:18:21 air kernel: nfsd: unauthenticated request from (c0a8f40a:714)
> [snip]
> Then, on the server, I do:
>
> $ kexportfs iris:/
>
> And try the mount again:
>
> Oct 15 21:25:01 air kernel: svc: unknown version (3)
> Oct 15 21:25:01 air kernel: svc: unknown version (3)
> Oct 15 21:25:01 air mountd[121]: authenticated mount request from iris.steve.net:1022

Last time I looked that knfsd, it refused to respond to clients that
the kernel doesn't know about, which breaks Solaris and amd.

The client uses the portmapper to determine which port the NFS service
is on. Due to a weakness in the portmap protocol, it can't determine
which versions of NFS are available until without dumping the entire
list of portmapper services. [See RFC1057, A.2 "PMAPPROC_GETPORT" and
"PMAP_DUMP"]

Rather than call PMAP_DUMP, Solaris sends a request to NFSPROC_NULL.
If the client and server versions match, the client then calls the
mountd. If the versions don't match, the server responds with
PROG_MISMATCH. (This is an RPC error rather than an NFS error.) The
client then tries a different NFS version.

With Solaris or amd, the client doesn't mount until after the NFS
server has responded; with knfsd, the server doesn't respond until the
client has mounted => Deadlock.

A solution could be to implement NFSPROC_NULL even for unauthorized
clients.

Peter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/