On Tue, 11 Mar 2014 11:17:30 -0400 Steve Dickson <steved@xxxxxxxxxx> wrote: > From: NeilBrown <neilb@xxxxxxx> > > Protocol negotiation in mount.nfs does not correctly negotiate with a > server which only supports NFSv3 and UDP. > > When mount.nfs attempts an NFSv4 mount and fails with ECONNREFUSED > it does not fall back to NFSv3, as this is not recognised as a > "does not support NFSv4" error. > However ECONNREFUSED is a clear indication that the server doesn't > support TCP, and ipso facto does not support NFSv4. > So ECONNREFUSED should trigger a fallback from v4 to v2/3. > > However ECONNREFUSED may simply indicate that NFSv4 isn't supported > *yet*. i.e. the server is still booting and isn't responding to NFS > requests yet. So if we subsequently find that NFSv3 is supported, we > need to check with the server to confirm that NFSv4 really isn't > supported. > > If server reports that v4 is not supported after reporting that v3 > is, we can safely use v4. If it reports that v4 is supported, we need > to retry v4. > > Signed-off-by: Steve Dickson <steved@xxxxxxxxxx> > Reported-by: Carsten Ziepke <kieltux@xxxxxxxxx> > --- > + memcpy(&save_sa, sap, salen); > + > + ret = nfs_probe_port(sap, salen, pmap, > + probe_nfs3_only, probe_proto); > + if (!ret || !checkv4 || probe_proto != probe_tcp_first) > + return ret; > + > + nfs_set_port((struct sockaddr *)&save_sa, NFS_PORT); > + ret = nfs_rpc_ping((struct sockaddr *)&save_sa, salen, > + NFS_PROGRAM, 4, IPPROTO_TCP, NULL); That turns out to be very neat, doesn't it? I'm quite happy with this version instead. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
