Custom Query (8042 matches)

A python 2.7 client was able to connect and upload files to my filezilla server 0.9.44 using the following:

sftp = FTP_TLS(SHOUTBOMB_HOST, SHOUTBOMB_USER, SHOUTBOMB_PASSWORD) sftp.login(SHOUTBOMB_USER, SHOUTBOMB_PASSWORD) sftp.prot_p()

put_file(sftp, holds_file, "/Holds/") for f in overdue_files:

put_file(sftp, f, "/Overdue/")

put_file(sftp, renewals_file, "/Renew/")

sftp.quit()

However after updating the server to 0.9.53 we are able to establish a connection however, the file upload is failing. This is the updated python:

sftp = FTP_TLS() sftp.ssl_version = ssl.PROTOCOL_TLSv1 sftp.connect(SHOUTBOMB_HOST) sftp.login(SHOUTBOMB_USER, SHOUTBOMB_PASSWORD) sftp.prot_p()

put_file(sftp, holds_file, "/Holds/") for f in overdue_files:

put_file(sftp, f, "/Overdue/")

put_file(sftp, renewals_file, "/Renew/")

sftp.quit()

Python error we see

Traceback (most recent call last):

File "<stdin>", line 1, in <module> File "C:\Program Files (x86)\Python27\lib\ftplib.py", line 759, in storlines

conn = self.transfercmd(cmd)

File "C:\Program Files (x86)\Python27\lib\ftplib.py", line 376, in transfercmd

return self.ntransfercmd(cmd, rest)[0]

File "C:\Program Files (x86)\Python27\lib\ftplib.py", line 696, in ntransfercmd

ssl_version=self.ssl_version)

File "C:\Program Files (x86)\Python27\lib\ssl.py", line 891, in wrap_socket

ciphers=ciphers)

File "C:\Program Files (x86)\Python27\lib\ssl.py", line 566, in init

self.do_handshake()

File "C:\Program Files (x86)\Python27\lib\ssl.py", line 788, in do_handshake

self._sslobj.do_handshake()

ssl.SSLEOFError: EOF occurred in violation of protocol (_ssl.c:581)

end of python error

Filezilla logs

(000186)11/12/2015 20:38:48 PM - (not logged in) (xxx.xxx.xxx.xxx)> Connected on port 990, sending welcome message... (000186)11/12/2015 20:38:48 PM - (not logged in) (xxx.xxx.xxx.xxx)> SSL connection established (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> USER xxxxxg (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> 331 Password required for xxxxxg (000186)11/12/2015 20:39:32 PM - (not logged in) (xxx.xxx.xxx.xxx)> PASS (000186)11/12/2015 20:39:32 PM - xxxxxg (xxx.xxx.xxx.xxx)> 230 Logged on (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PBSZ 0 (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 PBSZ=0 (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PROT P (000186)11/12/2015 20:39:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 Protection level set to P (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> TYPE A (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 200 Type set to A (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> PASV (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 227 Entering Passive Mode (xx,xx,xx,xx,19,149) (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> STOR chrome_installer.log (000186)11/12/2015 20:40:44 PM - xxxxxg (xxx.xxx.xxx.xxx)> 150 Opening data channel for file upload to server of "/chrome_installer.log" (000186)11/12/2015 20:40:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> 450 TLS session of data connection has not resumed or the session does not match the control connection (000186)11/12/2015 20:44:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> 421 Connection timed out. (000186)11/12/2015 20:44:45 PM - xxxxxg (xxx.xxx.xxx.xxx)> disconnected.

end of Filezilla logs

When downloading large files (1-2 GB) which take quite some time (e.g. several hours at 80 kB/s), they remain in the queue although they have been downloaded completely. Also, the connection seem to be still open.

If I reopen Filezilla and press the "Q->" button, a short transfer will be initiated (about 1 kB) and the file is then successfully removed.

This bug is annoying because the computer would not shut down over night, and if there are many of those files, other queue entries would wait forever for their turn.

Please see ticket: ​http://trac.filezilla-project.org/ticket/3914

This error appears to come from the server side. I'm working o a dedicated server and the timeout for inoperativity is set to 60 seconds (both options).

When downloading a large file which will take more than 60 seconds (normally 1-2 hours), the server appears to have dropped silently the command channel. When the download eventually finishes, the server can't tell the client it has done so, thus the file remains in the queue.

To fix this I believe it is necessary to keep the commend line up and connected as long as the file transfer is in progress. I've tried to disable the timeout, and then it works.