Error sending PROT P command in Explicit TLS/SSL connections
|Reported by:||pi72||Owned by:|
|Keywords:||Cc:||pi72, peter_daum, m_beli, Tim Kosse|
|Component version:||Operating system type:|
|Operating system version:|
Error sending PROT P command in Explicit TLS/SSL
This bug *may* be the same as 906633, 965367 and 1143883.
Symptoms: FileZilla connects using Explicit TLS or SSL
connection but fails to get a directory listing.
Version: FileZilla 2.2.10 trying to connect to a
Description: With the help of the guy running the
server, we traced down the problem to be with the order
of login and sending the PROT P command. In other
clients like CuteFTP Pro, the client first logs in and
then issues the command PROT P, which is accepted. With
FileZilla, it first issues the command PROT P, which is
rejected, and then logs in. FileZilla then fails to
retrieve a file listing. Although then you can manually
issue PROT P or PROT C commands and they are accepted,
you can't still get a file list.
Configurations tried: Using port 21, this exact problem
happens with both active and passive mode, and with
both "FTP over SSL (explicit encryption)" and "FTP over
TLS (explicit encryption)". Also tried disabling
compression, which seems to have nothing to do with
Comments: Apparently FileZilla doesn't know how to
handle the transfers after PROT P being rejected. This
might need to be handled. Although I'm not aware of how
the Explicit TLS/SSL connection standard describes the
adequate process of connection, it might be worth it to
place somewhere an option to send PROT P before or
after the login for these kind of connections. Another
option would be resending PROT P *after* the login in
the case it was rejected when sent before it.
Attachment: A log with Trace and Show Listings enabled.
Host details have been removed for privacy. The two
last commands were sent manually to show their results
after the login.