Red Hat Bugzilla – Bug 74696
Broken tcp_wrappers support
Last modified: 2007-04-18 12:46:56 EDT
Description of Problem: SGI fam will not allow any connections, and I presume it has something to do with these messages in /var/log/messages... Sep 30 18:31:27 code xinetd[2684]: warning: can't get client address: Transport endpoint is not connected Sep 30 18:31:27 code xinetd[2684]: libwrap refused connection to sgi_fam from <no address> Sep 30 18:31:27 code xinetd[2685]: warning: can't get client address: Transport endpoint is not connected Sep 30 18:31:27 code xinetd[2685]: libwrap refused connection to sgi_fam from <no address> Sep 30 18:31:27 code xinetd[2686]: warning: can't get client address: Transport endpoint is not connected Sep 30 18:31:27 code xinetd[2686]: libwrap refused connection to sgi_fam from <no address> Sep 30 18:31:27 code xinetd[693]: Deactivating service sgi_fam due to excessive incoming connections. Restarting in 30 seconds. ...so it looks like tcp_wrappers aren't being passed the correct IP address. Version-Release number of selected component (if applicable): fam-2.6.8-4 How Reproducible: Always. Steps to Reproduce: 1. Have secure machine, via. /etc/hosts.* 2. Try and run nautilus. 3. Observe messages about fam being broken. Actual Results: Expected Results: Additional Information:
Did you add 127.0.0.1 to the hosts.allow? -Ali
Yes, I'd also tried... sgi_fam: ALL ...in /etc/hosts.allow ... neither do anything useful.
For some reason I can't replicate this. Perhaps I've got a mutant package set here. I'm gonna try with a really fresh Psyche. -Ali
I get this on my 8.0 upgrade. Haven't looked into it yet.
On my fresh everthing 8.0 i don't get this. Strange.
Oh. It didn't have deny all:all. I suspect xinetd here. It tends to break fam all the time...
Correct. Someone disabled the xinetd patch that make stream+wait services work. It looks like it failed to apply due to whitespace changes. I'm attaching an updated version of the patch.
Created attachment 78044 [details] Replacement for patch0 in xinetd 2.3.7-3
Eh. make that 2.3.7-2
No go, the patch doesn't work for me. Gnome-session beautifully hangs upon login, until I kill xinetd.
After installing the patched xinetd, did you restart portmap and xinetd?
*** Bug 75055 has been marked as a duplicate of this bug. ***
and are you sure you applied the patch, patch0 is disbled (commented out) in the current xinetd specfile.
Bug 75055 was marked as a duplicate of this and closed, but I don't think it's a duplicate. I have FAM running, but nautilus and gnome-panel stall unless I kill fam. Then gnome-panel continues. It appears to be a race condition, down in the gnome-vfs - fam interaction. I posted some debug output to bug 75055 relevant to this. I'm currently running with fam disabled. nautilus and gnome-panel squawk that FAMOpen fails, but I assume vfs falls back to a polling method to determine relevant directory and file events. Now they seem to run fine (though they'd probably work better if I could use fam).
I have also the same problem on a fresh 8.0 install: xinetd refuses to start fam with same messages as reported initially and that blocks the gnome login. I have ALL: ALL in /etc/hosts.deny and ALL: 127.0.0.1 in /etc/hosts.allow. As a temporary workaround I added flags = NOLIBWRAP in /etc/xinetd.d/sgi_fam. Since fam is only bound to 127.0.0.1 this should not hinder security. Of course this is just a workaround to get the thing working and not a proper fix.
I believe an xinetd errata is planned.
I have the same problem on a fresh install of RedHat 8.0. I receive a single "can't get client address ... Transport endpoint ..." error message, but GNOME continues to run. I tried updating to the latest xinetd (2.3.9) - this did *not* eliminate the error. Applying the patch attached to this thread *did* eliminate the error message. Seems like the patch simply defeats libwrap. Is the patch more secure than putting flags = NOLIBWRAP in the sgi_fam xinetd config file ?
There really is no difference, fam is a stream+wait protocol. This means the launched app gets the socket that you accept() on, which is not connected to the endpoint. libwrap can never do anything useful on that socket. This is what is causing the "endpoint not connected" errors. our fam binds only to 127.0.0.1, so it's not a security issue.
I had the same problem on a fresh 8.0 install, and the 'flags = NOLIBWRAP' workaround solved it for me. This totally killed X logins on an old K6-2 box w/ 192MB - I got the Red Hat splash screen but no icons below, as nothing got around to starting up. Could I suggest putting out some respin isos once the fix is in? This could be a showstopper for a newbie...
Patch added in 2.3.7-5.
An errata has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2002-196.html
Hi, this error has been suffering by since I moved from Red Hat 9.0 to Fedora-1 a couple of weeks ago. I have read this bugtrack but I still don't know how to fix it. I'm affraid that the patch given in this bug list is for an old version of xinetd, and ist not valid for me, in fact I'm using xinetd-2.3.12-4.10.0. I don't know if it is relevant or not, but KDE is running ok in the same box. May I open a new bug? Thanx in advance Jose Luis Nuñez
Everyone, I am having the same problem as Jose on a new FC1 installation using xinetd xinetd Version 2.3.12 libwrap loadav. My message files and secure files are being filled by: xinetd[1077]: START: sgi_fam pid=5915 from=<no address> xinetd[5915]: FAIL: sgi_fam libwrap from=<no address> My gnome interface is also not working but KDE works fine. Since I did not get a solution i opened a new bug report #119918 Greg Ennis