Our customer uses X20CP3684, with software version: Version V 4.12.2.93 (2022-05-25) and runtime version: 4.93.0 communicate with 3 devices using IEC-104 protocal .
The current issue found is that individual stations frequently experience communication interruptions with 104 protocol. Our ETH port communicates with 3 master stations simultaneously. The new-generation master station frequently interrupts, while the other two master stations occasionally interrupt. When the communication is interrupted, communication with the master station indicates that our IP can be pinged, but the port cannot be opened (port number: 2404).
The above trace of the communication process is recorded using a network analyzer.
I would like to ask, in what situation will the 2404 port closed? and from the record there is a lot FIN message, what is the cause of that?
I don’t know the IEC-104 protocol or the implementation behind (it’s not a B&R lib delivered together with Automation Studio, right?).
Therefore it’s hard to say, but I think it has to be debugged on application level.
The FIN is nothing IEC-104 specific, it’s part of the 3-way handshake of the TCP protocol when disconnecting a TCP connection.
Under normal circumstances, FIN is sent from both communication partners if one of the partner wants to end the TCP channel (for example, if TCPclose() is called inside the PLC software).
Between closing an reopening a TCP socket, some time can go by before the same server port can be opened again (maybe this is a reason of a temporary unavailability of the port 2404).
But again, I think it has to be debugged on application level, the SYN / SYN-ACK / FIN sequence is a normal TCP protocol flow control mechanism.
Unfortunately I don’t have source code available, I’m sorry.
From what I know, the SO_KEEPALIVE is only needed if there’s no data flow on the TCP channel for a very long time but the channel should kept open - then, keepalive packets are sent automatically from the TCP stack after the configured time of inactivitiy.
First I recommend to check, under what circumstances the PLC code calls the TcpClose() function block. Because from the screenshot it looks like, that every first FIN packet is sent by the PLC.
Second, I would ask if there’s a known time between data is sent/received on the server socket… if yes, I would try to measure that time in the application, and would trigger a TcpClose + TcpOpen on the server socket, if the maximum time of data flow exceeds without receiving any new data on the server socket - this could make the port available again, if the TcpClose was not triggered by the application.
