> 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,
Thanks very much for taking the time to explain this! I was very confused
as to why knfsd was the first process to gripe about the connect attempt.
Not knowing what amd did, I assumed that I'd hear from the mount daemon
first.
HJ,
Is it possible to treat NFSPROC_NULL disjointly from the other services
for authentication? I'll take a look at the code this weekend, but you
have spent much more time in there than I.
Steve
-
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/