> On Feb 14, 2022, at 11:23 AM, Thomas Blume <tblume@xxxxxxxx> wrote: > > Hello Chuck, > > On Montag 2022-02-14 16:26, Chuck Lever III wrote: > >>> On Feb 14, 2022, at 4:26 AM, Thomas Blume via Libtirpc-devel <libtirpc-devel@xxxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> In some setups, it is necessary to try rpc protocol version 2 first. >> >> Before applying this, I hope we can review previous discussions of >> this issue. I've forgotten the reason some users prefer it, or >> maybe I'm just imagining we've discussed it before :-) > > We've had a discussion about 1 year ago: > > https://sourceforge.net/p/libtirpc/mailman/message/37227894/ > > actually that encouraged me to send a patch, even though I initially thought > is wasn't good enough for upstream. I agree that adding the sidecar file to toggle the rpcbind version order is a bit rough. >> The patch description, at the very least, has to have a lot more >> detail about why this change is needed. Can it provide a URL to >> threads in an email archive, for example? > > This goes back to an old SUSE bugreport following the change of rpc protocol > version 2, 3, 4 to 4, 3, 2. > Below an description of issue the customer was seeing: > > --> > An 3rd party NFS Server is behind a F5 front end load balancer device. > The F5 front end load balancer device is replacing IP addresses in packets as > they head to a NFS server. > It replaces IP addresses in headers but as you might expect it does not replace > the IP address within the RPC data payload, i.e. within RPC GETADDR request, > which places an address there for the universal address or hint. Without a > correct hint, the GETADDR reply which comes back gives an unexpected address > which happens to be unroutable from the nfs client's point of view. > --< > > We agreed that this is rather an issue of the loadbalancer hardware, but we > would have to address that anyway due to backward compatibility. > > So, the first question is, do we want to stay backward compatible upstream? > We have to do that as distributor, but of course upstream is different. Thanks for the reminder. I suggest that it should be included in the patch description if you post again so that it becomes part of the libtirpc commit history. >>> Creating the file /etc/netconfig-try-2-first will enforce this. >> >> A nicer administrative API would enable you to update the whole >> rpcbind version order, but that might be more work than you want >> to pursue. >> >> It would be a nicer if, instead of a separate file, a line is >> added to /etc/netconfig to toggle this behavior, or provide the >> whole version order. E.g. >> >> # rpcbind 4 3 2 >> >> # rpcbind 2 4 >> >> Really, though, this isn't related to the transport definitions >> in /etc/netconfig, so a separate configuration file might be >> more appropriate. > > Thanks for the hints, if you deem a patch would be still desireable I will work > on that. I'd like to hear other opinions. I'm not the maintainer of libtirpc, I'm just someone who is very opinionated :-) -- Chuck Lever
