TIA Version : V15 Update 4

Hardware Modules:

CPU 1517F-3 PN/DP,  6ES7 517-3FP00-0AB0, Hardware 7, firmware V2.6.0

CP 1543-1, 6GK7 543-1AX00-0XE0, Hardware 3, firmware V2.1.4

Short version:

With both ethernet interfaces integrated in the CPU, using tdiscon on an established tcp connection sends a RST instead of a FIN so the connection isn't closed cleanly.

If I use the CP instead, tdiscon sends a FIN but after a 3 seconds delay.

Long version:

after implementing the ftp communication with the cp using FTP_CMD (I managed it in spite of the pitiful documentation and badly designed examples), I'm now trying the FTP communication without the CP (I'll need it in a 1200 project). The project here:

https://support.industry.siemens.com/cs/ww/en/view/81367009

doesn't work (maybe it does with filezilla as a server, but with three other different servers I tried it doesn't, and it doesn't surprise me looking at the implementation), so I implemented my own version of an ftp client.

I have it mostly working, but I cannot send files to the server, only read them: the server always complains about connection reset by peer.

I traced the connection with wireshark and I saw what I described above: when I finish sending the data, I close the data connection with tdiscon, but instead of closing it with a FIN flag it closes it with a RST flag, so the server correctly gives the error connection reset by peer.

I also tried using the CP instead of the integrated ethernet interfaces. The cp correctly sends the FIN but it does so after 3 seconds (an unnecessary delay, besides I'd like to use the integrated ports).

Now I'm trying to get hold of a 1200 cpu to see if it does implement the TCP protocol correctly, but I kinda doubt it.

Since the only parameter I can give to tdiscon is the id, maybe there is an undocumented parameter/connection type that I can give to tcon in order to use FIN instead of RST when closing the connection?

Side question: why oh why doesn't the system allow me to put both integrated interfaces in the same subnet?

I tried with a different cpu (CPU 1513F-1 PN, 6ES7 513-1FL02-0AB0, Hardware 2, Firmware V2.6.0) and it does exactly the same. 

In the image (wireshark screen capture) 192.168.1.6 is the server and 192.168.1.22 is the 1500.

Edit I also attached the capture file (zipped since the forum doesn't allow the pcapng extension).

For completeness sake, here's the wireshark capture if I use the cp for the connection. Notice the 3 seconds delay between the data packet and the FIN packet. The program is the same, i.e. I call the tdiscon at the same time in both cases, so the 3 seconds delay is produced by the cp.

The capture file is attached.

Kaulquappe

Hello,
I recommend to raise a support request at Siemens.

Regards,
Kaulquappe

 I just did, let's see...

Hello!

We have discovered exactly the same problem here at our factory trying to use Open TCP communication. Specifically Siemens FTP client for 1200 and 1500. We get the exact same problem with our Microsoft IIS FTP server. We have raised a support case with simatic support and got the answer from them that closing a tcp connection can be done in one of two ways. FIN or RST. Siemens choose RST. We argued that their choice is wrong. The specification of the FTP protocol clearly states the FIN should be used to close a connection and only use RST as a last resort. We regard this as a BUG in Simatic's implementation of the TDISCON function. The function doesn't follow good network practice. 

We are not alone with issues regarding TDISCON as there are a couple more forum threads on this subject. Now we hope that Siemens take real notice of this issue and will resolve it with a prompt update of firmware for the 1200 and the 1500 as more and more people have the same problem.

Not only the choice is wrong, they do it differently with the cp and the integrated interface!

Don't hold your breath for a solution: this is Siemens after all

Hello,

the problem is known. Fact is, the S7-1500 sends a "RST", the S7-1500CPs and S7-300 a "FIN".

Most of the external Application (e.g. FTP-Server) only understand "FIN" and do not close the connection successful.

Only FTP server like jana or filezilla understand the "RST".

All the application in SIOS using the T-Blocks must "live" with the Problem of the T-Blocks. The T-Blocks are instructions of TIA Portal and not from SIOS.

What I don't understand is, if it's a known problem why don't they fix it.

Well, actually I understand, that's why I usually add an H and an extra T in simatic