Invalid value in data payload lead to crash in print_set_debug from xpath.c

[lorandt1]

Hi,

I sent an invalid key for the id, -1:

<user-plane-configuration xmlns="urn:o-ran:uplane-conf:1.0">
            <endpoint-prach-group>
                <id>-1</id>
                <supported-prach-preamble-formats>LTE-0</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-2</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-1</supported-prach-preamble-formats>
            </endpoint-prach-group>
            <endpoint-prach-group>
                <id>2</id>
                <supported-prach-preamble-formats>LTE-0</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-2</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-3</supported-prach-preamble-formats>
            </endpoint-prach-group>
            <endpoint-prach-group>
                <id>3</id>
                <supported-prach-preamble-formats>LTE-0</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-2</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-NB3</supported-prach-preamble-formats>
            </endpoint-prach-group>
            <endpoint-prach-group>
                <id>4</id>
                <supported-prach-preamble-formats>LTE-3</supported-prach-preamble-formats>
                <supported-prach-preamble-formats>LTE-1</supported-prach-preamble-formats>
            </endpoint-prach-group>
        </user-plane-configuration>

Yang definition is as follows:

list endpoint-prach-group  {
      key "id";
      config false;
      description
        "Represents group of a series of PRACH preamble formats";

      leaf id {
        type uint16;
        description
          "Identifies group of PRACH preamble formats.";
      }

      leaf-list supported-prach-preamble-formats {
        type prach-preamble-format;
        min-elements 1;
        description
          "the list of PRACH preamble formats supported by the endpoint-type that is
          applicable to static-low-level-rx-endpoints in the O-RU";
      }

    }

1. Crash at else if ((!item->node->schema && !lyd_child(item->node)) || (**item->node->schema**->nodetype == LYS_LEAFLIST))
2. Why NC_MSG_TYPE from nc_recv_reply is NC_MSG_REPLY in this case and not NC_MSG_ERROR ?

[michalvasko]

Fine, fixed. It seems the reply is parsed because unknown data are expected. This is the case (in libnetconf2) if some server YANG modules fail to load.

[lorandt1]

Thanks a lot!

1. I think old libraries did not allow the rpc-reply to have any invalid data, but now I see that it is allowed and only the part with the invalid data is not parsed, in this case first endpoint-prach-group with id -1, can you please tell why was this changed and should not be the entire rpc-reply be an NC_MSG_ERROR ?
   I understand other part of the reply is still valid and can be used, but for me it seemed better to not allow at all invalid data in a rpc-reply.

2. Please check also to not have crash if rpc-reply is invalid due to <endpoint-prach-group =""> and if this fix is enough for that too.

[michalvasko]

1. What exactly is your use-case? Do you have your own libnetconf2-based client or are you using netopeer2-cli? Normally, a message with invalid data should not be parsed but there are cases when it is.
2. This was a very specific debug-print issue, it should work correctly now.

[lorandt1]

1. I have libnetconf2-based client version 3.0.17, the use case is sending the rpc-reply that I posted and has invalid value: -1. The crash is avoided but the other part of the reply is still parsed: endpoint-prach-groups 2, 3 and 4.

[michalvasko]

Right, the data are most likely enclosed in an anyxml or anydata node, which allow them not to fit the schema, based on the specification of the node. The expectation is that the server sends correct data and if not, it has a reason for doing so.