On Wed, Feb 07 2018, Chuck Lever wrote: >> 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." Maybe we are using the word "register" a bit differently because ..... > > 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). .... I can see no evidence of what you say. > > https://marc.info/?l=linux-nfs&m=151705744428289&w=2 the "listing" is this email message is *not* an rpcinfo listing. "rpcinfo" is not mentioned in the email. The listing results "when I do netstat". If I run netstat -uanp | grep rpcbind I see a very similar listing, though only of the non-111 port (702 on my desktop). The 111 port is attributed to systemd, which is expected when rpcbind was started by systemd's socket-activation. Thanks, NeilBrown
Attachment:
signature.asc
Description: PGP signature
