On Wed, Feb 07 2018, Chuck Lever wrote: >> On Feb 6, 2018, at 11:35 PM, NeilBrown <neilb@xxxxxxxx> wrote: >> >> On Mon, Feb 05 2018, Tom Talpey wrote: >> >>> On 2/5/2018 12:02 PM, Chuck Lever wrote: >>>> Heya Steve- >>>> >>>>> On Feb 5, 2018, at 11:36 AM, Steve Dickson <steved@xxxxxxxxxx> wrote: >>>>> >>>>> Over the weekend I did some experimenting with >>>>> the remote call code in rpcbind. The code does >>>>> functionally work but is very antiquated when >>>>> it comes to the latest NFS versions. >>>>> >>>>> Since only UDP sockets are used to do remote calls >>>>> using the documented interfaces pmap_rmtcall() and callrpc() >>>>> calls to NFS will fail (actual times out) since UDP is no >>>>> longer supported. >>>>> >>>>> The undocumented interface rpc_call() can be used to >>>>> call into NFS since the protocol can specified, which >>>>> also means the PMAPPROC_CALLIT protocol is not used. >>>>> >>>>> It turns out privilege port are not needed to make >>>>> remote calls, at least with my testing. >>>> >>>> It's not quite clear what you are claiming here, but >>>> I'm guessing that what you demonstrated is that the >>>> CALLIT _listener_ does not have to be privileged? >> >> rpcbind listens for CALLIT on port 111. > > Right, my bad. CALLIT is an RPC procedure, not an RPC > program. > > >> Listening on some other port wouldn't ever get the messges... > > Then we still do not understand why rpcbind is opening > and registering a second listener port. I can't think of > any reason it should do this other than that there is a > bug. This is a port on which it forwards CALLIT messages and listens for replies, which it then sends back to the originator. In order to be able to handle CALLIT asynchronously with other requests, it needs to register the port with the internal listening framework. For comparison, portmap handles CALLIT asynchronously by forking. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
