| Message ID | 20181001094646.11539-1-christian.gmeiner@gmail.com |
|---|---|
| State | Deferred |
| Delegated to: | Joe Hershberger |
| Headers | show |
| Series | [U-Boot,1/4] nfs: convert supported_nfs_versions bitfield to an enum | expand |
Dear Christian, In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: > From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> > > Prep. work to support nfs v1. Hm... as you are putting efforts into NFS support... Here comes a more general question: I wonder if it's worth the work on NFS at all, or if we should remove NFS support from U-Boot alltogether? 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux distros support only v4 in their default configurations. 2) We support only UDP, but most standard Linux distros support only TCP in their default configurations (see [1]) [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 Try a NFS download from any recent Linux distro (i. e. one including nfs-utils 2.3.1 or later)... I feel a half-way solution is unsatisfactory, but the way for the Real Thing (TM) is a pretty long one... The fact that nobody compained yet that NFS stopped working fo him suggests that there are only very, very few users of NFS at all. If one of these is willing to step up and fix this for real, he is of course more than welcome. But if not - should we not remove the more or less obsolete code? Best regards, Wolfgang Denk
Hi Wolfgang > > In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: > > From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> > > > > Prep. work to support nfs v1. > > Hm... as you are putting efforts into NFS support... > > Here comes a more general question: > > I wonder if it's worth the work on NFS at all, or if we should > remove NFS support from U-Boot alltogether? > > 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > distros support only v4 in their default configurations. > Linux is not the only operating system used in the world. My NFSv1 server runs on a vxWorks 5 device which I need to support - sadly. > 2) We support only UDP, but most standard Linux distros support only > TCP in their default configurations (see [1]) > > [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > > Try a NFS download from any recent Linux distro (i. e. one including > nfs-utils 2.3.1 or later)... > That is true. > > I feel a half-way solution is unsatisfactory, but the way for the > Real Thing (TM) is a pretty long one... > > The fact that nobody compained yet that NFS stopped working fo him > suggests that there are only very, very few users of NFS at all. > If one of these is willing to step up and fix this for real, he is > of course more than welcome. But if not - should we not remove the > more or less obsolete code? > As u-boot is lacking TCP support this is quite a challenging task. I have seen some work in progress patches, which I have reviewed and hoped that it helps to get them further. I am also interested in using ftp directly in u-boot. At the moment we are using uip as tcp stack and hacked together a ftp client. If you want to remove nfs all together I need to keep nfs in our downstream repo which is kinda sad but doable.
Hi Christian, On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner <christian.gmeiner@gmail.com> wrote: > > Hi Wolfgang > > > > > In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: > > > From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> > > > > > > Prep. work to support nfs v1. > > > > Hm... as you are putting efforts into NFS support... > > > > Here comes a more general question: > > > > I wonder if it's worth the work on NFS at all, or if we should > > remove NFS support from U-Boot alltogether? > > > > 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > > distros support only v4 in their default configurations. > > > > Linux is not the only operating system used in the world. My NFSv1 > server runs on a vxWorks 5 device which > I need to support - sadly. > > > 2) We support only UDP, but most standard Linux distros support only > > TCP in their default configurations (see [1]) > > > > [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > > > > Try a NFS download from any recent Linux distro (i. e. one including > > nfs-utils 2.3.1 or later)... > > > > That is true. > > > > > I feel a half-way solution is unsatisfactory, but the way for the > > Real Thing (TM) is a pretty long one... > > > > The fact that nobody compained yet that NFS stopped working fo him > > suggests that there are only very, very few users of NFS at all. > > If one of these is willing to step up and fix this for real, he is > > of course more than welcome. But if not - should we not remove the > > more or less obsolete code? > > > > As u-boot is lacking TCP support this is quite a challenging task. I > have seen some work in progress > patches, which I have reviewed and hoped that it helps to get them > further. I'm trying to get those patches into a state that they are acceptable, but currently they are pretty brittle. I've not actually seen them work, though the contributor says they do in some case. I had to do some work to have the series just not break UDP functionality, so we have more work to do there. > I am also > interested in using ftp directly in u-boot. At the moment we are using > uip as tcp stack and hacked > together a ftp client. I was contemplating if using something like that or lwip would be better than rolling our own, but my concern is both how configurable those stacks are to make them lean as well as adding an external dependency / forking their code into our repo. Not excited about either. > If you want to remove nfs all together I need to keep nfs in our > downstream repo which is kinda sad but > doable. I think that if it is in use by you, then it's ok to keep around... especially if you are contributing to make it more capable. I would ask that you come up with a way to test the functionality in one of the travis tests. Cheers, -Joe > -- > greets > -- > Christian Gmeiner, MSc > > https://christian-gmeiner.info > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
On 22.10.2018 20:53, Joe Hershberger wrote: > Hi Christian, > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner > <christian.gmeiner@gmail.com> wrote: >> Hi Wolfgang >> >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> >>>> >>>> Prep. work to support nfs v1. >>> Hm... as you are putting efforts into NFS support... >>> >>> Here comes a more general question: >>> >>> I wonder if it's worth the work on NFS at all, or if we should >>> remove NFS support from U-Boot alltogether? >>> >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux >>> distros support only v4 in their default configurations. >>> >> Linux is not the only operating system used in the world. My NFSv1 >> server runs on a vxWorks 5 device which >> I need to support - sadly. >> >>> 2) We support only UDP, but most standard Linux distros support only >>> TCP in their default configurations (see [1]) >>> >>> [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 >>> >>> Try a NFS download from any recent Linux distro (i. e. one including >>> nfs-utils 2.3.1 or later)... >>> >> That is true. >> >>> I feel a half-way solution is unsatisfactory, but the way for the >>> Real Thing (TM) is a pretty long one... >>> >>> The fact that nobody compained yet that NFS stopped working fo him >>> suggests that there are only very, very few users of NFS at all. >>> If one of these is willing to step up and fix this for real, he is >>> of course more than welcome. But if not - should we not remove the >>> more or less obsolete code? >>> >> As u-boot is lacking TCP support this is quite a challenging task. I >> have seen some work in progress >> patches, which I have reviewed and hoped that it helps to get them >> further. > I'm trying to get those patches into a state that they are acceptable, > but currently they are pretty brittle. I've not actually seen them > work, though the contributor says they do in some case. I had to do > some work to have the series just not break UDP functionality, so we > have more work to do there. > >> I am also >> interested in using ftp directly in u-boot. At the moment we are using >> uip as tcp stack and hacked >> together a ftp client. > I was contemplating if using something like that or lwip would be > better than rolling our own, but my concern is both how configurable > those stacks are to make them lean as well as adding an external > dependency / forking their code into our repo. Not excited about > either. As the maintainer of lwIP, I already have thought about this more than once. My main concern however was the license (lwIP is BSD style) and the fact that it expects to always run (I don't know the U-Boot network stack that well, but it only runs when called, doesn't it?). Forking is never a good idea with open source projects. We try to integrate as much back into the mainline code as possible. Although we of course depend on the people using the stack to contribute things back. Of course I don't want to push anyone (and I don't want to load myself with more work), but I could offer some help in getting it to run if anyone had a real interest. Configuration shouldn't be too much of an issue. Given the systems U-Boot runs on, lwIP would definitively be a better choice than uIP if you have performance improvements of tcp in mind. [BTW: a http client (a.k.a. 'wget') is already included in lwIP and with help of a 3rd party TLS library, it even provides HTTPS support] Simon
On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> wrote: > > On 22.10.2018 20:53, Joe Hershberger wrote: > > Hi Christian, > > > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner > > <christian.gmeiner@gmail.com> wrote: > >> Hi Wolfgang > >> > >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: > >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> > >>>> > >>>> Prep. work to support nfs v1. > >>> Hm... as you are putting efforts into NFS support... > >>> > >>> Here comes a more general question: > >>> > >>> I wonder if it's worth the work on NFS at all, or if we should > >>> remove NFS support from U-Boot alltogether? > >>> > >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > >>> distros support only v4 in their default configurations. > >>> > >> Linux is not the only operating system used in the world. My NFSv1 > >> server runs on a vxWorks 5 device which > >> I need to support - sadly. > >> > >>> 2) We support only UDP, but most standard Linux distros support only > >>> TCP in their default configurations (see [1]) > >>> > >>> [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > >>> > >>> Try a NFS download from any recent Linux distro (i. e. one including > >>> nfs-utils 2.3.1 or later)... > >>> > >> That is true. > >> > >>> I feel a half-way solution is unsatisfactory, but the way for the > >>> Real Thing (TM) is a pretty long one... > >>> > >>> The fact that nobody compained yet that NFS stopped working fo him > >>> suggests that there are only very, very few users of NFS at all. > >>> If one of these is willing to step up and fix this for real, he is > >>> of course more than welcome. But if not - should we not remove the > >>> more or less obsolete code? > >>> > >> As u-boot is lacking TCP support this is quite a challenging task. I > >> have seen some work in progress > >> patches, which I have reviewed and hoped that it helps to get them > >> further. > > I'm trying to get those patches into a state that they are acceptable, > > but currently they are pretty brittle. I've not actually seen them > > work, though the contributor says they do in some case. I had to do > > some work to have the series just not break UDP functionality, so we > > have more work to do there. > > > >> I am also > >> interested in using ftp directly in u-boot. At the moment we are using > >> uip as tcp stack and hacked > >> together a ftp client. > > I was contemplating if using something like that or lwip would be > > better than rolling our own, but my concern is both how configurable > > those stacks are to make them lean as well as adding an external > > dependency / forking their code into our repo. Not excited about > > either. > > As the maintainer of lwIP, I already have thought about this more than > once. My main concern however was the license (lwIP is BSD style) and Yes, the license is a concern. I'm not a lawyer, but maybe someone can comment on what our options are here. Wolfgang? Tom? > the fact that it expects to always run (I don't know the U-Boot network > stack that well, but it only runs when called, doesn't it?). Yes, it currently works that way... it is pretty aggressive about going away. That is something that I've wanted to rework for a while, but haven't gotten to it. It certainly has no threads so nothing persists. Only if you are calling into a command that uses the network stack do you have the ability to do networking. > > Forking is never a good idea with open source projects. We try to > integrate as much back into the mainline code as possible. Although we > of course depend on the people using the stack to contribute things back. Yes, though due to the low-level nature of U-Boot, it seems that forking while changing as little as reasonable is the approach we've taken in all cases I've seen in the past. Much like the bits of Linux that are included, the forks strongly encourage changes to first be sent to the main project, so as to support the mainline project and to make upgrades from the mainline project much easier. > > Of course I don't want to push anyone (and I don't want to load myself > with more work), but I could offer some help in getting it to run if > anyone had a real interest. Configuration shouldn't be too much of an issue. That's good to hear. > > Given the systems U-Boot runs on, lwIP would definitively be a better > choice than uIP if you have performance improvements of tcp in mind. That was my instinct... glad to hear from you. > > [BTW: a http client (a.k.a. 'wget') is already included in lwIP and with > help of a 3rd party TLS library, it even provides HTTPS support] Excellent. > > > Simon > _______________________________________________ > U-Boot mailing list > U-Boot@lists.denx.de > https://lists.denx.de/listinfo/u-boot
On Mon, Oct 29, 2018 at 08:13:37PM +0000, Joe Hershberger wrote: > On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > On 22.10.2018 20:53, Joe Hershberger wrote: > > > Hi Christian, > > > > > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner > > > <christian.gmeiner@gmail.com> wrote: > > >> Hi Wolfgang > > >> > > >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote: > > >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info> > > >>>> > > >>>> Prep. work to support nfs v1. > > >>> Hm... as you are putting efforts into NFS support... > > >>> > > >>> Here comes a more general question: > > >>> > > >>> I wonder if it's worth the work on NFS at all, or if we should > > >>> remove NFS support from U-Boot alltogether? > > >>> > > >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux > > >>> distros support only v4 in their default configurations. > > >>> > > >> Linux is not the only operating system used in the world. My NFSv1 > > >> server runs on a vxWorks 5 device which > > >> I need to support - sadly. > > >> > > >>> 2) We support only UDP, but most standard Linux distros support only > > >>> TCP in their default configurations (see [1]) > > >>> > > >>> [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6 > > >>> > > >>> Try a NFS download from any recent Linux distro (i. e. one including > > >>> nfs-utils 2.3.1 or later)... > > >>> > > >> That is true. > > >> > > >>> I feel a half-way solution is unsatisfactory, but the way for the > > >>> Real Thing (TM) is a pretty long one... > > >>> > > >>> The fact that nobody compained yet that NFS stopped working fo him > > >>> suggests that there are only very, very few users of NFS at all. > > >>> If one of these is willing to step up and fix this for real, he is > > >>> of course more than welcome. But if not - should we not remove the > > >>> more or less obsolete code? > > >>> > > >> As u-boot is lacking TCP support this is quite a challenging task. I > > >> have seen some work in progress > > >> patches, which I have reviewed and hoped that it helps to get them > > >> further. > > > I'm trying to get those patches into a state that they are acceptable, > > > but currently they are pretty brittle. I've not actually seen them > > > work, though the contributor says they do in some case. I had to do > > > some work to have the series just not break UDP functionality, so we > > > have more work to do there. > > > > > >> I am also > > >> interested in using ftp directly in u-boot. At the moment we are using > > >> uip as tcp stack and hacked > > >> together a ftp client. > > > I was contemplating if using something like that or lwip would be > > > better than rolling our own, but my concern is both how configurable > > > those stacks are to make them lean as well as adding an external > > > dependency / forking their code into our repo. Not excited about > > > either. > > > > As the maintainer of lwIP, I already have thought about this more than > > once. My main concern however was the license (lwIP is BSD style) and > > Yes, the license is a concern. I'm not a lawyer, but maybe someone can > comment on what our options are here. Wolfgang? Tom? We have BSD-2 and BSD-3 clause code today in the tree, usually because we've had need to bring in existing code under such license.
Dear Joe, In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd=LD8JTXR3gRGg@mail.gmail.com> you wrote: > > > As the maintainer of lwIP, I already have thought about this more than > > once. My main concern however was the license (lwIP is BSD style) and > > Yes, the license is a concern. I'm not a lawyer, but maybe someone can > comment on what our options are here. Wolfgang? Tom? IANAL... Fact is, we already have some 80+ source files in U-Boot which are covered by the BSD-3-Clause license. Apparently there are also statements from the FSF that BSD-3-Clause is considered compatible with GPLv2. My _personal_ opinion is that I try to avoid BSD-3-Clause because of both the: 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. and the 3. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. clauses. The former forces me to add "some text" to all documentation, and the latter forbids me to say who wrote the code as this might be considered promotion of the product. Both are obligations I have to adhere to, while GPL clearly says "You may not impose any further restrictions on the recipients' exercise of the rights granted herein." So in my opinion BSD-3-Clause should be avoided - but then, this is just my $0.02 - YMMV. I take chances to have lwIP relicenced under a dual license (GPLv2 OR BSD-3-Clause) are epsilon? Best regards, Wolfgang Denk
Wolfgang Denk <wd@denx.de> schrieb am Di., 30. Okt. 2018, 09:46: > Dear Joe, > > In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd= > LD8JTXR3gRGg@mail.gmail.com> you wrote: > > > > > As the maintainer of lwIP, I already have thought about this more than > > > once. My main concern however was the license (lwIP is BSD style) and > > > > Yes, the license is a concern. I'm not a lawyer, but maybe someone can > > comment on what our options are here. Wolfgang? Tom? > > IANAL... > > Fact is, we already have some 80+ source files in U-Boot which are > covered by the BSD-3-Clause license. Apparently there are also > statements from the FSF that BSD-3-Clause is considered compatible > with GPLv2. > > My _personal_ opinion is that I try to avoid BSD-3-Clause because of > both the: > > 2. Redistributions in binary form must reproduce the above > copyright notice, this list of conditions and the > following disclaimer in the documentation and/or other > materials provided with the distribution. > > and the > > 3. The name of the author may not be used to endorse or > promote products derived from this software without > specific prior written permission. > > clauses. > > The former forces me to add "some text" to all documentation, and > the latter forbids me to say who wrote the code as this might be > considered promotion of the product. Both are obligations I have > to adhere to, while GPL clearly says "You may not impose any further > restrictions on the recipients' exercise of the rights granted > herein." So in my opinion BSD-3-Clause should be avoided - but > then, this is just my $0.02 - YMMV. > > I take chances to have lwIP relicenced under a dual license (GPLv2 > OR BSD-3-Clause) are epsilon? > Given that I am not the only author but lwIP has a long history of contributors, I don't know how I should handle such a license change... Simon
diff --git a/net/nfs.c b/net/nfs.c index d6a7f8e827..81c08de626 100644 --- a/net/nfs.c +++ b/net/nfs.c @@ -74,10 +74,13 @@ static char *nfs_filename; static char *nfs_path; static char nfs_path_buff[2048]; -#define NFSV2_FLAG 1 -#define NFSV3_FLAG 1 << 1 -static char supported_nfs_versions = NFSV2_FLAG | NFSV3_FLAG; +enum nfs_version { + NFS_UNKOWN = 0, + NFS_V2 = 2, + NFS_V3 = 3, +}; +static enum nfs_version choosen_nfs_version = NFS_V3; static inline int store_block(uchar *src, unsigned offset, unsigned len) { ulong newsize = offset + len; @@ -185,10 +188,19 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen) rpc_pkt.u.call.prog = htonl(rpc_prog); switch (rpc_prog) { case PROG_NFS: - if (supported_nfs_versions & NFSV2_FLAG) - rpc_pkt.u.call.vers = htonl(2); /* NFS v2 */ - else /* NFSV3_FLAG */ - rpc_pkt.u.call.vers = htonl(3); /* NFS v3 */ + switch (choosen_nfs_version) { + case NFS_V2: + rpc_pkt.u.call.vers = htonl(2); + break; + + case NFS_V3: + rpc_pkt.u.call.vers = htonl(3); + break; + + case NFS_UNKOWN: + /* nothing to do */ + break; + } break; case PROG_PORTMAP: case PROG_MOUNT: @@ -296,7 +308,7 @@ static void nfs_readlink_req(void) p = &(data[0]); p = rpc_add_credentials(p); - if (supported_nfs_versions & NFSV2_FLAG) { + if (choosen_nfs_version == NFS_V2) { memcpy(p, filefh, NFS_FHSIZE); p += (NFS_FHSIZE / 4); } else { /* NFSV3_FLAG */ @@ -325,7 +337,7 @@ static void nfs_lookup_req(char *fname) p = &(data[0]); p = rpc_add_credentials(p); - if (supported_nfs_versions & NFSV2_FLAG) { + if (choosen_nfs_version == NFS_V2) { memcpy(p, dirfh, NFS_FHSIZE); p += (NFS_FHSIZE / 4); *p++ = htonl(fnamelen); @@ -365,7 +377,7 @@ static void nfs_read_req(int offset, int readlen) p = &(data[0]); p = rpc_add_credentials(p); - if (supported_nfs_versions & NFSV2_FLAG) { + if (choosen_nfs_version == NFS_V2) { memcpy(p, filefh, NFS_FHSIZE); p += (NFS_FHSIZE / 4); *p++ = htonl(offset); @@ -395,13 +407,13 @@ static void nfs_send(void) switch (nfs_state) { case STATE_PRCLOOKUP_PROG_MOUNT_REQ: - if (supported_nfs_versions & NFSV2_FLAG) + if (choosen_nfs_version == NFS_V2) rpc_lookup_req(PROG_MOUNT, 1); else /* NFSV3_FLAG */ rpc_lookup_req(PROG_MOUNT, 3); break; case STATE_PRCLOOKUP_PROG_NFS_REQ: - if (supported_nfs_versions & NFSV2_FLAG) + if (choosen_nfs_version == NFS_V2) rpc_lookup_req(PROG_NFS, 2); else /* NFSV3_FLAG */ rpc_lookup_req(PROG_NFS, 3); @@ -528,31 +540,30 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) switch (ntohl(rpc_pkt.u.reply.astatus)) { case NFS_RPC_SUCCESS: /* Not an error */ break; - case NFS_RPC_PROG_MISMATCH: + case NFS_RPC_PROG_MISMATCH: { /* Remote can't support NFS version */ - switch (ntohl(rpc_pkt.u.reply.data[0])) { - /* Minimal supported NFS version */ - case 3: - debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n", - (supported_nfs_versions & NFSV2_FLAG) ? - 2 : 3, - ntohl(rpc_pkt.u.reply.data[0]), - ntohl(rpc_pkt.u.reply.data[1])); - debug("Will retry with NFSv3\n"); - /* Clear NFSV2_FLAG from supported versions */ - supported_nfs_versions &= ~NFSV2_FLAG; - return -NFS_RPC_PROG_MISMATCH; - case 4: - default: + const int min = ntohl(rpc_pkt.u.reply.data[0]); + const int max = ntohl(rpc_pkt.u.reply.data[1]); + + if (max < NFS_V2 || max > NFS_V3 || min > NFS_V3) { puts("*** ERROR: NFS version not supported"); debug(": Requested: V%d, accepted: min V%d - max V%d\n", - (supported_nfs_versions & NFSV2_FLAG) ? - 2 : 3, + choosen_nfs_version, ntohl(rpc_pkt.u.reply.data[0]), ntohl(rpc_pkt.u.reply.data[1])); puts("\n"); + choosen_nfs_version = NFS_UNKOWN; + break; } - break; + + debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n", + choosen_nfs_version, + ntohl(rpc_pkt.u.reply.data[0]), + ntohl(rpc_pkt.u.reply.data[1])); + debug("Will retry with NFSv%d\n", min); + choosen_nfs_version = min; + return -NFS_RPC_PROG_MISMATCH; + } case NFS_RPC_PROG_UNAVAIL: case NFS_RPC_PROC_UNAVAIL: case NFS_RPC_GARBAGE_ARGS: @@ -565,7 +576,7 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len) return -1; } - if (supported_nfs_versions & NFSV2_FLAG) { + if (choosen_nfs_version == NFS_V2) { memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE); } else { /* NFSV3_FLAG */ filefh3_length = ntohl(rpc_pkt.u.reply.data[1]); @@ -626,7 +637,7 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len) rpc_pkt.u.reply.data[0]) return -1; - if (!(supported_nfs_versions & NFSV2_FLAG)) { /* NFSV3_FLAG */ + if (choosen_nfs_version == NFS_V3) { nfsv3_data_offset = nfs3_get_attributes_offset(rpc_pkt.u.reply.data); } @@ -684,7 +695,7 @@ static int nfs_read_reply(uchar *pkt, unsigned len) if (!(nfs_offset % ((NFS_READ_SIZE / 2) * 10))) putc('#'); - if (supported_nfs_versions & NFSV2_FLAG) { + if (choosen_nfs_version == NFS_V2) { rlen = ntohl(rpc_pkt.u.reply.data[18]); data_ptr = (uchar *)&(rpc_pkt.u.reply.data[19]); } else { /* NFSV3_FLAG */ @@ -787,7 +798,7 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct in_addr sip, nfs_state = STATE_UMOUNT_REQ; nfs_send(); } else if (reply == -NFS_RPC_PROG_MISMATCH && - supported_nfs_versions != 0) { + choosen_nfs_version != NFS_UNKOWN) { /* umount */ nfs_state = STATE_UMOUNT_REQ; nfs_send();