FireFTP(Mozilla) cannot LIST files

[Martijn Kaandorp]

Binary package hint: vsftpd

serverside ubuntu intrepid ibex:
vsftpd (2.0.7-0ubuntu1)
libgnutls-dev (2.4.1-1ubuntu0.2)

clientside: windows xp
FireFTP (Mozilla)

FireFTP is able to login via Auth TLS (best), but cannot LIST files.
Is there a configuration problem or GnuTLS implementation issue?

[Martijn Kaandorp (m.a.j.w.kaandorp)]

libgnutls-dev (2.4.1-1ubuntu0.2) is NOT installed!!!

The used openssl version is 0.9.8g-10.1ubuntu2

[João Pinto (joaopinto)]

On the server install the ftp-ssl package, login to the server with:
ftp -z ssl localhost
If you can login with the plain ftp, it's a FireFTP addon problem, you should follow up from http://fireftp.mozdev.org/developers.html, fireftp is not provided as an ubuntu package.

Thanks

[Martijn Kaandorp (m.a.j.w.kaandorp)]

Hi,

I now have tried standard ftp and I am experiencing the same problems, so it is not the ssl part.
I can list files and directories, but not during a file transfer. With gutsy and the same vsftpd configuration i had no problems.

[Martijn Kaandorp (m.a.j.w.kaandorp)]

Here is a filezilla log of a standard ftp session. During file transfer the LIST command results in a disconnect from
server. The file transfer however continues and is finally aborted by me.

Status: Resolving IP-Address for dom
Trace: ControlSocket.cpp(979): CRealControlSocket::ContinueConnect(0x8a3cf98) m_pEngine=0x87898f0 caller=0x8a61828
Status: Connecting to 192.168.1.67:21...
Status: Connection established, waiting for welcome message...
Trace: CFtpControlSocket::OnReceive()
Response: 220 Welcome to Exetron's FTP service.
Trace: CFtpControlSocket::SendNextCommand()
Command: USER exetron
Status: Connection established, waiting for welcome message...
Trace: CFtpControlSocket::OnReceive()
Response: 331 Please specify the password.
Trace: CFtpControlSocket::SendNextCommand()
Command: PASS ********
Trace: CFtpControlSocket::OnReceive()
Response: 230 Login successful.
Trace: CFtpControlSocket::SendNextCommand()
Command: OPTS UTF8 ON
Trace: CFtpControlSocket::OnReceive()
Response: 200 Always in UTF8 mode.
Status: Connected
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Retrieving directory listing...
Trace: CFtpControlSocket::SendNextCommand()
Trace: CFtpControlSocket::ChangeDirSend()
Command: PWD
Trace: CFtpControlSocket::OnReceive()
Response: 257 "/"
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::ParseSubcommandResult(0)
Trace: CFtpControlSocket::ListSubcommandResult()
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Status: Directory listing successful
Status: Resolving IP-Address for dom
Trace: ControlSocket.cpp(979): CRealControlSocket::ContinueConnect(0x8a36480) m_pEngine=0x8838a58 caller=0x8aa43c8
Status: Connecting to 192.168.1.67:21...
Status: Connection established, waiting for welcome message...
Trace: CFtpControlSocket::OnReceive()
Response: 220 Welcome to Exetron's FTP service.
Trace: CFtpControlSocket::SendNextCommand()
Command: USER exetron
Status: Connection established, waiting for welcome message...
Trace: CFtpControlSocket::OnReceive()
Response: 331 Please specify the password.
Trace: CFtpControlSocket::SendNextCommand()
Command: PASS ********
Trace: CFtpControlSocket::OnReceive()
Response: 230 Login successful.
Trace: CFtpControlSocket::SendNextCommand()
Command: OPTS UTF8 ON
Trace: CFtpControlSocket::OnReceive()
Response: 200 Always in UTF8 mode.
Status: Connected
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::FileTransfer()
Status: Starting download of /pub/linux/distros/ubuntu/ubuntu-8.10-desktop-i386.iso
Trace: CFtpControlSocket::SendNextCommand()
Trace: CFtpControlSocket::ChangeDirSend()
Command: CWD /pub/linux/distros/ubuntu/
Trace: CFtpControlSocket::OnReceive()
Response: 250 Directory successfully changed.
Trace: CFtpControlSocket::SendNextCommand()
Trace: CFtpControlSocket::ChangeDirSend()
Command: PWD
Trace: CFtpControlSocket::OnReceive()
Response: 257 "/pub/linux/distros/ubuntu"
Trace: CFtpControlSocket::ResetOperation(0)
Trace: CControlSocket::ResetOperation(0)
Trace: CFtpControlSocket::ParseSubcomman...

[Martijn Kaandorp (m.a.j.w.kaandorp)]

Hello, i reverted back to FileZilla_3.0.7.1_i586-linux-gnu.tar.bz2 and it is working fine now. No more strange screen artifacts and unresponsive gui.

[quendi (quendi)]

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=2&t=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

[quendi (quendi)]

Created attachment 362167
wireshark screenshot of the data connection

[Bugzilla-tf (bugzilla-tf)]

Does this happen without Fireftp ?
If not: what is Fireftp doing different from the Mozilla ftp implementation ?
Example FTP URL ?

[quendi (quendi)]

(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.

[Bugzilla-tf (bugzilla-tf)]

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.

[Mimecuvalo (mimecuvalo)]

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.

[Lox-f (lox-f)]

Any new about that bug? I have setup a hosting server based on vsftp and I allow only TLS connections to it. So none of my clients can use fireftp....

Filezilla works nice with it....

[Chuck Short (zulcss)]

Looks like a client problem.

[Lox-f (lox-f)]

(In reply to comment #5)
> Basically, all FireFTP does is, when it comes to SSL sockets:
> this.dataTransport = this.transportService.createTransport(["ssl"], 1,
> this.host, this.port, proxyInfo);

Why do you force passive mode for TLS/SSL connections?

I think it may work without passive mode, may you have a try?

[Lox-f (lox-f)]

Anybody watching bugs here?

[Mimecuvalo (mimecuvalo)]

I'm watching this bug but I'm not one who could fix this. Somebody from Mozilla needs to look into it.

[Q-maniac (q-maniac)]

Hi, I have also problem with FireFtp connecting to FTP+TLS server. I can provide Mozilla team with FTP+TLS testing account and extensive debugging outputs if required.

[Lox-f (lox-f)]

A year ago that bug was reported and documented but:

1- it is still at the UNCONFIRMED state

2- nobody at Mozilla seems to have had a look at it

When will firefox properly implement ftp over ssl/tls? Is it planned?

[Donovan Cameron (sault-don)]

November 2012 and this problem is still there with fireftp when using "Auth TLS(Best)"

After the 5min timeout, vsftpd outputs the following error:

522 SSL connection failed; session reuse required: see require_ssl_reuse option in vsftpd.conf man page
421 Data timeout. Reconnect. Sorry.

But I have require_ssl_reuse=YES and tried NO in my vsftpd.conf file, but it doesn't seem to matter for fireftp. FileZilla works great either way.

Almost a year since the last post on this bug, is there any hope of it getting fixed?

[mmalmeida (mmalmeida)]

My team is experiencing the same problem, which seems to render fireFTP useless.

Any idea what is keeping this from being fixed?

[moenchmeyer (rm-anracon)]

This annoying problem still exists

[Patrick McManus (mcmanus-ducksong)]

We are in a period where ftp is clearly deprecated and in general, making changes to the code is riskier than letting it ride unless there is a patch and reviewer available to make a good judgment about it. So I'm going to wontfix ftp bugs related to enhancements, interop errors, etc.. We will be better off putting our energy into including a different js based ftp stack.

[Patrick McManus (mcmanus-ducksong)]

ignore comment 15 - this bug wasn't supposed to be in that list

[Bug-husbandry-bot (bug-husbandry-bot)]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

[Gijskruitbosch+bugs (gijskruitbosch+bugs)]

FireFTP is no longer supported.