Description of problem: The new rpcbind breaks connectivity with some NIS clients (e.g. MacOS X). Switching back to portmap fixes the problem. Version-Release number of selected component (if applicable): The current rpcbind supplied Fedora 7. The latest MacOS X (10.4.9). How reproducible: Try to use MacOS X NIS clients with Fedora 7 NIS server. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Let me know what additional information you need...
Can you give me a bzip2 binary network trace of the breakage something similar to tshark -w /tmp/macos.pcap host <macos_client> (Note: you might have to 'yum install wireshark' to get tshark
Created attachment 157765 [details] tshark -w macos-rpcbind.pcap host <ip-of-the-client> OK, I finally had a chance to play with this. Let me know if capture file is what you wanted...
Ok... it looks like Portmap CALLIT proc is broken... hmmm...
I believe the problem is with the order of network ids in /etc/netconfig. Please switch the order of udp/tcp and udp6/tcp6 makeing udp/tcp first. Something similar to: --- /etc/netconfig.orig 2005-05-18 01:10:50.000000000 -0400 +++ /etc/netconfig 2007-07-24 09:45:40.000000000 -0400 @@ -10,10 +10,10 @@ # The <device> and <nametoaddr_libs> fields are always empty in this # implementation. # -udp6 tpi_clts v inet6 udp - - -tcp6 tpi_cots_ord v inet6 tcp - - udp tpi_clts v inet udp - - tcp tpi_cots_ord v inet tcp - - +udp6 tpi_clts v inet6 udp - - +tcp6 tpi_cots_ord v inet6 tcp - - rawip tpi_raw - inet - - - local tpi_cots_ord - loopback - - - unix tpi_cots_ord - loopback - - -
Note You'll also have to restart rpcbind to have this change take effect
I tried the change but it did not resolve the problem. I can see that things somehow behave differently but did not have time to do wire shark on it.
Even after a reboot the problem persisted? When I rebooted my machine the exact same problem went away...
I rebooted the machine. I think I will need to get network debug for you. However, this is a "production" machine and I can't this right away..
I confirm this bug too. I made the edit to /etc/netconfig from Comment #4 (Steve Dickson). Mac OS X 10.4 (Tiger) NIS client is still broken. This output is from rpcbind -d on F7 NIS server: pmap_rmtcall callit req for (100004, 2, 2, udp) from 192.168.2.116.192.237 : not found svc_maxfd now 8 polling for read on fd < 5 6 7 8 > poll returned read fds < 6 > pmap_rmtcall callit req for (100004, 2, 2, udp) from 192.168.2.116.192.237 : not found Please let me know what else I can do to help. My production FC5 box is dying. I need to move to my new F7 box soon! Best regards, Joe Kotran
Joe, are the network interfaces configure to use ipv6? (In reply to comment #9)
Steve, No, I am not using ipv6. Joe Kotran P.S. In 'production server' I mean my home multi-purpose server. We use RHEL 5 at work!
Quick Update, I am looking for a mac0S machine so I can try and reproduce this...
I am having the same problem with FC5 and FC8 ypbind on i386 clients trying to broadcast bind to a FC8 i386 ypserv. There is no ip6 anywhere in our network.
I found another typo in the /etc/netconfig file Please try the following: --- /etc/netconfig.orig 2005-05-18 01:10:50.000000000 -0400 +++ /etc/netconfig 2007-07-24 09:45:40.000000000 -0400 @@ -10,10 +10,10 @@ # The <device> and <nametoaddr_libs> fields are always empty in this # implementation. # -udp6 tpi_clts v inet6 udp - - -tcp6 tpi_cots_ord v inet6 tcp - - udp tpi_clts v inet udp - - tcp tpi_cots_ord v inet tcp - - +udp6 tpi_clts v inet6 udp6 - - +tcp6 tpi_cots_ord v inet6 tcp6 - - rawip tpi_raw - inet - - - local tpi_cots_ord - loopback - - - unix tpi_cots_ord - loopback - - -
I already had netconfig reordered. Also tried commenting the "6" lines out (that solves a different problem). Here is rpcbind debug output for a ypbind broadcast: polling for read on fd < 5 6 7 8 9 > poll returned read fds < 9 > PMAPPROC_DUMP svc_maxfd now 9 polling for read on fd < 5 6 7 8 9 > program vers proto port service 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100000 4 0 111 portmapper 100000 3 0 111 portmapper 100000 2 0 111 portmapper 100004 2 udp 821 ypserv 100004 1 udp 821 ypserv 100004 2 tcp 824 ypserv 100004 1 tcp 824 ypserv poll returned read fds < 9 > svc_maxfd now 8 polling for read on fd < 5 6 7 8 > poll returned read fds < 6 > pmap_rmtcall callit req for (100004, 2, 2, udp) from 192.168.20.30.128.5 : found at uaddr 0.0.0.0.3.53 addrmerge(caller, 0.0.0.0.3.53, NULL, udp addrmerge: hint 127.0.0.1.0.111 addrmerge: returning 127.0.0.1.3.53 addrmerge(caller, 0.0.0.0.3.53, NULL, udp addrmerge: hint 192.168.20.30.128.5 addrmerge: returning 192.168.20.252.3.53 merged uaddr 192.168.20.252.3.53 rpcbproc_callit_com: original XID 1f2cf8b5, new XID d9b28980 svc_maxfd now 8 polling for read on fd < 5 6 7 8 > poll returned read fds < 7 > my_svc_run: polled on forwarding fd 7, netid udp - calling handle_reply handle_reply: recvfrom returned -1, errno 22 polling for read on fd < 5 6 7 8 > poll returned read fds < 6 > pmap_rmtcall callit req for (100004, 2, 2, udp) from 192.168.20.30.128.5 : found at uaddr 0.0.0.0.3.53 addrmerge(caller, 0.0.0.0.3.53, NULL, udp addrmerge: hint 127.0.0.1.0.111 addrmerge: returning 127.0.0.1.3.53 addrmerge(caller, 0.0.0.0.3.53, NULL, udp addrmerge: hint 192.168.20.30.128.5 addrmerge: returning 192.168.20.252.3.53 merged uaddr 192.168.20.252.3.53 rpcbproc_callit_com: duplicate request svc_maxfd now 8
Could you also possibly post a bzip2 tshark network trace? Something similar to: tshark -w /tmp/bz244492.pcap host <server> bzip2 /tmp/bz244492.pcap tia!
Created attachment 290945 [details] Correcting recvfrom argument (fromlen) I had the same problem with a Leopard client, tracked down the issue to an incorrect argument to recvfrom.
Thank you for tracking this down!!! Fixed in rpcbind-0.1.4-13.fc9.src.rpm Fixed in rpcbind-0.1.4-13.fc8.src.rpm Which will be avaiable as soon as the build system starts working again....
(In reply to comment #18) > Fixed in rpcbind-0.1.4-13.fc9.src.rpm > Fixed in rpcbind-0.1.4-13.fc8.src.rpm I would very much like it to be fixed in fc7 as well!
rpcbind-0.1.4-13.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.