60

According to the documentation:

The rpcbind[3] utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The client system then contacts rpcbind on the server with a particular RPC program number. The rpcbind service redirects the client to the proper port number so it can communicate with the requested service

To test this, I set up an NFS server and client and monitored the traffic between them. From what I saw, the client already knew that the NFS service on the server was listening on port 2049.

So when does rcpbind come into play? When I do rpcinfo on the server, I get the following:

100003    2    udp       0.0.0.0.8.1            nfs        superuser
100003    3    udp       0.0.0.0.8.1            nfs        superuser
100003    2    udp6      ::.8.1                 nfs        superuser
100003    3    udp6      ::.8.1                 nfs        superuser
100003    2    tcp       0.0.0.0.8.1            nfs        superuser
100003    3    tcp       0.0.0.0.8.1            nfs        superuser
100003    2    tcp6      ::.8.1                 nfs        superuser
100003    3    tcp6      ::.8.1                 nfs        superuser

what does 0.0.0.0.8.1 mean in this case? And how does this translate to port 2049?

Kenster
  • 3,410
SivaDotRender
  • 1,207
  • 2
  • 13
  • 13

1 Answers1

33

rpcbind is a close analog of BIND, or really, any DNS server. If I recall correctly, you choose or are given a protocol number when you compile the RPC interface's declaration into server and client stub code with rpcgen.

When a client signs up for a given interface on a particular host, usually with a clnt_create() call, the stub code asks rpcbind on that host a question, something like "on what UDP or TCP port is protocol number X listening?" rpcbind, unlike most other ONC services, listens on TCP and UDP port 111, so given a host name or IP address, a program can just ask rpcbind on that host or IP address. rpcbind responds with the appropriate port number, if a server has registered with it on that host. That registration is done by the server process when it calls svc_create().

In your example, the 100003 is the protocol number for NFS. Some process(es) have registered with rpcbind, giving their protocol number (100003) and whatever TCP or UDP port they've acquired. It's up to rpcbind to correctly give out that port number, 2049 in your case, to any call upon it for "what port should I use for protocol number 100003".

Now we're getting into weirder territory. The "0.0.0.0.8.1" is in the "address" column of rpcinfo output. Since that's the "universal address" of the NFS server process, I bet the "0.0.0.0" prefix is the IP address (INADDR_ANY in this case) that the server used in the bind() system call when getting a port number. I'm not sure what the "8.1" suffix is, but looking at rpcinfo output, it has to have something to do with the NFS server basically being a kernel thread.

  • The biggest issue in my case was that I I did not see a query to rcpbind on the server by the client when i was monitoring network traffic. Do you know when this query for the port number happens? – SivaDotRender Oct 05 '15 at 23:12
  • @SivaDotRender - I'm not 100% certain, but I believe when client code calls clnt_create() to get a handle for the protocol and host. It will probably be done via UDP, unless you set up the whole thing to use TCP. –  Oct 05 '15 at 23:19
  • 41
    "8.1" is the two bytes of the port number. 2049 = (8 * 256) + 1. – Kenster Oct 06 '15 at 01:44
  • Please stick to the term "program num". As man page does – 炸鱼薯条德里克 Mar 21 '19 at 04:30
  • "The biggest issue in my case was that I I did not see a query to rcpbind on the server by the client ...."

    I know this is late, but NFSv4 doesn't use rpcbind. Perhaps it was a v4 client?

     – PlayDough Jan 23 '24 at 16:18