Hi,
It is still a DNS problem i beleive, not on the client side, but on the
server side: the ftp server tries to reverse lookup the incoming address
to log it probably and so hang on that. Check if 192.168.0.3 is resolvable
on the server side. (host 192....)
Hope this help,
JeF
On Thu, 27 Sep 2001, Minh Van Le wrote:
> My CuteFTP sessions hang or timeout during the handshake to a linux
> host.
>
> It could be DNS/hostname related. I'm not sure. nslookups to the target
> host always return the same interface, even though there are two
> interfaces - so the proportion of connection problems to the probability
> of hitting the right interface doesn't suggest that it is DNS/hostname
> related. The status messages in CuteFTP clearly say it's connecting to
> 200.0.0.2, which is right. The source is 192.168.0.3 however.
>
> I've checked hosts.{allow,deny} and it checks out. I've also disabled
> firewalls. There's nothing in the syslogs to suggest a problem.
> CuteFTP just sits there indefinitely on trying to establish a socket to
> one of my linux hosts.
>
> The socket is established properly immediately after a 2nd retry, and
> successive reconnects. But if a socket hasn't be established for 10 or
> 15 minutes, CuteFTP hangs again.
>
> "STATUS:> Socket connected. Waiting for welcome message ..."
>
> I'm using Redhat 7.1.
>
> Is it a tcpwrapper thing ? something to do with TCP streams and xinetd
> firing child processes to accomodate the connection ?
>
> I haven't tried running a standalone instance of FTP. Maybe that'd help.
>
> Are there other ways to debug these sorts of problems ? Should I use
> tcpdump ?
>
>
>
> --
> SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
> More Info: http://lists.slug.org.au/listinfo/slug
>
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://lists.slug.org.au/listinfo/slug