lwm2mclient_tinydtls problem

[kevin5562]

For lwm2mclient_tinydtls: I type ./lwm2mclient_tinydtls -s 4f75724964656e74697479 -i public -b

Result: lwm2mclient_tinydtls is stuck in State: STATE_BOOTSTRAPPING and I found it doesn't execute connection_rehandshake function.

Finallt, it show: lwm2m_step() failed: 0xA3 [BOOTSTRAP] ObjectList restored

Question: Is it correct for the command ? Could you please help me to solve this problem?

[boaks]

If you assume it is an issue of tinydtls, is it possible for you the post a IP-capturing?

[kevin5562]

The environment I set up is based on wakaama opensource, and I did't modify any code. So, Could you please help me how to correctly do the dtls connection part? Is it correct for the command I type?

[boaks]

Unfortunately, it's very long ago, that I was up-2-date with lwm2m or wakaama. As written in my comment above, what I'm able to offer, is support for the DTLS handshake. If you're able to provide a IP-capture as described in the link in my comment above, I will check it. Anyway, maybe someone else can help your more direct and without a IP-capture.

[kevin5562]

Unfortunately, it's very long ago, that I was up-2-date with lwm2m or wakaama. As written in my comment above, what I'm able to offer, is support for the DTLS handshake. If you're able to provide a IP-capture as described in the link in my comment above, I will check it. Anyway, maybe someone else can help your more direct and without a IP-capture.

Okay, I will adopt your advice.

[boaks]

Having a short look at the bootstrap_server, I wonder, if that supports DTLS for its own communication at all.

 ./lwm2mclient_tinydtls -s 4f75724964656e74697479 -i public -b

May not work with the wakaama bootstrap server, though it uses PSK/DTLS

bootstrap_server.ini

Information on a LWM2M server running on localhost

using Pre-Shared Key security

[Server] id=3 uri=coaps://localhost:5684 bootstrap=no lifetime=300 security=PSK public=4f75724964656e74697479 secret=4F7572536563726574

my feeling is, you used the line public=4f75724964656e74697479 for the parameters. That is not the way, it is intended. if you want to connect to a lwm2m server, which is configured with these credentials of the "bootstrap_server.ini", you must use:

 ./lwm2mclient_tinydtls -s 4F7572536563726574 -i 4f75724964656e74697479

In sum, it requires one, which is common about the current implementation state of wakaama and how that is used. Sometimes, it's easier to check for leshan, if you search for an lwm2m-server.

[kevin5562]

After adopting your advice, I found the rehandshake error. Could you please explain why it happend?

[boaks]

I checked the capture you sent me by mail.

It shows some traffic to and from 5784. If your bootstrap server runs on 5685, that traffic in the capture is not related to your question. A CoAP/DTLS endpoint runs on a host's service port. And if you want to capture the traffic you need to use that port to filter the packages.

As I already wrote above, I don't think it's a tinydtls issue, it's a question what is actually implemented in wakaama. And that is something out of my scope, others know that better.

[kevin5562]

But I found the rehandshake error is arising from the parameter res = dtls_connect_peer(ctx, peer), it will return 54.(not 0), so it will print "error dtls reconnection". Any suggestino to fix this issue?

[boaks]

Your description of this issue is too wired for me, therefore I can't say too much. And your capture seems to be not related to this issue, I don't know what you actually do.

res = dtls_connect_peer(ctx, peer), it will return 54.(not 0), so it will print "error dtls reconnection".

tinydtls - dtls.h

@return A value less than zero on error, greater or equal otherwise.

Maybe wakaama prints an error for "otherwise" as well, but I'm not sure why.

And again, I can't see, that the bootstrap-server supports DTLS. The client uses

#ifdef WITH_TINYDTLS
#include "dtlsconnection.h"
#else
#include "connection.h"
#endif

and I can't find that in the bootstrap-server.

So, maybe you're better off, to start without DTLS to become more common to lwm2m.

[kevin5562]

Actually, I don't use bootstrap server according to your suggestion, and I will send you an email with the code with issue.

[boaks]

I will send you an email with the code

Please not, I will not be able to check your code! I assume, the connection_rehandshake was not tested.

[kevin5562]

You don't have to check the code and you can only check the sceenshot I provided. The code I get from the wakaama opensource website and I didn't modify any change. Could you please provide some solution or any related useful resource for me to solve this dtls_handshake issue?

[boaks]

Could you please provide some solution or any related useful resource for me to solve this dtls_handshake issue?

Again, starting from the begin: I need a capture of the handshake in order to say anything. But from our conversation so far, I don't think your able to provide that.

The connection_rehandshake seems to be broken. if you like, I don't know, if that makes it better or not, try out:

    // start a fresh handshake
    int result = dtls_connect(connP->dtlsContext, connP->dtlsSession);

    if (result < 0) {
         printf("error dtls reconnection %d\n",result);
    } else if (result > 0) {
        // dtls_connect uses value larger than 0 also for success
        result = 0;
    }
    return result;

[boaks]

I got your e-mail. No, I can't see more details and so I can't offer more help. So, try it without DTLS.

[boaks]

#ifdef WITH_TINYDTLS
#include "dtlsconnection.h"
#else
#include "connection.h"
#endif

and I can't find that in the lwm2m-server either. I guess, it's also not implemented that the server uses DTLS. Therefore, try it without DTLS.

[kevin5562]

Thanks for your explanation. Is there any difference between dtls and tinydtls? Does the lwm2m only support tinydtls? no dtls? Is that because lwm2m is based on coap protocol?

[boaks]

Is there any difference between dtls and tinydtls?

DTLS is the name of the encryption protocol (see RFC6347 ). tinydtls is the name of one of the DTLS implementations (see eclipse/tinydtls). mbedtls is an other DTLS implementation (see Mbed-TLS). There is an open PR #626 and an issue #623 about supporting mbedtls.

All that will not help you to use DTLS successful with on of the wakaama servers, their implementations are just not supporting it. At least, that's what I see.

Therefore, just try to use it without DTLS and see, if that works for you as expected. Only if that is the case, you may start to consider using eclipse/leshan as server with DTLS support.

[boaks]

Does the lwm2m only support tinydtls? no dtls?

Though lwm2m is a specification, it refers to dtls, not to a specific implementation as "tinydtls".

Is that because lwm2m is based on coap protocol?

No. lwm2m is a specification, which refers to the coap specification RFC 7252 and the dtls specification RFC6347.

wakaama and leshan are implementations of lwm2m. As lwm2m refer to coap and dtls, those lwm2m implementations are also using implementations for coap and dtls. For leshan, that's currently mainly eclispe/californium, which implements coap and dtls. For wakaama, it's "erbium", which is included in the source as coap implementation. And tinydtls is used by the wakaama lwm2m-client. But currently not for the wakaama servers.

[kevin5562]

I reference RFC7257, but I found there is some parameter missing in er-coap-13.h. Could anyone tell me where is the following parameter NSTART, DEFAULT_LEISURE, PROBING_RATE in the file er-coap-13.h?

[boaks]

You mean RFC7252, not 7257, as you wrote?

Not all implementation will put these parameter in a "easy to change" configuration, especially the implementation for embedded use-cases frequently have them "fixed in code". e.g. NSTART larger than 1 requires a lot more in the code to handle parallel pending requests. Also some embedded implementation don't fully implement RFC7252, if multicast is not intended, DEFAULT_LEISURE doesn't make too much sense.

[kevin5562]

Thanks for your explanation. The NSTART not defined in wakaama, it explicitly mean its value is 1, right? And the PROBING_RATE is also not been found in wakaama. How to explain this situation?

[boaks]

The NSTART not defined in wakaama, it explicitly mean its value is 1, right?

At least, I consider that. it may be even, that you need to consider it in your application code, by not sending new request until the old ones are completed (maybe by timeout).

And the PROBING_RATE is also not been found in wakaama. How to explain this situation?

Please explain, where you need that? AFAIK, that value is only relevant, if you send data the first time to an peer via an unknown ip-route. It is used to prevent "transmission congestion" assuming very "constraint bandwidth".
In many cases, it already works with NSTART-1 and "timeout is doubled" on retransmission.

See also core-mailing-list

(Let me try to explain my involvement: it's years ago, that I worked with/in wakaama. And also years ago, that I decided, that improving eclipse/californium is more important for me. Last year I started to improve tinydtls as well, in order to benefit more from Californium unique features. I mainly used mobile IoT (LTE-M, NB-IoT) and neither the bandwidth nor the device are too constraint there. So the most concerns don't apply to my recent work. I don't plan to focus back on wakaama.)

[kevin5562]

AFAIK, that value is only relevant, if you send data the first time to an peer via an unknown ip-route. It is used to prevent "transmission congestion" assuming very "constraint bandwidth".

I don't implement any application code, just use the wakaama source code. So, What does mean unknown ip-route?

In many cases, it already works with NSTART-1 and "timeout is doubled" on retransmission.

Does it mean the value of probing rate is 1?

[boaks]

I don't implement any application code, just use the wakaama source code.

I'm not sure, if I get that. I would assume, that a lwm2m-device is considered to implement at least some custom code to fill the some application values in the lwm2m resources.

So, What does mean unknown ip-route?

IP-messages are usually forwarded over a couple of links, e.g. "wifi"-"dsl-router"-"ip-provider-network"-"cloud-provider-network". A "unknown ip-route" is then the route, which the message will take, if there was no traffic for a certain amount of time. It may use different links with other speed. Generally, this doesn't make too much difference, but assuming really "narrow-banded" links, it requires to relax the timings.

Does it mean the value of probing rate is 1?

Did you read the messages in the mailing list? Carsten's answer should help to understand the relation ship.

[kevin5562]

Did you read the messages in the mailing list? Carsten's answer should help to understand the relation ship.

Yes, he said that an application should not send a sustained rate of more than about 1 B/s to a peer endpoint that might not be reachable (“into thin air”). So, the probing rate may be smaller or equal to 1 in wakaama?

[boaks]

So, the probing rate may be smaller or equal to 1 in wakaama?

That depends mainly on the used message size for the lwm2m-(re)-registration and the notifies. It's not really granted, there are no "means" to throttle it, except you adjust the initial timeout accordingly. If this is relevant for you at all depends then more on the really used network.