> On Feb 7, 2018, at 6:16 PM, NeilBrown <neilb@xxxxxxxx> wrote: > > 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. So we have: 1 listener bound to 111. This is the main rpcbind service, and it is "registered" with the rpcbind service so that it is advertised to other RPC clients. 1 ephemeral port bound to N. This is an RPC client. This socket should be completely invisible to remote systems; ie. it is not "registered" with the rpcbind service, it is not a passive listener. I don't understand what you mean by "registers both of these internally." What was reported (in another email thread) is that there appears to be a second rpcbind registration on another port visible in the rpcinfo listing. I'm trying to understand what that port is for (and secondarily why it is using a port < 1024). https://marc.info/?l=linux-nfs&m=151705744428289&w=2 I still don't see the point of the listener on port 831. I don't expect that ephemeral "client" socket to be visible in the rpcinfo listing, for example. > 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. That aligns with my understanding of how CALLIT works. The second socket is not a listener, as I understand it, unless you're suggesting that rpcbind sets up the second socket as a listener to receive only replies to forwarded CALLIT requests? The bug, then, would be that the second socket shouldn't be registered with the official rpcbind service, so that it will not be displayed in rpcinfo output. Clients have "port 111" nailed in as the portmapper, so I can't see what use a second rpcbind registration would provide. > NeilBrown > > > >> >>> For comparison, portmap handles CALLIT asynchronously by forking. >>> >>> Thanks, >>> NeilBrown >> >> -- >> Chuck Lever -- Chuck Lever -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
