Linux – FTP: How to get rid of “WARNING! 1 bare linefeeds received in ASCII mode” message

ftplinuxshellups

I wrote a little shell script (on CentOS) to download statistics from our APC UPS device. It works great, but everyday cron sends an email with this message:

WARNING! 1 bare linefeeds received in ASCII mode File may not have transferred correctly.

I also get that message when I get the file manually on the shell. The FTP part of my script looks like this:

ftp -in $ftpip <<END_FTP_DOWNLOAD
user $ftpuser $ftppassword
get data.txt
bye
END_FTP_DOWNLOAD

How can I get rid of this warning message which may disturb my colleagues?

The manual FTP connection looks like this. I tried to type "ascii" this time:

220 AP9617 Network Management Card AOS v2.6.4 FTP server ready.
Name (192.168.0.50:myusername): username
331 User name okay, need password.
Password:
230 User logged in, proceed.
ftp> ascii
200 TYPE Command okay.
ftp> get data.txt
local: data.txt remote: data.txt
227 Entering Passive Mode (192,168,0,50,161,31).
125 Data connection already open; transfer starting.
WARNING! 1 bare linefeeds received in ASCII mode
File may not have transferred correctly.
226 Closing data connection.
131468 bytes received in 19,3 secs (6,6 Kbytes/sec)
ftp> bye
221 Thank you for using APC products!

The data.txt has between 500 and 800 lines and the last line is always empty.

Best Answer

Try to use binary mode instead of ASCII mode. It should be something like:

ftp -in $ftpip << END_FTP_DOWNLOAD
user $ftpuser $ftppassword
bin
get $filename
bye
END_FTP_DOWNLOAD

Related Solutions

Firewall – Can explicitly ftps via Filezilla but not from code

Dealing with these types of problems can be difficult because the logs usually tell you only part of what is happening.

Your best bet at this point is to use a packet capture and analysis software (like the most excellent - and free - wireshark) to see what is really going on the wire.

Make sure you capture all the traffic between your machine and the remote system and try to see what difference you can spot between a working connection and your code. That might give you an indication where the problem lies.

Do pay special attention to the way the TLS connection is negociated because it might point out to the actual issue (there is a pretty nice and simple to understand document that can be found at IBM's). For instance:

If the connection stops after certificates have been exchanged, it is an indication that one of the parties cannot verify the other's certificate. This is a quite common source of problem with TLS software, especially when self-signed certificate or private roots are used.
If the connection is broken in the first stage of the handshake, it can be that the client and server cannot agreed on what protocol to use (usually because one of the party restricts itself to "safe" protocols that the other does not support).
If the server has set the "client certificate required" flag, then it could be that you haven't setup a client certificate for authentication.
(etc)

If you see that the TLS channel has been successfully negociated, then you'll have to gring in the big guns: grab the server's private key and decode the TLS traffic. That will only be possible, however, if the TLS connection does not use DH key exchange so first, disable that in your server or client.

Once DH has been deactivated and you have the private key, you can follow the instructions on the Wireshark's wiki page about SSL/TLS which explains the process in quite a bit of details or this blog post that is perhaps a bit easier to follow.

Ftp – vsftpd not responding to LIST

Agree with Luke404. Check that your vsftpd.conf has the following entries configured and your firewall allows the pasv_min & pasv_max port ranges (10000 - 100010 is just an example). Remember to restart the service if changes are made to the conf file.


    pasv_enable=YES
    pasv_min_port=10000
    pasv_max_port=10010
    pasv_address=[Public IP address of your server]

Related Topic