CoAP block transfer invalid payload bytes about mbed-client-c HOT 8 CLOSED

Versions:
|_ mbed-client 1.12.2
| |_ mbed-client-c 2.7.1 yotta_modules\mbed-client-c
| | _ nanostack-libservice 3.5.1 yotta_modules\nanostack-libservice
| |_ mbed-trace 1.1.3 yotta_modules\mbed-trace
| |_ mbed-client-mbed-os 3.0.0 yotta_modules\mbed-client-mbed-os

from mbed-client-c.

Hi and thanks for you report.
Unfortunately, we weren't able to reproduce this issue yet. We tried with K64F board as well as linux where registration message size was > 2500bytes and block size was set to 512 but we couldn't see any invalid blocks.
1st block
;obs,</3200/0/138>;obs,</3200/0/137>;obs,</3200/0/136>;obs,</3200/0/135>;obs,</3200/0
2nd block
/134>;obs,</3200/0/133>;obs,</3200/0/132>;obs,</3200/0/131>;obs,</3200/0/130>;obs,</3200/0/129>

Would it be possible you to create a small application that demonstrate this issue?

from mbed-client-c.

ARM Internal Ref: IOTCLT-777

from mbed-client-c.

Hello,

It looks like the calculated message_len and hereby the allocated memory size is wrong for the first block (not checked what happens for the next blocks). Finally this could results in a overwrite. The length output sn_coap_protocol_build() made this clear for me. The output size was larger than the allocated size.
In our application using a block size of 128 bytes, the function sn_coap_builder_calc_needed_packet_data_size_2 returns a message_len = 147 bytes and sn_coap_protocol_build length returned 150 bytes, written bytes.

sn_grs.c function sn_grs_send_coap_message:

    /* Calculate message length */
    message_len = sn_coap_builder_calc_needed_packet_data_size_2(coap_hdr_ptr, handle->grs->coap->sn_coap_block_data_size);
    /* Allocate memory for message and check was allocating successfully */
    message_ptr = handle->grs->sn_grs_alloc(message_len);
    if (message_ptr == NULL) {
        return SN_NSDL_FAILURE;
    }

    /* Build CoAP message */
    message_len = sn_coap_protocol_build(handle->grs->coap, address_ptr, message_ptr, coap_hdr_ptr, (void *)handle);
    if (message_len < 0) {
        handle->grs->sn_grs_free(message_ptr);
        message_ptr = 0;
        return SN_NSDL_FAILURE;
    }

from mbed-client-c.

Hi,
We have identified the issue and the problem is with the first block message as you have spotted. Reason for miscalculation is in sn_coap_builder_calc_needed_packet_data_size_2() function, when the function is called first time block options are not allocated and therefore size is not matching with length returned by sn_coap_protocol_build() function. We are currently working on this and hopefully we get fix released soon.

from mbed-client-c.

Hi,
Fix proposal is now available if you want to check does it solve your issue.
6e4076e
We will do more testing with this before releasing it out.

from mbed-client-c.

I have executed my tests and the LWM2M client registrations with the sn_coap_builder.c. My issue seems to be fixed. Also no artifacts seen. Thanks...

from mbed-client-c.

Hi,
Fix is released in mbed-client-c version 2.7.2.

from mbed-client-c.