From owner-freebsd-net@freebsd.org Wed Jan 23 20:40:42 2019 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 55D1A14B22BD for ; Wed, 23 Jan 2019 20:40:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id C1E948A374 for ; Wed, 23 Jan 2019 20:40:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: by mailman.ysv.freebsd.org (Postfix) id 7C58B14B22BC; Wed, 23 Jan 2019 20:40:41 +0000 (UTC) Delivered-To: net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59D1614B22BB for ; Wed, 23 Jan 2019 20:40:41 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660086.outbound.protection.outlook.com [40.107.66.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDA178A36F for ; Wed, 23 Jan 2019 20:40:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM (10.169.141.13) by YQBPR01MB0532.CANPRD01.PROD.OUTLOOK.COM (10.169.143.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1558.18; Wed, 23 Jan 2019 20:40:39 +0000 Received: from YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM ([fe80::1428:85bd:f34d:e423]) by YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM ([fe80::1428:85bd:f34d:e423%2]) with mapi id 15.20.1537.031; Wed, 23 Jan 2019 20:40:39 +0000 From: Rick Macklem To: Alexey Dokuchaev , "net@freebsd.org" Subject: Re: Why rpcb_getaddr(3) uses UDP even for TCP NFS mounts? Thread-Topic: Why rpcb_getaddr(3) uses UDP even for TCP NFS mounts? Thread-Index: AQHUsvqJpI9+eixCN0WbsnsZapKEFaW9Tk7c Date: Wed, 23 Jan 2019 20:40:39 +0000 Message-ID: References: <20190123093454.GA87168@regency.nsu.ru> In-Reply-To: <20190123093454.GA87168@regency.nsu.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; YQBPR01MB0532; 6:OSSoHlRr8gAswifVv87whBHNigLrm9m31fy3EzaKRfdUfRPhVVCOHnFJXYP9Fj0AcK4v/WLAdMVu0HkL/Fj6qMu8dP1gqCurremRqIh6oMYVNYGIILOQfySk9elaDXEMryzrHAeFrgedc5Z2spUxNc6fbYR/7fMNiLI/jzr8JfR5RQvxw/5MJkbWCn1Z+D+EwWlMt0eFbFxX9GQ1+X2HgVNH4+1EAwqa3XkWdYqTImaH0chjNiJmLJQhG30tO8DUy9+l3IAv4yjeSvgT5s5jKPFB5QI5PIDunIgsO8LFPhr0jVuhQcPHuoRHlTTplFxQ3LY/s0st/4QIKQi1MmbqT6nKXCAH2dChGY+YpNaP69njjTi5PTAyqhnXx2HaW913Y4DhC8oPnuvDgwPMe0tJmf/HIKfvCa4d269xFdlMZMbb/83CafBwz9SgqM3xbyPLKjH1RBUGBaWNUdKVmAy9pg==; 5:JxHsKsqUY576bASXmh7hl4AxK+2Taxj+kPd20jlj7ktxLghf2F9Qnz6DPn1RzQCTzbllZf9Y4EWf4IFZI/LW1Is/GPXF/KhYX4tU4BClVEIn4KrDc9RCRfAEVVZe+U1Oa01aETU5LIL9fFItGfKnYfZo2U6VxmB60XCNRQxhxJZARPYjy/7NLpAVpVZf940gO3oWBJ+lR8qDkZaiwCyfLw==; 7:HWwRr/gKU0SsGbGS+VPuy+TlNhe+SfYK9Ezx9EN+kkA1E9vuaeBxki08IE2X8nM5mF9bXcep8/ARTiVy3nunx23Eb/YJ8TnB7kFZlLR75Z3mPVjjfi0H5oTP8aJfvsMtpBXw1u8Sxq5DXqZZPNPCaA== x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: e58d7ab3-acb6-449e-2d2d-08d68173092e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(2017052603328)(7153060)(7193020); SRVR:YQBPR01MB0532; x-ms-traffictypediagnostic: YQBPR01MB0532: x-microsoft-antispam-prvs: x-forefront-prvs: 0926B0E013 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(396003)(346002)(376002)(39860400002)(199004)(189003)(6246003)(25786009)(9686003)(71190400001)(71200400001)(486006)(786003)(217873002)(74482002)(6436002)(55016002)(97736004)(53936002)(256004)(26005)(102836004)(446003)(11346002)(186003)(86362001)(476003)(229853002)(99286004)(105586002)(106356001)(33656002)(2906002)(74316002)(14454004)(478600001)(2501003)(76176011)(6506007)(316002)(110136005)(81166006)(8936002)(81156014)(8676002)(305945005)(7696005)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:YQBPR01MB0532; H:YQBPR01MB0113.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jKX2saY8pBy5TBbarvnWrKcBynz3/TZCW0Jy1+SZdCtothhXO0riJk07/YEaBtCZNNem+9okjJ0q+B3Dv8aVTqGoTRBtPpULOXnE3xhOFq++dq4V114+eINNVhfrE5D6lBM9MRzWfNj9j9WfnnP08kv9W15sURiWdV5myO0Iicg3Tu++GXZwgmmACTbLKfXli+BY+XfzYWUYpDsBHYmCA07Fgzm/IwjFFFo8aX//FXUN0No0w3iNMDRbDgyKeOFh3ekCmMZ2WsdKNd8QvXW0vdIGUosNgK5hm7gM6iBsIzbm0nq7mf0ugTQ/2q4WLZkowCzZ2qOUJgJMBb6/121XKn4uf2Msp+MyDFqqrg4YPMDrYaNna6og3f8H1tKyitMqzKHZziPpbIVxW6r29tX3789TnhcaY37MI7iNjVPjABs= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: e58d7ab3-acb6-449e-2d2d-08d68173092e X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2019 20:40:39.4434 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR01MB0532 X-Rspamd-Queue-Id: EDA178A36F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.98 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.983,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2019 20:40:42 -0000 Alexey Dokuchaev wrote: >Hi there, > >I've recently encountered a problem that my NFS box was not directly >accessible to one of its clients. I've forwarded TCP ports for the >rpcbind(8), mountd(8), and nfsd(8) with ssh(1), but mount_nfs(8) did >not work, that is, with -o tcp,proto=3Dtcp. > >Running it under truss(1) revealed something odd: > > socket(PF_INET,SOCK_DGRAM,IPPROTO_UDP) =3D 3 (0x3) > ... > sendto(3,"blah-blah"...,56,0,{ AF_INET :111 },16) =3D 56 (= 0x38) > > >Only after I've forwarded port 111 via UDP, it worked as expected. >Apparently, this happens inside rpcb_getaddr(3), and there is no easy >way to create SOCK_STREAM/IPPROTO_TCP socket, which kind of prevents >working with NFSv3 in a pure TCP environment, as forcing TCP mounts via >-o tcp,proto=3Dtcp is useless, per /usr/src/lib/libc/rpc/rpcb_clnt.c: Well, there is a reason why NFSv4 (published in an RFC in 2003) does not u= se the Mount protocol or rpcbind. Those protocols were defined decades ago by a company that no longer exists= . If you took a look at Linux sources and found that they avoided using UDP f= or rpcbind, then a compatible change would probably be ok. I now consider the Linux NFS implementation as being the defacto standard. >#ifdef PORTMAP > ... > /* > * Try UDP only - there are some portmappers out > * there that use UDP only. > */ > >Is there a reason for this behavior (apart from what the comment says, >ignoring the fact that it is 2019 now), and more importantly, correct >way to avoid talking to the rpcbind(8) via UDP? As above, who knows what implementations are still out there? Since the company (Sun) is long gone, what the Linux sources do probably would be a guide w.r.t. this can be changed. (When I say "Linux", I am not referring to the kernel, but what most distros use. I think most of them will use roughly the same GNU sources, but that also introduces another "degree of freedom" here. To do this well, you probably have to look at several distros and see if they all handle TCP only rpcbind.) rick