Bug 77845
Summary: | get says BINARY mode but uses ASCII mode | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Need Real Name <nettleton> |
Component: | vsftpd | Assignee: | Bill Nottingham <notting> |
Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | ben.klang, gfrankliu, kr, rvokal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-07-07 17:00:23 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Need Real Name
2002-11-14 11:57:03 UTC
I have been trying to duplicate this behavior. Have you been able to do the same thing on multiple FTP servers - or just one in particular? OK. I've tried this again, and this is what I find. With anonymous ftp, the transfers seem to be OK. With ftp to a named login, it fails every time, even with small text files such as a README. Example: [nettleto@ccfn tmp]$ ftp -n localhost Connected to localhost (127.0.0.1). 220 XGC Software FTP server ready. All transfers are logged. ftp> user nettleto 331 Please specify the password. Password: 230 Login successful. Have fun. ftp> cd pics 250 Directory successfully changed. ftp> ls 227 Entering Passive Mode (127,0,0,1,159,171) 150 Here comes the directory listing. -rw-rw-r-- 1 500 500 183045 Oct 24 16:18 kws30ord.exe.jpeg -rw-rw-r-- 1 500 500 649575 Oct 21 11:49 m31_gendler_big.jpg -rw-r--r-- 1 500 500 88909 Apr 23 2002 w.gif 226 Directory send OK. ftp> get w.gif local: w.gif remote: w.gif 227 Entering Passive Mode (127,0,0,1,113,195) 150 Opening BINARY mode data connection for w.gif (88909 bytes). WARNING! 534 bare linefeeds received in ASCII mode File may not have transferred correctly. 226 File send OK. 88909 bytes received in 0.0233 secs (3.7e+03 Kbytes/sec) ftp> quit 221 Goodbye. [nettleto@ccfn tmp]$ gqview w.gif ** WARNING **: Unhandled Case. If you have an image that causes this, let me <jrb> know. (the file is corrupted) I can't reproduce the case described with binary files. However, I have a similar issue with ASCII files in an ASCII transfer mode. On upload to the vsftp server in ASCII mode it always converts LF to CR-LF. Even if you upload a file that already contains CR-LF it converts it to CR-CR-LF. Also worth noting is that doing a download in ASCII mode of a file that contains LF works fine. Doing a download of a file that contains CR-LF strips the CR leaving just the LF. It is almost as if the vsftpd server thinks it is a Windows server? I tried uploading numerous shell scripts written in windows to a RH 8.0 stock system using vsftpd, and all files were corrupted. I verified that all files uploaded were sent in ascii mode, but they all arrived in binary. A simple dos2unix rendered the scripts usable again. I just tried the latest version vsftpd-1.2.0-2.1 from rawhide and was able to reproduce the problem. Everything is default, no change in vsftpd.conf from a Solaris box (client), I ftp into this linux with vsftpd. the ftp client default to ASCII mode (I also tried to run "ascii" just to make sure). I tried to download a file. it says "Opening BINARY mode data connection...". That's ok, since the default vsftpd.conf works this way ... The problem is the downloaded file has a different cksum from the original file. It seems "an ascii conversion" has been made by vsftpd. The test file can be found at http://mama.indstate.edu/users/liug/216.mp3 (it seems the problem only happens for some files, that's why I am including this file for your test). (for the last comment, I downloaded vsftpd-1.2.0-2.1 SRPM from rawhide and rebuilt it for my redhat linux). To eliminate the Solaris dependency, I just tried a redhat linux (localhost) ftp client and got the same problem. ftp localhost Connected to localhost (127.0.0.1). 220 (vsFTPd 1.2.0) Name (localhost:fliu): 331 Please specify the password. Password: 230 Login successful. Remote system type is UNIX. Using binary mode to transfer files. ftp> asc 200 Switching to ASCII mode. ftp> lcd /tmp Local directory now /tmp ftp> get 216.mp3 local: 216.mp3 remote: 216.mp3 227 Entering Passive Mode (127,0,0,1,253,152) 150 Opening BINARY mode data connection for 216.mp3 (5704307 bytes). WARNING! 22293 bare linefeeds received in ASCII mode File may not have transferred correctly. 226 File send OK. 5704307 bytes received in 1.22 secs (4.6e+03 Kbytes/sec) now cksum /tmp/216.mp3 and $HOME/216.mp3 differs. Do you have ascii_download_enable enabled in your configuration? (and uploads, for that matter) as I mentioned in my early comments, the vsftpd.conf is the default one that comes with RPM. I just verified it and here is a section from /etc/vsftpd/vsftpd.conf: ... #ascii_upload_enable=YES #ascii_download_enable=YES So I am NOT setting it. As per man page, those two should default to NO, which is confirmed by the message : 150 Opening BINARY mode data connection for 216.mp3 in my test. BTW, I just did more testing and confirmed that this vsftpd bug exists in RedHat 7, 8, 9, rawhide. for vsftpd version 1.1.3 or 1.2.0 This means it should be very easy for you to reproduce the problem, no matter which OS version or vsftpd you are using. Before you ask more questions, can you confirm if you were or were not able to reproduce it following my steps? If you do not enable ASCII downloads or uploads, vsftpd sends files in binary regardless of what mode the client sets. This is exactly the behavior you're seeing; vsftpd is sending files in binary mode, your client is expecting ASCII. if vsftpd sends in binary, why the cksum doesn't match in some test cases, and does match in other test cases? maybe I missed something, isn't the binary/ascii conversion happening on the server (vsftpd) side? it should have nothing to do with client, right? If the client is in ASCII mode, it will convert the data received from the server. (rfc 959, 3.1.1.1). |