Coap client not triggering handler for observed resource

I am using:

NCS 3.0.1
nRF52840DK

My project is based on the coap_client sample, currently running on a nRF52840DK.  I have modified it to add the 'observe' option in the request to the server.  The response handler is invoked when the server responds to the original request.  However, the client returns a Reset message to later notifications from the server, and does not invoke the response handler.

I have implemented observer functionality on the client using NCS 2.4.1, and when I compile this project for NCS 2.4.1, the client sends an ACK to the server when it receives a notifications.

The server is implemented on a Raspberry Pi (with OTBR) using libcoap.

In prf.conf

# Enable OpenThread CoAP support API
CONFIG_OPENTHREAD_COAP=y
CONFIG_OPENTHREAD_COAP_OBSERVE=y
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
static void send_dustsensor_request(struct k_work *item)
{
ARG_UNUSED(item);
LOG_INF("Send 'dustsensor' GET request \r\n");
if (g_server_addr.mFields.m8[0] == 0) {
LOG_WRN("Peer address not set. Can't send dustsensor get");
return;
}
poll_period_response_set();
ot_coap_send_request(OT_COAP_CODE_GET, &g_server_addr, dustsensor_option,
(uint8_t *)&g_eui64, sizeof(g_eui64),
on_dustsensor_reply, 1, 0); // observe
}
otError ot_coap_send_request(enum otCoapCode code, otIp6Address *addr,const char *uri_path,
uint8_t *payload, uint16_t payload_size,
otCoapResponseHandler reply_cb, bool observe_option, uint32_t observe_flag)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
See attached Wireshark log.  
observed_resource_reset.pcapng
Frame 1458:  original request from client
Frame 1460: server response
Frame 1469: Server notification
Frame 1471:  RST from client
What's changed since 2.4.1?
How do I get debug log output from ot:coap?  I've included the 'debug' snippet, and the 'logging' snippet, but am not seeing an low level debug output.
Mary
  • Hi,

    What's changed since 2.4.1?
    I have implemented observer functionality on the client using NCS 2.4.1, and when I compile this project for NCS 2.4.1, the client sends an ACK to the server when it receives a notifications.

    Are you now using NCS v3.0.1 and having reset problem but everything worked fine in NCS v2.4.1?

    How do I get debug log output from ot:coap?  I've included the 'debug' snippet, and the 'logging' snippet, but am not seeing an low level debug output.

    How did you include snippets?
    For logging, you can look at OpenThread logging levels and Zephyr L2 logging options.

    Best regards,
    Dejan

    • Yes. Everything worked fine NCS 2.4.1.  The reset problem occurs with NCS 3.0.1.

      I included the snippets in the build configuration. (mtd, debugging, logging, ci).  Using the same snippets, I get a ton of debug log messages when I compile with NCS 2.4.1, but only application level logs with NCS 3.0.1.

      Mary

      • Hi Mary,

        Can you provide your network key so that we can look into your provided Wireshark file? Please let me know if there is any reason to make this case private with regard to sharing your key.

        Can you try to increase logging level using CONFIG_OPENTHREAD_LOG_LEVEL_DEBG?

        Best regards,
        Dejan

        • Network key: d2970b94e1eecfcb92fcdd3d825d5efd

          That logging level is already set.

          logging.conf

          Fullscreen
          1
          2
          3
          4
          5
          6
          7
          8
          9
          10
          11
          12
          13
          14
          15
          16
          17
          18
          19
          20
          21
          # Option for configuring log level in Zephyr L2 logging
          CONFIG_OPENTHREAD_L2_DEBUG=y
          CONFIG_OPENTHREAD_L2_LOG_LEVEL_DBG=y
          # CONFIG_OPENTHREAD_L2_DEBUG_DUMP_15_4=y
          # CONFIG_OPENTHREAD_L2_DEBUG_DUMP_IPV6=y
          # Configure sample logging setting
          CONFIG_LOG=y
          CONFIG_COAP_CLIENT_LOG_LEVEL_DBG=y
          CONFIG_COAP_CLIENT_UTILS_LOG_LEVEL_DBG=y
          CONFIG_COAP_UTILS_LOG_LEVEL_DBG=y
          CONFIG_OPENTHREAD_DEBUG=y
          CONFIG_COAP_LOG_LEVEL_DBG=y
          # Adjust log strdup settings
          # Enable Mbed TLS logging
          # CONFIG_OPENTHREAD_MBEDTLS_DEBUG=y
          # CONFIG_MBEDTLS_DEBUG_LEVEL=3
          XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

          Mary

          • Hi Mary,

            Thank you for providing your network key.

            I will look into it during next week.

            Best regards,
            Dejan

        • wireshark 1458 is a NON request, but the snippet requests a OT_COAP_TYPE_CONFIRMABLE. Not sure, what goes wrong.

          wireshark 1469 is a CON response (notify)

          Let me recommend to capture also with NCS 2.4.1 and check, if the observe-request there uses CON or NON.

          (Looking forward to the analysis/answer from Nordic.)

          • Here's a capture with NCS 2.4.1.

            Frame 64:  Request from client (CON)
            Frame 66:  Response from server (ACK)

            Frame 73:  Notification from server (CON)
            Frame 75:  ACK from client

            The network key is the same.

            Mary

            observed_resource_ack_241.pcapng

            • Yes.

              I guess that's two issues:

              1. NCS 3.0.1 uses NON instead of CON. Maybe OT_COAP_TYPE_CONFIRMABLE is broken or requires some additional setup.

              2. The coap-client rejects a CON notify response for a NON request. I would recommend Nordic to open an issue in Constrained Application Protocol (CoAP): Corrections and Clarifications to ensure, that this a compliant handling.

              • 1. It's not broken.  I've been trying different things, and must have tried NON in the original request.  I just tried it again with CON, and got the same result.  ACK from the server for the original request, then RST from the client on subsequent notifications.  Sorry for the confusion.

                I've tried both CON and NON on the server side for the notification.  With NON, it still sends a CON every 5th notification (as required by the spec).  The client responds to the CON with a RST, and never invokes the response handler in either case.

                Frame 90: Request (CON)
                Frame 92: ACK from server

                Frame 97: Notification from server (CON)
                Frame 99: RST from client

                Mary

                observed_resouce_CON_reset.pcapng

                • Sorry for the confusion.

                  Luckily Nordic has now this second capture with CON and the first issues (CON/NON) is already "solved" ;-).

                  With NON, it still sends a CON every 5th notification (as required by the spec).  The client responds to the CON with a RST, and never invokes the response handler in either case.

                  Just to be clear:

                  In this cases the received NON notifications are also not handled by the response handler? 

                  Let's see, what the analysis there shows.

                  • In this cases the received NON notifications are also not handled by the response handler? 

                    You are correct.  The response handler is not called for either NON or CON notifications.  It's only called for the original request, after the ACK is received at the client.

                    Mary

                    • Hi Mary,

                      For logging verbosity change, you could try to include CONFIG_OPENTHREAD_SOURCES=y

                      I will get back to you regarding reset problem.

                      Best regards,
                      Dejan