Bug #3807


rpc_clnt_create uses udp when tcp is requested

Added by Lauri Tirkkonen almost 10 years ago. Updated about 9 years ago.

lib - userland libraries
Start date:
Due date:
% Done:


Estimated time:
Gerrit CR:
External Bug:


I ran into this while trying to use showmount -e through a firewall which allows sunrpc/tcp but not udp.

Apparently clnt_create() called with nettype="tcp" will create a rpc client for UDP instead. There's even a comment to that effect in the source [1] so maybe someone intended this to be a feature, but that just seems wrong to me. At the very least it's undocumented behavior.


Actions #1

Updated by Yuri Pankov almost 10 years ago

Quoting the function comment:

The algorithm used: If the transports is TCP or UDP, it first tries version 2 (portmap), 4 and then 3 (svr4). This order should be changed in the next OS release to 4, 2 and 3.

Looks like the "next OS release" never happened.

Actions #2

Updated by Gary Mills about 9 years ago

  • Status changed from New to Feedback
  • Assignee set to Gary Mills

I'll see what I can do with this one.

Actions #3

Updated by Gary Mills about 9 years ago

Blocking UDP in a firewall likely will never work. The reason is that an RPC client first has to send a query to the remote rpcbind server to obtain the port number on which the server is listening. Only then will it send a second query to the actual server. Even if TCP is used for the second, it will likely use UDP for the first query. At the very least, you will have to allow RPC or UDP queries to rpcbind (port 111).

Actions #4

Updated by Marcel Telka about 9 years ago

rpcbind listens on both transports: UDP and TCP. It is client's decision what transport it uses/tries.

Actions #5

Updated by Gary Mills about 9 years ago

Yes, the rpcbind server listens on both transports, but the client application does not get to choose which one. The clnt_create() function can only be given the transport that's used to contact the remote service. It may listen on only one transport. It's quite possible then that the client application specifies TCP, but that UDP is used first to contact the remote rpcbind server. In fact, the __rpcb_findaddr_timed() function in rpcb_clnt.c selects UDP in two places, one for rpcbind version 4 and one for version 2. I'm assuming it does this for efficiency reasons. It doesn't do this for version 3 because there's no mechanism for doing it.

Actions #6

Updated by Gary Mills about 9 years ago

Since contacting the rpcbind service with UDP before contacting the destination service with TCP is normal behavior, I'm recommending that this bug report be closed.

Actions #7

Updated by Marcel Telka about 9 years ago

I think there is a bug and I believe the client should try more than UDP only when it is contacting the rpcbind.


Also available in: Atom PDF