SSL connection only works when debug enabled

[bayblade]

This bug was found in versions 2.2.0 and 2.2.3

It appears FileZilla has a timing/synchronization
problem when using SSL

When connecting via SSL passively to my freebsd server
I repeatedly get the following...

Status: Connecting to www.realdesk.com ...
Status: Connected with www.realdesk.com, negotiating
SSL connection...
Response: 220 www.beq.ca FTP server (Version
6.00LS+TLS) ready.
Command: AUTH SSL
Response: 234 AUTH SSL OK.
Error: Timeout detected!
Error: Unable to connect!
Status: Waiting to retry... (5 retries left)
Status: Connecting to www.realdesk.com ...
Status: Connected with www.realdesk.com, negotiating
SSL connection...
Response: 220 www.beq.ca FTP server (Version
6.00LS+TLS) ready.
Command: AUTH SSL
Response: 234 AUTH SSL OK.
Error: Timeout detected!
Error: Unable to connect!

However when I turn on debugging, I get the SSL popup
immediately and the output looks like this:

Status: Connecting to www.realdesk.com ...
Status: Connected with www.realdesk.com, negotiating
SSL connection...
Response: 220 www.beq.ca FTP server (Version
6.00LS+TLS) ready.
Command: AUTH SSL
Response: 234 AUTH SSL OK.
Trace: Using TLSv1, cipher TLSv1/SSLv3: AES256-SHA,
1024 bit RSA
Status: SSL connection established. Waiting for welcome
message...
Command: USER realdesk
Trace: FtpControlSocket.cpp(578): OnReceive(0)
OpMode=1 OpState=0 caller=0x00b79288
Response: 331 Password required for realdesk.
Command: PASS *
Trace: FtpControlSocket.cpp(578): OnReceive(0)
OpMode=1 OpState=3 caller=0x00b79288
Response: 230 User realdesk logged in.
Status: Connected
Trace: FtpControlSocket.cpp(2877): ResetOperation(1)
OpMode=1 OpState=-2 caller=0x00b79288
Trace: FtpControlSocket.cpp(846): List(FALSE,0,"","",1)

OpMode=0 OpState=-1 caller=0x00b79288

Status: Retrieving directory listing...
Command: PWD
Trace: FtpControlSocket.cpp(578): OnReceive(0)
OpMode=4 OpState=0 caller=0x00b79288
Response: 257 "/home/realdesk" is current directory.
Trace: FtpControlSocket.cpp(846): List(FALSE,0,"","",0)

OpMode=4 OpState=0 caller=0x00b79288

Status: Directory listing successful
Trace: FtpControlSocket.cpp(2877): ResetOperation(1)
OpMode=4 OpState=0 caller=0x00b79288

These behaviours are consistent with whether I have
debugging enabled or not.

[Tim Kosse]

This is strange, turning on the debug settings should not
have any effect. Please try the latest test release from
​http://filezilla.sourceforge.net/FileZilla_setup.exe

[bayblade]

I tried the 2.2.4 beta, as suggested, but I still get no
connection without debugging.

My own experience with different behaviors with debugging
levels enabled is that the minor latencies incurred by the
debugging usually resolves or create a timing/syncronization
problem. This problem may reapper on faster hardware, even
with debugging enabled, but in the meantime, because there
IS a work-around (enable debugging) I'd consider this a
failry low-priority issue (changed to priority 3).

[Tim Kosse]

In the first log you did a timeout error. Does it really
take the amount of time specified until the error appears?
Also, do you have tried to change the timeout value in the
settings dialog?

[bayblade]

Well, where it does the waiting is after the line:

Response: 234 AUTH SSL OK.
and it does run the full (default) 30 seconds

With debugging enabled, the SSL dialog typically appears in
less than 2 seconds.

Since asked, I've changed the timeout in the dialog, to 40
and 60 with no changes in behavior.

OF NOTE: I got a modal, dialog (v2.4.4 beta) with a warning
icon and a single OK button, but NO MESSAGE when the timeout
was less than 30 (Does this warrant another bug submission?)
I'm assuming the message should say "timeout cannot be less
than 30 seconds" or something similar.

[anonymous]

Logged In: NO

I got the same problem in v2.2.6 and solved the connection
problem by enable trace messages from debug settings.

While this cannot make upload/download works. Before real
upload/download, FileZilla send AUTH SSL again and without
trace messages (!) although trace messages setting was still
enabled.

I got no problem at all for v2.2.4b

[Tim Kosse]

This bug report has been closed due to inactivity and has possibly
already been solved.

You can reopen this report if the issue still exists in the
latest version of FileZilla (Server).