Bug 77845

Summary: get says BINARY mode but uses ASCII mode
Product: [Retired] Red Hat Linux Reporter: Need Real Name <nettleton>
Component: vsftpdAssignee: Bill Nottingham <notting>
Status: CLOSED NOTABUG QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: 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
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Using vsftpd to copy a large compressed (binary) file, without explicitly
setting the mode to binary, the file was apparantly transferred in ASCII mode
and therefore corrupted. 

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.ftp -n some.address
2.cd pub/somewhere
3.get a_file
	

Actual Results:  ftp> get erc32-ada-1.5.5.tgz
local: erc32-ada-1.5.5.tgz remote: erc32-ada-1.5.5.tgz
227 Entering Passive Mode (192,168,1,7,109,253)
150 Opening BINARY mode data connection for erc32-ada-1.5.5.tgz (254291970 bytes).
WARNING! 867457 bare linefeeds received in ASCII mode
File may not have transferred correctly.
226 File send OK.
254291970 bytes received in 225 secs (1.1e+03 Kbytes/sec)


Additional info:

Comment 1 Michael Lee Yohe 2002-11-14 16:16: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?



Comment 2 Need Real Name 2002-11-15 06:44:50 UTC
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)


Comment 3 K.R. Foley 2003-02-13 20:41:45 UTC
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?

Comment 4 Ben Klang 2003-02-27 16:32:02 UTC
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. 

Comment 5 Frank Liu 2003-06-29 05:06:17 UTC
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).





Comment 6 Frank Liu 2003-06-29 14:58:38 UTC
(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.


Comment 7 Bill Nottingham 2003-06-30 16:27:44 UTC
Do you have ascii_download_enable enabled in your configuration? (and uploads,
for that matter)

Comment 8 Frank Liu 2003-07-03 21:13:48 UTC
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?


Comment 9 Bill Nottingham 2003-07-07 17:00:23 UTC
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.

Comment 10 Frank Liu 2003-07-07 18:03:13 UTC
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?

Comment 11 Bill Nottingham 2003-07-07 18:22:34 UTC
If the client is in ASCII mode, it will convert the data received from the server.
(rfc 959, 3.1.1.1).