> On Feb 7, 2018, at 7:45 PM, NeilBrown <neilb@xxxxxxxx> wrote: > > 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. The clouds are lifted. Thanks. -- 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
