Any idea of how i may implement the send operation from Lwm2m1.1 using the version lwm2m1.0?

[ce237]

Hello,

It is possible to implement the "send operation" from Lwm2m v1.1 using lwm2mv.1.0? when yes, any idea on how i may implement it?

When no, just out of curiosity , when will it be possible for Zepyhr's Lwm2m to support the "send operation" from Lwm2m v.1.1?

Best regards,

Cedric

[carlescufi]

Maybe @rlubos can give you some info here.

[rlubos]

I don't think it's possible to implement Send Operation exclusively based on LwM2M 1.0. Send operation is expected to use new data formats introduced in LwM2M 1.1, the spec makes it clear:

The value included in the payload MUST be either SenML JSON or SenML CBOR format
So this doesn't seem to be a feature that could be "cherry-picked" from LwM2M feature set.

As for the LwM2M 1.1 support in Zephyr, currently there's no timeline for that. We might support this in the future, as it's a desired feature, but I can't give any dates as for now.

[ce237]

Thanks for your reply

Meaning the specification of the "send operation" compared to other operations already implemented by Zephyr is not supported?

From your experience, is it possible for the client to send updates to the server with the operations implemented by Zephyr, without this server explicitly having to send an "observe" request?

I will like to know your thoughts on this.

Thanks

[rlubos]

Zephyr supports LwM2M in version 1.0.2, so Send operation is not supported as it was introduced in LwM2M 1.1.

As far as I know, the only way for the client to proactively send data in LwM2M 1.0.2 is the observe mechanism, so I'm afraid that what you want to achieve is not possible with current implemetation, you need to explicity send observe request to get updates.

As mentioned earlier, we'd need to implement a subset of LwM2M 1.1 specification (not only the send op but also new data encoders) in order to get a different method on data delivery on the client side.

[ce237]

Ok thanks

[ce237]

I get another question.

I am using a nrf9160 DK from Nordic semiconductor. I am trying to connect it to californium server. And i want to be able to see the iteractions between the two using wireshark. I want to be able to send a Coap request with a payload of 100bytes.

Here is a sample of my code:

main.zip

I am very new in this area. So my first step is to be able to have a connection between nrf9160 dk (which is my client) and the californium server. Please do you have any idea of how i can implement it?

I already had a look at coap client

I will really appreciate if you could help.

[ce237]

Thanks for your reply.

Did you actually try to run the coap_client sample from nRF Connect SDK?

Yeah i tried it and it worked.

Now i modified it and trace the iteraction. That's what i got:

trace-2021-10-28T10-52-42.203Z.zip

And here is my code:

main.zip

[rlubos]

So we can see in the PCAP that handshake fails at a very early stage. I'm not sure what security the Californium test server is running (couldn't find any info here), but from what I see it fails at ciphersuite negotiation level so it seems that the client and server could not find a common one. Note that nRF91 modem only supports PSK-based DTLS.

[ce237]

So we can see in the PCAP that handshake fails at a very early stage. I'm not sure what security the Californium test server is running (couldn't find any info here), but from what I see it fails at ciphersuite negotiation level so it seems that the client and server could not find a common one. Note that nRF91 modem only supports PSK-based DTLS.

I tried again and i got this what do you think:

trace-2021-10-28T12-32-41.786Z.zip

[rlubos]

This seems more like a server-side issue - it simply stops responding during the handshake. I have no idea why (it should send the Alert message if something went wrong during the handshake).

[ce237]

This seems more like a server-side issue - it simply stops responding during the handshake. I have no idea why (it should send the Alert message if something went wrong during the handshake).

ok thanks very much for your support. I really appreciate you taking the time for me

[ce237]

Good morning @rlubos,

i have another question:

Does DTLS libraries support draft-ietf-tls-dtls-connection-id?

My goal is to be able to initiate the communication with the server after my device come out of the PSM (Sleeping mode).

Or what do you think, will be the best approach to implement that? Any idea

[rlubos]

Hi, we don't support this feature yet.

I've tried to implement it some time ago, but it turned out that there are some inconsistencies in mbed TLS cmpared to the recent draft spec of this feature, so it was not straightforward to use it.

I have created a draft PR with the implementation (#36738) but at this point we're waiting for things to settle on mbed TLS side (the connection ID specification was pulled out of the draft state and is now waiting for approval, it could be official soon). Once we get a new mbed TLS release with Connection ID implemented consistently with the spec, I'll pull the PR out of the draft and try to get it into Zephyr.

[ce237]

I have created a draft PR with the implementation (#36738) but at this point we're waiting for things to settle on mbed TLS side (the connection ID specification was pulled out of the draft state and is now waiting for approval, it could be official soon). Once we get a new mbed TLS release with Connection ID implemented consistently with the spec, I'll pull the PR out of the draft and try to get it into Zephyr.

Thanks for the info.

Just to be sure i understood that means, it isn't possible to initiate the communication to the server after a device come out of the PSM yet? correct?

[rlubos]

It's not possible to continue DTLS session sue to NAT rules in cellular networks. From the server perspective you'll likely be communicating from a different port/IP that invalidates the DTLS session.

[ce237]

It's not possible to continue DTLS session sue to NAT rules in cellular networks. From the server perspective you'll likely be communicating from a different port/IP that invalidates the DTLS session.

I guess to be able to use PSM, i will rather use CoAP without DTLS meaning CoAP/UDP instead of CoAP/DTLS.

[ce237]

Hi @rlubos

sorrying for bordering you once again, but i have a question:

i want to send a JSON payload {"command":"periodic","type":"8","number":"33"} using the PUT-method from CoAP. For that i have to send the content format option for JSON.

   coap_packet_append_option(&request, COAP_OPTION_CONTENT_FORMAT,
                              (uint8_t *)value, 
                              sizeof(value));

request is my CoAP packet and value is an unsigned integer with the value COAP_CONTENT_FORMAT_APP_JSON (50).

Despite the fact that JSON is one of the context format from CoAP. I do want to if my annotation is correct, since i tried and i couldn't send the payload to the californium server.

test.zip

Thanks in advance

[rlubos]

I'm afraid there's too little information to give exact answer, please use this code snippet as a reference on how to create and send a valid CoAP packet with JSON content format.

[ce237]

I am creating my JSON Payload with the following function:

cJSON * createJsonFromParams(void)
{

cJSON *root = cJSON_CreateObject();
    cJSON_AddNumberToObject(root, "JSON", 50);
    cJSON_AddNumberToObject(root, "Content-Form", 12);


    cJSON_Delete(root);

return root;

}

The main function :

    cJSON_Init();
    cJSON *payload = createJsonFromParams();

Do you think it is the appropriate way of forming my JSON Payload?

[rlubos]

You shouldn't call cJSON_Delete(root); before return root;, the memory could be overwritten by some other part of the application if you release it too early. You should delete the object only after it's content has been copied to the CoAP packet.

Additionally, you cannot just send CJSON object as is to the network, you need to serialize it first (see cJSON_Print()/cJSON_PrintUnformatted()).

[ce237]

Thank you very much