Resume downloaded files over 2Gb on ftpes (Auth TLS) connection fails 3.2.4.1

[Smalla]

It seems that the client is trying to resume the transfer from the total bytes of file on server, not on the client.

Server is proftpd and can resume files (other clients working)
Connection is ftpes (AUTH TLS)
Filezilla 3.2.4.1 on Vista_x64

it should use a command like REST 2147473408 (2gb), not REST 12025908427 (this is the total bytes of the file)

Status: Starting download of *.*
Status: Testing resume capabilities of server
Command: PASV
Response: 227 Entering Passive Mode (*.*.*.*,157,203).
Command: REST 12025908427
Response: 350 Restarting at 12025908427. Send STORE or RETRIEVE to initiate transfer
Command: RETR *.*
Response: 150 Opening BINARY mode data connection for *.* (13847051 bytes)
Response: 426 Transfer aborted. Operation not permitted
Error: Server does not support resume of files > 2GB.
Error: Critical error
Status: Disconnected from server
Response: 421 No transfer timeout (300 seconds): closing control connection
Status: Server did not properly shut down TLS connection
Error: Disconnected from server: ECONNABORTED - Connection aborted

[Tim Kosse]

There are many broken servers that do not support resume of files who's filesize exceeds 2^{31 or 2}32.

To check for such broken servers, FileZilla requests a single byte a the end of the file. If the server fails to send exactly one byte, the server does not support resume of files exceeding the boundary.

Your server on the other hand doesn't allow resume, you have to contact the server administrator.

[Smalla]

Actually, I have managed to download the file, with another ftp client (flashfxp), continuing the download that filezilla had begun. checking the file consistency showed no error, so I think, that the server can continue downloadings.

[Roaming Knight]

I think this should be reopened. I have the same problem with resuming transfers over 2GB and other clients work fine. This is not a server issue as suggested above. I am using version 3.2.8.1.

[Tim Kosse]

Response: 426 Transfer aborted. Operation not permitted

Broken server.

[Steve Allison]

​http://tools.ietf.org/html/rfc5246#section-7.2.1

Unless the client specifically closes a TLS session the session should be re-used. TCP connections opening/closing have no bearing on the TLS session.

By default ProFTPd enforces this requirement by dropping new related connections that do not re-use the TLS session.

Filezilla erroneously reports that the server is unable to resume >2GB files when the server denies a new data connection due to attempting to establish a parallel TLS session.

ProFTPd can be configured to break RFC by using this TLSOption, ​http://www.proftpd.org/docs/contrib/mod_tls.html#TLSOptions

TLSOptions NoSessionReuseRequired

This is a workaround for clients mishandling TLS and works around Filezilla's shortcomings.

CuteFTP, FlashFXP, WS_FTP and SmartFTP have shown not to be affected by this bug and do not require any special configuration options in ProFTPd.

Broken client.

[Tim Kosse]

FileZilla did use session resumption since version 3.1.2, ticket is about version 3.2.4.1, comment from stalks is thus false.

[Steve Allison]

Latest Filezilla client (3.14.1) doesn't have this issue, so this should be closed :)

However, so that this ticket remains with the facts. My comment 3 years ago was related to client version 3.2.4.1 and is reproducible from that version.