Description of Problem:
The fam utility is not working correctly with tcp wrappers. Tcp wrappers
reports via /var/log/messages that it cannot get client address.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure /etc/hosts.allow as:
ALL: LOCAL, 127.0.0.1
2. Configure /etc/hosts.deny as:
3. Login using KDE as your desktop environment
The KDE login hangs will initializing services. TCP Wrappers repeatedly logs
this to /var/log/messages:
Jan 13 08:36:19 pcp096489pcs xinetd: warning: can't get client address:
Transport endpoint is not connected
Jan 13 08:36:19 pcp096489pcs xinetd: libwrap refused connection to
sgi_fam from 0.0.0.0
KDE login should not hang. TCP Wrappers should be able to resolve which host
that fam is connecting as.
I do not think that there is a severity rating appropriate. I would classify
this bug as moderate as the work around is to disable tcp wrappers or not use
KDE. Disabling tcp wrappers is not allowed in many businesses, including my
I don't think this is fam related.
libwrapper always prints that for fam because of a bug in xinetd where it looks
at the wrong socket.
I get a few of these at startup, but I can still log in to KDE. Even with the
tcp wrappers setttings above.
Where exaclty is is blocking?
Sorry, but I cannot be more exact. The KDE login process hanges at the
initializing services step. The icon blinks indefinitely and the computer
thrashes as xinetd logs error messages to /var/log/messages. I am quite
surprised to hear that you cannot recreate this problem. I have verified it on
four different computers. I am curious to know if I am missing or doing
Bero, have you seen this? It seems pretty bad for KDE, but I'm not at all sure
fam is to blame.
Haven't seen this (guess nobody tried using tcp wrappers with fam yet).
Does upgrading xinetd to the version from rawhide fix this?
On the first look, this seems to be an xinetd/libwrap issue.
Bero, I'm not sure at all the fam message has anything to do with it. I get that
all the time, and fam still works. We traced it once, and it was some problem
with xinetd and wait = yes RPC services, where it looked at the listening
instead of the connected socket.
Thist problem should be fixed in xinetd 2.3.4-0.8