UaSession monitored by the client gets disconnected with server after 1hr

[KaushalKiran95]

Currently we are using the C++ Client SDK V1.8.2.604 on a Windows application that acts an OpcUa client. It connects to an OpcUa server running on an embedded device[ARM, Arch Linux ]based on the ANSI C SDK V1.3.3.

The client creates a OpcUa thread which is responsible for the initialization and connection to the server. It is noticed that after 1hr/~60-64min the client monitors a disconnect through the connectionStatusChanged callback where the server status is Disconnected. This causes the server to remove certain providers. The callback triggered is not by a call to disconnect but rather the client SDK which monitors the connection.

Logs:

• Client Trace Logs:

During and up until the callback is invoked the client trace logs enabled at OPCUA_TRACE_OUTPUT_LEVEL_ALL show no error or messages related to disconnection. After which the client does not initiate any requests to the server.

• Server journalctl logs:

Because the client has monitored a disconnect the server running seems to remove providers that were added. [Note : This removal of providers is similar to that performed by the server during gracefull shutdown of the client application that cleans up the OpcUa stack]

• Wireshark capture:

After the callback is executed the client no longer sends OpcUa messages to the server

I am not able to clearly identify the reason for this behavior with the existing logs generated, I have instrumented the client as below just before connection to the server.

Code: Select all

SrvT::initTrace(UaTrace::Data, 500000, 5, "OPC_UA_Client.log", "Client Logs");
SrvT::setTraceActive(true);
/* Set Trace Settings for stack*/
UaPlatformLayer::changeTraceSettings(OpcUa_True, OPCUA_TRACE_OUTPUT_LEVEL_ALL);
SrvT::setStackTraceActive(true, OPCUA_TRACE_OUTPUT_LEVEL_ALL);

Questions:

• If the client SDK is monitoring the connection and responsible for connection handling what are the possible reasons for disconnection ?

• Are there any other ways to instrument the code to analyse disconnections triggered by the client or server ?

• The OpcUa client thread is running with session that was responsible for initialization and connection :
  a. What is the correct procedure to reconnect with the server after a disconnect ?
  b. Can the existing UaSession be used to reconnect with the server ?

• It is expected that the OpcUa connection to keep running given that problem is seen only after upgrade of the client SDK from version 1.3.2.200 to 1.8.2.604. Is there any recommendation on the right upgrade path.

Happy, to provide more information regarding the same.

Thanks,
Kaushal

[Support Team]

Hi,

there are multiple reasons that may trigger the issue. The first to consider is that the (new) C++ Client SDK has experienced constant improvement in the handling of security relevant issues during initial connect, but also during re-connect. There are callbacks indicating error to the application that you (the client application) might need to handle, initially and also after re-connection, and any time the secure channel is renewed (this is different between old client SDK and new client SDK)

On the serverside you use rather old ANSIC SDK which has reached EoL (end of life) long time ago. The server may use old security policies that are "deprecated" as of now and it may even use old SHA1, which may not pass the security checks of the new client (hence need to be handled in the application side code) .

Have you experienced same hickup after 60 minutes when connecting the UaExpert?

Our SDK has multiple mechanizm to check if connection is still alive, we do watchdog read, check server status variable, we have subscription-keepalive messages (in case the data doesn't change), we have publish request and response including acknowledge of received data, and the session and subscription objects have life time. That said there might be multiple reasons why client may have the assumption that server is in disconnected state.

Your best option is to create support ticket via our support form, and send trace and wireshark for analysis. To not record the full hour, you best record the startup phase, and in addition catch the trace on failior.

[KaushalKiran95]

Thanks for the quick and detailed response of the possible reasons affecting the behavior.

I do use the UaExpert 1.5.1 and have not noticed the hiccups compared to our custom implementation of the OpcUa client.
Will verify this again though.

I believe we are eligible for a commercial support. Will check with my team about the credentials to raise the same.

Also will furnish the requested details at the earliest.

Thanks,
Kaushal

[Support Team]

Hi,

you definitely need to update all the components you have !

Anyways, there is one more thing: You report about 60 minutes timeframe, how precisely reproducible is that duration until the "disconnect" hits in?

Just an educated guess, the only time that hits in after 60 minutes, is the "evaluation" period. Hoping you are not accidently using the eval edition, instead of the purchased one that was given to you via personal download share?

[KaushalKiran95]

Yes, the scenario of disconnect is very much reproducible.
The timeframe until the sudden disconnect hits is between 60-62min.

And, YES! it looks like the upgrade was performed using the evaluation edition of the latest client SDK.

If I am right the use of evaluation release could be the possible reason for this behavior..?

I will reach out to get the purchased one.
Just a general question, Is there a procedure to get from the "personal dowload share" mentioned ?

I should then be able to test for this behavior we see if in case it appears...

Thanks for the responses..

Kaushal