OPC Twin -> Publisher: NodeRead doesnt work anymore

[alxy]

Describe the bug
We are right moving from the old OPC Twin (2.8.6) to the new Publisher (2.9.4) module for all functionalities. One of the functionalities we use is a NodeRead direct method call that we wanted to refactor to Publisher using the MQTT API. The OPC UA server implementation Im testing this with is KepserverEX 6.9. Result is that with the new Publisher call we are not able to successfully do the NodeRead call, whereas with the Twin its easily possible.

To Reproduce

1. OPC twin direct method call NodeRead_V2

{
  "endpoint":
  {
      "url": "opc.tcp://hostname1:49320",
      "securityMode": 2,
      "securityPolicy": "http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256"
  },
  "request":
  {
      "attributes":
      [
          {
              "nodeId": "ns=0;i=2254",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2261",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2262",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2263",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2264",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2265",
              "attribute": 13
          },
          {
              "nodeId": "ns=0;i=2266",
              "attribute": 13
          }
      ],
      "header":
      {
          "elevation":
          {
              "type": 1,
              "value":
              {
                  "user": "user",
                  "password": "password"
              }
          }
      }
  }
}

2. Result is a successful response with the values
3. Publisher MQTT payload to methods/noderead topic

{
"Connection": {
  "Endpoint": {
    "Url": "opc.tcp://hostname:49320",
    "AlternativeUrls": null,
    "SecurityMode": 2,
    "SecurityPolicy": "http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256",
    "Certificate": null
  },
  "User": {
    "Type": 1,
    "Value": {
      "User": "user",
      "Password": "password"
    }
  }
},
"Request": {
  "Attributes": [
    {
      "NodeId": "ns=0;i=2254",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2261",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2262",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2263",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2264",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2265",
      "Attribute": 13
    },
    {
      "NodeId": "ns=0;i=2266",
      "Attribute": 13
    }
  ],
  "Header": null
}
}

4. Result in publisher logs:

[24-05-21 11:38:35.8293] info: Azure.IIoT.OpcUa.Publisher.Stack.Services.OpcUaClient[0]
    Connecting Client opc.tcp://hostname:49320_5B983096 [state:Connecting|refs:1] to opc.tcp://hostname:49320...
[24-05-21 11:38:35.8355] info: Azure.IIoT.OpcUa.Publisher.Stack.Services.OpcUaClient[0]
    Selecting endpoint opc.tcp://hostname:49320/ with SecurityMode None and http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256 SecurityPolicyUri from:
          #051: opc.tcp://hostname:49320/|SignAndEncrypt [http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256]
[24-05-21 11:38:36.3321] warn: Azure.IIoT.OpcUa.Publisher.Stack.Services.OpcUaClient[0]
    No endpoint found that matches connection of session opc.tcp://hostname:49320_5B983096.

5. Response never appears on the selected response topic

Expected behavior
Both modules should be able to read from the exact same server.

Additional context
It seems to be working if we use security mode None and anonymous auth. However, most of the real servers we have will use some sort of encryption and username/password auth. The logs suggest that for some reason the publisher is selecting the unsecure endpoint, even though we instruct it to use the SignAndEncrypt one.

[pesetskyps]

+1, experiencing the same issue

[marcschier]

Can you try using "SignAndEncrypt" instead of 2 for "securityMode"? with SecurityMode None and http://opcfoundation.org/... seems like the Security mode is not parsed correctly, although the default is "Best", not "None". Need to investigate.

[alxy]

We have tested this using the direct methods api of publisher and this seems to be successful (using an encrypted + authenticated connection):

{
    "connection": {
        "Endpoint": {
            "url": "opc.tcp://hostname:50020",
            "securityMode": 2,
            "securityPolicy": "http://opcfoundation.org/UA/SecurityPolicy#Basic256Sha256"
        },
        "User": {
            "type": 1,
            "value": {
                "user": "user1",
                "password": "password"
            }
        }
    },
    "request": {
        "attributes": [
            {
                "nodeId": "nsu=2104020;s=1.PartData.OKStatus.Status.OK",
                "attribute": 13
            }
        ]
    }
}

[marcschier]

I have added a mqtt sample for attribute reading, using the security mode/profile settings as shown. This issue might have been fixed in a previous release as I was not able to repro with the sample. Closing for now.