Azure / Industrial-IoT

Azure Industrial IoT Platform
MIT License
523 stars 214 forks source link

OPC Twin -> Publisher: NodeRead doesnt work anymore #2226

Closed alxy closed 4 months ago

alxy commented 4 months ago

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 commented 4 months ago

+1, experiencing the same issue

marcschier commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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.