Hi,

Very odd. That kind of an error shouldn’t be related to any SDK (unless like they would use multiple sessions etc). Basically we (the UaClient) do first a secure channel to do the GetEndpoints call, then close that channel and open another (security mode is tied to the opensecurechannel call and GetEndpoints needs None mode) once we have the EndpointDescription and then open the Session on top of that. Thus there should be just a single Session.

However, you do mention “We can switch back and forth between SDKs”. Please note that we have nothing to do with Eclipse Milo. Any API there that might have the same name as we do might not do the same thing.

Do you get the error always? Is this reproduce-able? Any option to name or make such server available to us (uajava-support@prosysopc.com if needed)?

Does this happen on first connect or somewhere later? Is a reconnection situation happening i.e. does this only happen after losing connection? IF yes, do you happen to have calls to UaClient.reconnect()? There is a somewhat known issue if the AutoReconnect feature of UaClient is on (it is by default) and manual calls would be done to reconnect. Currently that would log a WARN message, but in the future we will probably start throwing instead (warn log was safer option when we did add this, but this is somewhat big of a problem). This could cause a situation where multiple sessions are opened due to race conditions, but not closed as both the manual call and SDK internals would be trying to reconnect at the same time.

Sorry, but this will be complicated to solve with just this info. Like I can make guesses and theories, but they might be quite specific scenarios. Basically you would want to observe the ‘problem server’ about how many active sessions it has. All this is also on the assumption that the server is behaving properly i.e. that the Bad_TooManySessions really means it, nothing per se prevents servers just like returning the wrong status code.

Anyway, first on the status codes, they are defined by the OPC Foundation (https://github.com/OPCFoundation/UA-Nodeset/blob/v1.04/Schema/StatusCode.csv). Just the number is transferred (as UnsignedInteger), rest relies on look-up-tables inside SDKs i.e. the text is not given by the server, just the code (but the text comes form the CSV file then).

Then on the Sessions. It is important to differentiate Sessions and Connections, or more specifically secure channels. I’m also assuming here that opc.tcp is being used, as that is 99.999% of the cases (I’ll note that opc.https exists, but basically it should not be used). Sessions can be “live” on the server even though their channel is broken or closed. If the “owner” of that session connects again, they can use the ActivateSession to reactivate the session on top of another secure channel (https://reference.opcfoundation.org/Core/docs/Part4/5.6.3/). Sessions also have a timeout value, typically it is something like an hour. So, the session will exist on the server unless closed or it times out.

Each Session on the server will take up resources, typically servers do limit themselves to X amount of concurrent Sessions. For example in our SDK’s server side the default would be 100 concurrent Sessions, but it is impossible to say what is the limit in the ‘problem server’. However in some chip-lvl micro embedded OPC UA Servers it could be like 2 (https://reference.opcfoundation.org/Core/docs/Part7/6.6.67/).

If you connect your app (in “Milo mode”) to our Simulation Server, you can observer active sessions (Options->Switch to Expert Mode) in the ‘Sessions’ tab. IF it shows the session even after you have seemingly disconnected it then there is a CloseSession service call missing and you must consult on Milo if there is a call you must make before disconnecting. Just a very_specific_scenario_theory though, this is kinda hard to debug without having access to the server.

Assuming the ‘problem server’ is properly using the error code, it did mean we were able to open the secure channel, but creating the session on top of that failed (and per the server it has already too many). Can you try with e.g. can https://www.unified-automation.com/products/development-tools/uaexpert.html open the Session? If not, that sort of would indicate the problem is with the server itself. Or another way to ask this is, did you always “start with Milo” and only after that made the “switch”? But anyway, like typically at least normal servers will allow many sessions so it would be not that normal to reach the max limit. Though, e.g. our public test instance of the simulation server (at opc.tcp://uademo.prosysopc.com:53530/OPCUA/SimulationServer) could very will reach the limit (I believe we have 50 sessions as the limit in that application) as many test on that and we have it as a sample in our Browser application.

IF you are not using sign&encrypt, you could maybe see via https://www.prosysopc.com/blog/opc-ua-wireshark/ does a CloseSession happen with the “Milo Mode”.

Like I’m also not ruling out possible bugs in our implementation, just that it sort of feels a bit odd.

Also, since you mentioned 2 servers with the same software with one of failing, any option to compare their configurations?

Some day we will improve this forum, but anyway for now if you want you can send them to uajava-support@prosysopc.com (zip first).

As far as I’m aware, there is no OPC UA specification-wise way to get that limit. Nothing would prevent a server e.g. making a custom node to show it, but most likely there is none. There is a defined diagnostics node(s) from where maybe the current session count could be observed, though it depends on the server to support diagnostics and also have them on (and it is a server-wide flag, so it could affect all clients i.e. it could run more slow). Anyway, our simulation server does have that in path /Root/Objects/Server/ServerDiagnostics/ServerDiagnosticsSummary/CurrentSessionCount.

I might reply things via email as well, but anyway to note most of the things here:

Sorry, I forgot that we also had a blog post regarding the thing https://www.prosysopc.com/blog/invalid-server-nonces-vulnerability/.

So, like technically we could make a flag to UaClient which could then be used to disable the check. I’m not sure should one be made yet, but it is something that we will discuss internally and it might take a bit of time. We do have other flags for some checks, but the impact of disabling this is like a lot bigger. Though then in turn IF you are in a situation where you have a server that wouldn’t support Anonymous UserTokenPolicy and you could not change the server AND you would be in a network where everyone who ever will be able to monitor the traffic is effectively allowed to know or knows that password already it probably would be ok to skip the test. But IF there is an option to use Anonymous instead of username/password I would say it should be done instead (as that would skip the test), or basically disabling the check would “convert” the Username/password into Anonymous as everyone on the network who would have seen at least once ActivateSession would be able to replay-attack that same encrypted password again (as there would be no nonces to make the difference it would be the same each time).