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]> : :' : `. `'` `- -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
