Red Hat Bugzilla – Bug 244120
ypserv doesn't respond to broadcast requests
Last modified: 2008-05-16 18:50:29 EDT
Description of problem: Ypserv doesn't respond to broadcast requests, but it does work properly when using the format for yp.conf of "domain nisdomain server nisserver" Version-Release number of selected component (if applicable): ypserv-2.19-4.fc7 How reproducible: Always Steps to Reproduce: 1.On client machine, set /etc/yp.conf to be: domain nisdomain broadcast 2.Start ypbind service 3. Actual results: Ypbind service hangs after printing "Binding NIS service:" Expected results: Ypbind should connect when using broadcast Additional info: Ypbind does work with broadcast when connecting to a FC6 ypserv. Ypbind does work when not using broadcast, but explicitly declaring the server.
Is there anything being logged in /var/log/message that might help understand this?
Jun 13 14:29:47 porthos ypbind[30750]: broadcast: RPC: Timed out.
yeah.. I think I see the problem... for some strange reason ypbind is only broadcasting using the IPV6 address... I'm looking into it...
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 - - -
This seems to fix it in my setup. Now I can remove that pesky "nis_servers" line from dhcpd.conf.
Fixed in libtirpc-0.1.7-8.fc7
I have similar problem, but this fix does not work for me. Broadcast requests with fc6 server works, if I have only fc7 and fc8 servers -no. I ended up listing all servers in separate lines: domain my_domain server ypserver1 domain my_domain server ypserver2 ... etc to have fall-back solution. Here is the /var/log/messages lines: Nov 27 12:18:24 leonpc ypbind: NIS server for domain nisdomainname is not responding. Nov 27 12:18:33 leonpc ypbind[18832]: broadcast: RPC: Timed out.
Just noticed that after the latest round of updates earlier this week, it started to work as expected. I have following rpms: libtirpc-0.1.7-14.fc8 ypserv-2.19-7.fc8 ypbind-1.20.4-2.fc8
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Closing bug as per comment #8.