I might have something for the libtirpc autodetection in my git clone ...

FEDORA-2019-f8eeec9679 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8eeec9679

libsigrok-0.5.1-3.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f23af0cef0

libsigrok-0.5.1-3.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-f8eeec9679

Yeah... there's a problem with libtirpc that I believe did not exist with glibc RPC.  The device I have apparently only speaks TCP over port 111 (portmap).  That's in direct conflict libtirpc, which says this:

rpcb_clnt.c:
432		/*
433		 * Try UDP only - there are some portmappers out
434		 * there that use UDP only.
435		 */

It then goes on to override the protocol specified by the caller.

Wireshark shows that it is switching to UDP while querying portmapper.

Now... the really stupid thing about all of this is that litirpc has already called GETADDR to negotiated the protocol version with the portmapper over the TCP connection!!  That makes the fallback to UDP completely unnecessary.  It starts the fallback halfway through the conversation with the portmapper, when doing the GETPORT call.

With the following patch to libtirpc, sigrok-cli finally works:

--- libtirpc-1.1.4/src/rpcb_clnt.c.orig	2019-06-28 22:23:02.304547981 -0500
+++ libtirpc-1.1.4/src/rpcb_clnt.c	2019-06-28 22:23:14.505332538 -0500
@@ -429,11 +429,7 @@
 	CLIENT *client = NULL;
 	rpcvers_t pmapvers = 2;
 
-	/*
-	 * Try UDP only - there are some portmappers out
-	 * there that use UDP only.
-	 */
-	if (nconf == NULL || strcmp(nconf->nc_proto, NC_TCP) == 0) {
+	if (nconf == NULL) {
 		struct netconfig *newnconf;
 
 		if ((newnconf = getnetconfigent("udp")) == NULL) {
@@ -442,7 +438,8 @@
 		}
 		client = getclnthandle(hostname, newnconf, tgtaddr);
 		freenetconfigent(newnconf);
-	} else if (strcmp(nconf->nc_proto, NC_UDP) == 0) {
+	} else if (strcmp(nconf->nc_proto, NC_UDP) == 0 ||
+	    strcmp(nconf->nc_proto, NC_TCP) == 0) {
 		if (strcmp(nconf->nc_protofmly, NC_INET) != 0)
 			return NULL;
 		client = getclnthandle(hostname, nconf, tgtaddr);


$ sigrok-cli --driver=siglent-sds:conn=vxi/sds2204x --scan
The following devices were found:
siglent-sds - Siglent SDS2204X 1.2.2.2 R19 with 4 channels: CH1 CH2 CH3 CH4

Rob, could you, please, make a separate bug report against libtirpc for the patch from comment #5? We should get it fixed upstream, thanks.

I am happy to do so.  https://bugzilla.redhat.com/show_bug.cgi?id=1725329

With that said, has Red Hat considered just forking the GLIBC sunrpc code and adding whatever features it thinks are necessary instead of relying on libtirpc?  I was looking at the two code bases to determine whether there was any commonality or if this fallback behavior was hidden somewhere within GLIBC's implementation.  It does not appear to invoke any such behavior.

It is also apparent that the GLIBC code is cleaner and more modern.  GLIBC's code appears cultivated and cared for.  libtirpc appears to have been forked long ago and looks like an accumulation of hacks over time.  This seems like a step in the wrong direction for maintaining OS quality and stability.  libtirpc doesn't just need bug fixes.  It needs wholesale refactoring.

The behavior I am hitting appears to be some vestigial behavior of an ancient RPC stack.  It has existed from the beginning of libtirpc's repository history.  (I am not up for doing further code archeology.)

As someone who uses RHEL extensively in my professional life, I would hate to see this hackery make its way into Red Hat's enterprise product.  I am disappointed I have to deal with this sort of unnecessary breakage in Fedora.

Per https://fedoraproject.org/wiki/Changes/SunRPCRemoval the switch to libtirpc was initiated by glibc developers for technical reasons.

Per that wiki page:

"As a result, upstream decided to move Sun RPC support to a separate library, libtirpc, which has been packaged since Fedora 7."

What does "upstream" mean in this regard?  Red Hat?

The rest of the Linux community appears to be using libntirpc (notice the "n"), which is also in much better shape than libtirpc:

https://github.com/CentOS-Storage-SIG/libntirpc/blob/master/README.md

This is also shipped by Fedora.  Please link libsigrok to this RPC library instead.

Nevermind on libntirpc... it appears to have an incompatible API.

(In reply to Rob Riggs from comment #9)
> Per that wiki page:
> 
> "As a result, upstream decided to move Sun RPC support to a separate
> library, libtirpc, which has been packaged since Fedora 7."
> 
> What does "upstream" mean in this regard?  Red Hat?

glibc upstream I suppose, where Red Hat represents only a minority
 
> The rest of the Linux community appears to be using libntirpc (notice the
> "n"), which is also in much better shape than libtirpc:
> 
> https://github.com/CentOS-Storage-SIG/libntirpc/blob/master/README.md
> 
> This is also shipped by Fedora.  Please link libsigrok to this RPC library
> instead.

shame libntirpc is with incompatible API, it really looks more active, etc

libsigrok-0.5.1-3.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

libsigrok-0.5.1-3.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.