Bug 244492 - New rpcbind breaks connectivity with some NIS clients
New rpcbind breaks connectivity with some NIS clients
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
7
All Linux
low Severity medium
: ---
: ---
Assigned To: Steve Dickson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-16 00:36 EDT by Jussi Eloranta
Modified: 2008-01-27 02:13 EST (History)
2 users (show)

See Also:
Fixed In Version: 0.1.4-13.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-27 02:13:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tshark -w macos-rpcbind.pcap host <ip-of-the-client> (2.25 KB, application/x-bzip)
2007-06-25 11:35 EDT, Jussi Eloranta
no flags Details
Correcting recvfrom argument (fromlen) (355 bytes, patch)
2008-01-07 07:11 EST, Anders Blomdell
no flags Details | Diff

  None (edit)
Description Jussi Eloranta 2007-06-16 00:36:45 EDT
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...
Comment 1 Steve Dickson 2007-06-16 09:40:15 EDT
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
Comment 2 Jussi Eloranta 2007-06-25 11:35:59 EDT
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...
Comment 3 Steve Dickson 2007-07-20 12:11:05 EDT
Ok... it looks like Portmap CALLIT proc is broken... hmmm... 
Comment 4 Steve Dickson 2007-07-24 10:16:07 EDT
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  -      -       -
Comment 5 Steve Dickson 2007-07-26 12:17:05 EDT
Note You'll also have to restart rpcbind to have
this change take effect
Comment 6 Jussi Eloranta 2007-07-26 15:08:47 EDT
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.
Comment 7 Steve Dickson 2007-07-27 09:10:59 EDT
Even after a reboot the problem persisted? When I rebooted my
machine the exact same problem went away... 
Comment 8 Jussi Eloranta 2007-07-27 12:06:32 EDT
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..
Comment 9 Joseph Kotran 2007-09-12 23:23:18 EDT
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
Comment 10 Steve Dickson 2007-09-14 11:21:47 EDT
Joe,

are the network interfaces configure to use ipv6? (In reply to comment #9)
Comment 11 Joseph Kotran 2007-09-14 14:32:00 EDT
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!
Comment 12 Steve Dickson 2007-09-15 07:00:05 EDT
Quick Update,

I am looking for a mac0S machine so I can try and reproduce this...


Comment 13 soochon radee 2007-12-17 14:48:39 EST
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.
Comment 14 Steve Dickson 2007-12-17 14:59:59 EST
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  -      -       -


Comment 15 soochon radee 2007-12-17 15:23:23 EST
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
Comment 16 Steve Dickson 2007-12-18 08:53:33 EST
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!
Comment 17 Anders Blomdell 2008-01-07 07:11:03 EST
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.
Comment 18 Steve Dickson 2008-01-24 13:56:03 EST
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.... 
Comment 19 Anders Blomdell 2008-01-25 11:58:13 EST
(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!
Comment 20 Fedora Update System 2008-01-27 02:13:53 EST
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.

Note You need to log in before you can comment on or make changes to this bug.