InvalidServerEndpointException when connecting to KepserverEX 6.9 | OPC UA SDK for JavaProsys Forum

Please consider registering
guest

Forum

OPC UA SDK for Java
sp_ArrowRight

InvalidServerEndpointException when connecting to KepserverEX 6.9

Topic RSS

InvalidServerEndpointException when connecting to KepserverEX 6.9

December 2, 2020
16:11, EET

hordurth

Member

Members

Forum Posts: 3

Member Since:
July 25, 2018

Offline

Hello,

I am using the Java SDK to connect to KepserverEx and have been doing so successfully for years, works great.
Yesterday I set up a new Windows VPS, installed KepserverEx 6.9.572 on it, enabled OpcUA server and so on like I always do. Then tried to connect with some code that was working fine against KepserverEx 6.8.796 on another Windows VPS, and got an InvalidServerEndpointException.
After figuring out what this meant I can connect to the server by setting UaClient.setValidateDiscoveredEndpoints() to false.
However I can’t see from the information logged by the SDK what the problem is. I have pasted it below in case anyone can explain it to me.
The server has 2 endpoints which are created by default by KepserverEx on setup:
– opc.tcp://127.0.0.1:49320
– opc.tcp://myserver:49320

Here is the exception log from the SDK. Everything looks exactly the same as far as I can see:
The endpoint received from GetEndpoints is not in the endpoints of CreateSessionResponse.
Endpoint=
EndpointDescription [EndpointUrl=”opc.tcp://127.0.0.1:49320″, Server=”null”, ServerCertificate=”null”, SecurityMode=”None”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”, UserIdentityTokens=”[UserTokenPolicy [PolicyId=”UserName”, TokenType=”UserName”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15″], UserTokenPolicy [PolicyId=”Anonymous”, TokenType=”Anonymous”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”]]”, TransportProfileUri=”http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”, SecurityLevel=”16″]

GetEndpoints returned endpoints=[
EndpointDescription [EndpointUrl=”opc.tcp://127.0.0.1:49320″, Server=”null”, ServerCertificate=”null”, SecurityMode=”None”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”, UserIdentityTokens=”[UserTokenPolicy [PolicyId=”UserName”, TokenType=”UserName”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15″], UserTokenPolicy [PolicyId=”Anonymous”, TokenType=”Anonymous”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”]]”, TransportProfileUri=”http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”, SecurityLevel=”16″],

EndpointDescription [EndpointUrl=”opc.tcp://mynewserver:49320″, Server=”null”, ServerCertificate=”null”, SecurityMode=”None”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”, UserIdentityTokens=”[UserTokenPolicy [PolicyId=”UserName”, TokenType=”UserName”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15″], UserTokenPolicy [PolicyId=”Anonymous”, TokenType=”Anonymous”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”]]”, TransportProfileUri=”http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”, SecurityLevel=”16″]
]

CreateSessionResponse endpoints=[
EndpointDescription [EndpointUrl=”opc.tcp://mynewserver:49320″, Server=”null”, ServerCertificate=”null”, SecurityMode=”None”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”, UserIdentityTokens=”[UserTokenPolicy [PolicyId=”UserName”, TokenType=”UserName”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#Basic128Rsa15″], UserTokenPolicy [PolicyId=”Anonymous”, TokenType=”Anonymous”, IssuedTokenType=”null”, IssuerEndpointUrl=”null”, SecurityPolicyUri=”http://opcfoundation.org/UA/SecurityPolicy#None”]]”, TransportProfileUri=”http://opcfoundation.org/UA-Profile/Transport/uatcp-uasc-uabinary”, SecurityLevel=”16″]
]

Cheers,

Hordur Th.

December 2, 2020
18:06, EET

Bjarne Boström

Moderator

Moderators

Forum Posts: 1032

Member Since:
April 3, 2012

Offline

Hi,

Unless I did read that wrong, well, basically the CreateSessionResponse has one vs. two from the GetEndpoints.

https://reference.opcfoundation.org/v104/Core/docs/Part4/5.6.2/ (for CreateSession)

A)
“The Server returns its EndpointDescriptions in the response. Clients use this information to determine whether the list of EndpointDescriptions returned from the DiscoveryEndpoint matches the Endpoints that the Server has. If there is a difference then the Client shall close the Session and report an error.”
+
B)
“The Server returns all EndpointDescriptions for the serverUri specified by the Client in the request. The Client only verifies EndpointDescriptions with a transportProfileUri that matches the profileUri specified in the original GetEndpoints request. A Client may skip this check if the EndpointDescriptions were provided by a trusted source such as the Administrator.”
+
C, for the serverUri parameter)
serverUri String This value is only specified if the EndpointDescription has a gatewayServerUri.
This value is the applicationUri from the EndpointDescription which is the applicationUri for the underlying Server. The type EndpointDescription is defined in 7.10.

Since basically no-one ever has used gatewayServerUris, at least that I know of, I would assume that to be null and not influence the situation. Also the TransportProfileUri is the same in both endpoints, so no difference there.

In general, this has been a problem sometimes, I’m not ruling out a potential bug in our impl, but it sort of would seem that the server should be giving the endpoint with the ip number as well here. (And in general, not saying that it makes like any sense that it would have to be returned, but as far as I’m understood that the check should check that they are equal, minus the non-recommended fields specified in the CreateSessionResponse part).

Any comments?

P.S. In general we typically just have an endpoint with the hostname. But it is a separate discussion or post why this is the case, but basically the EndpointUrl in our opinion should only be used for connection, if you do not have anything better at hand. This is because they typically wont work behind NATs etc, thus Clients are basically forced to use their original connection url anyway (or replace the hostname portion of the endpointurls). Though if obtained from a DiscoveryServer, the endpointurl might be all you have.

All RSS

Forum Timezone: Europe/Helsinki

Most Users Ever Online: 1919

Currently Online:
44 Guest(s)

Currently Browsing this Page:
1 Guest(s)