David Navarro

Wakaama has no dependency on the security layer. Thus you can switch easily to the one present on your target platform.

Hi, Per design, solution 1. is the way to go. By modifying lwm2m_step(), the client application would never know a problem occurred. Regards

Hi, Sorry, I can not reproduce your issue. Here are my logs: [log_189_dnav.txt](https://github.com/eclipse/wakaama/files/369328/log_189_dnav.txt)

The issue is still valid. As it lies in the dtls_connection code, it does not have a high priority on **my** task list. Regards

No, it was not. Sorry.

As stated in #263, my opinion is that the Object plugin should do the base64 decoding. The base64 decoding is required if, for an opaque resource, the lwm2m_data_t is of...

The encoding is done in the core because the Object plugin sets the lwm2m_data_t::type to LWM2M_TYPE_OPAQUE. Then the core knows it has to base64 encode the data for JSON format....

Hi, When received as JSON, the lwm2m_data_t has a type String. The security object should indeed base-64 decode it. Thanks for reporting this.

1. and 2. are the Object plugin responsability. It should call lwm2m_resource_value_changed() when instances are created and deleted. Note that creating or deleting instances will generate a registration update message....

Hi, We also spotted the ambiguity and in the next release of the LwM2M TS, the related text is updated to: > According to the ABNF syntax above, the values...