ftp error : 500 '': command not understood

[so.nimda]

Hi,

Could someone be kind enough to explain the above error and how it can be resolved?

I have a ftp script in HP UX that puts a file into a windows server daily at a pre-determined time (via crontab) during quiet hours. 

This script has been running without any problems for a while but today, we have the error "500 '': command not understood" and the file failed to transfer.  The log is attached :

Connected to 1.2.3.4.
220 Microsoft FTP Service
331 Password required for myid.
230 User myid logged in.
200 Type set to A.
Local directory now /mydirectory
250 CWD command successful.
local: THISFILE.TXT remote: THISFILE.TXT
200 PORT command successful.
500 '': command not understood
150 Opening ASCII mode data connection for THISFILE.TXT.

As the script has been running mostly fine, I'm puzzled as to how this error can occur plus it always runs at a time when there is very minimal user/system activity.

Any help is much appreciated.

Thanks

[Bill Hassell]

Can't really help until you post the commands that were sent to the server. If your script uses a 'here' document method to send the commands, and the commands are formed with script variables, something in the script has failed. It would be best to turn on script tracing with: set -x just before the ftp section.

[so.nimda]

Hi Bill,

Thanks for your reply.  Appreciate your attempt to help.

Found another similar error but this one has an error 425 which the previous one didn't : 

Connected to 1.2.3.4.
220 Microsoft FTP Service
331 Password required for myid.
230 User myid logged in.
200 Type set to A.
Local directory now /mydirectory
250 CWD command successful.
local: THATFILE.TXT remote: THATFILE.TXT
200 PORT command successful.
500 '': command not understood
local: THATFILE.TXT remote: THATFILE.TXT
150 Opening ASCII mode data connection for THATFILE.TXT.
425 Can't open data connection.

I understand that error "425 Can't open data connection." could be network related whereby a connection couldn't be establish.  

Could this disconnect cause the 500 error?

Thanks

[Dennis Handly]

>Found another similar error but this one has an error 425 which the previous one didn't

Again, we need to see your commands, not just their results.

>Could this disconnect cause the 500 error?

Not likely, since in wrong order.

[so.nimda]

Thanks, once again, Bill for the reply.

[so.nimda]

Hi Steven,

I didn't mean to waste anybody's time.  

The script has been running without any errors for many months and there was no change to the scripts nor how the data files were created and as such, I didn't post the script.

I have googled prior to posting this message and most of the info I obtained are very broad and general in nature.

I was, perhaps looking for someone who has encountered similar error to point me in the direction to narrow down to what to look for - I was certainly not looking for psychic.

Regards

[Dennis Handly]

>looking for someone who has encountered similar error to point me in the direction

It looks like you'll need to start from scratch and provide more details.

[Matti_Kurkela]

Based on general knowledge of the FTP protocol, I'll try to reconstruct the protocol-level conversation.

Reconstructed FTP client commands are in red; reconstructed protocol-level commands sent by the client are in blue.

According to the usual convention, the messages in black without a three-digit result code are created locally by the FTP client, and the messages with the result code are sent from the FTP server. I assume this is true in this case, too.

NOTE: as the actual transfer script is not available to me, this includes some guesswork. Most people really hate having to guess things if the original poster could easily supply the necessary information instead. The requests to see the script do not necessarily mean people expect to find errors in the script: seeing the actual script would just make it easier to reconstruct the protocol-level conversation accurately, so there would be no doubt of what exactly is happening.

Connected to 1.2.3.4.
220 Microsoft FTP Service

USER myid

331 Password required for myid.

PASS something
230 User myid logged in.

ASCII

TYPE A
200 Type set to A.

LCD /mydirectory
Local directory now /mydirectory

CD /some/directory

CWD /some/directory
250 CWD command successful.

PUT THATFILE.TXT
local: THATFILE.TXT remote: THATFILE.TXT

PORT aa,bb,cc,dd,xx,yy
200 PORT command successful.

??? (should be STOR THATFILE.TXT but the server seems to receive something else)
500 '': command not understood

PUT THATFILE.TXT
local: THATFILE.TXT remote: THATFILE.TXT

PORT aa,bb,cc,dd,xx,zz (apparently ignored by the server)

STOR THATFILE.TXT
150 Opening ASCII mode data connection for THATFILE.TXT.
425 Can't open data connection.

Note that a single client-side PUT command actually translates to two FTP protocol-level commands: PORT and STOR. Since LCD only takes effect locally, no command is sent to the server for that.

PORT tells the server which IP address and port to use for the data connection: in active-mode FTP, the server opens the data connection to the client, not vice versa. In the arguments of the PORT command, aa,bb,cc,dd is the IP address of the client; the two remaining parameters are the high and low bytes of the port number; i.e. with the PORT aa,bb,cc,dd,xx,yy command, the actual port number is (256 * xx) + yy.

My guess is that after the PORT command, the server is expecting either a STOR or RETR, and ignores any other commands. Something causes the first STOR command to be corrupted to something that looks like an empty string. The server reports it does not understand the corrupted command, but the server still waits for either a STOR or RETR command after the error.

But the client moves forward in the script to another PUT command, or retries the first command (as indicated by the second "local: THATFILE.TXT remote:THATFILE.TXT" message output by the FTP client). The new PUT command causes a new PORT command to be sent to the server... but it seems like the server ignores it, as it's already received the first one.Then the STOR command tells the server to initialize a file transfer (as indicated by the message with the 150 code)... but now the client expects a data connection in port (256 * xx) + zz, while the server is actually connecting to port (256 * xx) + yy according to the first PORT command. As a result of the miscommunication, the server is trying to connect to the wrong port of the client, and the data connection fails.

I think you'll need to find out what actually gets sent from the FTP client to the server at the point marked ???. You might want to take a network traffic dump and examine it.

If the command is sent out correctly, it might get corrupted on the way to the server if there is a firewall or a FTP proxy in between the client and the FTP server. If the software of the firewall/proxy has recently been updated, it might be a new bug in the updated software. Another traffic dump at the FTP server side might be needed to really confirm this.

If the command is sent in wrong form by your FTP client, you'll really have to examine the transfer script. Perhaps the filename is actually something like "THATFILE.TXT " (note the extra space at the end) which confuses the script or the FTP client, causing a wrong/empty FTP command to be sent.

If a server-side traffic dump indicates the command is actually received correctly by the FTP server host, then the only remaining option would be that the FTP server mis-interprets the command. That would be a bug in the FTP server software. The first message indicates it is a "Microsoft FTP Service", so the server is apparently running some version of Windows. Perhaps one of the Microsoft's patches caused a new bug in their FTP server? You should ask the administrator of the Windows server if any updates has been installed to the server recently.