What solution is needed to avoid the mismatch error in my customer's 8.1 environment and my 8.3 Maker? From the other post, it sounds like I should only need to enable None for security (everything else is base OPC UA config), but that doesn't seem to work in 8.3.
In both systems, the server cert is trusted by the client, and the client trusts the server.
The only main difference between my environment and the customer's is that the client software is installed on the gateway server (whereas mine is setup on another server), so the bind address is localhost and the client is connecting to localhost:port (which works with UaExpert).
This isn't a configuration problem in Ignition, it's a bug in the software you're using. We can confirm that if you're able to provide a Wireshark capture.
We've seen this bug in later versions of the OSI PI adapter or connector (forget which it's called), but the bug is from the underlying SDK they use, so in theory other clients using that SDK could experience the same issue.
Trace.zip (2.0 KB)
I'd agree it's an issue with the newer versions - it's been a few years since I've tried connecting AVEVA to read from Ignition, which did work the last time.
I have attached the filtered output of Wireshark from the AVEVA side. I'm not sure of what exactly to look for, but I can see some of the requests and responses. I let it go through the initial connection and two connect/disconnect cycles.
You'd need to get the whole thing, with security turned off, to verify.
If this is OSI PI though you might as well not bother. If you're a paying customer, call their support and complain. We reported this to them like a year ago. Separately, one of our devs who used to work there reached out to a PM and let them know that way as well. Multiple customers have run into this.
That's my bad - when I saved the filtered output, I selected the wrong option. I did have security enabled before, so this also removes that.
I'll have to see what they say then (I'm assuming the trace below will confirm what you have in all these other issues), but until then it sounds like my options are to use an older Adapter or to use MQTT instead.
According to the information we received from past cases, it was stated that Ignition OPC UA servers don't seem to provide the certificate information in the CreateSession response, so the connection fails.
Could you please confirm this behaviour for me and check with your developer if there is any way for the certificate information to be provided?
Is there anything from the trace you can provide to indicate the server side is doing what it should? I'd like to get AVEVA to address the problem.
It’s not supposed to provide the certificate in the CreateSessionResponse. The spec passage I linked to says as much, and it says the client shall not require it.
That's the whole issue here - they are requiring the certificate be there when the spec explicitly says they shall not.
