I think it will also work if you skip to advanced and use “opc.tcp://127.0.0.1:4840” as both discovery URL and endpoint URL.
Either way, somewhere in the discovery process with this server is causing the resulting config to be wrong. If you could give me a Wireshark capture of the process or a screenshot of every stage of the endpoint wizard on a fresh connection I might be able to confirm.
I can use “opc.tcp://127.0.0.1:4840” as the discovery address and leave the endpoint address blank and it works. But if I put it in “endpoint address” too, it stops working.
Please find attached screenshots of every step I go through when creating the connection from scratch. This results in a non-working connection. The only thing I type in is the discovery address, all the rest I leave the default values.
After creating this connection, it is faulted. I go to the endpoint config, choose “advanced”, delete the endpoint address and save, and then the connection succeeds.
For now, I have only gotten the 127.0.0.1 server to connect. The one on the Raspberry Pi is still not working.
Can you get me those DEBUG logs after setting both discovery URL and endpoint URL to “opc.tcp://127.0.0.1:4840”, letting it fail to connect, and then go and remove the endpoint URL and let it connect successfully?
Please find attached. To ensure no “pollution” in the logs, I deleted all connections prior to doing the test. As before, initially the connection does not work, then when I go back and clear the endpoint URL field in the advanced config, it connects immediately.
There is one thing I find weird. Although I use “opc.tcp://127.0.0.1:4840” as the discovery URL and endpoint, in the log I see lines showing “endpointURL=opc.tcp://fajean-x1-6thG:4840” all over the place. “fajean-x1-6thG” is the Windows name of my computer.
wrapper.log.txt (8.5 KB)
That half explains what’s going wrong.
For some reason the server is returning endpoint urls with your hostname when we try to connect but during discovery it returns endpoint urls with an IP address. This is why you get a mismatch error.
If you put that url with the hostname into the endpoint url setting it should work. It also works when you leave it blank because then any url is accepted, but that’s not as desirable for security.
I can confirm that using “opc.tcp://fajean-x1-6thG:4840” in both field works.
I need to say UA Expert deals with this somehow. Are you 100% sure this is the OPC-UA server returning this value, rather than Ignition doing some kind of resolution extracting back a name where it is fed with an address? If you think Ignition’s behavior is correct, then at least there should be something in the log (or preferably in the UI) that clearly indicates the mismatched addresses that causes the connection to be faulted.
Now, I need to work on the Raspberry Pi side of the issue. I will look at the logs for that one and see if it may be related to the same issue.
Yes it’s definitely returning this value.
The only doubt in my mind is about the url returned during the discovery wizard flow. It’s new for 8.0 and I didn’t write it myself so I inherently distrust it a little…
I re-tested with the Raspberry Pi, and I suspect something similar is happening. I see “endpoints[0]: endpointUrl=opc.tcp://raspberrypi:4840” in the log, although I do not see it on almost every line as was the case with the 127.0.0.1 connection.
However, whereas my laptop (which runs Ignition) is able to find itself from its name, it does not know “raspberrypi”, which is the hostname configured on the Pi.
So I added “raspberrypi” to the “hosts” file, and once that is done I observe the exact same behavior as with the 127.0.0.1 connection (i.e. using numerical address in “discovery address” field with “endpoint url” left blank works, and using the name in both field works too).
Once again, UA Expert deals with this without any issue, and it seems to me having to add things to the hosts file really should not be a requirement to establish a connection.
No, the wizard is absolutely supposed to handle this case but something about the results we get from the server are throwing it off.
The host override setting is meant to handle an irresolvable hostname and the wizard should auto populate it when the discovery url differs from the returned endpoint urls during the flow. That’s not happening for some reason and it’s not clear why without more logging or some wireshark captures.
I installed Wireshark, but being new to it, I have difficulty figuring out how to filter properly to get everything that is needed without getting a flood of packets logged. Are you able to suggest a filter that would be appropriate?
You should be able to just use “opcua” as the filter. It will catch traffic on 4840. Since you’re on windows you won’t capture the local host traffic so you’ll have to test against the pi.
Ok, let me know if the attached file are what you need.
“Failed” = Letting the wizard do its thing
“Success 1” = Advanced config, numerical address in discovery, endpoint blank
“Success 2” = Advanced config, hostname in both fields
wireshark_data.zip (51.3 KB)
Also, as an aside… The mention of required certificates in the upgrade guide obviously sent me down a path where I thought my problem was related to security. I have removed all certificates on both sides, things still work (though I only get the “none/none” option in the wizard, of course), so obviously it was not the root cause of my problem.
The guide says :
"Ensuring the remote certificate is trusted is required for all secured inbound and outbound connections."
Does that mean that certificates are required if and only if the security (mode, policy or both?) is different from “none”?
It depends.
You definitely need to trust the remote certificate when using security.
When using no security it depends on whether or not you’re connecting with a username and password and if the server has configured the UserTokenPolicy to secure the password in transit. In early version of the spec this was not required but in later versions it became a strong recommendation (I think…), so it’s possible to encounter a scenario where you’re using None/None but still need to mark the server certificate trusted on the certificates page.
Thanks for your patience with this and for the Wireshark captures. I think I have enough info to debug the wizard and figure out what’s wrong with it.
For now you’ll have to use the advanced config escape hatch.
For now, it seems I should be OK to proceed with my tests. I sure encourage you to correct this issue, I guess I will not be the last to stumble upon this. Thanks a lot for your support.
Best regards,
Thank you, fajean, for posting your screenshots and resolution to the issue on the OPC connection. I was pulling my hair out wondering why it would connect with other OPC clients, but not Ignition. Finally found your;
““I can use “opc.tcp://127.0.0.1:4840” as the discovery address and leave the endpoint address blank and it works. But if I put it in “endpoint address” too, it stops working.””
solution and ours came to life too. Thanks!
Hi,
I am having the same issue but slightly different. My opc ua server is in a K8S cluster. When I put the discovery URL: opc.tcp://192.168.0.3:31033, it can discovery the server.
When use it as both of them in discover or endpoint url, it fails. Only put in the discovery, fails. Only put in endpoint url also fails.
Anyone could help?
