Is there an API that can get 29, 30 and 31 diagnostic TLVs data through a single request?

[jinpeng1989]

I expect to get 29, 30 and 31 diagnostic TLVs data through a single request.
I did some experiments where I could get this data separately though meshdiag.

root@KNBA5F000300:~# ot-ctl meshdiag childtable 0x4000
rloc16:0x4002 ext-addr:ea6c419803df76bb ver:2
    timeout:3300 age:124 supvn:129 q-msg:1
    rx-on:no type:mtd full-net:yes
    rss - ave:-26 last:-27 margin:94
    err-rate - frame:0.63% msg:0.00% 
    conn-time:01:39:10
    csl - sync:no period:0 timeout:0 channel:0
Done
root@KNBA5F000300:~# ot-ctl meshdiag childip6 0x4000
child-rloc16: 0x4002
    fdfd:b182:4277:1297:fc4f:36b8:9f79:ff9
    fd0c:179e:644b:1:1f37:faa:c5b7:19a4
Done
root@KNBA5F000300:~# ot-ctl meshdiag routerneighbortable 0x4000
rloc16:0xe000 ext-addr:22cbf7eace20d1a3 ver:4
    rss - ave:-42 last:-42 margin:78
    err-rate - frame:1.28% msg:1.53% 
    conn-time:01:48:39
Done

I tried to use the networkdiagnostic to get 29, 30 and 31 diagnostic TLVs data and the Thread Router responded with no data.

root@KNBA5F000300:~# ot-ctl networkdiagnostic get fdfd:b182:4277:1297:0:ff:fe00:4000 29 30 31
DIAG_GET.rsp/ans from fdfd:b182:4277:1297:0:ff:fe00:4000: 
Done

And then I tried to use the networkdiagnostic to get 0, 1 and 6 diagnostic TLVs data and the Thread Router responded with data successfully. It looks like the stack is discriminating against these new TLVs. Why?

root@KNBA5F000300:~# ot-ctl networkdiagnostic get fdfd:b182:4277:1297:0:ff:fe00:4000 0 1 6
DIAG_GET.rsp/ans from fdfd:b182:4277:1297:0:ff:fe00:4000: 0008567aacc880b7b4810102400006084cebf5e940a89810
Ext Address: '567aacc880b7b481
Rloc16: 0x4000
Leader Data:
    PartitionId: 0x4cebf5e9
    Weighting: 64
    DataVersion: 168
    StableDataVersion: 152
    LeaderRouterId: 0x10
Done

[abtink]

I expect to get 29, 30 and 31 diagnostic TLVs data through a single request.
I did some experiments where I could get this data separately though meshdiag.
It looks like the stack is discriminating against these new TLVs. Why?

You can use the meshdiag commands. Please see mesh_diag.h

The new network diag TLVs function differently. They're list-based, meaning the answer can potentially contain numerous entries (e.g., a device might have up to 512 children or multiple addresses) which may not fit in a single IPv6 message MTU.

• To accommodate this, the design defines a mechanism for sending responses across multiple TMF Diag Answer messages. Additional TLVs indicate the relevant query and whether more information is forthcoming.
• The MeshDiag module handles this complexity, providing collected information directly to the user. This simplifies the process, removing the need for users of API to track and associate multiple answers with individual queries.

BWT, this question is similar to https://github.com/orgs/openthread/discussions/9302.

[jinpeng1989]

Thank you, I understand the design, defines a mechanism for sending responses across multiple TMF Diag Answer messages.
This mechanism is also capable of responding to multiple TLVs. So, I recommend adding Get Diagnostic API Query API that support request multiple specified TLVs.

[jinpeng1989]

Why not use the CoAP Block2 Option? It can also solve the problem of very long packets.

[abtink]

Many ideas including CoAP block-wise were considered and discussed in Thread Technical group during the design of the new mechnasim.

• You can read more details in SPEC-1151 and other JIRAs.
• All the related PRs and SPEC JIRAs are listed in [Network Diagnostics and Troubleshooting] related OT PR and/or Thread Jiras #8460

Quick answer on CoAP block-wise:

• Code size overhead: Both sender and receiver would need to support CoAP block options (at least Block2). Adding this functionality will increase code size.
• Block boundaries don't necessarily align with TLVs, complicating the preparation and parsing process. Receivers may need to collect multiple blocks before parsing, impacting memory efficiency.
• The block-wise CoAP support in OT was an external contribution and may lack the extensive testing of other CoAP functions. I wouldn't personally recommend its use in a production environment without careful consideration.