UA Expert unable to resolve hostname, but python and windows are

[Nathan.Hickling]

I am a developer currently in the process of implementing an OPC UA Server on our device and we are having an issue where UA Expert will sometimes report BadHostUnknown if the security settings are set to None/None. Enabling a supported security mode currently appears to always work.

While in this state, our python opc ua tests (based on asyncua), ping and SMB can resolve the target even while UA Expert is trying and failing to connect. Retrying the connection eventually works but it can take a significant amount of time.

Using an IP address instead of a machine name so far has always succeeded, but as we expect to run in network environments where IP addresses can change frequently just using IP addresses is not an acceptable solution long term.

If I enable tracing and reproduce the issue, the trace file includes the following excerpt:

06:54:58.004Z|5|590C* Ctor UaDiscovery
06:54:58.004Z|6|590C* --> UaDiscovery::getEndpoints simplified
06:54:58.004Z|6|590C* --> UaDiscovery::getEndpoints DiscoveryUrl=opc.tcp://<DeviceName>.local:48030/
06:54:58.004Z|6|590C* --> UaDiscovery::connect URL=opc.tcp://<DeviceName>.local:48030/
06:54:58.004Z|4|590C* CALL OpcUa_Channel_Create
06:54:58.005Z|4|590C* DONE OpcUa_Channel_Create [ret=0x0]
06:54:58.005Z|4|590C* CALL OpcUa_Channel_Connect
06:54:59.212Z|4|590C* DONE OpcUa_Channel_Connect [ret=0xa0060000]
06:54:59.212Z|4|590C* CALL OpcUa_Channel_Delete
06:54:59.213Z|4|590C* DONE OpcUa_Channel_Delete
06:54:59.213Z|6|590C* <-- UaDiscovery::connect [ret=0xa0060000]
06:54:59.214Z|6|590C* <-- UaDiscovery::getEndpoints [ret=0xa0060000] - connect to server failed
06:54:59.214Z|6|590C* <-- UaDiscovery::getEndpoints [ret=0xa0060000]
06:54:59.214Z|5|590C* --> Dtor UaDiscovery
06:54:59.214Z|5|590C* <-- Dtor UaDiscovery

[Support Team]

Hi,

there are multiple different ways to resolve hostname FQDM or the short name. Different operating systems have different strategy and fallback (including unfortunately a cache where insisting on error). So "ping" is a good indicator, but may not be the full truth.

Can you give more details on which version of UaExpert you use and who is running on which operating system? Are you using .NET6 on Linux on the serverside? Is that name resolved into IP4 or IP6 address?

The trace you show is already getting error during discovery (GetEndpoints). The "real" connect, create session would have been coming thereafter. But you are not getting so far. The name resolution error is comming after 1 sec, the UaExpert will enter into reconnect loop (every 5 seconds) and depending on the connect timepout it might take a while to respond.

You may get more usefull information, if you enable the Stack-Trace in UaExpert. It will show more low level network information.

[Nathan.Hickling]

Hi,

Server side we are running C# on windows 10, the name resolves to an IPV4 address.
In terms of UA Expert we are running 1.6.3 build 448 on windows 10 operating systems.
I am just trying to capture some clean logs of the issue with stack tracing enabled, that's a bit delayed by holidays, so I will attach once available.

[Support Team]

Hi,

in case you have to send large log files, please zip them and create support ticket using form on website:
https://webdav.unifiedautomation.com/support/support_form.html

[Nathan.Hickling]

Hi,

Due to holidays and timings, I was a little delayed in being able to reply to this. Pasting the log from a failing attempt below, (Machine name replaced)
When checking Wireshark during this attempt for mDNS queries, I can see both the queries and responses within reasonable time frames (Response is 0.04s after queries are finished being sent). Ticket has been raised.

[Support Team]

Hi,

in your initial post your trace file shows:

URL=opc.tcp://<DeviceName>.local:48030/

How did the ".local" made it into the configuration?
Have you added it manually on the serverside configuration file?
Was that returned by OPC Foundation LDS (local discovery server)?

NOTE: The ".local" (as an extension to the hostname) indicates that you are using mDNS which is not supported my Microsoft Windows (just remove the ".local" and it will probably work). If you want to use mDNS on Windows you must install "mDNS-Responer" (known as Bonjour-Service).