OpENer CIP connection Timeout event is occurring rarely in 24 hours test

[rakesh1225]

Hello,

We are using OpENer stack version 2.1.0 on Linux for our development test. We ran 24 hours CIP communication test between our device(Adapter - OpENer stack) and computer(Scanner). After a couple of hours Timeout event is observed from OpENer stack callback. Can anyone let us know why this Timeout event occurs?
Note: Scanner is sending data periodically, however after sometime the adapter is throwing timeout after couple of hours.(RPI is 500ms). Scanner reconnects(using ForwardOpen) after no response from adapter(for 500*4=2000ms).

[MartinMelikMerkumians]

One thing which could be, is when the message number overflows. Do you have a wireshark trace of the relevant time period?

[rakesh1225]

Wireshark logs are attached for reference. xxx.30 is Adapter IP and xxx.35 is the Scanner IP. From the logs I understood that Scanner is keep sending messages periodically to the adapter, whereas Adapter stopped sending messages. This issue is intermittently observed in 24 hours test. Once the Adapter stopped sending messages, scanner initiates ForwardOpen requests and then the communication resumes.
Not clear why the Timeout is triggered from the Adapter callbacks.

[MartinMelikMerkumians]

So, do I see this correct, you have 3 O->T connections and one T->O? Could you please tell me the connections configurations? (EO, IO, LO, etc.).
Perhaps the algorithm when the Timeout has to be reset has a corner-case error, if all sequence numbers connected to an assembly are equal.

[rakesh1225]

Yes, in this test I have 3 O->T connections and one T->O connection.

[rakesh1225]

O->T Connection: 0x4802
Owner:Exclusive
ConnectionType: Point To Point
Priority: Scheduled(2)
Connection Size Type: Fixed
Connection Size: 2 bytes

T->O Connection: 0x29fa
Owner:Exclusive
ConnectionType: Multicast
Priority: Scheduled(2)
Connection Size Type: Fixed
Connection Size: 506 bytes

[rakesh1225]

@CapXilinx , please let me know if any idea on the above issue
small info: we are using OpENer stack with commitID: 9181a4d
9181a4d

[MartinMelikMerkumians]

Probably the same as #349