FTP Upload issue

[garysdickinson]

I have been working with the ExtendedFilesystem.PC6 program to provide file uploads to an FTP fileserver.

I've noticed that the first character of the first response from the FTP server is discarded.

I have modified the ExtendedFilesystem.PC6 program to provide additional debug by echoing all of the commands to Port #1 (RS-232 on the FMD-1616 PLC) and capturing both the commands the responses from INPUT$(4) (TCP/IP) port.

In the following example, lines prefixed with ">>> " represent the commands, "<<< " are the responses and those lines that start with "*** " are status or other information.

This is typical of what I am seeing:


>>> <TCPCONNECT marat.com:21>
*** FTP Connection Established
>>> HELP
<<< 14-The following SITE commands are recognized
<<<  CHMOD
<<<  IDLE
<<<  UTIME
<<< 214 Pure-FTPd - http://pureftpd.org/
>>> USER anonymous
<<< 230 Anonymous user logged in
>>> PASS
<<< 230 Any password will work
>>> CWD FTPFolder
<<< 250 OK. Current directory is /FTPFolder
>>> TYPE I
<<< 200 TYPE is now 8-bit binary
[/color]

Look at the line following ">>> HELP" and notice that it begins with "14-".  It should begin with "214-".  If I access this same FTP server with FileZilla, I see the correct response messages.  "14-" is not a correct value for the FTP protocol.

If I eliminate the FTP "HELP" command then then first command that is issued to the FTP server is "USER xxxx".  This is what I see:


>>> <TCPCONNECT marat.com:21>
*** FTP Connection Established
>>> USER anonymous
<<< 30 Anonymous user logged in
>>> PASS
<<< 230 Any password will work
>>> CWD FTPFolder
<<< 250 OK. Current directory is /FTPFolder
>>> TYPE I
<<< 200 TYPE is now 8-bit binary
[/color]

You will notice that now the response to the "USER" command starts with "30 " instead of the correct pattern of "230 ".

I suspect that this is a firmware issue.  I am testing with an FMD-161 r79A PLC.

I'm guessing that your firmware discards the sign-on message from the FTP server.  This may be a clue as to why the first character of the response to the first FTP command is lost.

This is what I see using FileZilla on the same FTP Server:

Status:   Connecting to 180.74..:21...
Status:   Connection established, waiting for welcome message...
Response:   220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
Response:   220-You are user number 1 of 10 allowed.
Response:   220-Local time is now 13:27. Server port: 21.
Response:   220-IPv6 connections are also welcome on this server.
Response:   220 You will be disconnected after 10 minutes of inactivity.
Command:   USER anonymous
Response:   230 Anonymous user logged in
[/color]

Best regards,

Gary D.

[support]

We used B$ to F$ to capture the return strings from RdComm4 custom function during the FTP connection sequence but didn't see any missing characters.  Please see the screen shot attached below.

The server we tested was a FileZilla FTP Server program with Windows Firewall turned OFF.

[garysdickinson]

Thanks for your kind reply.

I had been using a FTP server in Malaysia as the test system. I'm in California.

I switched my testing to an FTP server located 2 feet away (rather than 1/2 a world away) and see the correct (expected) messages from the server.

I will use my local FTP server as a test system.  There are two significant differences between the FTP Servers:

1.  The round trip delay for ping is about 900 ms for Malaysia and < 1 ms for my California FTP server.
2.  The Malaysian FTS Server sends multiple line sign-on message.  This server also sends 2 and 3 line transfer completion messages. I think that these long messages can overflow the receive buffer associated with Port #4.  I understand the issue with the buffer size having worked with the serial ports.  I'm guessing that I'm running into the same issue.

I'll let you know what I find out.

Gary D.