FileZilla Forums

Hi,

today i got prompted to update to 3.54.1 – and i did.

I clicked on changelog and it opened

https://filezilla-project.org/versions. ... 2&product=

...therefore i guess before the update i was using 3.52.2.

Since I updated i get lots of

TLS session resumption on data connection failed. Closing control connection to start over.

Looking at the changelog i assume this is related to

3.53.0-rc1 (2021-03-05)
New features:
Require explicit confirmation on FTP servers not supporting TLS session esumption on the data connection

Any ideas what i can do to fix this problem? right now i have to babysit the uploads to reconnect, then requeue all failed uploads which is quite cumbersome.

it seems to happen once i transmit a large file which takes long enough for the connection to end, then once the large transmition finishes the next one fails and all others fail too

The mentioned change does not have anything to do with it. It only concerns connections to servers not supporting TLS session resumption at all and require confirmation from the user. It would trigger a confirmation dialog in that case, not an error.

That being said, I'm getting that error, too, the last few versions. I'm experiencing it with one server I use, but not with FileZilla Server. My suspicion is that it could have something to do with TLS 1.3, as FileZilla Server uses only TLS 1.2 so far.

Could you please check if you are using TLS 1.3 with your server? Click the lock icon in the status bar and check the Protocol entry at the bottom.

boco wrote: ↑

2021-06-19 00:41

The mentioned change does not have anything to do with it. It only concerns connections to servers not supporting TLS session resumption at all and require confirmation from the user. It would trigger a confirmation dialog in that case, not an error.

Ah, OK, did not know that.
Well, it still could be, that this feature introduced a bug as a side effect. After all, thematic, it seems pretty close to me, and it never happened for me in 3.52.2 but happens almost every time with 3.54.1 (basically every time I transmit more than a few files)

boco wrote: ↑

2021-06-19 00:41

Could you please check if you are using TLS 1.3 with your server? Click the lock icon in the status bar and check the Protocol entry at the bottom.

TLS 1.0

Closing the control connection as result of a failed resume on a server supporting resume is part of the explicit confirmation feature.

If you experience this issue it means that your server isn't properly caching sessions, discarding the prematurely and probably even sharing them between unrelated control connections.

botg wrote: ↑

2021-06-21 11:39

Closing the control connection as result of a failed resume on a server supporting resume is part of the explicit confirmation feature.

If you experience this issue it means that your server isn't properly caching sessions, discarding the prematurely and probably even sharing them between unrelated control connections.

I am a bit confused, sorry. If I understand you correct, you are trying to tell me, that its the servers fault that filezilla became unusable after upgrading filezilla?

I fail to see how it became unusable. It even detects the faulty server behavior and reconnects automatically.

In my case, all transfer after that fail as well. The recovery by closing and reconnecting is unsuccessful.

(Unfortunately, FileZilla Server is only TLS 1.2 and I don't have any other TLS 1.3 server for testing if it is TLS 1.3 or not. Hopefully, the new FileZilla Server will arrive soon.)

botg wrote: ↑

2021-06-22 07:41

I fail to see how it became unusable. It even detects the faulty server behavior and reconnects automatically.

well, as I wrote in the initial Posting:

Guenther80 wrote: ↑

2021-06-18 16:14

...
once the large transmition finishes the next one fails and all others fail too

this results in transmitting 680 files taking something like 4 hours, since I have to baby sit Filezilla and reconnect all the time, adding failed transmissions again, start queue again, and often it does not work, then reconnect again, etc etc.
This should not take 4 hours. Before the update it was 10 Minutes, without baby sitting.

I hope this explains how this makes Filezilla unusable for me since this update.

boco wrote: ↑

2021-06-22 17:09

In my case, all transfer after that fail as well. The recovery by closing and reconnecting is unsuccessful.

That's a server bug, you should report it to your server vendor.

Guenther80 wrote: ↑

2021-08-15 19:09

once the large transmition finishes the next one fails and all others fail too

Very much sounds like the same server-side bug.


Which FTP server software are you both using?

I experienced the problem with my ProVide Server. For now, I'm using FileZilla Server 1.x for the FTP(S) and ProVide for the other protocols (WebDAV, SFTP, HTTPS), which works fine.

Looks like I'm about the only ProVide customer still using FTP with it. Should write a support email, soon.

I have a same problem with new update of FileZilla...

I need to transfer a lot of files to my web-site... Sometimes I left FileZilla to transfer overnight.

But, with new update the transfer stops, but not close connection... just try and try to connect... but without success... non-stop.

And, I must close the FileZilla, and start again.
And I got same ERROR again...

This is what I got...
...............
TLS session resumption on data connection failed. Closing control connection to start over.
File transfer failed.
Waiting for replies to skip before sending next command...
--------------
and this repeat over and over...

Before new update I have NO PROBLEMS with uploads.

I can not use FileZilla anymore!

That's a server bug, you should report it to your server vendor.

We have the exact same problem. We use Serv-U as a server. With other clients this error does not occur but only with FileZilla.

Other clients are insecure, they don't care if your data gets stolen, that's why you don't get an error with them.

botg wrote: ↑

2021-10-15 07:23

Other clients are insecure, they don't care if your data gets stolen, that's why you don't get an error with them.

Forgive me however you say that it is a server bug (with more than one server it occurs), then you say that the other clients with which the problem does not occur is because they are not safe.

Can you explain the cause of this message, it seems to be related to security can you explain what the server is wrong?