Your message dated Wed, 17 Mar 2010 14:46:08 -0400 (EDT)
with message-id
<1970009957.19842351268851568456.javamail.r...@md01.wow.synacor.com>
and subject line Closing bug report
has caused the Debian Bug report #574373,
regarding Found a solution to bug #377020
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
574373: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574373
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: lftp
Version: 3.7.3-1
I stumbled across the symptoms of bug number 377020 today.
A search of the internet is how I found the above bug report.
I was disappointed to find that there was no resolution.
The bug was closed because the problem could be reproduced
with another ftp client as well. But the server in both cases
was vsftpd, which is the same server that I am using. I
searched bug reports for vsftpd in vain for a resolution.
To reiterate, the symptom was
ls: Fatal error: gnutls_record_recv: A record packet with illegal version
was received.
in response to a "dir" command.
I experienced this same error today, trying to connect to vsftpd from lftp
with a secure connection (FTPS). Fortunately, I found a solution.
Here are the relevant lftp variable settings that I was using.
ftp:passive-mode on
ftp:ssl-allow yes
ftp:ssl-auth TLS
ftp:ssl-data-use-keys false
ftp:ssl-force yes
ftp:ssl-protect-data true
ftp:ssl-protect-list true
ftp:ssl-use-ccc false
ssl:ca-file /etc/ssl/certs/ca-certificates.crt
ssl:check-hostname true
ssl:verify-certificate true
Any variables not mentioned above may be assumed to be either not
relevant to this discussion or else have their default values.
I was doing "server authentication only". I.e. the client did not
have its own certificate. Only the server used a certificate.
With the above settings I attempted to connect to a vsftpd server,
login with a non-anonymous userid and password (the id is a local
user) and issue the "dir" command. The command failed with the
error symptom above.
To make a long story short, the key to solving the problem was the
ftp:ssl-data-use-keys variable. According to the help file, a
value of "true" causes the ssl:key-file to be used for the data
connection. Since I was doing server authentication only, there
is no value set for ssl:key-file. Therefore, I assumed that "false"
was the correct value to set in this situation. But I was wrong.
It turns out that setting this variable to true (the default value)
causes the "dir" command to work just fine. Setting it to false
causes the above failure. This is not intuitive! I would have
appended this entry to bug report 377020 if I could have. But
this bug report has been archived, and no changes can be made.
I don't know if this is the exact same scenario that the original
poster experienced, but maybe it will help someone. Perhaps whatever
other ftp client the OP tried, he made an analogous setting to
a similar client configuration variable, and got a similar result.
Thus, he concluded a bug in vsftpd.
--
.''`. Stephen Powell <[email protected]>
: :' :
`. `'`
`-
--- End Message ---
--- Begin Message ---
Closing, as the solution was given in the original report.
--
.''`. Stephen Powell <[email protected]>
: :' :
`. `'`
`-
--- End Message ---
