Using the Diagnostic API

[mwie...@btrcontrols.com]

Hi,

I am trying to use Thread's Diagnostic API to obtain some information about each Thread device. I am using a tool called CoAP-CLI on the border router. I did the following:

$ echo -n -e \\x12\\x01\\x00 | coap --non-confirmable post coap://[ff03::2]:61631/d/dg

events.js:167

      throw er; // Unhandled 'error' event

      ^

Error: No reply in 30s

The echo'ed payload is a Type List TLV (0x12) with a TLV Type of MAC Extended Address (64-bit) (0x00) and length of one. Is this correct? I am looking at section 10.11.4.6 in Thread specification 1.1.1.

I verified that I can communicate with my Thread node(s). If I change the port to 3002 (used with otCoapStart()), I can successfully receive the message. Thread uses port 61631 specifically for Thread management, correct?

Is there anything else I am missing?

Thanks,

Mateusz

[mwie...@btrcontrols.com]

Here's Wireshark's packet dissection:

No.   Time    Source                                Protocol   Info

1     0.000   fdde:ad00:beef::73af:3fcf:48b1:6575   CoAP       NON, MID:17344, POST, TKN:5b 6c 92 ae, /d/dg

Frame 1: 65 bytes on wire (520 bits), 65 bytes captured (520 bits) on interface 0

Raw packet data

Internet Protocol Version 6, Src: fdde:ad00:beef::73af:3fcf:48b1:6575, Dst: ff03::2

    0110 .... = Version: 6

    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)

    .... .... .... 0100 0100 1001 1111 0010 = Flow Label: 0x449f2

    Payload Length: 25

    Next Header: UDP (17)

    Hop Limit: 1

    Source: fdde:ad00:beef::73af:3fcf:48b1:6575

    Destination: ff03::2

User Datagram Protocol, Src Port: 35386, Dst Port: 61631

    Source Port: 35386

    Destination Port: 61631

    Length: 25

    Checksum: 0x06a1 [unverified]

    [Checksum Status: Unverified]

    [Stream index: 0]

Constrained Application Protocol, Non-Confirmable, POST, MID:17344

    01.. .... = Version: 1

    ..01 .... = Type: Non-Confirmable (1)

    .... 0100 = Token Length: 4

    Code: POST (2)

    Message ID: 17344

    Token: 5b6c92ae

    Opt Name: #1: Uri-Path: d

    Opt Name: #2: Uri-Path: dg

    End of options marker: 255

    [Uri-Path: /d/dg]

    Payload: Payload Content-Format: application/octet-stream (no Content-Format), Length: 3

Data (3 bytes)

0000  12 01 00                                          ...

    Data: 120100

    [Length: 3]

[Jonathan Hui]

Thread 1.1.1 requires using DIAG_GET.qry (d/dq) with a multicast destination. However, the Wireshark trace shows you are trying to use DIAG_GET.req (d/dg) with a multicast destination.

Try changing the Uri-Path to d/dq.

For more details, see Thread 1.1.1 Section 10.11.2.3.

--

Jonathan Hui

--
You received this message because you are subscribed to the Google Groups "openthread-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openthread-use...@googlegroups.com.
To post to this group, send email to openthre...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openthread-users/a2f66ac1-4281-400b-89b5-b052e5c0a769%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[mwie...@btrcontrols.com]

Thanks Jonathan. That was it.

I did have to use a sniffer to confirm, as this tool does not appear to fully work with multicast addresses. I do receive DIAG_GET.ans commands as a result of DIAG_GET.qry. DIAG_GET.ans are confirmable and ACKs are sent back.