Bug 1724865
Summary: | libsigrok missing libtirpc | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Rob Riggs <rob+redhat> | ||||
Component: | libsigrok | Assignee: | Dan Horák <dan> | ||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
Severity: | unspecified | Docs Contact: | |||||
Priority: | unspecified | ||||||
Version: | 29 | CC: | dan, mr.nuke.me | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Whiteboard: | |||||||
Fixed In Version: | libsigrok-0.5.1-3.fc31 libsigrok-0.5.1-3.fc30 libsigrok-0.5.1-3.fc29 | Doc Type: | If docs needed, set a value | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2019-07-10 00:51:29 UTC | Type: | Bug | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
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. |
Created attachment 1585389 [details] Patch to add tirpc dependency in order to regain VXI support. Description of problem: libsigrok is being built without VXI support Version-Release number of selected component (if applicable): 0.5.1-1 How reproducible: Always Steps to Reproduce: 1. Attempt to use sigrok-cli with any VXI device 2. Review the output of the RPM build process 3. etc. Actual results: Does not understand "vxi" as a communication protocol Expected results: Understands the "vxi" protocol specifier. Additional info: This is broken since the removal of RPC from glibc (Fedora 28). ./configure CPPFLAGS=-I/usr/include/tirpc LDFLAGS=-ltirpc Patch for spec file attached. Is there an update to autotools that will find this library when RPC is needed?