Thank you - this is precisely what I needed.

The server certificate could not be validated on the client side, but since you have set the client to accept all certificates, it gets accepted anyway - that's the "fallback method". In that sense, I do not see anything wrong or unexpected there.

The important lines of the log are these - near the end:

3128 - 16:56:50.557 CreateSession Called. RequestHandle=1, PendingRequestCount=1
3128 - 16:56:53.167 CreateSession Completed. RequestHandle=1, PendingRequestCount=0
3128 - 16:56:53.198 Create session failed with client certificate NULL. No such host is known
3128 - 16:56:53.198 CreateSession Called. RequestHandle=2, PendingRequestCount=1
3128 - 17:06:50.574 ***EXCEPTION*** BadRequestTimeout
3128 - 17:06:53.199 ***EXCEPTION*** BadRequestTimeout
3128 - 17:06:53.215 CreateSession Completed. RequestHandle=2, PendingRequestCount=0

What is means is that we have first tried to call the CreateSession service on the server with a NULL client certificate (because the security policy = None). When this fails (which is allowed), we re-try the CreateSession with the client certificate we have. This call blocks for 10 minutes on the server side, and afterwards it fails with "BadRequestTimeout" error..

You need to resolve the problem on the server side.

Best regards

---> ADDED LATER:
1. Actually, the 10 minutes are probably not caused by the server - it is yet another ("operation") timeout, this time on the UA Stack level.
2. There is one remaining (but unlikely) thing I need to check, whether the "block" cannot be on our side. In case I find anything, I will post it here.

The new build (5.31.1424.1) is ready now. Please download it from www.opclabs.com/products/quickopc/downloads/download/form/4-quickopc-download-form , install, and enable the extended tracing as described in the previous post.

Then please rebuild your app and make the test again. Of course I would be interested in seeing the generated log.

Best regards

Thank you - OK so it works with the sample server, we need to go deeper.

Please read the document attached to this post (plus the mentioned configuration file contents is attached as well). The QuickOPC build described in the document is not yet ready; if all goes well, it should be available tomorrow.

Best regards

The likeliest cause of this appears to be some blocked call inside the server, but of course there is no certainty until we obtain enough information about it.

We have deeper layers of diagnostics inside the component, but they are currently only for our internal purposes and not exposed to the developer. What I plan to do is to make it possible for them be enabled for customer usage as well, and make a new build of QuickOPC that you will then run and obtain further info. This will, however, need some time. Currently I think it could be ready on Friday, or after the weekend.

An additional question: What happens if you replace your server's endpoint URL with that of the test server installed with the product (e.g. opc.tcp://localhost:51210/UA/SampleServer )?.

Thank you.

Do you have access to the server side? Can you check whether there isn't something on the server, waiting e.g. for user input?

I am asking this question because (similarly to clients), some servers behave in this way - the first time they are presented with a client application certificate, and it cannot be found or validated they show a dialog box, prompting the user to confirm whether the certificate should be accepted. This can block the server side.

Please indicate whether you are using QuickOPC version 5.23 or 5.31. Based on this, I will check whether we can enable some additional diagnostics.