FileZilla Forums

Since filezilla also was linked against gnutls 3.6.5 and uploading didn't work I don't think it will start working with 3.6.6.

Oh btw I forgot about another "client": Uploading with PHP also does work. That was actually one of my first tests.

edit: and via curl it doesn't work. So I'm back to square one.
edit2: However with curl it's behaving a little bit different. Filezilla upload terminates at 16k. Curl upload terminates just before the end.

Strange, FileZilla 3.40 should link against 3.6.6, not 3.6.5...

I'm testing on fedora 29. Fedora 29 is shipping gnutls 3.6.5 so filezilla is linked against that.

Depending on the changes between them, the problem could have something to do with it.

I am using FileZilla on Windows 10 and have the same problem. So the GnuTLS Version does not seem to solve the problem.

It seems that it's something that FileZilla does with the connection.

Unless somebody can explain to me why the server says it lost its link to the file server, there's nothing on my end to do.

This can happen if for example not all data has been read from the socket but the socket gets forcefully closed. e.g. In TLS 1.3 (at least with openssl) per default two session tickets gets send during the handshake. During uploading data sockets usually don't need to be read from which upon finish causes the socket to be forcefully closed (serverside receives econnreset). For example this bug I've fixed in PHP: https://bugs.php.net/bug.php?id=76972

This is just an example why the server may answer with "link to file server lost" with TLS 1.3 enabled. Haven't digged into the filezilla source yet, I ran out of time.

@botg So the issue is really as described. If I remove the close call in socket_thread::close_socket_fd (and therefor leaking the fd) the upload succeeds. FileZilla is hard closing the socket without doing the full bidirectional shutdown. I can try to find out what's the best location to fix this but most certainly you will do a better job at this.

Hey, @manuel I just cloned and recompiled proftpd from git and everything seem to work perfectly with FZ 3.40. However, I've lost my trust and respect to these ftpd authors so I gave up ftp for awhile and use sftp instead for the time being. A little bit slow especially when deleting lol but its working for now...

FTR: This got fixed with 3.41.1: https://svn.filezilla-project.org/filez ... ision=9128 - Thanks @botg

manuel wrote: ↑

2019-04-25 08:12

FTR: This got fixed with 3.41.1: https://svn.filezilla-project.org/filez ... ision=9128 - Thanks @botg

That didn't fix the server-side bug. The server-side bug is just less likely to be triggered.

Sorry for the bump but I would like to know the outcome of this server-side issue? Did it got fix recently or is it still there? I would love to use FTP again because this asshole cPanel is hiking their new pricing model. I swear I will install an FTP server and administer my own system manually.

I think you need to ask the server software creators, not us?