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

["hyslopc (via GitHub)" <gi...@apache.org>]

hyslopc opened a new issue, #1897:
URL: https://github.com/apache/plc4x/issues/1897

   ### What happened?
   
   We use an OPC UA server ia a WAN connection which is not present in our DNS, which we connect to 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 instead of the IP address.  This is easily addressed by adding configuration parameter endpoint-host=<hostname> 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 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://<ip>?endpoint-host=<hostname> used by **URL 1** above should connect via IP address and not via hostname.
   
   ### Version
   
   v0.13.0
   
   ### Programming Languages
   
   - [X] plc4j
   - [ ] plc4go
   - [ ] plc4c
   - [ ] plc4net
   
   ### Protocols
   
   - [ ] AB-Ethernet
   - [ ] ADS /AMS
   - [ ] BACnet/IP
   - [ ] CANopen
   - [ ] DeltaV
   - [ ] DF1
   - [ ] EtherNet/IP
   - [ ] Firmata
   - [ ] KNXnet/IP
   - [ ] Modbus
   - [X] OPC-UA
   - [ ] S7


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@plc4x.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

["sruehl (via GitHub)" <gi...@apache.org>]

sruehl closed issue #1897: [Bug]: OPC-UA v0.13.0 struggles with servers without hostnames
URL: https://github.com/apache/plc4x/issues/1897


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

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

["splatch (via GitHub)" <gi...@apache.org>]

splatch commented on issue #1897:
URL: https://github.com/apache/plc4x/issues/1897#issuecomment-2480666481

   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?


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: issues-unsubscribe@plc4x.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org