NetworkInterface Type serialization format differences

[olavt]

The attributes for General Diagnostics Cluster attribute NetworkInterfaces (attribute path "0/51/0") seems to have possible variations in the serialization format.

For one device:

    "0/51/0": [
      {
        "0": "OpenThread-9244",
        "1": true,
        "2": null,
        "3": null,
        "4": "sA4BIJ8CCwg=",
        "5": [],
        "6": [],
        "7": 4
      }
    ],

For another device:

    "0/51/0": [
      {
        "name": "WIFI_AP_DEF",
        "isOperational": true,
        "offPremiseServicesReachableIPv4": null,
        "offPremiseServicesReachableIPv6": null,
        "hardwareAddress": "AAAAAAAA",
        "IPv4Addresses": [
          "wKgEAQ=="
        ],
        "IPv6Addresses": [],
        "type": 1
      },
      {
        "name": "WIFI_STA_DEF",
        "isOperational": true,
        "offPremiseServicesReachableIPv4": null,
        "offPremiseServicesReachableIPv6": null,
        "hardwareAddress": "VDIEqxSE",
        "IPv4Addresses": [
          "wKgB7A=="
        ],
        "IPv6Addresses": [
          "/oAAAAAAAABWMgT//qsUhA=="
        ],
        "type": 1
      }
    ],

It also looks like format can be different for the same device.

I now also see in another test:

    "0/51/0": [
      {
        "name": "OpenThread-9244",
        "isOperational": true,
        "offPremiseServicesReachableIPv4": null,
        "offPremiseServicesReachableIPv6": null,
        "hardwareAddress": "sA4BIJ8CCwg=",
        "IPv4Addresses": [],
        "IPv6Addresses": [],
        "type": 4
      }
    ]

[marcelveldt]

That first one is the only real/correct value. The others come from an old node or whatever ?
Please check values of an actual, live node that has been interviewed recently.

[olavt]

Hm, it was interviewed quite recently:

  "date_commissioned": "2024-02-20T23:11:43.174090",
  "last_interview": "2024-02-22T15:38:30.664012",
  "interview_version": 6,

[olavt]

I re-tested today.

Running Python Matter Server using Docker on a freshly formatted Raspberry Pi 4 and a clean data directory.

Added two Matter over Thread devices.

This is the response from the "start_listening" command:

{
"message_id": "1",
"result": [
{
"node_id": 1,
"date_commissioned": "2024-02-26T11:09:49.653291",
"last_interview": "2024-02-26T11:09:49.653298",
"interview_version": 6,
"available": true,
...
"0/51/0": [
{
"name": "OpenThread-f865",
"isOperational": true,
"offPremiseServicesReachableIPv4": null,
"offPremiseServicesReachableIPv6": null,
"hardwareAddress": "yA4BII0DCwg=",
"IPv4Addresses": [],
"IPv6Addresses": [],
"type": 4
}
],
...
{
"node_id": 2,
"date_commissioned": "2024-02-26T11:31:25.052847",
"last_interview": "2024-02-26T11:31:25.052854",
"interview_version": 6,
"available": true,
...
"0/51/0": [
{
"name": "OpenThread-f865",
"isOperational": true,
"offPremiseServicesReachableIPv4": null,
"offPremiseServicesReachableIPv6": null,
"hardwareAddress": "+PAAIN/mCAg=",
"IPv4Addresses": [],
"IPv6Addresses": [],
"type": 4
}
],
...

[marcelveldt]

hmm strange, that would indicate an issue with our serializer as it should use the index as key for those sdk structs.
I'll look into it. Our client can handle both variants. I prefer the index key as the attribute names could potentially change

[olavt]

@marcelveldt Did you make any explicit changes lately to address this?

When testing now with 5.8.0, I get the format like this again:

"0/51/0": [
  {
    "0": "OpenThread-9244",
    "1": true,
    "2": null,
    "3": null,
    "4": "sA4BIJ8CCwg=",
    "5": [],
    "6": [],
    "7": 4
  }
],

[olavt]

I still see "randomness" in format.

This is from 5.8.1 setup from a blank data directory:

    "0/53/61": {
      "activeTimestampPresent": true,
      "pendingTimestampPresent": false,
      "masterKeyPresent": true,
      "networkNamePresent": true,
      "extendedPanIdPresent": true,
      "meshLocalPrefixPresent": true,
      "delayPresent": false,
      "panIdPresent": true,
      "channelPresent": true,
      "pskcPresent": true,
      "securityPolicyPresent": true,
      "channelMaskPresent": true
    },

[olavt]

I have a question about the format if index are used for structs that are fabric-scoped.

This is an example where names are used:

    "0/42/0": [
      {
        "providerNodeID": 1,
        "endpoint": 0,
        "fabricIndex": 1
      }
    ],

In the 23-27349-003_Matter-1.2-Core-Specification.pdf the the documentation for the ProviderLocation Type is clear on the index values for "providerNodeID" and "endpoint". Since this structure is so-called "fabric-scoped" it also contains an implicitly documented "fabricIndex". However the index number for "fabricIndex" is then a bit unclear.

How can one be sure about what index number the "fabricIndex" would get by reading the documentation?

Will it always be the last documented index + 1?

What if a newer version of the standard defines more attributes? Could one risk that the index for the "fabricIndex" field would change?

If there is a risk for the "fabricIndex" index number to change, I think it would be safer to user the names only.

[olavt]

I found the answer to my last concerns about the index of the "fabricIndex" field and it is documented under 7.13. Global Elements to be 0xFE (245).