Ftp – FileZilla could not send reply

ftp

I have an automated FTP process that runs at night to a FileZilla server on a windows XP box. The FTP traffic comes from an automated FTP client on a proprietary health care server (Meditech Magic). Sometimes the transfer works fine and sometimes it fails. This is all within our LAN, and the XP firewall is turned off.

Any ideas?

This is the filezilla log:

> Connected, sending welcome message...
> 220 M
> could not send reply, disconnected.

This is the client log:

RESULT: Host response failed: Timed out OPEN

Best Answer

It looks like network problem. Try connecting to other services on same server when this happens (You can share some big dummy file on http server). If the other services fail too then it is most probably network problem.

If hosting other services on same server is not possible. Then use the same ftp client to connect to other ftp servers on Internet to download some test files. Also connect to your ftp server from other locations as clients. If you face problem in one of the two then also it is network problem.

Try running wireshark at both ends to ensure their is no other problem, like bad ARP, etc. that stalls the communication sometimes.

Related Solutions

Firewall – Can explicitly ftps via Filezilla but not from code

Dealing with these types of problems can be difficult because the logs usually tell you only part of what is happening.

Your best bet at this point is to use a packet capture and analysis software (like the most excellent - and free - wireshark) to see what is really going on the wire.

Make sure you capture all the traffic between your machine and the remote system and try to see what difference you can spot between a working connection and your code. That might give you an indication where the problem lies.

Do pay special attention to the way the TLS connection is negociated because it might point out to the actual issue (there is a pretty nice and simple to understand document that can be found at IBM's). For instance:

If the connection stops after certificates have been exchanged, it is an indication that one of the parties cannot verify the other's certificate. This is a quite common source of problem with TLS software, especially when self-signed certificate or private roots are used.
If the connection is broken in the first stage of the handshake, it can be that the client and server cannot agreed on what protocol to use (usually because one of the party restricts itself to "safe" protocols that the other does not support).
If the server has set the "client certificate required" flag, then it could be that you haven't setup a client certificate for authentication.
(etc)

If you see that the TLS channel has been successfully negociated, then you'll have to gring in the big guns: grab the server's private key and decode the TLS traffic. That will only be possible, however, if the TLS connection does not use DH key exchange so first, disable that in your server or client.

Once DH has been deactivated and you have the private key, you can follow the instructions on the Wireshark's wiki page about SSL/TLS which explains the process in quite a bit of details or this blog post that is perhaps a bit easier to follow.

Ftp – vsftpd not responding to LIST

Agree with Luke404. Check that your vsftpd.conf has the following entries configured and your firewall allows the pasv_min & pasv_max port ranges (10000 - 100010 is just an example). Remember to restart the service if changes are made to the conf file.


    pasv_enable=YES
    pasv_min_port=10000
    pasv_max_port=10010
    pasv_address=[Public IP address of your server]

Best Answer

Related Solutions

Firewall – Can explicitly ftps via Filezilla but not from code

Ftp – vsftpd not responding to LIST

Related Topic