Bug 244492

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.