Launchpad has imported 13 comments from the remote bug at
https://bugzilla.mozilla.org/show_bug.cgi?id=478322.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
On 2009-02-13T02:25:45+00:00 quendi wrote:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6)
Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.6)
Gecko/2009020911 Ubuntu/8.04 (hardy) Firefox/3.0.6
during the past months various FTP servers have changed their behavior
how to shut down encrypted connections. this has been inspired by a
change in the filezilla ftp client implementation, see http://forum
.filezilla-project.org/viewtopic.php?f=2t=7688
vsftpd since version 2.0.7 also changed the way tls connections are closed.
since then fireftp, a popular ftp addon for firefox, is awfully slow. this has
been reported here: https://www.mozdev.org/bugs/show_bug.cgi?id=20043
since fireftp uses the mozilla framework for ssl bugzilla.mozilla.org is the
right place to report the bug.
from what i've seen the problem is as follows:
# fireftp opens an encrypted connection
# command channel (e.g. authentication or noop) works fine
# when you do a directory listing or file transfer it opens a new data
connection using passive ftp
# the server replies with the requested data on the new conncetion and sends a
tls close notify
# fireftp simply acks this and waits for more data
# after 5 minutes the server times out and sends a fin/ack packet
# fireftp closes the connection using fin/ack and finally displays the
directory / dowloads the file
this means you have to wait 5 minutes for each directory listing or file
transfer!
i'll attach an decrypted wireshark screenshot of the data connection
Reproducible: Always
Reply at:
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/308952/comments/6
On 2009-02-13T02:27:28+00:00 quendi wrote:
Created attachment 362167
wireshark screenshot of the data connection
Reply at:
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/308952/comments/7
On 2009-02-13T16:24:55+00:00 Bugzilla-tf wrote:
Does this happen without Fireftp ?
If not: what is Fireftp doing different from the Mozilla ftp implementation ?
Example FTP URL ?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/308952/comments/8
On 2009-02-13T17:44:21+00:00 quendi wrote:
(In reply to comment #2)
Does this happen without Fireftp ?
it can't happen without fireftp since firefox only offers a standard
(non ftps) client.
If not: what is Fireftp doing different from the Mozilla ftp
implementation ?
don't know, this is what the fireftp maintainer says at
https://www.mozdev.org/bugs/show_bug.cgi?id=20043
FireFTP just runs off of the Mozilla APIs as far as sockets and SSL and the
like is concerned. This sounds like something that should be handled at that
level.
Example FTP URL ?
you could try lnxnt.org, it runs vsftpd 2.0.7 and currently has tls for
anonymous users enabled.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/308952/comments/9
On 2009-02-13T17:54:22+00:00 Bugzilla-tf wrote:
We don't accept extension bugs in bugzilla unless the developer of that
addon explains what he is doing. Only with this information a Gecko
developer can deceide if the bug is valid. You can't expect that our
developers waste their time with digging through every addon that gets
reported here and 90% of such issues are bugs in the addon itself.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/308952/comments/10
On 2009-02-13T21:10:41+00:00 Mimecuvalo wrote:
Matthias,
I'm the developer of FireFTP. Sorry for not weighing in earlier.
The code in question is here:
http://www.mozdev.org/source/browse/fireftp/src/content/js/connection/dataSocket.js?rev=1.52
Basically, all FireFTP does is, when it comes to SSL sockets:
this.dataTransport = this.transportService.createTransport([ssl], 1,
this.host, this.port, proxyInfo);
There isn't anything that the extension does beyond that in messing
around with the socket. It seems that something underlying in Mozilla's
socket code is conflicting with vsftpd patched code.
Is vsftpd at fault or is Mozilla code at fault? I'm not sure - I think
a networking engineer at Mozilla might need to take a look.
FWIW, my guess is this bug should be filed under Core-Networking.
Reply at:
