pelioniot / mbed-cloud-client

Izuma Device Management Client library

Device Management Client

This repository contains Izuma Device Management Client: a library that connects devices to Izuma Device Management service and to Mbed-enabled cloud services from our partners.

The documentation is hosted here.

You can report concerns about the documentation or this SW as issues to this GitHub repository.

mbed-cloud-client's Issues

Errors when disabling bootstrapping

Disabling the bootstrap features causes some issues with version 4.10.
Below a list of issues I faced so far, but might not be exhaustive:

Compile-time:

• ConnectorClient uses bootstrap related functions which are excluded when disabling the feature
• ConnectorClient doesn't derive from M2MTimerObserver anymore but relays on observation for some timers.

Runtime:

• Bootstrap related states in M2mIntefaceImpl are excluded, but the states are not excluded as well in the generated state machines, which leads to incorrect state transitions
  https://github.com/PelionIoT/mbed-cloud-client/blob/master/mbed-client/source/include/m2minterfaceimpl.h#L503
  https://github.com/PelionIoT/mbed-cloud-client/blob/master/mbed-client/source/m2minterfaceimpl.cpp#L160

Receiving ConnectMemoryConnectFail

I am getting the Error MbedCloudClient::ConnectMemoryConnectFail while running the official Connect Guide.
Target: nucleo_f207zg

I have compiled this program both with mbed CLI (ARM-GCC) and the Online Compiler, both getting the same error.

This is what I am getting:

[BOOT] Mbed Bootloader
[BOOT] ARM: 00000000000000000000
[BOOT] OEM: 00000000000000000000
[BOOT] Layout: 0 80079C8
[BOOT] Active firmware integrity check:
[BOOT] SHA256: 7C60E8509CD265EF51AA3A456B6062955CAF5C6F39E49B10BAF395AE01AAE8F0
[BOOT] Version: 1552350966
[BOOT] Slot 0 is empty
[BOOT] Active firmware up-to-date
[BOOT] Application's start address: 0x8010400
[BOOT] Application's jump address: 0x8039E41
[BOOT] Application's stack address: 0x20020000
[BOOT] Forwarding to application...
Starting Simple Pelion Device Management Client example
You can hold the user button during boot to format the storage and change the device identity.
Connecting to the network using the default network interface...
Connected to the network successfully. IP address: 192.168.2.14
Initializing Pelion Device Management Client...
Initialized Pelion Device Management Client. Registering...
**** current_size: 18113
**** max_size : 20074
[SMCC] Error occurred : MbedCloudClient::ConnectMemoryConnectFail
[SMCC] Error code : 9
[SMCC] Error details : Client cannot connect anymore Memory allocation failed

I have tried increasing the nanostack-hal.event_loop_thread_stack_size with no success.
How can I fix this? THANK YOU!

Security object not lwm2m specification compliant

Hello,

to me it seems that the Security Object as implemented in Mbed-Cloud-Client is not compliant to the Lwm2m Specification. Mbed-Cloud-Client defines the following resources for the Security Object: https://github.com/PelionIoT/mbed-cloud-client/blob/master/mbed-client/mbed-client/m2msecurity.h#L38-L58

The Lwm2m Object Registry on the other hand uses those: http://www.openmobilealliance.org/tech/profiles/LWM2M_Security-v1_0.xml

Consider the difference for resource with id 12 (Bootstrap-Server Account Timeout vs OpenCertificateChain).

Best regards,
Sebastian

Building .a library

What are the steps to build a .a library from this?
So that I can just -lmbed or something in the Linker flags

Target: x86_64 Generic Linux

mbed-os pal_crypto.h file name conflict with cloud-client file

Description of defect

Note: this is a duplicate of ARMmbed/mbed-os#13989 to track progress in mbed-cloud-client as well.

(cc @YannLocatelli)

This is the exact same issue as described in ARMmbed/mbed-os#10022.

The issue was fixed in ARMmbed/mbed-os#10042

But then the changes were reverted and the issue brought back with ARMmbed/mbed-os#13217 and ARMmbed/mbed-os@3e011a9

On the cloud client end, the PR mentioned by @adamelhakham (ARMmbed/mbed-os#10022 (comment)) is nowhere to be found.

Target(s) affected by this defect ?

Custom target with BLE and Pelion

Toolchain(s) (name and version) displaying this defect ?

arm-none-eabi-gcc --version
arm-none-eabi-gcc (GNU Arm Embedded Toolchain 9-2020-q2-update) 9.3.1 20200408 (release)

What version of Mbed-os are you using (tag or sha) ?

6.5.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed --version
1.10.4

mbed-tools --version
3.5.1.dev36

How is this defect reproduced ?

Setup Pelion mbed-cloud-client using a target with BLE.

Resource 1/0/7 (Server/Binding) should be writable

Hello,

according to http://openmobilealliance.org/release/ObjLwM2M_Server/V1_0-20170208-A/OMA-SUP-XML_LWM2M_Server-V1_0-20170208-A.xml resource 7 (Binding) is readable and writable. Therefore at https://github.com/PelionIoT/mbed-cloud-client/blob/master/mbed-client/source/m2mserver.cpp#L63 M2MBase::GET_PUT_ALLOWED should be set instead of M2MBase::GET_ALLOWED.

Best regards,
Sebastian

Bug fix for multi instance resource with no initial instances

Fix added as a PR:
#70

Client does not report running out of memory

There a lot of naked mallocs in the application that either don't check the result or report a generic error and give no indication that the application has ran out of memory. This needs to be fixed and out of memory errors need to be propagated and reported.

Pin this repository to top of ARMmbed Group

There is an open space at the top of the ARMmbed group. I think this repository ought to be pinned there.

'"mbedtls_hardware_poll" is undefined' error when using MBEDTLS_TEST_NULL_ENTROPY

I'm trying to use NUCLEO_F207ZG (Cortex-M3, 128K RAM, 1MB Flash, Ethernet, no TRNG) in developer mode. The MCU is lacking TRNG, but since I'm using it for development only, I should be able to use that platform with software entropy, e.g. "target.macros_add" : ["MBEDTLS_TEST_NULL_ENTROPY", "MBEDTLS_NO_DEFAULT_ENTROPY_SOURCES"], in my mbed_app.json.

Most of the codebase compiles fine, except for the PAL for Mbed OS, which apparently makes assumptions that mbedtls_hardware_poll is always available.

Here's the compile log:

Compile [ 90.1%]: m2mresource.cpp
Compile [ 90.2%]: pal_plat_rtos.cpp
[Warning] config.h@3227,0:  #1215-D: #warning directive: "MBEDTLS_TEST_NULL_ENTROPY has been enabled. This "     "configuration is not secure and is not suitable for production use"
[Error] pal_plat_rtos.cpp@739,0:  #20: identifier "mbedtls_hardware_poll" is undefined
[DEBUG] Output: ".\simple-mbed-cloud-client\mbed-cloud-client\mbed-client-pal\Source\Port\Reference-Impl\OS_Specific\mbedOS\RTOS\pal_plat_rtos.cpp", line 739: Error:  #20: identifier "mbedtls_hardware_poll" is undefined

Is there another way I can use this board for development? @yogpan01

CC @MarceloSalazar

client-lite public release

Any update on when client lite will be publicly available?

Thread safety of M2MResourceBase::set_value

Hi,

So out of the box, mbed-cloud-client forks several threads that can manipulate the underlying data of the published Objects and Resources (that is, those threads can change the underlying values of the Resources if the Lwm2m Server makes a PUT / Write)

Given that, can you comment on the thread safety of using the various get and set functions inside of M2MResourceBase? Are the data structures mutexed within the client such that, if the main thread happens to call "set_value" while some event thread happens to be servicing a Lwm2m Write from the network on the same resource, that you won't have a synchronization issue?

Release Benchmarks

Can we get RAM/Flash consumption benchmarks with each release of the client?

Different struct layouts in source files cause hard faults

Hello,

MBED_CLIENT_DISABLE_BOOTSTRAP_FEATURE is defined as MBED_CONF_MBED_CLIENT_DISABLE_BOOTSTRAP_FEATURE in https://github.com/ARMmbed/mbed-cloud-client/blob/f72a23e0dc21de4c82ee53fe947153341419a5b9/mbed-client/mbed-client/m2mconfig.h but not all users of MBED_CLIENT_DISABLE_BOOTSTRAP_FEATURE include m2mconfig.h. Therefore the struct might have a different layout e.g. for sn_nsdl.c and nsdlaccesshelper.c. The result are hard faults.

https://github.com/ARMmbed/mbed-cloud-client/blob/caf14b6e3117636ea86a3845929ac5c22f303d3f/mbed-client/mbed-client-c/source/include/sn_grs.h#L65-L79

[INFO][mClt]: M2MInterfaceImpl::address_ready() Server Type LWM2M
[INFO][mClt]: M2MNsdlInterface::send_register_message()
[INFO][mClt]: M2MNsdlInterface::observation_to_be_sent() - object NULL, in reconnection mode or not registered
[INFO][COAP]: REGISTER MESSAGE: </3/0/5>,</3/0/16>;obs,</3/0/11>;ct="99";aobs="2",</3/0/11/0
[INFO][COAP]: REGISTER MESSAGE: >;obs,</3/0/4>,</5000>;ct="99",</5000/0>;ct="99",</5000/0/1>
[INFO][COAP]: REGISTER MESSAGE: ;obs,</3201>;ct="99",</3201/0>;ct="99",</3201/0/5850>;obs,</
[INFO][COAP]: REGISTER MESSAGE: 3201/0/5853>;obs,</3200>;ct="99",</3200/0>;ct="99",</3200/0/
[INFO][COAP]: REGISTER MESSAGE: 5501>;obs,</1>;ct="99",</1/0>;ct="99",</1/0/8>,</1/0/7>;obs,
[INFO][COAP]: REGISTER MESSAGE: </1/0/6>;obs,</1/0/1>;obs,</1/0/0>;obs
[INFO][COAP]: sn_nsdl_internal_coap_send() - handle: 0x20003d98
[INFO][COAP]: sn_nsdl_internal_coap_send() - handle->grs: 0x20003e00
[INFO][COAP]: sn_nsdl_internal_coap_send() - offsetof(struct nsdl_s, grs): 0x00000018
[INFO][COAP]: sn_nsdl_internal_coap_send() - sizeof(struct nsdl_s): 0x00000040
[INFO][COAP]: __nsdl_c_send_to_server() - nsdl_handle: 0x20003d98
[INFO][COAP]: __nsdl_c_send_to_server() - nsdl_handle->grs: 0x00000000
[INFO][COAP]: __nsdl_c_send_to_server() - offsetof(struct nsdl_s, grs): 0x00000014
[INFO][COAP]: __nsdl_c_send_to_server() - sizeof(struct nsdl_s): 0x0000003c

++ MbedOS Fault Handler ++

FaultType: HardFault

Context:
R0   : 00000020
R1   : 30020A04
R2   : 200072D8
R3   : 20042AF0
R4   : 200175F8
R5   : 200072D8
R6   : 00000004
R7   : 20042AF0
R8   : 00000180
R9   : 00000000
R10  : 00000180
R11  : 0806ECD4
R12  : 0800F9ED
SP   : 20042AB0
LR   : 080364AD
PC   : 30020A04
xPSR : 20000000
PSP  : 20042A90
MSP  : 2003FF78
CPUID: 410FC241
HFSR : 40000000
MMFSR: 00000001
BFSR : 00000000
UFSR : 00000000
DFSR : 00000000
AFSR : 00000000
Mode : Thread
Priv : Privileged
Stack: PSP

Solution would be to directly use MBED_CONF_MBED_CLIENT_DISABLE_BOOTSTRAP_FEATURE in sn_grs.h or to include m2mconfig.h somehow. Eventually other structures are also affected.

Backup & restore FCC on production devices

Hi,

We have discovered a mayor problem with our production devices. They're running mbed-os 5.9.2, cloud-client 1.5 and are using a SD card. At one point we're running into problems where the storage is no longer writable due to some other configuration problems that we drag along with us over time.
Long story cut short, the easiest way to solve our problem would be that we could load the FCC'd stuff (that is created on the SD during factory) into RAM, format storage, and then redeploy all.

With a quick test in Windows I've copied the WORKING and BACKUP directory into some other SD card, and next inserted that one into the device, but then fcc_verify_device_configured_4mbed_cloud() returns an errorcode.

Is there any way we could accomplish this?

sotp_flash_write_area expects less than 8 byte flash page size

This is reported by Renesas during to consider increasing internal flash page size (currently =1 and wanted to increase 32 bytes to speed-up firmware update);

When they set 32 for the flash page size, they got page alignment error at runtime here:

https://github.com/ARMmbed/mbed-cloud-client/blob/master/mbed-client-pal/Source/PAL-Impl/Modules/Storage/Flash/pal_internalFlash.c#L399

This is because the sotp_flash_write_area() is called by write_record() function here:

https://github.com/ARMmbed/mbed-cloud-client/blob/9b0bc6a2f3f1f5dbb5be1827db83004d531b99c9/factory-configurator-client/mbed-client-esfs/source/sotp/sotp.c#L339

And the flash write size ((uint32_t *)&header) is 8-bytes because this is size of the record_header_t structure

https://github.com/ARMmbed/mbed-cloud-client/blob/3137b3d7c8da10bae38749a9384e5e5c77a55012/factory-configurator-client/mbed-client-esfs/source/sotp/sotp_int.h#L43-L47

Therefore, when platform flash page size (return value of flash_get_page_size()) is bigger than 16, it always generate alignment error.

Possible case platforms:

• Arm MPS2 (256 bytes)
• NXP LPC54xxx (256 bytes)
• Toshiba TMPM46B (16 bytes)

Memory leak

The following leaks memory if LWM2M_COMPLIANT is defined:

mbed-cloud-client/source/ConnectorClient.cpp

Line 988 in cdacedb

buffer = (uint8_t *)malloc(max_size);

Avoid unnecessary includes

Hello,

when MBED_CLOUD_CLIENT_SUPPORT_UPDATE is not defined, UpdateClientResources.h and update_client_public.h should probably not be included in ServiceClient.cpp to avoid unnecessary dependencies towards update client hub.

mbed-cloud-client/source/ServiceClient.cpp

Lines 28 to 31 in d7edc52

	#if !defined(MBED_CLOUD_CLIENT_FOTA_ENABLE)
	#include "include/UpdateClientResources.h"
	#include "update-client-hub/update_client_public.h"
	#else

Proposal:

#if !defined(MBED_CLOUD_CLIENT_FOTA_ENABLE)
#if defined(MBED_CLOUD_CLIENT_SUPPORT_UPDATE)
#include "include/UpdateClientResources.h"
#include "update-client-hub/update_client_public.h"
#endif
#else

Deletion of Server object should be allowed during bootstrapping

Hello,

in http://www.openmobilealliance.org/release/LightweightM2M/V1_0_2-20180209-A/OMA-TS-LightweightM2M-V1_0_2-20180209-A.pdf bootstrap delete is specified as:

5.2.7.5 BOOTSTRAP DELETE
The Delete operation targets one or several Object Instances and can be sent multiple times.
Only in Bootstrap Interface, the Delete operation MAY target any Instance or all Instances of any Object including the
Security Object (ID:0), supported by the LwM2M Client. The two exceptions are the LwM2M Bootstrap-Server Account and
the single Instance of the Mandatory Device Object (ID:3) which are not affected by any Delete operation.
When the Delete operation is used without any parameter (i.e. without Object ID parameter), all Instances of all Objects in
the LwM2M Client MUST be removed (except for the two cases mentioned above); this functionality could be used for
initialization purpose before LwM2M Bootstrap-Server sends Write operation(s) to the LwM2M Client.

with LwM2M Bootstrap-Server Account beieng specified as:

3.2 Definitions
LwM2M Bootstrap-Server Account LwM2M Security Object Instance with Bootstrap-Server Resource true
LwM2M Server Account LwM2M Security Object Instance with Bootstrap-Server Resource false and associated LwM2M Server
Object Instance

In contrast to the specification bootstrap delete on the e.g. object /1 (Server) is effectively prohibited by https://github.com/PelionIoT/mbed-cloud-client/blob/master/mbed-client/source/m2mnsdlinterface.cpp#L2495-L2508

Best regards,
Sebastian

Success check in M2MNsdlInterface::create_nsdl_list_structure() checks only success of last call to create_nsdl_structure()

success is assigned multiple times at
https://github.com/ARMmbed/mbed-cloud-client/blob/9b0bc6a2f3f1f5dbb5be1827db83004d531b99c9/mbed-client/source/m2mnsdlinterface.cpp#L375

There is no early return on fail. Thus only the last assignment will be returned. This assumes that all following calls after an initial fail will always fail. Was not the case in our codebase.

M2MConnectionHandlerPimpl::eventloop_event_handler is called after object instance is deleted

Running mbedos 5.15.4 with mbed cloud client 4.5.0

Application running is succesfully connecting to the cloud. Then, when it disconnects, I observe following logs:
[DBG ][mClt]: M2MNsdlInterface::remove_object() 0x20030e18
[DBG ][mClt]: M2MBase::free_resources()
[DBG ][mClt]: M2MBase::~M2MBase() 0x20030e18
[DBG ][mClt]: M2MNsdlInterface::~M2MNsdlInterface() - OUT
[DBG ][mClt]: ~M2MConnectionHandlerPimpl()
[DBG ][mClt]: M2MConnectionHandlerPimpl::eventloop_event_handler 2
[DBG ][mClt]: M2MConnectionHandlerPimpl::socket_connect_handler - _socket_state = 0
[DBG ][mClt]: ~M2MConnectionHandlerPimpl() - OUT
[INFO][TRANSMISSION]: NSAPI_STATUS_DISCONNECTED
[DBG ][mClt]: M2MConnectionHandlerPimpl::eventloop_event_handler 66
[INFO][mClt]: M2MInterfaceImpl::network_interface_status_change - disconnected

The [INFO][TRANSMISSION]: NSAPI_STATUS_DISCONNECTED is printed from the application code, a status update listener:

  std::atomic<int> net_up{false};

  auto const status_update_listener = [&net_up](nsapi_event_t status, intptr_t param) {
    if(status == NSAPI_EVENT_CONNECTION_STATUS_CHANGE) {
      switch(param) {
        case NSAPI_STATUS_GLOBAL_UP:
          tr_info("NSAPI_STATUS_GLOBAL_UP");
          net_up = NSAPI_STATUS_GLOBAL_UP;
          break;
        case NSAPI_STATUS_LOCAL_UP:
          tr_info("NSAPI_STATUS_LOCAL_UP");
          break;
        case NSAPI_STATUS_DISCONNECTED:
          tr_info("NSAPI_STATUS_DISCONNECTED");
          net_up = NSAPI_STATUS_DISCONNECTED;
          break;
        case NSAPI_STATUS_CONNECTING:
          tr_info("NSAPI_STATUS_CONNECTING");
          net_up = NSAPI_STATUS_CONNECTING;
          break;
        case NSAPI_STATUS_ERROR_UNSUPPORTED:
        default:
          tr_info("NSAPI_STATUS_ERROR_UNSUPPORTED");
          net_up = NSAPI_STATUS_DISCONNECTED;
          break;
      }
    }
  };

  auto net_iface = m_device->get_network_interface();
  net_iface->add_event_listener(status_update_listener);

This method is registering the callback on the interface disconnect event, passing "this" as event argument.
Later PAL generates the event with passed 'this' address.
https://github.com/ARMmbed/mbed-cloud-client/blob/f72a23e0dc21de4c82ee53fe947153341419a5b9/mbed-client/mbed-client-classic/source/m2mconnectionhandlerpimpl.cpp#L665

The logs marked in bold suggest that the eventloop_event_handler is called after M2MConnectionHandlerPimpl instance have been deleted. If that is the case, then this call https://github.com/ARMmbed/mbed-cloud-client/blob/f72a23e0dc21de4c82ee53fe947153341419a5b9/mbed-client/mbed-client-classic/source/m2mconnectionhandlerpimpl.cpp#L64
I haven't observed any crashes related to this yet, however the logs suggest an undefined behavior.

To verify my observation I added a simple address logging to the destructor and the event handler.

extern "C" void eventloop_event_handler(arm_event_s *event)
{
    tr_debug("M2MConnectionHandlerPimpl::eventloop_event_handler %d", event->event_type);

    if (event->event_type != M2MConnectionHandlerPimpl::ESocketIdle) {
        if(!event->data_ptr) {
            tr_error("M2MConnectionHandlerPimpl::eventloop_event_handler event->data_ptr=NULL !!!!");
            assert(event->data_ptr);
        }
        M2MConnectionHandlerPimpl* instance = (M2MConnectionHandlerPimpl*)event->data_ptr;
        tr_debug("instance address: %p", instance);
        instance->event_handler(event);
    }
}

M2MConnectionHandlerPimpl::~M2MConnectionHandlerPimpl()
{
    tr_debug("~M2MConnectionHandlerPimpl()");
    tr_debug("instance address: %p", this);
#if (PAL_DNS_API_VERSION == 2)
    if ( _handler_async_DNS > 0) {
        pal_cancelAddressInfoAsync(_handler_async_DNS);
    }
#endif

    close_socket();
    delete _security_impl;
    _security_impl = NULL;
    pal_destroy();
    tr_debug("~M2MConnectionHandlerPimpl() - OUT");
}

The this pointer in the destructor is the same one as in the instance inside event handler. Logs:
[DBG ][mClt]: ~M2MConnectionHandlerPimpl()
[DBG ][mClt]: instance address: 0x20029d90
[DBG ][mClt]: ~M2MConnectionHandlerPimpl() - OUT
[DBG ][mClt]: M2MConnectionHandlerPimpl::eventloop_event_handler 2
[DBG ][mClt]: instance address: 0x20029d90
[DBG ][mClt]: M2MConnectionHandlerPimpl::socket_connect_handler - _socket_state = 0
[INFO][TRANSMISSION]: NSAPI_STATUS_DISCONNECTED
[DBG ][mClt]: M2MConnectionHandlerPimpl::eventloop_event_handler 66
[DBG ][mClt]: instance address: 0x20029d90
[INFO][mClt]: M2MInterfaceImpl::network_interface_status_change - disconnected

Connection issue to portal.mbedcloud.com from STM32F769I-DISC1 board with Pelion example

I am trying to bring up the Pelion example on a STM32F769I-DISC1 board.

I have tried pelion-example-common(https://os.mbed.com/teams/ST/code/pelion-example-common/)
and pelion-ready-example (https://os.mbed.com/teams/mbed-os-examples/code/pelion-ready-example/ )
Both of the programs fails to register with portal.mbedcloud.com.

I have followed the the steps correctly from this site.
https://os.mbed.com/guides/connect-device-to-pelion/1/?board=ST-Discovery-F769NI

---

<< serial log >>
[BOOT] Mbed Bootloader
[BOOT] ARM: 00000000000000000000
[BOOT] OEM: 00000000000000000000
[BOOT] Layout: 0 8009328
[BOOT] Active firmware integrity check:
[BOOT] SHA256: 87C10F94E43F5F3BBC6E1CF10E76468103D61A01D65C0482F501F15A69062E2B
[BOOT] Version: 1560524045
[BOOT] Slot 0 is empty
[BOOT] Active firmware up-to-date
[BOOT] Application's start address: 0x8010400
[BOOT] Application's jump address: 0x80110A9
[BOOT] Application's stack address: 0x20080000
[BOOT] Forwarding to application...
p@@
Starting Simple Pelion Device Management Client example
You can hold the user button during boot to format the storage and change the device identity.
Connecting to the network using the default network interface...
Connected to the network successfully. IP address: 10.122.16.108
Initializing Pelion Device Management Client...
Initialized Pelion Device Management Client. Registering...
Press the user button to increment the LwM2M resource value...
ADC temp: 23.2234 C, vref: 0.3665 %
Button clicked 1 times
Button clicked 2 times
[SMCC] Error occurred : MbedCloudClient::ConnectNetworkError
[SMCC] Error code : 6
[SMCC] Error details : Client in reconnection mode NetworkError

---

<< above error happens every 30 seconds and no device
listed here. https://portal.mbedcloud.com/devices/list
What could be the root cause ?
My connection credentials as below from the mbed_cloud_dev_credentials.c file .

const char MBED_CLOUD_DEV_BOOTSTRAP_ENDPOINT_NAME[] = "016b5222ff847a6af473872f03c00000";
const char MBED_CLOUD_DEV_ACCOUNT_ID[] = "016b2914a5fc762d28a836d200000000";
const char MBED_CLOUD_DEV_BOOTSTRAP_SERVER_URI[] = "coaps://bootstrap.us-east-1.mbedcloud.com:5684?aid=016b2914a5fc762d28a836d200000000";

I am on corporate network and I able to ping the target. This proves that network stack is alive.
vgeorge@CI0700000000653:~$ ping 10.122.16.108
PING 10.122.16.108 (10.122.16.108) 56(84) bytes of data.
64 bytes from 10.122.16.108: icmp_seq=1 ttl=254 time=0.318 ms
64 bytes from 10.122.16.108: icmp_seq=2 ttl=254 time=0.384 ms

Is it possible my corporate policy blocking the port 5684 ?

Any small help to debug this issue is greatly appreciated.

Varughese George

dereferencing pointer to incomplete type 'mbedtls_md_info_t' build error

Description of defect

Fails to compile with latest tools:

Build error on MacOS Catalina 10.15.3

[Error] arm_uc_crypto_mbedtls.c@66,77: dereferencing pointer to incomplete type 'mbedtls_md_info_t' {aka 'const struct mbedtls_md_info_t'}
[ERROR] ./src/libs/mbed-cloud-client/update-client-hub/modules/common/source/arm_uc_crypto_mbedtls.c: In function 'ARM_UC_cryptoHashFinish':
./src/libs/mbed-cloud-client/update-client-hub/modules/common/source/arm_uc_crypto_mbedtls.c:66:77: error: dereferencing pointer to incomplete type 'mbedtls_md_info_t' {aka 'const struct mbedtls_md_info_t'}
   66 |     if (hDigest && output && (output->size_max >= (unsigned)hDigest->md_info->size)) {
      |                                                                             ^~

[mbed] ERROR: "/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python" returned error.
       Code: 1
       Path: "/Users/ash/dev/mbed_porject"
       Command: "/System/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python -u /Users/ash/dev/mbed_porject/mbed-os/tools/make.py -t GCC_ARM -m NUCLEO_L496ZG --source . --build ./BUILD/NUCLEO_L496ZG/GCC_ARM"
       Tip: You could retry the last command with "-v" flag for verbose output
---

Target(s) affected by this defect ?

TARGET=NUCLEO_L496ZG
TOOLCHAIN=GCC_ARM
ROOT=.

Toolchain(s) (name and version) displaying this defect ?

arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]

What version of Mbed-os are you using (tag or sha) ?

mbed-os #e642a7d8b360 (tags: latest, mbed-os-5.15.1)

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

mbed-cli --version
1.10.2

How is this defect reproduced ?

1. create new mbed project
2. add mbed-cloud-cloud lib
3. add SN_COAP_MAX_BLOCKWISE_PAYLOAD_SIZE
4. add and setup mbedtls_mbed_client_config.h
5. run mbed compile
6. observe failure

Project Name

In a generic sense the name of this project still makes sense in that it enables Mbed OS and MBL to connect to the cloud.

However this is more specifically an LWM2M client.

If there are extensions for Pelion, then it should probaly be called Pelion client.

There are a lot of vestigial Mbed client Pelion Mbed cloud examples and repositories.

Even someone who is somewhat versed in the history of these projects very often ends up at the deprecated client by accident.

GitHub provides an option to archive projects which might help too.

SMCC could also use a rename. Pelion Client "Helper" or some other better word than "simple".

@maclobdell

No bootstrapping when EST feature is disabled

Hello,

successfully finishing bootstrapping seems not to be possible when MBED_CONF_MBED_CLOUD_CLIENT_DISABLE_CERTIFICATE_ENROLLMENT is defined (which further defines MBED_CLIENT_DISABLE_EST_FEATURE). The reason is that M2MInterfaceImpl::STATE_BOOTSTRAPPED can only be reached when M2MInterfaceImpl::finish_bootstrap() is called in state ConnectorClient::State_EST_Success, which obviously is only possible when the EST feature is enabled. One option might be to call M2MInterfaceImpl::finish_bootstrap() directly in M2MInterfaceImpl::bootstrap_finish() but there might be complications in the EST-enabled case then.

Best regards,
Sebastian

Compiler error with IAR

The line

mbed-cloud-client/mbed-client/source/m2minterfaceimpl.cpp

Line 978 in 105a184

tr_info("M2MInterfaceImpl::state_register - lwm2m_id: %"PRId32", server_address: %s", m2m_id, _server_ip_address.c_str());

produces a compiler error on IAR:

m2minterfaceimpl.cpp",978  Error[Pe2486]: user-defined literal operator not found

It could be fixed by adding spaces before and after PRId32 in order to be not evaluated as user defined literal operator.

Retransmission buffer size invalidated

Hello,
the following line overwrites coap_s::sn_coap_resending_queue_bytes and therefore essentially disables retransmissions. Further it invalidates the eventually configured configuration option MBED_CONF_MBED_CLIENT_SN_COAP_RESENDING_QUEUE_SIZE_BYTES.
https://github.com/ARMmbed/mbed-cloud-client/blob/f72a23e0dc21de4c82ee53fe947153341419a5b9/mbed-client/source/m2mnsdlinterface.cpp#L273

What i would propose is to remove the function call, because sn_coap_resending_queue_msgs and sn_coap_resending_queue_bytes is already initialized by configuration options MBED_CONF_MBED_CLIENT_SN_COAP_RESENDING_QUEUE_SIZE_MSGS and MBED_CONF_MBED_CLIENT_SN_COAP_RESENDING_QUEUE_SIZE_BYTES:
https://github.com/ARMmbed/mbed-cloud-client/blob/4fc8a9c027623f2f7722ea0b2d475e7772352f6d/mbed-coap/source/sn_coap_protocol.c#L161-L164

Regards,
Sebastian

Client lite

Any status on client lite?

Auto Observable Allocation Event Handler

When setting a resource as auto observable mbed-client fails to allocate memory for the event handler

[DBG ][mClt]: M2MInterfaceFactory::create_resource() - creating /32769/0/26241
[DBG ][mClt]: M2MInterfaceFactory::create_object : Name : 32769
[DBG ][mClt]: Created new /32769
[DBG ][mClt]: M2MObject::object_instance(inst_id 0)
[DBG ][mClt]: M2MObject::create_object_instance - id: 0
[DBG ][mClt]: M2MObject::object_instance(inst_id 0)
[DBG ][mClt]: M2MBase::M2Mbase resource name is EMPTY ===========
[DBG ][mClt]: Created /32769/0
[DBG ][mClt]: M2MObjectInstance::create_dynamic_resource(resource_name 26241)
[DBG ][mClt]: Created new /32769/0/26241
[INFO][APP ]: bytes allocated currently: 17786
[INFO][APP ]: current number of bytes allocated for the heap: 280672
[INFO][APP ]: free bytes on the heap: 262886
[INFO][APP ]: current number of allocations: 105
[INFO][APP ]: number of failed allocations: 0
[INFO][APP ]: cumulative sum of bytes ever allocated: 1143221
[INFO][APP ]: max bytes allocated at a given time: 17944
[INFO][APP ]: threads: name:main, priority: 24, size: 12288, free: 9384
[INFO][APP ]: threads: name:rtx_idle, priority: 1, size: 1408, free: 868
[INFO][APP ]: threads: name:rtx_timer, priority: 40, size: 1536, free: 1392
[INFO][APP ]: threads: name:stm_queue, priority: 24, size: 4096, free: 2888
assertion "_tasklet_id >= 0" failed: file "./src/libs/mbed-cloud-client/mbed-client/mbed-client-classic/source/m2mtimerpimpl.cpp", line 78, function: M2MTimerPimpl::M2MTimerPimpl(M2MTimerObserver&)

Mbed-os: 5.15.2
Cloud Client Version: v4.4.0 #64

TLV encoding?

Release notes say:
"Fixed handling of content type format for PUT requests on resource level. Client only accepts text/plain and opaque content-types."

Does it no longer support TLV?

Compilation is ok but mcc_platform_storage_init() - bd->init() failed with -5005

Hello,
On NUCLEO_F429ZI we have a problem after flashing the firmware compiled by this tutorial: https://cloud.mbed.com/docs/current/connecting/mbed-os.html
Here is the boot log:

[BOOT] Mbed Bootloader
[BOOT] ARM: 00000000000000000000
[BOOT] OEM: 00000000000000000000
[BOOT] Layout: 0 8007798
[BOOT] Application's start address: 0x8010400
[BOOT] Application's jump address: 0x80584F9
[BOOT] Application's stack address: 0x20030000
[BOOT] Forwarding to application...

mcc_platform_storage_init() - bd->init() failed with -5005
Failed to initialize storage

Abort unregistration process on failure

Hello,

Platform: mbed-client of mbed-cloud-client 4.6 with mbed-os 5.15

We noticed in the mbed-client that in case there is a communication error during M2MInterfaceImpl::unregister_object (e.g simulated failure on the server) the client will try to reconnect, which might fail again, etc.

It would be nice to have a proper way to abort the process in this scenario (at least I couldn't find a way right now) as this might lead to increased energy consumption while it may be acceptable to not cleanly deregister from the server after every connection.

Current behavior:

[INFO][mClt]: M2MNsdlInterface::send_unregister_message
....
[INFO][mClt]: M2MNsdlInterface::handle_unregister_response - unregistered
[ERR ][mClt]: M2MNsdlInterface::handle_unregister_response - unregistration error 4
[ERR ][mClt]: M2MInterfaceImpl::registration_error code [13]
[ERR ][mClt]: M2MInterfaceImpl::socket_error: (-8), retry (1), reconnecting (0), reconnection_state (2)
[INFO][mClt]: M2MInterfaceImpl::create_random_initial_reconnection_time() initial random time 21
[INFO][mClt]: M2MInterfaceImpl::socket_error - reconnecting in 21(s)
...

So far I tried to workaround it by stopping the reconnect attempt during M2MNsdlInterface::handle_unregister_response
in case we receive a coap header with status COAP_STATUS_BUILDER_MESSAGE_SENDING_FAILED. This allows us to early out of the process.

Is there a better way to handle this or should the client try to reconnect at all during unregistration?

Thanks!

Difference between mbed-cloud-client and simple-mbed-cloud-client

What exactly is the difference between the two? It seems both repositories are actively maintained and both are intended to be used for Pelion Device Management.