On 2004-05-17, Matthias Hupp <mhupp.nospampls@gmx.de> wrote:

> The ftp server on a web/mail/inet-gateway machine I am taking care of can
> no longer be accessed, ever since one of the secretaries decided to
> switch it off and on again because she could not access her files on a
> Windows server. I have made some changes on the ipchains rules since
> then, but ftp is open on the internal interface.
>
> Anyway, access is possible neither from the LAN, nor from the machine
> itself when I am logged on via ssh.
>
> I get this message on the shell:

> ftp: connect to address ::1: Connection refused

> May 17 13:01:01 server ftpd[12726]: getpeername (in.ftpd): Transport
> endpoint is not connected
> May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
> May 17 13:01:01 server in.ftpd[12727]: warning: can't get client address:
> Invalid argument

> May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
> May 17 13:01:01 server inetd[813]: ftp/tcp server failing (looping),
> service terminated
> ***
>
> ... repeated over and over again, with rising pids.
> Trying other ftp servers (by changing inetd.conf) resulted in the same,
> with in.ftpd changed to proftpd etc.
> BTW, the name of the machine is included in /etc/hosts.


Hmmm...you say you changed FTP servers, but what about removing tcpd out of
the mix? It seems like something's going on with it, possibly something to
do with what's in /etc/hosts.deny/allow? The tcpd server can be compiled
with different security flags on by default, on up thru "paranoid", which
may also play a part (this is in the tcpd man page). You said you ssh'ed in-
what about if you sit down at the server and connect localhost - localhost,
no ssh involved? I'd turn up the debugging features on the ftp server,
verify that it was operating correctly, then work backwards from there. I'm
curious about tcpd being removed. "Transport endpoint is not connected" is a
very popular error message which usually means that the target machine can't
be reached- either due to some phyiscal reason, or, possibly here, a bad
allow/deny rule. You may want to try a few runs of tcpdmatch:

tcpdmatch -i /etc/inetd.conf in.ftpd <address to check out>

Listing your iptables rules might shed some light too.

Sorry I can't say without a doubt what it is, but maybe something I touched
on here might get you looking in the right place.




--
[jayjwa]======[SkyNet.cz]SystemsMutex===VxL@Atr2====