On Wed, Feb 07 2018, Chuck Lever wrote:
>> On Feb 7, 2018, at 4:16 PM, NeilBrown <neilb@xxxxxxxx> wrote:
>>
>> 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.
>
> Sorry, this is still not making sense to me. Can you create a
> ladder diagram that shows the exchange of Call and Reply messages?
Firstly, portmap binds 2 sockets (ignoring tcp for now), one on port 111
and one on an ephemeral port (EP). It registers both of these internally so
incoming packets get noticed.
If it receives SET or UNSET or GETADDR etc on 111, it replies directly.
CALLIT is a bit more complete.
remote-client rpcbind local-service
111
send CALLIT(XX) ------>rpcbproc_callit_com() EP
unwrap/send XX ----------------->handle
EP
111 handle_reply()<----------------send reply
receive reply<-------wrap-and-send
does that help? The callit request/reply to/from port 111 has
some other request/reply embeded in it.
This embedded request/reply is sent/received unwrapped on the ephemeral
port.
NeilBrown
>
>> For comparison, portmap handles CALLIT asynchronously by forking.
>>
>> Thanks,
>> NeilBrown
>
> --
> Chuck Lever
Attachment:
signature.asc
Description: PGP signature
