Upload timeout after 80kib when using TLS

[nubix]

@boco you are right, the problem is caused by a change in GnuTLS

but reading the details it seems it's a feature and not a bug (so when my understanding is right, then filezilla needs to follow the change..)
- see here: https://savannah.gnu.org/support/?107660
- quote from #3 "gnutls 2.12.0 changed the semantics of gnutls_transport_set_lowat() and the default value is zero."
- and from #5 "We could fix it in gnutls 2.12.x and restore the old default, but we'll just postpone the inevitable for the next release that abolishes that functionality."

[boco]

http://forum.filezilla-project.org/view ... 140#p97140

[neuropa]

http://forum.filezilla-project.org/view ... 140#p97140

We all look forward to a solution for this problem.
In this moment FileZilla isn't supported on Ubuntu distribution.

Thank you!

[DoughPro]

I am also affected by this. Is there a Filezilla patch on the way?

[botg]

I'm currently working on some TLS problems. Might also fix what you are experiencing.

[DoughPro]

I'm currently working on some TLS problems. Might also fix what you are experiencing.

Great! I'll be happy to try it out.

[rongrimes]

I also found the same problem today on my office computer. Mostly the same configuration, but in my case, Filezilla hung at the 212kB point.

I'm not on my work computer now, but some relevant release stuff:
OS: Mint 13
Filezilla: 3.5.? (Latest from Mint)
Server FTP: proftpd
server OS: Ubuntu 12.04 LTS
FTP: FTP over TLS/SSH

Filezilla works fine for files < 212kB.

Happy to test a beta release.

[boco]

First, check if the fix you desire is already in the code here: http://filezilla-project.org/changelog.php
Then, if it is, you can test beginning from the next Nightly build: http://filezilla-project.org/nightly.php

[rongrimes]

Thanks boco. The change-log hinted the TLS problem was fixed so I retrieved & ran last night's update. It still hangs at 212kB.

(Is there a better place to continue this dialogue?)

FileZilla Client
----------------

Version: 3.5.3-nightly

Build information:
Compiled for: x86_64-pc-linux-gnu
Compiled on: x86_64-unknown-linux-gnu
Build date: 2012-10-05
Compiled with: x86_64-linux-gnu-gcc (Debian 4.4.5-8) 4.4.5
Compiler flags: -g -O2 -Wall -g -fexceptions -std=gnu++0x

Linked against:
wxWidgets: 2.8.12
GnuTLS: 2.12.14

Operating system:
Name: Linux 3.2.0-23-generic x86_64
Version: 3.2

[xeon]

This upload issue sounds strange, I haven't ever noticed that.

[botg]

@rongrimes: Try GnuTLS 2.12.x with x >= 16 or GnuTLS 3.0.x with x >= 11. The bug that affects you might be http://savannah.gnu.org/support/?107929

[rintoslo]

I observe the bug too (after 163.840 bytes) but even with GnuTLS 2.12.20 installed from Debian
ord GnuTLS 3.0.11.
checked out a svn version but that still doesnt resolve the problem (it shows 2.12.20 as version there too)

seems to be the code still has to be fixed to work with 2.12 or 3.0 versions
i didnt find "fixed" code like stated in https://savannah.gnu.org/support/?107660
in a search in filezilla cpp files

1. Quick fix. Programs that require another value must explicitly call:
gnutls_transport_set_lowat (session, 1)

2. Long-term fix. Because later versions of gnutls abolish the functionality of using the system call select() to check for gnutls pending data, the function
gnutls_record_check_pending()
has to be used to achieve the same functionality.

[botg]

Regarding lowat, FileZilla doesn't need a value other than 0. In fact it actively requests a value of 0 if gnutls_transport_set_lowat is available.

[nubix]

thanks a lot for fixing this!
(for me the problem is solved with version 3.6.0.2)