Could connect using v1.3.4 but can not connect using v1.3.6, the connection sequence has changed

[robert-johnston]

I'm using the amalgamated source code files in a project. The early connection sequence for the client seems to have changed and my code now fails to connect to my test server. When using open62541 v1.3.4 it works but when I substituted open62541 v1.3.6 the connection fails because it seems to try an http endpoint even though I specified a TCP endpoint and gives a BadTcpEndpointUrlInvalid status. I am unable to connect to my test server using v1.3.6.

The simplest code that shows the problem:

#include "open62541.h"

int main(int argc, char* argv[])
{
UA_Client* client = UA_Client_new();
UA_ClientConfig_setDefault(UA_Client_getConfig(client));
UA_StatusCode retval = UA_Client_connect(client, "opc.tcp:https://skkynet-think:62541/Quickstarts/ReferenceServer");

if (retval != UA_STATUSCODE_GOOD)
{
    UA_Client_delete(client);
    return (int)retval;
}

UA_Client_delete(client);
return EXIT_SUCCESS;

}

The output log when using v1.3.4 (working):
[2023-06-01 17:04:45.912 (UTC-0400)] warn/userland AcceptAll Certificate Verification. Any remote certificate will be accepted.
[2023-06-01 17:04:45.931 (UTC-0400)] info/channel Connection 360 | SecureChannel 270 | SecureChannel opened with SecurityPolicy http:https://opcfoundation.org/UA/SecurityPolicy#None and a revised lifetime of 600.00s
[2023-06-01 17:04:45.932 (UTC-0400)] info/client Client Status: ChannelState: Open, SessionState: Closed, ConnectStatus: Good
[2023-06-01 17:04:45.934 (UTC-0400)] info/client Rejecting endpoint 0: security policy not available
[2023-06-01 17:04:45.934 (UTC-0400)] info/client Selected endpoint 1 in URL opc.tcp:https://localhost:62541/Quickstarts/ReferenceServer with SecurityMode None and SecurityPolicy http:https://opcfoundation.org/UA/SecurityPolicy#None
[2023-06-01 17:04:45.934 (UTC-0400)] info/client Selected UserTokenPolicy 0 with UserTokenType Anonymous and SecurityPolicy http:https://opcfoundation.org/UA/SecurityPolicy#Basic256
[2023-06-01 17:04:45.936 (UTC-0400)] info/client Client Status: ChannelState: Open, SessionState: Created, ConnectStatus: Good
[2023-06-01 17:04:45.939 (UTC-0400)] info/client Client Status: ChannelState: Open, SessionState: Activated, ConnectStatus: Good
[2023-06-01 17:04:45.940 (UTC-0400)] info/client Client Status: ChannelState: Closed, SessionState: Closed, ConnectStatus: Good

Here is the short WireShark trace.
open62541-1.3.4_trace.zip
The server port number is 62541

The output log when using v1.3.6 (shows not working):
[2023-06-01 17:08:48.432 (UTC-0400)] warn/userland AcceptAll Certificate Verification. Any remote certificate will be accepted.
[2023-06-01 17:08:48.455 (UTC-0400)] info/channel Connection 368 | SecureChannel 271 | SecureChannel opened with SecurityPolicy http:https://opcfoundation.org/UA/SecurityPolicy#None and a revised lifetime of 600.00s
[2023-06-01 17:08:48.456 (UTC-0400)] info/client Client Status: ChannelState: Open, SessionState: Closed, ConnectStatus: Good
[2023-06-01 17:08:48.457 (UTC-0400)] info/client Use the EndpointURL http:https://localhost:62540/Quickstarts/ReferenceServer/discovery returned from FindServers
[2023-06-01 17:08:48.457 (UTC-0400)] info/client Client Status: ChannelState: Closed, SessionState: Closed, ConnectStatus: Good
[2023-06-01 17:08:48.460 (UTC-0400)] error/channel Connection 388 | SecureChannel 0 | Received an ERR response with StatusCode BadTcpEndpointUrlInvalid and the following reason:
[2023-06-01 17:08:48.461 (UTC-0400)] warn/channel Connection 388 | SecureChannel 0 | Receiving the response failed with StatusCode Good
[2023-06-01 17:08:48.461 (UTC-0400)] info/client Client Status: ChannelState: Closed, SessionState: Closed, ConnectStatus: BadConnectionClosed

Here is the short WireShark trace:
open62541-1.3.6_trace.zip
The server port number is 62541

The test server that I am trying to connect to is the OPC Foundation Sample Applications QuickStarts Reference Server.
I've attached the Sample Application installer (Windows) and the Reference Server can be started from the main menu.
OPC UA Sample Applications 1.02.zip

[elcapitanu]

I had a similar problem.

After cloning the recent version of op62541 my opc-ua client coulnd't connect to server, but it worked fine in an older version.

I was using "UA_StatusCode status = UA_Client_connect(client, "opc.tcp:https://localhost:4840");", then I changed "localhost" to my actual IPV4 address ("UA_StatusCode status = UA_Client_connect(client, "opc.tcp:https://IPV4address:4840");") and it started working again.

I don´t know if this is an actual solution for the problem, but I hope this helps.

[jpfr]

In 1.3 we added the feature to first call FindServers and then reconnect.
Because Prosys requires the use of the DiscoveryUrl in the initial HEL message that can only be found that way.
We will look into this.

[genuaboro]

I also ran into this issue after switching from open62541 1.3.4 to 1.3.6.

From my understanding this will happen if the returned servers don't match the used endpoint URL (e. g. if you connect via IP but the server returns the DNS name in the URL or vice versa) and the first URL is unusable (e. g. not "opc.tcp" but "http").

I think it makes sense if open62541 would skip URLs / protocols that it can't handle in ua_client_connect.c:responseFindServers().

[robert-johnston]

When I connect to the OPC Foundataion Quickstarts Reference server I specify in the connect command that I want to connect to its opc.tcp:https://address and the new use of FindServers (the FindServers uses that TCP address) but returns an endpoint that is http:https://address and the connect fails because it is not an opc.tcp address URL. I would expect that if I connect with a TCP address that the FindServers will return an TCP address that is valid (specifically the one I issued because that is a valid endpoint on the server). I'm specifying a valid URL endpoint and 1.3.4 could connect just fine, 1.3.6 does not. The only command I issue is UA_Client_connect() there is no adjustments that can be made.

…

On Thu, Aug 17, 2023 at 9:41 AM genuaboro ***@***.***> wrote: I also ran into this issue after switching from open62541 1.3.4 to 1.3.6. From my understanding this will happen if the returned servers don't match the used endpoint URL (e. g. if you connect via IP but the server returns the DNS name in the URL or vice versa) and the first URL is unusable (e. g. not "opc.tcp" but "http"). I think it makes sense if open62541 would skip URLs / protocols that it can't handle in ua_client_connect.c:responseFindServers(). — Reply to this email directly, view it on GitHub <#5801 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJKUGMYZE3S55HY4K244NQTXVYNRPANCNFSM6AAAAAAYXQQXPY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[genuaboro]

To be fair I think the new behaviour does fix issues with servers
where you couldn't connect before (or at least had to specify the
complete URL). I also ran into this issue with servers before.

I would expect that if I connect with a TCP address that the
FindServers will return an TCP address that is valid (specifically
the one I issued because that is a valid endpoint on the server).

FindServers does return a TCP address, open62541 just doesn't use it -
which I think is an easy fix in this specific case.

The only command I issue is UA_Client_connect() there is no
adjustments that can be made.

If you do connect locally, you probably have to connect via
"opc.tcp:https://localhost:62541/Quickstarts/ReferenceServer" for the
moment. But in general this is also the biggest issue for me at the
moment. If a server is misconfigured, you may not be able to connect
to it anymore.

[jpfr]

There is now a unit test to reproduce servers with funky DiscoveryUrl.
#5964

Is this the server you are using?
https://github.com/OPCFoundation/UA-.NETStandard-Samples/tree/master/Samples/Server

[genuaboro]

Is this the server you are using? https://github.com/OPCFoundation/UA-.NETStandard-Samples/tree/master/Samples/Server

Yes, that should be it.

[genuaboro]

Is this the server you are using? https://github.com/OPCFoundation/UA-.NETStandard-Samples/tree/master/Samples/Server

Yes, that should be it.

I'm sorry. I was mistaken. We are using https://github.com/OPCFoundation/UA-.NETStandard/tree/master/Applications/ConsoleReferenceServer in tests. I don't know if that makes a difference.

[robert-johnston]

The OPC Foundation Quickstarts Reference server I am trying to connect with is supplied as part of the sample applications release. I don't have a link to the source because this has been provided to me at work: "opc-ua-1.02-.net-sample-applications-setup-336.0-20150630" . I did supply the full application in the Github issues post and will attach a link to my copy here: OPC UA Sample Applications 1.02.zip <https://skkynet-my.sharepoint.com/:u:/p/robert_johnston/EQ203D3_wqxKgOxVau3qaDoBk1pPk7L5Tet9M5V7ztgIgQ?e=U4QC7o> It seems that Findservers returns two URLs the http:https:// and the opc.tcp:https:// but open62541 does not use the tcp URL which is the correct one. Thank you for looking into this.

…

On Mon, Aug 21, 2023 at 11:22 AM genuaboro ***@***.***> wrote: Is this the server you are using? https://github.com/OPCFoundation/UA-.NETStandard-Samples/tree/master/Samples/Server Yes, that should be it. I'm sorry. I was mistaken. We are using https://github.com/OPCFoundation/UA-.NETStandard/tree/master/Applications/ConsoleReferenceServer in tests. I don't know if that makes a difference. — Reply to this email directly, view it on GitHub <#5801 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJKUGM54LBILIPHCUU7YT73XWN4KNANCNFSM6AAAAAAYXQQXPY> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jpfr]

Could reproduce and solve.
The fix is in #5971 and will be forward-ported to 1.4 and master as well.