Online Forums
Technical support is provided through Support Forums below. Anybody can view them; you need to Register/Login to our site (see links in upper right corner) in order to Post questions. You do not have to be a licensed user of our product.
Please read Rules for forum posts before reporting your issue or asking a question. OPC Labs team is actively monitoring the forums, and replies as soon as possible. Various technical information can also be found in our Knowledge Base. For your convenience, we have also assembled a Frequently Asked Questions page.
Do not use the Contact page for technical issues.
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- EasyUAClient - browsing, user authentication with a certificate, etc.
EasyUAClient - browsing, user authentication with a certificate, etc.
05 Nov 2014 13:13 - 05 Nov 2014 13:15 #2490
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Here are the details that I have promised. There are actually 2 issues in one:
1. The client first connects to a discovery endpoint of the server, and obtains a list of the actual endpoints that we can select from (they may have different protocols, security settings etc.). Normally, all these endpoints returned by the server will have the same "domain name" as the discovery endpoint itself. For example, when accessing a server through opc.tcp://myhost.mydomain.com:4841, all the endpoints returned will be on "myhost.mydomain.com". The client then selects the best endpoint, and attempts to connect to it using the URL provided by the server for *that* particular server.
In your case, however, the server is not aware that it should be accessed through "myhost.mydomain.com", and is configured to return a local name of the machine in its endpoints. The available endpoints returned by the server then actually look something like e.g. "opc.tcp://mylocalname:4841" (I am not posting your actual data here - not sure about the confidentiality of it - can send it offline). Of course, "mylocalname" is not known outside the local network, and attempts to connect to it fail, with an error like "unknown host".
This is actually a well known situation in the OPC UA world. One solution is to configure the server so that it returns the actual host name that clients can use to connect to it. Clients can also (try to) cope with it by replacing the domain name in the endpoints returned by the server by the host name of the original discovery endpoint. We have this functionality implemented, and it can be enabled by the EnforceSameSite setting I have described. I tried to investigate why it is not enabled by default in version 5.31, but did not come to a definitive answer. We are probably going to enable it by default in version 5.32.
2. There is a second issue as well - when the host name resolution failed (in this particular scenario - with Security = None), the connection code proceeded to a second attempt (with non-null client certificate), and hanged. This means that you should have immediately received an "unknown host" exception, but instead you received a time-out exception, much later. My investigation about this currently points to a problem inside the OPC Foundation's .NET stack/SDK, and I have filed a bug report and will work within OPC Foundation to get it resolved.
Best regards
1. The client first connects to a discovery endpoint of the server, and obtains a list of the actual endpoints that we can select from (they may have different protocols, security settings etc.). Normally, all these endpoints returned by the server will have the same "domain name" as the discovery endpoint itself. For example, when accessing a server through opc.tcp://myhost.mydomain.com:4841, all the endpoints returned will be on "myhost.mydomain.com". The client then selects the best endpoint, and attempts to connect to it using the URL provided by the server for *that* particular server.
In your case, however, the server is not aware that it should be accessed through "myhost.mydomain.com", and is configured to return a local name of the machine in its endpoints. The available endpoints returned by the server then actually look something like e.g. "opc.tcp://mylocalname:4841" (I am not posting your actual data here - not sure about the confidentiality of it - can send it offline). Of course, "mylocalname" is not known outside the local network, and attempts to connect to it fail, with an error like "unknown host".
This is actually a well known situation in the OPC UA world. One solution is to configure the server so that it returns the actual host name that clients can use to connect to it. Clients can also (try to) cope with it by replacing the domain name in the endpoints returned by the server by the host name of the original discovery endpoint. We have this functionality implemented, and it can be enabled by the EnforceSameSite setting I have described. I tried to investigate why it is not enabled by default in version 5.31, but did not come to a definitive answer. We are probably going to enable it by default in version 5.32.
2. There is a second issue as well - when the host name resolution failed (in this particular scenario - with Security = None), the connection code proceeded to a second attempt (with non-null client certificate), and hanged. This means that you should have immediately received an "unknown host" exception, but instead you received a time-out exception, much later. My investigation about this currently points to a problem inside the OPC Foundation's .NET stack/SDK, and I have filed a bug report and will work within OPC Foundation to get it resolved.
Best regards
Last edit: 05 Nov 2014 13:15 by support. Reason: typo corr.
Please Log in or Create an account to join the conversation.
05 Nov 2014 10:56 #2489
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
I am glad it works now. Can you please keep the access open for some time, I am doing some more tests and want to finalize my investigation.
Best regards
Best regards
Please Log in or Create an account to join the conversation.
05 Nov 2014 10:15 #2488
by g.aino
Replied by g.aino on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Thank you, now works!
This explain why I'd no problem with local server. It was mandatory to pass the host information received at first step to work task (if I understand the meaning of solved problem).
Grazie
This explain why I'd no problem with local server. It was mandatory to pass the host information received at first step to work task (if I understand the meaning of solved problem).
Grazie
Please Log in or Create an account to join the conversation.
05 Nov 2014 09:14 #2487
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
[Nov 4. 2014: Internet connection information provided by the client]
Dear Sir,
in order to resolve the connection problem, change the EnforceSameSite parameter in the EndpointSelectionPolicy to 'true'; the affected piece in your source code will then look like this:
I will post more detailed explanation about the issue later.
Best regards
Dear Sir,
in order to resolve the connection problem, change the EnforceSameSite parameter in the EndpointSelectionPolicy to 'true'; the affected piece in your source code will then look like this:
EndpointSelectionPolicy =
{
AllowedMessageSecurityModes = UAMessageSecurityModes.SecurityNone,
EnforceSameSite = true,
},I will post more detailed explanation about the issue later.
Best regards
The following user(s) said Thank You: g.aino
Please Log in or Create an account to join the conversation.
21 Oct 2014 09:42 - 21 Oct 2014 09:44 #2461
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
I agree with you that the fact that UA Sample Client works is a bit bothering. For this reason. I would like to get to the true reason of the problem as well.
Yes, there may be differences. For example, the UA Sample Client is probably not making the first call to CreateSession with no client certificate - because, I believe, the ability to omit the certificates with no security has been added in a later version of the UA spec, for certain very limited, embedded UA server profiles. This may even confuse the server, or it may not be correctly handled in the client side of the stack - there is no absolute certainty at this point.
As to whether our client is more "relaxed" or "strict", we find ourselves between two stones here. Ideally we would like to be as relaxed as possible. But we decided to certify our OPC client for compliance, and it has forced us to implement checks that are more strict than we ever wanted. The OPC Sample Client is *not* compliant. We have, however, resolved this by having configurable settings, and defaulting to a reasonably relaxed configuration. Whoever wants the full compliance can switch to it easily. Therefore you (and we) should (ideally) be OK in this matter, with the QuickOPC product as it comes out of the box.
If we get an ability to connect to the server, we would be able to debug into finer details, and either find a problem on our side, OR provide a "definitive" log (such as full TCP trace) proving a problem on the server side.
For a test connection from our side, our outbound IP would be 88.146.100.93 (or even better, 88.146.100.80/28).
There is one more option I am thinking of: The OPC Foundation provides a tool (intended for compliance testing primarily) that can serve as an analyzer, catching the communication between the client and the server. I will need to check whether it supports this particular scenario, and whether we (as OPC Foundation Members) would be allowed to pass the tool onto you for this particular test case. In case the answer is positive, would you be willing to deploy the tool and test with it?
Also, next month we are going to the annual OPC Interoperability Workshop (in Nuremberg) where we will test with a large number of servers. We do this every year anyway. Obviously this gives a chance to catch the same issue if the server appears on the floor, or a server that is built using the same technology/codebase. Can you reveal which OPC toolkit has been used to build the server (or which OPC UA stack, if no toolkit was involved)?
Yes, there may be differences. For example, the UA Sample Client is probably not making the first call to CreateSession with no client certificate - because, I believe, the ability to omit the certificates with no security has been added in a later version of the UA spec, for certain very limited, embedded UA server profiles. This may even confuse the server, or it may not be correctly handled in the client side of the stack - there is no absolute certainty at this point.
As to whether our client is more "relaxed" or "strict", we find ourselves between two stones here. Ideally we would like to be as relaxed as possible. But we decided to certify our OPC client for compliance, and it has forced us to implement checks that are more strict than we ever wanted. The OPC Sample Client is *not* compliant. We have, however, resolved this by having configurable settings, and defaulting to a reasonably relaxed configuration. Whoever wants the full compliance can switch to it easily. Therefore you (and we) should (ideally) be OK in this matter, with the QuickOPC product as it comes out of the box.
If we get an ability to connect to the server, we would be able to debug into finer details, and either find a problem on our side, OR provide a "definitive" log (such as full TCP trace) proving a problem on the server side.
For a test connection from our side, our outbound IP would be 88.146.100.93 (or even better, 88.146.100.80/28).
There is one more option I am thinking of: The OPC Foundation provides a tool (intended for compliance testing primarily) that can serve as an analyzer, catching the communication between the client and the server. I will need to check whether it supports this particular scenario, and whether we (as OPC Foundation Members) would be allowed to pass the tool onto you for this particular test case. In case the answer is positive, would you be willing to deploy the tool and test with it?
Also, next month we are going to the annual OPC Interoperability Workshop (in Nuremberg) where we will test with a large number of servers. We do this every year anyway. Obviously this gives a chance to catch the same issue if the server appears on the floor, or a server that is built using the same technology/codebase. Can you reveal which OPC toolkit has been used to build the server (or which OPC UA stack, if no toolkit was involved)?
Last edit: 21 Oct 2014 09:44 by support.
Please Log in or Create an account to join the conversation.
21 Oct 2014 09:17 #2460
by mabian
Replied by mabian on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Hello,
first of all, once again, huge thanks for following this case with such a high level of commitment and supportiveness.
I understand the hard work that hides below this kind of blind investigation - being unable to test directly must be utterly frustrating.
We're trying to involve the server mantainer to allow external connections (have you got a static outbound IP so that we can add it to a firewall rule?) so that you can check with your development environment where the problem actually lies.
As already pointed by the original poster, I'm a bit surprised for the fact that the UA Sample Client is able to deal with this same server apparently without problems.
This leads to think there's something different in your code (maybe something less "relaxed" for the sake of more strict standard compliancy?)
Also, could the different port configuration between the example server and our test server explain somehow the different behaviours?
Thank you very much,
Mario
first of all, once again, huge thanks for following this case with such a high level of commitment and supportiveness.
I understand the hard work that hides below this kind of blind investigation - being unable to test directly must be utterly frustrating.
We're trying to involve the server mantainer to allow external connections (have you got a static outbound IP so that we can add it to a firewall rule?) so that you can check with your development environment where the problem actually lies.
As already pointed by the original poster, I'm a bit surprised for the fact that the UA Sample Client is able to deal with this same server apparently without problems.
This leads to think there's something different in your code (maybe something less "relaxed" for the sake of more strict standard compliancy?)
Also, could the different port configuration between the example server and our test server explain somehow the different behaviours?
Thank you very much,
Mario
Please Log in or Create an account to join the conversation.
20 Oct 2014 15:45 #2458
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
The input argument to DiscoverServer is not an URI, it is just a host name. See www.opclabs.com/files/onlinedocs/QuickOpc/Latest/Reference/Q...380-9151-c4d4-ce79a1b5153e.htm . In your example, it should be "my.discoveryserver.it".
Regarding the connection problem, I have explained our position earlier already. The logs indicate a server problem; with approx. 90% likeliness, it is a server problem, the remaining 10% could point to a client problem. But we have done our analysis and it looks like that the call is blocked on the server. The fact that the server works in one situation is not a proof that it is bug-less. The "ball" is on the server developer's side now. Either they should look into what is happening on the server and supply their own logs, or you need to provide us with remote access to the server, so that we can at least reproduce the problem ourselves. Without this, we cannot make further on this issue.
Even if the problem was on the client side, it would be in the .NET stack that we take from OPC Foundation, so we have only quite limited control over what happens inside. QuickOPC version 5.31 is built with UA stack version 1.02.334.5. The upcoming QuickOPC 5.32 will be built with the newest version of the UA stack (1.02.334.6), so if we could reproduce the problem, we would also be able to try out the newest stack version.
Regarding the connection problem, I have explained our position earlier already. The logs indicate a server problem; with approx. 90% likeliness, it is a server problem, the remaining 10% could point to a client problem. But we have done our analysis and it looks like that the call is blocked on the server. The fact that the server works in one situation is not a proof that it is bug-less. The "ball" is on the server developer's side now. Either they should look into what is happening on the server and supply their own logs, or you need to provide us with remote access to the server, so that we can at least reproduce the problem ourselves. Without this, we cannot make further on this issue.
Even if the problem was on the client side, it would be in the .NET stack that we take from OPC Foundation, so we have only quite limited control over what happens inside. QuickOPC version 5.31 is built with UA stack version 1.02.334.5. The upcoming QuickOPC 5.32 will be built with the newest version of the UA stack (1.02.334.6), so if we could reproduce the problem, we would also be able to try out the newest stack version.
Please Log in or Create an account to join the conversation.
20 Oct 2014 12:20 #2457
by g.aino
Replied by g.aino on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Hello,
below the code
Thank you,
Regards
below the code
string strUri = "opc.tcp://my.discoveryserver.it:4841";
EasyUAClient.LogEntry += EasyUAClient_LogEntry;
// Instantiate the client object
EasyUAClient easyUAClient = new EasyUAClient()
{
Isolated = true,
IsolatedParameters =
{
Session =
{
CertificateAcceptancePolicy = { AcceptAnyCertificate = true, AllowUserAcceptCertificate = false },
EndpointSelectionPolicy =
{
AllowedMessageSecurityModes = UAMessageSecurityModes.SecurityNone
},
UserIdentity =
{
UserNameToken = { UserName = "myUserName", Password = "MyPassword" }
},
SelectBestEndpoint = true
},
}
};
var test = easyUAClient.DiscoverServers(strUri);Thank you,
Regards
Please Log in or Create an account to join the conversation.
20 Oct 2014 09:38 #2456
by support
Replied by support on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Hello,
please post here the statement you use to call DiscoverServers, including the argument value.
Thank you
please post here the statement you use to call DiscoverServers, including the argument value.
Thank you
The following user(s) said Thank You: g.aino
Please Log in or Create an account to join the conversation.
20 Oct 2014 08:06 - 20 Oct 2014 09:09 #2455
by g.aino
Replied by g.aino on topic EasyUAClient - browsing, user authentication with a certificate, etc.
Hi, I found right your first observation, but for the second I point off that we're using SecurityPolicy=SecurityNone (not SecurityPolicy=none), as you suggested in a previous post.
Another point is that connection and data reading works correctly with standard example UA Sample Client supplied in the installation package.
The session initialization code is as follows:
In addition, I report a different problem happens if instead of reading data using easyUAClient.BrowsingDataNodes(...) we try easyUAClient.DiscoverApplications(strUri) or easyUAClient.DiscoverServers(strUri): below the InnerException thrown
Unfortunately, we can't access customer server (as we said in previous posts), but I think the problem is not definitely here, because as said standard example works.
Is there something we can do to workaround this problem?
Hope it is helpful,
Regards
Another point is that connection and data reading works correctly with standard example UA Sample Client supplied in the installation package.
The session initialization code is as follows:
string strUri = "discoveryserver.com"
EasyUAClient.LogEntry += EasyUAClient_LogEntry;
// Instantiate the client object
EasyUAClient easyUAClient = new EasyUAClient()
{
Isolated = true,
IsolatedParameters =
{
//Discovery = { CheckApplicationDescription = true, DiscoveryTimeout = 10000 },
//Host = { ParallelDiscovery = true, DiscoveryUriTemplateStrings = new string[] { strUri }, ParallelDiscovery = false },
Session =
{
CertificateAcceptancePolicy = { AcceptAnyCertificate = true, AllowUserAcceptCertificate = false },
EndpointSelectionPolicy =
{
AllowedMessageSecurityModes = UAMessageSecurityModes.SecurityNone,
//AllowZeroSecurityLevel = true,
//MessageSecurityPreference = OpcLabs.BaseLib.Sign.None
},
UserIdentity =
{
UserNameToken = { UserName = "crosetti", Password = "andrea" }
},
//AllowEndpointDomainPrompt = false,
//CheckEndpointDomain = true, //Come da http://www.opclabs.com/forum/ua-browsing/1299-browse-data-nodes?start=12
//DiagnosticsMasks = UADiagnosticsMasks.All,
SelectBestEndpoint = true,
//UpdateEndpointBeforeConnect = true
SessionConnectTimeout = 20000
},
}
};
UAEndpointDescriptor uaEndpointDescriptor = new UAEndpointDescriptor(strUri);In addition, I report a different problem happens if instead of reading data using easyUAClient.BrowsingDataNodes(...) we try easyUAClient.DiscoverApplications(strUri) or easyUAClient.DiscoverServers(strUri): below the InnerException thrown
System.Net.Sockets.SocketException: The requested name is valid, but no data of the requested type was found (SocketErrorCode=NoData, NativeErrorCode=11004)
at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
at System.Net.Dns.GetHostAddresses(String hostNameOrAddress)
at Opc.Ua.Bindings.TcpMessageSocket.BeginConnect(Uri endpointUrl, AsyncCallback callback, Object state)
at Opc.Ua.Bindings.TcpClientChannel.BeginConnect(Uri url, Int32 timeout, AsyncCallback callback, Object state)
at Opc.Ua.Bindings.TcpClientChannel.BeginSendRequest(IServiceRequest request, Int32 timeout, AsyncCallback callback, Object state)
at Opc.Ua.Bindings.TcpTransportChannel.BeginSendRequest(IServiceRequest request, AsyncCallback callback, Object callbackData)
at Opc.Ua.Bindings.TcpTransportChannel.SendRequest(IServiceRequest request)
at Opc.Ua.DiscoveryClient.FindServers(RequestHeader requestHeader, String endpointUrl, StringCollection localeIds, StringCollection serverUris, ApplicationDescriptionCollection& servers)
at Opc.Ua.DiscoveryClient.FindServers(StringCollection serverUris)
at OpcLabs.EasyOpc.UA.Toolkit.UADiscoverySession.<>c__DisplayClassb.<FindServers>b__8()
at OpcLabs.EasyOpc.UA.Toolkit.UAEngineBase.PerformSdkAction(UASdkCallType callType, Func`1 usingFunction, String name, Action sdkAction)
Unfortunately, we can't access customer server (as we said in previous posts), but I think the problem is not definitely here, because as said standard example works.
Is there something we can do to workaround this problem?
Hope it is helpful,
Regards
Last edit: 20 Oct 2014 09:09 by g.aino. Reason: Added another exception found in different trial
Please Log in or Create an account to join the conversation.
Moderators: support
- Forum
- Discussions
- QuickOPC-UA in .NET
- Connections, Reconnections, Certificates
- EasyUAClient - browsing, user authentication with a certificate, etc.
Time to create page: 0.082 seconds