Comment 3 for bug 20358

I am not sure whether I should report this against lftp or gnutls11, I just
decided for lftp, because on my hoary installation, with the same libgnutls11,
lftp works (however ldd shows it's not even linked against it. Oh well...). If
you think it's wrong, move it or something.

lftp :~> open <email address hidden>
Password:
lftp <email address hidden>:~> ls
-rwxrwxr-x 1 fanopanic fanopanic 6070281 Jun 18 10:23 first_file_in_directory
ls: Fatal error: gnutls_record_recv: A TLS packet with unexpected length was
received.
lftp <email address hidden>:~>

with "ls" lftp always prints the first line, and then the error occurs. The
attempt to tab-complete a directory just fails. I can however GET a file, or
RMDIR a directory, if I know their names.

ftp without TLS/SSL works.

Locally I run Breezy (2.6.12-7-k7),

On the server runs ProFTPD Version 1.3.0rc2 with essentially:
<IfModule mod_tls.c>
TLSEngine on
TLSRequired ctrl
TLSProtocol SSLv23
</IfModule>

The tls.log there only says:
Aug 25 03:33:31 mod_tls/2.1[10109]: using default OpenSSL verification locations
(see $SSL_CERT_DIR)
Aug 25 03:33:31 mod_tls/2.1[10109]: TLS/TLS-C requested, starting TLS handshake
Aug 25 03:33:31 mod_tls/2.1[10109]: TLSv1/SSLv3 connection accepted, using
cipher AES256-SHA (256 bits)
Aug 25 03:33:31 mod_tls/2.1[10109]: Protection set to Private
Aug 25 03:33:31 mod_tls/2.1[10109]: starting TLS negotiation on data connection
Aug 25 03:33:31 mod_tls/2.1[10109]: TLSv1/SSLv3 data connection accepted, using
cipher AES256-SHA (256 bits)

I can't test it with other TLS-servers, because I have no other accounts.
If you need anything, just shout. I will add some tcpdump output tomorrow.