Bug 844631

Hello,
thanks for reporting.

I'd like to ask you if you tested another FTP client. I recommend lftp.

Thanks & Best regards

Jiri

Hi,

I have not tested with other FTP client for a reason - not many FTP clients have an interactive shell; in particular, lftp only logs onto the remote server after you actually try to upload/download something, so the situation as I described it cannot be repeated with lftp.

However, before reporting here I did test against different FTP server in order to check whether this is client's or server's fault. Same FTP client and same test case against NcFTPd (www.ncftpd.com) produces properly uploaded file. 

For the sake of completeness, I think I have somewhere a copy of RH7 (Guinness), which used wu-ftpd - I might try this too :)

I'm not able to reproduce it. The ftp hangs after the second password insertion. Please, could you provide me an output of this grep:

# grep -v '^#\|^$' /etc/vsftpd/vsftpd.conf

Do you have a content in the file ~/.netrc on your client system? If so I'd like to see it.

The recommended lftp works fine for me. So It would be helpful to provide me an output of 'lftp -du <username> <server>' too.

Thanks, Jiri

Still 100% reproducible for me (clint is now ftp console client on F18 since F17 was long time ago). 

As I wrote: attempt logon once with wrong password, then (when prompt returns) force a second logging by sending the 'username xxx' command and enter your correct password when prompted. Upload a file, then download it (first is the original file, second is what I get after uploading and downloading it; filesystem is the same): 

File before uploading: 

[root@archimed ~]# ls -l rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm 
-rw-r--r-- 1 root root 2745140 Feb 27 19:59 rpmbuild/RPMS/noarch/msttcorefonts-2.5-1.noarch.rpm

File on the server: 

ftp> ls
227 Entering Passive Mode (217,75,128,2,186,204)
150 Here comes the directory listing.
-rw-r--r--    1 558      558       2755620 Apr 28 16:59 msttcorefonts-2.5-1.noarch.rpm
226 Directory send OK.

File after downloading: 

[root@archimed ~]# ls -l msttcorefonts-2.5-1.noarch.rpm 
-rw-r--r-- 1 root root 2755620 Apr 28 19:59 msttcorefonts-2.5-1.noarch.rpm

No even need to md5 as files are clearly of a different size. 

Can't help you with the vsftpd.conf as I no longer have SSH access to the server (SSH access is restriced by IP address). From what I see, some for of virtual chroot is configured as I cannot get up my home directory. 

I have no .netcr in my home directory (dedfault hoem directory as created by the 'adduser' on Fedora 17 and 18). 

lftp even with debug does not reveal anything to me:

[root@archimed ~]# lftp -du assen server.domain.com
Password: 
lftp assen.com:~> 

lftp may somehow be mitigating the issue but, as I wrote before, it is 100% reproducible by using yet another client, the NcFTP client. Can't buy the idea of only using lftp against vsftpd.

Hi,
as I wrote I'm currently not able to reproduce it. So I need more data that will lead to identifying the issue. Please, do understand my recommendation to use lftp at least as a workaround to be able to get files correctly.

You "can't buy the idea of only using lftp ..." but I didn't read if lftp works fine for you without any issue. Please, do clear me up this question.

I'd like to see debug logs from 'lftp -du assen server.domain.com'. Entering a password doesn't produce logs. You have to continue putting commands (ls, get, etc.). The logs could help me to reproduce the issue. I'm not able to do anything without reproducer. If the lftp works fine we can't predicate vsftpd is buggy.

Thanks, Jiri

There are no answers to comment #5, no vsftpd.conf. I don't have enough data to investigate. So I'm going to close this bug.
You can reopen it when the difficulties persist and the desired data is available.