Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Thomas Blume <tblume@suse.com>
CC:     libtirpc List <libtirpc-devel@lists.sourceforge.net>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>
Subject: Re: [Libtirpc-devel] [PATCH] rpcb_clnt.c config to try
 protocolversion 2 first
Thread-Topic: [Libtirpc-devel] [PATCH] rpcb_clnt.c config to try
 protocolversion 2 first
Thread-Index: AQHYIYhKDk3jkCVie0yBKH6y3YG1OqyTK2AAgAAP9ACAAAUSgA==
Date:   Mon, 14 Feb 2022 16:41:38 +0000
Message-ID: <45A65BD8-8712-4B43-A91E-9DBA21ECE6E3@oracle.com>
References: <20220214092607.24387-1-Thomas.Blume@suse.com>
 <F1A91E0B-4544-4739-ADAD-CF9FCC9E8F66@oracle.com>
 <q7n3pnn5-6o3-524-8rn1-q7oprr139258@fhfr.pbz>
In-Reply-To: <q7n3pnn5-6o3-524-8rn1-q7oprr139258@fhfr.pbz>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?CUqLI91m3E5RhDQXvgADSx7l464P8IbXNG9fz3+Z5UzDLJaeQt3p2FzfTolW?=
 =?us-ascii?Q?3Vqkq4J+/S9Iij9oa6LKPx3lrOhRsP8415WX/vDUQxgKr0XbCF9eRWzVLSoA?=
 =?us-ascii?Q?OpV2hwmAtEjLzbhHuDxnlQb1NPMifGqytcldPzv1tjBErqcG4RC10Nxy2wAF?=
 =?us-ascii?Q?AZLIJA5WF8CEqWe57lH7GJuoP5xGsmPg0HU4Gll6/+m/gM3CALM4wqie0OT/?=
 =?us-ascii?Q?n0qVOk7gO6coKpc7JAv/stKXeoWZEaVE427xiaqHszP5+ErAASadiWct8llj?=
 =?us-ascii?Q?O2rMn8opiVwsmuqqAa9CGnwsfZFitdlTJtqTo59vtNUo11ttUWxnLwPUp82y?=
 =?us-ascii?Q?bliVSMc6thwajMRjT0fqgqrljZtCGKFkp48aVF3xw0cQXnvl0adT6cLTndl9?=
 =?us-ascii?Q?g98ePN1R79o5mluondnDmsld13TvwGUHjpWTdrWdE8xCHhcGo30tENrCdR/8?=
 =?us-ascii?Q?yoNE31jr26rkrfc+FA91zbvvhTK6THtW2Ye8uxcajx8J8Uu/qzwTNgBTYSC/?=
 =?us-ascii?Q?53Pvm9eA0W983HRvKLyhMOevgcQZM1VZ41sgKLgWirTRpjJAQypkumsuZPdP?=
 =?us-ascii?Q?oZ973GEhZrYcM3b3lv4xNIUQzIyXjTdIWsyQx4QnSM986prYr7uhdRm8SKQL?=
 =?us-ascii?Q?0domvj96m7Ex92acbr2C0OQlCP0aBVB6fTV4aiYy5tcUOB+qErcwsDgdG/Ep?=
 =?us-ascii?Q?+3T6KFKho2UqcP57ctnJXfT90QZWZfhrsoJXIvhyVopmPqkzTv3uwsUt6rW6?=
 =?us-ascii?Q?BPz3Z0Yc6UJqKFjveObpw9i/3L1+ans4+l4HeP5SSfRIEDyCVwUqS8XYcVi1?=
 =?us-ascii?Q?84WCnPkZiTdB5fdwbrVam6X11X+xZ/FFkrmPa8B+Hr6siHJDn8neL9MLYEzG?=
 =?us-ascii?Q?zFLspCxEukT4toLcc3jDSr/1L4w227Z4YuvhvDo0tJz51epb+nfxOT9y2IJ/?=
 =?us-ascii?Q?xmZlrK9mb6oU+nRdekWraxqxu/jMu0Pwug+aD94SjWnX2KKSS20/HmItfMAW?=
 =?us-ascii?Q?RdjLC0JpTdWu8SfrYh5q1r4upFEPqp6rZtQ7tlSZU6wsUVqRIZbMYCNeQ2ea?=
 =?us-ascii?Q?PDHZgfNtAkkyCZwdBHzC3BrXXX6B+By2i5Z1DOcUpCNRM/5gC3bLBpYSdqs5?=
 =?us-ascii?Q?4WTjOTq3wz2nb5Eci3t0ZPTmZbZkB5wiiFvmGZknfhCa4K5GXmkvc8Tt3b7I?=
 =?us-ascii?Q?4m2aEn5n0cWOTFSiBGo3ZUjy7pKwKP6mM8InRWDw7jRfN9z+AXZOMsugatqX?=
 =?us-ascii?Q?zcDViZXvj79FP1W8PV+EbKJ394lkvD3z7kobVXn9UTii0dYqcUpE0qoH1nKL?=
 =?us-ascii?Q?lLS3mba8dlDHv4I6q+srG0C4X2UnBrvnlq8dHadJlASRKyguGFXjA3IjS5Bk?=
 =?us-ascii?Q?kSSUnR+4u10bUC/UB0MLE0e1DA/jBn05hvE18+2YYf62rBd4nQvWFYAbnPLs?=
 =?us-ascii?Q?M06b+lt3xAckLoKiFmK3/NDPNluin7pugUY56OLdaf2YDzouGlVxnWZB4jM/?=
 =?us-ascii?Q?bz1Rv9w9a6Sy62QjSIJOyp0EsllObdgyDaAInX+NqcNeYwOoUCBYRGVyRX7U?=
 =?us-ascii?Q?zWepxq0JFsYBeocyNVSXHoeSUup14oSGYzPyUjps8wfqTVDM9VWYez6+O5kh?=
 =?us-ascii?Q?OGrgVzJFc+29jqG/oiQyxNo=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <CC33AD4B9E99D6448D6C9EF342BC3987@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6550c440-659c-4321-ae6a-08d9efd8df56
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2022 16:41:38.7518
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ki7MCfGd2gcVwdLNVptcxv6MfiBKQ7RjOJeIClbarj2hET3ztNjntbFVCRkIZpqA2uUZJrWHnvXUUtomun3wCg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR1001MB2407
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10258 signatures=673431
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 bulkscore=0 suspectscore=0
 phishscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000
 definitions=main-2202140099
X-Proofpoint-ORIG-GUID: EddcjaDxP8wzDIg1AzwXW8idlG2kQJ9v
X-Proofpoint-GUID: EddcjaDxP8wzDIg1AzwXW8idlG2kQJ9v
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE
	autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Feb 14, 2022, at 11:23 AM, Thomas Blume <tblume@suse.com> wrote:
>=20
> Hello Chuck,
>=20
> On Montag 2022-02-14 16:26, Chuck Lever III wrote:
>=20
>>> On Feb 14, 2022, at 4:26 AM, Thomas Blume via Libtirpc-devel <libtirpc-=
devel@lists.sourceforge.net> wrote:
>>>=20
>>> In some setups, it is necessary to try rpc protocol version 2 first.
>>=20
>> 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 :-)
>=20
> We've had a discussion about 1 year ago:
>=20
> https://sourceforge.net/p/libtirpc/mailman/message/37227894/
>=20
> actually that encouraged me to send a patch, even though I initially thou=
ght
> 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?
>=20
> This goes back to an old SUSE bugreport following the change of rpc proto=
col
> version 2, 3, 4 to 4, 3, 2.
> Below an description of issue the customer was seeing:
>=20
> -->
> 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 packet=
s as
> they head to a NFS server.
> It replaces IP addresses in headers but as you might expect it does not r=
eplace
> the IP address within the RPC data payload, i.e. within RPC GETADDR reque=
st,
> which places an address there for the universal address or hint.  Without=
 a
> correct hint, the GETADDR reply which comes back gives an unexpected addr=
ess
> which happens to be unroutable from the nfs client's point of view.
> --<
>=20
> We agreed that this is rather an issue of the loadbalancer hardware, but =
we
> would have to address that anyway due to backward compatibility.
>=20
> So, the first question is, do we want to stay backward compatible upstrea=
m?
> 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.
>>=20
>> 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.
>>=20
>> 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.
>>=20
>> # rpcbind 4 3 2
>>=20
>> # rpcbind 2 4
>>=20
>> Really, though, this isn't related to the transport definitions
>> in /etc/netconfig, so a separate configuration file might be
>> more appropriate.
>=20
> Thanks for the hints, if you deem a patch would be still desireable I wil=
l 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