Log In
Register
Forum
Topic RSS
12:48, EET
February 21, 2014
Offline
Hello,
we are using a ProsysOPC custom client application to connect to a Siemens WinCC OPC UA Server over a secure connection. Prior to the “connect” I’m obtaining the server’s endpoints. Despite having our certificate trusted at the server, the clients errors with the message: “Requested endpoint is not found on the server…”
I triple checked all endpoint parameters, the server’s hostname has been mapped to its IP address in the /etc/hosts file. Connection attempts have been made using the IP address as well as the hostname. Interestingly, the server’s certificate doesn’t get into the rejected folder nor is the validationListener called.
The connection succeeds using UAExpert.
This sounds like a deja vu from other blog entries (even my own), yet the error message (endpoint is not found) is different.
Any help would be much appreciated.
Hans-Uwe
PS: when comparing the certificates of UAExpert and our Prosys Client, they show different key strength (1024 UAExpert vs. 2048 Prosys) / SHA1 vs SHA256. Could this make any difference for the server in that it might not be able to handle the stronger keys? If so, is there any way to force the ProsysClient to create “weaker” certificates?
14:03, EET
April 3, 2012
Offline
The default key size is 2048. You could try by setting the keysize to 1024. See e.g. the SampleConsoleClient.initialize, there is line with int[] keySizes = null; change that to ..= new int[] {1024}.
– Bjarne
19:18, EET
February 21, 2014
Offline
Any ideas about the reason for the “Requested endpoint is not found on the server”? The endpoint discovery showed the use endpoint.
Thanks,
Hans-Uwe
10:03, EET
December 21, 2011
Offline
It sounds like the security settings are not matching to what the server actually defines. Which user identity mode are you using?
The certificate parameters do not need to match, and now the server is rejecting the connection attempt already before that.
You could verify the endpoints as received from client.discoverEndpoints() and try selecting one of them and using that with client.setEndpoint().
15:35, EET
February 21, 2014
Offline
After adding additional logging statement in the “Client” and “EndpointUtils” classes in the stack I found that the the serverCertificate, which is retrieved from the createSession response (and is empty or zero length), does not match the one from the endpointDiscovery or createSecureChannel. I tried to force set the createSession obtained cert to the channel.certificate and thus passed the verification, but all subsequent communication failed.
The strange thing is that UAExpert has no problems at all with this, and the customer gets a little nervous.
As for theUserIdentity: The server supports Anonymous as well as UserPassword; The former is used in this case
I also issued a client.connect() call after first setting the endpoint to the one discovered earlier – same unsuccessful result.
I also tried to comment out all endpoint validation in the createSession call, but this didn’t help either
8:21, EET
December 21, 2011
Offline
I would suggest contacting the server vendor. I don’t know why UaExpert can connect, if the server is not accepting the endpoint.
8:25, EET
December 21, 2011
Offline
Or actually, you could try to use the ‘client.setValidateDiscoveredEndpoints(false)’ option to omit validations on the client side.
15:14, EET
February 21, 2014
Offline
I set client.setValidateDiscoveredEndpoints(false) before with no difference in behavior.
Asking the server vendor will probably be troublesome: Siemens WinCC => OPC UA Server Implementing company => UA SDK Vendor
15:42, EET
December 21, 2011
Offline
Hmm. Looks like the stack really requires that the certificate returned in CreateSession corresponds to the one returned by GetEndpoints. And the validateDiscoveredEndpoints=false does not skip that test, after all.
If you have the source of the stack, you can modify Client.createSession(SecureChannel, UnsignedInteger, Double, String, EndpointDescription[]) to use ‘null’ instead of endpoint.getServerCertificate() in the select() call.
9:51, EET
February 21, 2014
Offline
A brief update and some more questions…
The problem which prevented at least the connection was that the endpoints from the createSessionResponse did not contain the serverCertificate (why soever). So I disabled the respective checks and the session can now be established.
The SDK UAClient then requests all kinds of node information to initialize its cache. For some unknown reason, this leads to an error:
===> org.opcfoundation.ua.encoding.DecodingException: Bad_EncodingLimitsExceeded (code=0x80080000, description=”MaxArrayLength=65535 < 1869903169")
, timewise after the UAClient sends a ReadRequest for 10 attributes of node i=45. This may or may not be related.
As mentioned before, UAExpert as well as a C# (.NET) client have not problems at all.
To investigate further, would it be possible to disable the built-in functionality of the SDK’s UAClient so to not issue any readRequests on its own?
-HU
11:27, EET
December 21, 2011
Offline
Thanks for the update.
Seems like a real huge array to be decoded (186 million elements), which cannot be a real array in practice. Do you have any stack trace available for the error?
Unfortunately, it is not easy to disable all the built-in functionality. The UaClient tries to establish the UaNode objects to cache all information related to the data that it initialises.
You could disable the status check by setStatusCheckInterval(0), in case it’s related to that.
Another option is to simply increase the encoding limits with ‘client.getEndpointConfiguration().setMaxArrayLength(MaxArrayLength);’
(i=45) is the HasSubtype node, so an option is that there is a custom (reference?) type that is being used – I don’t know though which attribute could be so huge.
But yes, the Java client tries to be more clever than the others, but can fail, if the server behaves badly, making it look a bit less clever in the end.
12:13, EET
February 21, 2014
Offline
I put the log level to “trace” and logged the complete conversation.
I can send the file to an email address of your choice (cleaned up for the real public IP addresses).
Yesterday, I increased the MaxArrayLength from UnsignedShort.MAX_VALUE to Integer.MAX_VALUE, which just resulted in a error a little further down in the path… So I reverted this back to the “original”.
The “HasSubtype” references looks pretty normal in UAExpert. The only deviation is the “Bad_AttributeInvalid” for any ArrayDimensions. But this should only result in a Bad statusCode.
7:07, EET
February 21, 2014
Offline
Good morning,
after further analysis I found, that the BuildInfo Structure delivered by the WinCC server is creating the problems. After excluding the Server_ServerStatus_BuildInfo from the readServerStatus() method in the UAClient class, a connection is finally successfully possible. While this is a functional workaround, it would still be interesting what exactly creates the problems with the BuildInfo extension object.
So bottomline, the following changes have been applied in order to connect to a WinCC OPC UA server:
– disable certificate checks in the endpoints from the createSessionResponse()
– exclude Server_ServerStatus_BuildInfo from readServerStatus() in the UaClient class
Cheers, -HU
9:34, EET
December 21, 2011
Offline
Analysing the logs, reveals that the BuildInfo structure of the ServerStatus gives a “huge” DiagnosticInfoArray from the server. This is obviously a problem in the server and cannot easily be ignored in the Java SDK, except by disabling the ServerStatusCheck (as instructed above). Unfortunately, the Stack also closes the connection due to this error.
Most Users Ever Online: 1919
Currently Online: mithun
56 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
Heikki Tahvanainen: 402
hbrackel: 144
rocket science: 88
pramanj: 86
Francesco Zambon: 83
Ibrahim: 78
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
Member Stats:
Guest Posters: 0
Members: 738
Moderators: 7
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1524
Posts: 6450
Newest Members:
jonathonmcintyre, fannielima, kristiewinkle8, rust, christamcdowall, redaahern07571, nigelbdhmp, travistimmons, AnnelCib, dalenegettingerModerators: Jouni Aro: 1026, Pyry: 1, Petri: 0, Bjarne Boström: 1026, Jimmy Ni: 26, Matti Siponen: 346, Lusetti: 0
Administrators: admin: 1
