[Bug]: OPC-UA v0.13.0 struggles with servers without hostnames

[hyslopc]

What happened?

We connect to an OPC UA server via a WAN connection where the hostname of the server is not present in our DNS, so we connect to it via IP address. We had no problems connecting to this PLC using eg v0.12.0 however with v0.13.0 the connection is rejected, since the endpoints advertised on the server itself use the hostname (which is not visible in our network) instead of the IP address. This is easily addressed by adding configuration parameter endpoint-host= so now the URL (URL 1) looks like this:

opcua:tcp://10.3.1.13:4840?endpoint-host=ahostname

• however that leads to a new problem: v0.13.0 tries to connect to the server using ahostname instead of using the IP address 10.3.1.13. This makes no sense: if we wanted to connect via hostname, we would use a much simpler URL (URL 2):

opcua:tcp://ahostname:4840

Thankfully, the code falls back to connecting via IP address, however it takes quite a bit of extra time, and a lot of errors and warnings are generated in the log. IMHO this is illogical: there is already a very simple way to connect to OPC UA servers via hostname (via URL 2). The only reason for the endpoint-host parameter that I am aware of is where the endpoint hostname and the connection address differ, with the point being to use the connection address (and not endpoint-host) to connect.

It should be possible to connect to an OPC UA server via IP address without any attempts to connect via hostname, ergo the format opcua:tcp://xxx?endpoint-host=hostname used by URL 1 above should connect using xxx and not hostname.

Version

v0.13.0

Programming Languages

• plc4j
• plc4go
• plc4c
• plc4net

Protocols

• AB-Ethernet
• ADS /AMS
• BACnet/IP
• CANopen
• DeltaV
• DF1
• EtherNet/IP
• Firmata
• KNXnet/IP
• Modbus
• OPC-UA
• S7

[splatch]

Hello @hyslopc,
Thank you for report, you are right that we have maybe not conflicting, but somewhat overlapping logic. This comes from fact that the difference between connected server and advertised hostname in its endpoints, which you mentioned, is indeed quite common.
The endpoint-host and endpoint-port parameters are recent inventions in 0.13 which allowed us to have a dynamic port/host pairs within unit tests, but as you found, can address also above problem. I have not removed earlier logic (attempting to resolve ip from host etc.) simply to avoid behavior change.

@hutcheb Are you ok to remove host resolution attempts in favor of fixing endpoint URI through two parameters mentioned here?