From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Description of problem: Prior to update, I had vsftpd running fine with TLS. This was enabled in /etc/vsftpd/vsftpd.conf: ssl_enable=YES After upgrade, vsftpd 2.0.1-5 was replaced with 2.0.1-5.EL4.3. Connecting to ftp then fails for all users, as follows (real domain and IP address replaced): === *** CuteFTP 7.0 - build Mar 10 2005 *** STATUS:> Getting listing ""... STATUS:> Resolving host name ftp.example.com... STATUS:> Host name ftp.example.com resolved: ip = 10.10.10.10. STATUS:> Connecting to FTP server ftp.example.com:21 (ip = 10.10.10.10)... STATUS:> Socket connected. Waiting for welcome message... 220 Welcome to ftp server. STATUS:> Connected. Authenticating... COMMAND:> AUTH TLS 234 Proceed with negotiation. STATUS:> Establishing SSL session. STATUS:> Initializing SSL module. STATUS:> Connected. Exchanging encryption keys... Session Cipher: 128 bit RC2 STATUS:> SSL Connect time: 241 ms. STATUS:> SSL encrypted session established. COMMAND:> PBSZ 0 200 PBSZ set to 0. COMMAND:> USER bstest 331 Please specify the password. COMMAND:> PASS ***** ERROR:> Can't read from control socket. Socket error = 0. === Reverting back to version 2.0.1-5 resolves the issue. Version-Release number of selected component (if applicable): 2.0.1-5.EL4.3 How reproducible: Didn't try Steps to Reproduce: 1. Setup vsftpd 2.0.1-5 with "ssl_enabled=YES" in /etc/vsftpd/vsftpd.conf. 2. Update to vsftpd 2.0.1-5.EL4.3. 3. Connect with TLS-aware client, such as CuteFTP. Actual Results: Get error message saying: ERROR:> Can't read from control socket. Socket error = 0. Cannot proceed after that. Expected Results: Should connect to FTP server and see directory listing. Additional info:
Strangely I can't reproduce the issue. Also I went through the patches I added to the RHEL4 version and there shouldn't be changes related to this (there were mainly changes related to new pam module). New RHEL4 Update will bring you vsftpd-2.0.1-5.EL4.4. Please retest with this package.
This new version (pulled from fasttrack, as Update 4 does not seem to be ready) appears to have resolved the problem. Thank you!
This bug has been fixed in RHEL4 Update 4.