PLC Connection

[Mike1688]

Hi,

I have been testing the Siemens Implementation of the LFTP-Client with FileZilla Server V1.4.1.
The PLC used is an S7-1515F (6ES7 515-2FM01-0AB0) - the PLC is also directly connected to my laptop where the Server is running.
So there should be no issues with firewalls or ports.
I can connect to the server without problems, but every time I try to upload a file, the server runs into an error (425) after the PLC closes the data-connection.

Error425.jpg (80.9 KiB) Viewed 2803 times

Although the server has encountered an error, the file has been successfully uploaded, so I don't know exactly what the problem is.
Now comes the tricky part - the TCP-implementation on the Siemens side.

As I have to use an older version of the siemens software (TIA Portal V15.1) the PLC always closes the TCP-connection with the "RST"-Flag instead of the correct "FIN"-Flag.
I know that this is a siemens issue, but I would like to know if this causes the error on the server side?

RST.jpg (205.3 KiB) Viewed 2803 times

With a newer version and the correct TCP termination, the server has no errors after uploading the file.
Is there maybe a setting on the server side where I can "allow" the termination of the connection with the "RST"-Flag?


Best Regards,
Michael

[botg]

This is an important mechanism to signal to the client whether the transfer has been successful (FIN got received by the server), or something went wrong (no FIN got received).

There is one situation in which this condition is relaxed: If you use FTP over TLS, it suffices that the TLS session on the data connection is properly shut down. The server in that case got cryptographic proof that the transfer is successful, the state of the TCP connection then no longer matters.


Just implement FTP over TLS, which you should anyhow. No sane person should still use plain insecure FTP.

[Mike1688]

Thank you very much for the very fast answer

I know the importance of these mechanisms, but unfortunately I can not change the behaviour of the PLC (but I am also in contact with siemens).
As this constellation is for a customer with pre-existing hardware, my hands are tied.
The only information I have found on the PLC site is that the used PLC without additional hardware does not support FTPS.

Siemens_Intro.jpg (50.69 KiB) Viewed 2799 times

As the customer doesn't have a Siemens CP, my only option is the software-implementation:

Siemens_FTPS.jpg (56.12 KiB) Viewed 2799 times

Unfortunately, the PLC only supports active/passive FTP without additional hardware.

So the only way to implement the FTP connection without errors would be to use FTPS?

Best regards,
Michael

[botg]

Using FTP over TLS is the preferred way. If you don't mind the lack of security you can alternatively ensure that the client ends the data connection with a FIN.

[lucasBB22]

Hi everyone, that is my first post here.

I'm using an application that has a PLC as the FTP server (PLC model: ABB PLC PM590-ETH) and, through FileZilla, I access the PLC and get some data from the memory. In the last few weeks the system has worked pretty well, but now (for no specific reason) the FileZilla is no longer able to connect with the PLC. I have checked (pinging) and the PLC is proporly connected in the network and with the HMI.

I don't see a clear error message or something like that, just:

"Error: Connection timed out after 20 seconds of inactivity
Error: Could not connect to server
Status: Waiting to retry..."

Someone can help me with that?

Thanks!

[AKG1963]

I'm definitely new at this, but I work with PLCs all the time. The PLC address is most likely static but the host computer might not be. I assume the PLC requires the server IP address. If the server is DHCP then it's address may change and the link is no longer valid.

Just a guess.

[SpeciJay]

Using FTP over TLS is the preferred way. If you don't mind the lack of security you can alternatively ensure that the client ends the data connection with a FIN.

Hi botg,

I seem to be in the same situation as Mike. Could you point me in the right direction about how to "ensure the client ends the data connection with a FIN"? I'm using TIA Portal v16 and a S7-1200.

Kind regards,

Barbara

[botg]

Look at the TCP specifications. Only FIN signals that the sender has no more data to send and is gracefully closing the connection. Everything else, from RST over timeouts to any other protocol errors, is seen as unsuccessful.