Reconnect works with Kepware & Prosys, but not with Inmation

[stevie77]

Hello all,

I would like to know if there is a known issue with reconnecting to an Inmation OPC server. Our milo client reconnects to Kepware and Prosys OPC servers, but doesn't reconnect to Inmation.
We implemented it as described here, I think standard. In case we stop and restart Inmation nothing happens in the log file of our client application, but the sessions monitored in Inmation increase up to 60,000 and then kill the Inmation server. Is this a known bug (maybe of milo or Inmation)?

We then tried to play around and implemented more callback methods (onPublishFailure) and tried to react manually although you shouldn't do that (unsubscribe and reconnect and subscribe manually). We then got this interesting exception:

2024-02-27 15:39:16,454 ERROR c.w.p.f.k.o.i.OpcUaSubscriberImpl [myScheduler-1] Cannot create subscription successfully. The following error occurred: UaServiceFaultException: status=Bad_IdentityTokenRejected, message=The user identity token is valid but the server has rejected it. 2024-02-27 15:39:16,454 ERROR c.w.p.f.k.o.i.OpcUaSubscriberImpl [myScheduler-1] failed to subscribe to nodeId=ns=2;s=/System/Core/localhost/Kepware OPC UA/Channel1/KPISIM/Good UaServiceFaultException: status=Bad_IdentityTokenRejected, message=The user identity token is valid but the server has rejected it.

So I think this is also the problem when we use the recommended standard approach of milo to reconnect. It looks like that the first time the connect is perfect, but when the Inmation server restarted, then Inmation rejects the milo request although it's the same Inmation user like the first time connecting to it.
reconnect-neu-Inmation-rejected.txt
In addition here the log of a successful reconnect with one of the other servers.
reconnect.txt
In the screenshot you can see that the amount of rejected sessions increases permanently. A new session is then created that is also rejected and so on.

Even more interesting: One time we managed to reconnect two times with our not standard approach and only the third reconnect try failed with the exception shown above. I do not understand this.

By the way, is it possible to activate logging in milo, maybe we can see more details whats happening here?

[kevinherron]

It might help to set the log level for these loggers to DEBUG:

• org.eclipse.milo.opcua.sdk.client.SessionFsm
• org.eclipse.milo.opcua.stack.client.ChannelFsm

and to make the connection without security and get a Wireshark capture while you turn that server off/on and observe the reconnect attempts.

It is strange that you are seemingly getting far enough to create a session but that the server rejects the attempt due to the identity token. I haven't seen something like that, not sure if it could be a bug in that server or not.

[asashour]

Please find attached, including the source code.

In the initial-working, there is ReadRequest and ReadResponse

However, when on trying to re-establish the connection, there is only ActivateSessionResponse, without ReadRequest or CreateSubscriptionRequest.

I couldn't find something in the server response which really differs that the subsequent requests aren't sent.

Appreciate the help, thanks a lot.

milo-inmation.zip

[kevinherron]

Ok, my best guess here is that you are restarting this server to test this, and upon restarting this server it generates new policy IDs for its UserTokenPolicys.

Policies returned in endpoints from CreateSessionResponse:

Policy being sent by client (from the first time it called GetEndpoints):

These policy IDs are not supposed to change. That they are changing means in order to reconnect a client must call GetEndpoints again to discover them, and that's not how re-establishing connections is supposed to work.

This needs to be reported to Inmation as a bug.

[kevinherron]

Technically, Milo shouldn't even be attempting to activate the Session, because this server is failing this requirement of the endpoints returned in the CreateSessionResponse:

List of Endpoints that the Server supports.
The Server shall return a set of EndpointDescriptions available for the serverUri specified in the request. All Endpoints are returned if the serverUri is null or empty. The EndpointDescription type is defined in 7.14. The Client shall verify this list with the list from a DiscoveryEndpoint if it used a DiscoveryEndpoint to fetch the EndpointDescriptions.
It is recommended that Servers only include the server.applicationUri, endpointUrl, securityMode, securityPolicyUri, userIdentityTokens, transportProfileUri and securityLevel with all other parameters set to null or empty. Only the recommended parameters shall be verified by the Client.

Milo client is not performing this verification, but if it was, this check would fail.