Discussion topic: It's the server's fault!

[da chicken]

This is the discussion topic for ECONNABORTED: It's the server's fault!

This is probably the best explanation I've seen of what's going on and why so many servers and clients might be broken:

> Links to (on page 2):
>
> http://tools.ietf.org/html/rfc4346#page-27
> http://rfc.net/rfc4217.html#p21
>
> Any thoughts on this?

Now that's interesting. Section 12.6 of RFC 4217 (FTP over SSL/TLS), for
data connections, shows a "passive" shutdown of the SSL session, i.e. the
client shuts down the session (sending a 'close_notify' to the server);
the server does not reply with its own 'close_notify' alert.

_However_, Section 12.3, for the control connection, uses an _active_
shutdown (both client and server send their 'close_notify' alerts) when
the CCC command is used.

Which means, effectively, that the SSL session shutdown behavior is not
consistent; some behaviors lead to an active (bi-directional) shutdown,
some do not. No wonder implementations get this wrong (mod_tls gets it
wrong, as it tries to use the same shutdown sequence for all connections,
be they control, data, or CCC-cleared).

--http://marc.info/?l=proftpd-users&m=121736627908173&w=2

[botg]

The answer is in RFC 4346 which clearly states the following in section 7.2.1.:

Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection

The write side is the server sending the directory listing or the file to the client. RFC 4217 isn't even involved.

[da chicken]

I'm not trying to say you're wrong at all, Tim. Honestly, I don't care who is right or wrong. I just want everyone to agree on reality so things work smoothly.

Additionally, if you are right that failure to send close_notify is a potential security risk, then it doesn't matter if your interpretation of the RFCs is the intended one or not. It should be how things are implemented because it's a security issue.

[boco]

And some server creators have already implemented this fix (or had it right even from the beginning), others will follow, it will be commonly accepted. That's how things work, sometimes you need to force things for the better.

[Panther]

The users of FileZilla usually do not have control of the ftp servers. All that's being forced is for people to either be stuck using old versions of FileZilla (as I am doing) or use a different client. My web browser does not refuse to display a web page simply because there are errors in the HTML code, such as on the SourceForge project page for FileZilla....something you have no control over (yes, I noticed that all your web pages do validate).

[boco]

My web browser does not refuse to display a web page simply because there are errors in the HTML code

You can't compare faulty HTML code to this problem. It's a security hole that has been closed, and I'm sure botg won't make his client insecure again.

[Panther]

You can't compare faulty HTML code to this problem. It's a security hole that has been closed, and I'm sure botg won't make his client insecure again.

It does no harm to FileZilla to allow connections to non-compliant servers. As it is now the current releases of FileZilla are completely useless to a lot of people, which is a shame because besides the disconnect (i.e. the servers like to ignore FileZilla's keep-alive and disconnect the client) and 1GB limitation (on certain servers transfers stop at every 1GB boundry) problems it's a great program.

[botg]

1GB limitation? Again the server's at fault.

[nix4me]

This issue is frustrating indeed. Now we have to wait for new server packages to be made for each distribution which will likely not be for several months.

This issue coupled with the inability of the community to agree on PRET support is maddening!

[botg]

This issue coupled with the inability of the community to agree on PRET support is maddening!

Show me an RFC that implements PRET.

[nix4me]

Yeah, i know there isn't one. But frankly I don't care about RFC's.

A ftp client that works would be preferable to a RFC compliant client that is useless. It's just unfortunate that usability has to suffer due to bureaucracy.

[botg]

Client interoperability cannot work if the extensions are not standardized.

[da chicken]

I'll go out on a limb and say it's neither a server problem or a client problem. It's an RFC problem. Simply speaking, it's a bit ridiculous for FTP to require more than one socket between the server and the client. It's trying to fix an Application layer problem at the Transport layer. It should not surprise anyone that there are endless problems.

[nix4me]

Here is the best the drftpd guys will do:

http://www.drftpd.org/phpBB2/viewtopic. ... light=pret

[botg]

150% bullshit. Examples make no formal specifications. Besides, from what I have seen, some servers seem to require PRET. Such behavior is totally against the FTP specifications, such a servers should NOT be considered to be FTP. One MUST NOT break backwards compatibility.