We are using the Wakaama client with a Leshan server. The Leshan server is sending a message to the Wakama client in multiple blocks and the Wakaama client is not able to parse the entire message. The first block is read and parsed properly by the Wakaama client, but then the following debug message is seen: "packet.c: Block1 NOT IMPLEMENTED".

According to http://dev_devtoolkit.openmobilealliance.org/IoT/LWM2M10/doc/TS/index.html#!Documents/bootstrapmodes.htm a client may bootstrap itself by using a boostrap server, a smartcard or using factory bootstrap information.

In the examples this is done by setting up the server address in the security object and calling lwm2m_configure.

If you have to wait for factory bootstrap information to be available for one or another reason,
what is the correct way to provide it to wakaama, after lwm2m_configure has been called?

The AwaLWM2M implementation provides a AwaStaticClient_SetFactoryBootstrapInformation in https://github.com/FlowM2M/AwaLWM2M/blob/master/api/include/awa/static.h#L299 for exactly this case. It that already possible or should wakaama support something similar, too?

IPv6 works well for non DTLS builds. But for non debug builds with DTLS enabled, IPv6 fails to register with leshan device management server. Commands used

cmake -DDTLS=1 ../client/ -DCMAKE_BUILD_TYPE=Release
make

Logs attached
Note: IPv6 works for DTLS debug builds.
Code is in sync with wakaama/master.
Compiler: Apple LLVM version 7.3.0 (clang-703.0.29)

Hi,

I've been trying out Wakamaa implementation and found a strange thing that the Xcode compiler warns about (yes, i'm running native-c code inside swift and it works fine).

In core/utils.c there is a function:
lwm2m_media_type_t utils_convertMediaType(coap_content_type_t type)
which checks LWM2M_CONTENT_TLV and LWM2M_CONTENT_JSON, but those two cases are not part of enum lwm2m_media_type_t. Why are there printouts? Wouldn't it be better instead to either add those to the enum or remove the two cases?

`

switch(type) {

case TEXT_PLAIN:
    return LWM2M_CONTENT_TEXT;

case APPLICATION_OCTET_STREAM:
    return LWM2M_CONTENT_OPAQUE;

case LWM2M_CONTENT_TLV:
    // print if compiler warning occur
    LOG("ERROR: Case value LWM2M_CONTENT_TLV, not in enumerated type: %d\r\n", type);
    return LWM2M_CONTENT_TLV;

case LWM2M_CONTENT_JSON:
    // print if compiler warning occur
    LOG("ERROR: Case value LWM2M_CONTENT_JSON, not in enumerated type: %d\r\n", type);
    return LWM2M_CONTENT_JSON;

case APPLICATION_LINK_FORMAT:
    return LWM2M_CONTENT_LINK;

default:
    return LWM2M_CONTENT_TEXT;
}

`

My setup:
I'm using the latest (git from 11.03.) lwm2mclient with a leshan server+bootstrap server. I register/unregister the client several times from the server and also reinitilize the client with bootstrap from time to time.

The error with memtrace enabled:

lwm2m_step() failed: 0xA3
[BOOTSTRAP] restore security and server objects
memory: free error (no malloc) /home/david/wakaama/tests/client/object_security.c, 501, free_security_object
memory: already frees at /home/david/wakaama/tests/client/object_security.c, 501, free_security_object
memory: free error (no malloc) /home/david/wakaama/tests/client/object_server.c, 450, free_server_object
memory: already frees at /home/david/wakaama/tests/client/object_server.c, 450, free_server_object
[BOOTSTRAP] ObjectList restored

And after looking into the code I actually have problems to understand void prv_restore_objects(lwm2m_context_t * context) in lwm2mclient.c. You first call free_security_object(object) which as last statement calls lwm2m_free(object). So the object pointer is invalid from this point on. After that you call copy_security_object(object, backup_object) which tries to do a memcpy to this (in my opinion) invalid pointer. Did I overlooked something?

prv_refreshServerList API makes unsorted list, as a result if we have more than 2 servers, lets say instance 0,1, then instead getting 0,1 list we will get 1,0 list.
it causes wakaama to not find instance 0 server.
eventually we will have duplicated servers.

see the following fix code:

static int prv_refreshServerList(lwm2m_context_t * contextP)
{
lwm2m_server_t * targetP;
lwm2m_server_t * nextP;
lwm2m_server_t * head=0;

// Remove all servers marked as dirty
targetP = contextP->bootstrapServerList;
contextP->bootstrapServerList = NULL;
while (targetP != NULL)
{
    DBG(DBG_VERBOSE,"bootstrapServerList not empty \n");
    nextP = targetP->next;
    if (targetP->dirty == false)
    {
        DBG(DBG_VERBOSE,"Bootstrap serverId=%d is NOT dirty, server was not deleted \n",targetP->shortID);
        targetP->status = STATE_DEREGISTERED;
        targetP->next=0;
        head = (lwm2m_server_t*)LWM2M_LIST_ADD(head, targetP);
    }
    else
    {
        DBG(DBG_VERBOSE,"prv_deleteServer \n");
        prv_deleteServer(targetP);
    }
    targetP = nextP;
}
contextP->bootstrapServerList=head;
head=0;
targetP = contextP->serverList;
contextP->serverList = NULL;
while (targetP != NULL)
{
    nextP = targetP->next;
    if (targetP->dirty == false )
    {
        // TODO: Should we revert the status to STATE_DEREGISTERED ?
        DBG(DBG_VERBOSE,"serverId=%d is NOT dirty, server was not deleted  \n",targetP->shortID);
        targetP->next=0;
        head = (lwm2m_server_t*)LWM2M_LIST_ADD(head, targetP);
    }
    else
    {
        prv_deleteServer(targetP);
    }
    targetP = nextP;
}
contextP->serverList=head;
return object_getServers(contextP);

}

I am using Leshan bootstrap and device management server. This is very similar to issue #155.

I had given wrong port for device management server in bootstrap server GUI. I started lwm2mclient and after a while found the mistake(of wrong port) and corrected port in bootstrap server. But Wakaama client, continues to use the old incorrect port. Kindly see attached bootstrap_new_entries_failed.txt. In Bootstrap GUI, I had changed Leshan device management port from 5784 to 5884. But the lwm2mclient is not picking it up.

Code in sync with wakaama/master
Compiler: gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4
Leshan BM/BS server version - 0.1.11-M10

In core/packet.c line 210

LOG(" Content type: %d\r\n Payload: %.*s\r\n\n", message->content_type, message->payload_len, message->payload);

Add %d for message->payload_len =>

LOG(" Content type: %d\r\n Lens: %d Payload: %.*s\r\n\n", message->content_type, message->payload_len, message->payload);

Hi,

I've implemented wakamaa server in a project. However if the server at the same time on the same objectId and instanceId:

1. request observation on resourceId 1 on client side
2. makes a read on resourceId 2 on client side
3. makes a write to resourceId 3 on client side
   then it seems like Wakamaa can't handle 3 requests, i.e it sends back an response from the client on the obervation request, but no response on the others.

Is it necessary to add a queue on a higher level on the server-side, so the client can cope without being choked. But isn't there a queue mechanism already inside of the Wakamaa protocol, or have I misunderstood the implementation?

Is it only me who need to make many requests? Are other people adding sleep(X) seconds between each request, or how are you using this protocol? All ideas/suggestions are welcome.

Best regards Magnus Lindstedt

Assuming wakaama user is invoking lwm2m_resource_value_changed in a background thread, for the response to be sent to device management server, the lwm2m_step timeout has to expire / wait for data from server. In order to avoid this wait, could wakaama consider adding a lwm2m* method, which the user could invoke, to get out of the lwm2m_step timeout ? Or any alternative plan which helps the lwm2m observer to notified as early as possible.

Hi,

sorry to bother again, with a new question. I've run into another question, that maybe someone knows the answer to?

Let's say the LWM2M server tells a LWM2M client that it wants to observe for example /3/0/0. And lets say server then stupidly doesn't keep track of what it is doing and requests an observe on the same value towards the LWM2M client again.

According to code in lwm2m_observe() function in core/observe.c, I can't see that there is a check to NOT observe on the same value again (neither lwm2m_list_newId or LWM2M_LIST_ADD does a check). Is that correct behaviour? What's the reason for being able to add multiple observations on same value? Is it because the observe callback could be to another function? Does anyone know?

`
int lwm2m_observe(lwm2m_context_t * contextP,

              uint16_t clientID,
              lwm2m_uri_t * uriP,
              lwm2m_result_callback_t callback,
              void * userData) {
lwm2m_client_t * clientP;
lwm2m_transaction_t * transactionP;
lwm2m_observation_t * observationP;
uint8_t token[4];

if (!LWM2M_URI_IS_SET_INSTANCE(uriP) && LWM2M_URI_IS_SET_RESOURCE(uriP)) return COAP_400_BAD_REQUEST;

clientP = (lwm2m_client_t *)lwm2m_list_find((lwm2m_list_t *)contextP->clientList, clientID);
if (clientP == NULL) return COAP_404_NOT_FOUND;

observationP = (lwm2m_observation_t *)lwm2m_malloc(sizeof(lwm2m_observation_t));
if (observationP == NULL) return COAP_500_INTERNAL_SERVER_ERROR;
memset(observationP, 0, sizeof(lwm2m_observation_t));

observationP->id = lwm2m_list_newId((lwm2m_list_t *)clientP->observationList);
memcpy(&observationP->uri, uriP, sizeof(lwm2m_uri_t));
observationP->clientP = clientP;
observationP->status = STATE_REG_PENDING;
observationP->callback = callback;
observationP->userData = userData;

token[0] = clientP->internalID >> 8;
token[1] = clientP->internalID & 0xFF;
token[2] = observationP->id >> 8;
token[3] = observationP->id & 0xFF;

transactionP = transaction_new(COAP_TYPE_CON, COAP_GET, clientP->altPath, uriP, contextP->nextMID++, 4, token, ENDPOINT_CLIENT, (void *)clientP);
if (transactionP == NULL)
{
    lwm2m_free(observationP);
    return COAP_500_INTERNAL_SERVER_ERROR;
}

observationP->clientP->observationList = (lwm2m_observation_t *)LWM2M_LIST_ADD(observationP->clientP->observationList, observationP);

coap_set_header_observe(transactionP->message, 0);
coap_set_header_token(transactionP->message, token, sizeof(token));

transactionP->callback = prv_obsRequestCallback;
transactionP->userData = (void *)observationP;

contextP->transactionList = (lwm2m_transaction_t *)LWM2M_LIST_ADD(contextP->transactionList, transactionP);

return transaction_send(contextP, transactionP);

}
`

DTLS enabled wakaama examples client (lwm2mclient) doesn't send update registration requests if initiated with a bootstrap. Kindly see attached logs.

Code in sync with wakaama/master. Same behavior in wakaama/registration_rework.
Compiler: Apple LLVM version 7.3.0 (clang-703.0.29)
Server: Leshan bootstrap and device management server.

Always crash in coap_serialize_message().

Starting program: /data/lwm2m/wakaama/build_client/lwm2mclient -h "leshan.eclipse.org" -p "5683" -4
Trying to bind LWM2M Client to port 56830
LWM2M Client "testlwm2mclient" started on port 56830

Opening connection to server at leshan.eclipse.org:5683
Sending 153 bytes to [5.39.83.206]:5683
44 02 49 11 11 49 10 87 B2 72 64 11 28 3D 05 65 D.I..I...rd.(=.e
70 3D 74 65 73 74 6C 77 6D 32 6D 63 6C 69 65 6E p=testlwm2mclien
74 03 62 3D 55 06 6C 74 3D 33 30 30 FF 3C 2F 3E t.b=U.lt=300.</>
3B 72 74 3D 22 6F 6D 61 2E 6C 77 6D 32 6D 22 3B ;rt="oma.lwm2m";
63 74 3D 31 35 34 33 2C 3C 2F 31 2F 30 3E 2C 3C ct=1543,</1/0>,<
2F 33 2F 30 3E 2C 3C 2F 35 2F 30 3E 2C 3C 2F 36 /3/0>,</5/0>,</6
2F 30 3E 2C 3C 2F 31 30 32 34 2F 31 30 3E 2C 3C /0>,</1024/10>,<
2F 31 30 32 34 2F 31 31 3E 2C 3C 2F 31 30 32 34 /1024/11>,</1024
2F 31 32 3E 2C 3C 2F 34 2F 30 3E 2C 3C 2F 37 2F /12>,</4/0>,</7/
30 3E 2C 3C 2F 32 2F 30 3E 0>,</2/0>
22 bytes received from [5.39.83.206]:5683
64 41 49 11 11 49 10 87 82 72 64 0A 38 73 78 79 dAI..I...rd.8sxy
44 7A 6A 62 67 76 Dzjbgv
15 bytes received from [5.39.83.206]:5683
45 01 4D 06 7D 2F F7 C6 E1 B1 33 01 30 01 36 E.M.}/....3.0.6

Program received signal SIGSEGV, Segmentation fault.
__memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:131
131 ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S: No such file or directory.
(gdb) bt
#0 __memmove_ssse3_back () at ../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:131
#1 0x000000000041d31e in coap_serialize_message ()
#2 0x0000000000414032 in message_send ()
#3 0x0000000000413e02 in lwm2m_handle_packet ()
#4 0x0000000000406618 in main ()

(gdb)

The client needs to handle this in handle_bootstrap_command() case COAP_PUT.

All IDEs that I know of, which support cmake as a buildsystem or consume a cmake generated project, require the header files also to be listed for the add_executable call. This affects: QtCreator, Visual Studio, XCode.

At the moment all examples repeat the source list of

• the platform
• tinydtls (if applicable).

I propose to create a cmake file for the platform and and tinydtls each and let those files be included by the example and test projects. That would also be consistent with how the core sources files are listed and included.

With Wakaama client, a single failed registration or failed update registration, stops the client. However, Wakaama behaves differently with a failed bootstrap, by retrying till it successfully bootstraps.

In Leshan LWM2M client, on a failed update registration, client tries to register, and further failures takes it to bootstrap server. Kindly see UpdateRegistrationTask(1).

I understand this is a conscious design decision taken, but this burdens the application developer. From my narrow perspective, any Wakaama user, would like the Leshan route. Is there any class of application developers benefiting from this kind of a decision and would like to know the reasoning behind this decision?

Hi,

Since tinydtls is sub module of wakaama, do we still need two client demo?

Actually in my local copy I already merge tests/securityclient into tests/client because tests/client has more features in it.

It's easier for maintain and bug fix. We may use define dtls feature in tests/client.

Thanks.

Callstack:

0xf7dbb770
coap_serialize_multi_option() at er-coap-13.c:225 0x8095dd3
transaction_send() at transaction.c:394
lwm2m_step() at liblwm2m.c
main()

Analysis:

If the EP is too long, and lead to the header is longer than COAP_MAX_HEADER_SIZE, the coap_serialize_multi_option() return 0 and transaction->buffer would be assigned to NULL.

But the coap_free_header is called and the transcationP->message is freed partially.

When re-send,transaction, coap_serialize_message is called again due to the NULL value of transaction->buffer,.................then the program is corrupted.

Solution

Remove the transaction if coap_serialize_message is failed

BR/Baoli

I'm not familiar with the new build system. Does anyone have the same problem?

ricky@ricky-VirtualBox:~/lwm2m/wakaama/bc$ cmake -DDTLS=1 ../examples/client/
-- The C compiler identification is GNU 4.8.4
-- The CXX compiler identification is GNU 4.8.4
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check if the system is big endian
-- Searching 16 bit integer
-- Looking for sys/types.h
-- Looking for sys/types.h - found
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of unsigned short
-- Check size of unsigned short - done
-- Using unsigned short
-- Check if the system is big endian - little endian
-- Found Git: /usr/bin/git (found version "1.9.1")
-- Configuring done
Segmentation fault (core dumped)

Two issues:

• I guess it should read RES_O_UPDATE_SUPPORTED_OBJECTS :-)
• Around line 111:

        case RES_O_UPDATE_SUPPORTED_OPJECTS:
            lwm2m_data_encode_int(data->supported, *dataArrayP + i);
            (*dataArrayP)[i].type = LWM2M_TYPE_RESOURCE;

            if (0 != (*dataArrayP)[i].length) result = COAP_205_CONTENT;
            else result = COAP_500_INTERNAL_SERVER_ERROR;

            break;

Should be lwm2m_data_encode_bool instead of lwm2m_data_encode_int according to specification OMA-SUP-XML_LWM2M_Firmware_Update-V1_0-20131210-C.txt

Regarding the advantages, look at the example here: https://github.com/google/googletest/blob/master/googletest/samples/sample1_unittest.cc.

• Compared to CUnit no boilerplate code (table of test functions, manually registering those in a main() etc) is necessary.
• Writing a new test case is as easy as adding a file new_test_suite.cpp and adding your test

TEST(TestSuiteName, TestName) {
  int a = test_important_func();
  EXPECT_EQ(1, a);
}

This of course only works seamlessly, if cmake collects all cpp files via file(GLOB) in tests/ and add it to the test binary.

• GTest is C++: A C++ compiler have to be used to compile the tests (and only the tests),
  but you can continue to write tests in C of course.

The latest wakaama client crashes with the following error, after registration with server.

*** glibc detected *** ./lwm2mclient: double free or corruption (!prev): 0x0018e640 ***
Aborted

The ipv4 fix is working but the crash is making the latest version, unusable.
Can you please fix the issue soon.

Thanks,
Rafeeq

I have found the bug in master brunch. The latest working revision of
bootstrap server is f8a8893. After
that revision it crashed with segmentation fault.

if we call prv_updateRegistration before registration was done,wakaama we crash from segfault.

see the following fix code:

static int prv_updateRegistration(lwm2m_context_t * contextP,
lwm2m_server_t * server,
bool withObjects)
{
lwm2m_transaction_t * transaction;
uint8_t payload[512];
int payload_length;

if(server->location == 0)
{
LOG("Server is Not registered yet\n");
return COAP_500_INTERNAL_SERVER_ERROR;
}

transaction = transaction_new(COAP_TYPE_CON, COAP_POST, NULL, NULL, contextP->nextMID++, 4, NULL, ENDPOINT_SERVER, (void *)server);
if (transaction == NULL) return COAP_500_INTERNAL_SERVER_ERROR;

coap_set_header_uri_path(transaction->message, server->location);

if (withObjects == true)
{
    payload_length = object_getRegisterPayload(contextP, payload, sizeof(payload));
    if (payload_length == 0)
    {
        transaction_free(transaction);
        return COAP_500_INTERNAL_SERVER_ERROR;
    }
    coap_set_payload(transaction->message, payload, payload_length);
}

transaction->callback = prv_handleRegistrationUpdateReply;
transaction->userData = (void *) server;

contextP->transactionList = (lwm2m_transaction_t *)LWM2M_LIST_ADD(contextP->transactionList, transaction);

if (transaction_send(contextP, transaction) == 0)
{
    server->status = STATE_REG_UPDATE_PENDING;
}

return COAP_NO_ERROR;

}

// update the registration of a given server
int lwm2m_update_registration(lwm2m_context_t * contextP,
uint16_t shortServerID,
bool withObjects)
{
lwm2m_server_t * targetP;
uint8_t result;

result = COAP_NO_ERROR;

targetP = contextP->serverList;
if (targetP == NULL)
{
    if (object_getServers(contextP) == -1)
    {
        return COAP_404_NOT_FOUND;
    }
}
while (targetP != NULL && result == COAP_NO_ERROR)
{
    if (shortServerID != 0)
    {
        if (targetP->shortID == shortServerID)
        {
            // found the server, trigger the update transaction

            if( targetP->status != STATE_REGISTERED)
            {
                LOG("Server is Not registered yet\n");
                return COAP_500_INTERNAL_SERVER_ERROR;
            }

            return prv_updateRegistration(contextP, targetP, withObjects);
        }
    }
    else
    {
        result = prv_updateRegistration(contextP, targetP, withObjects);
    }
    targetP = targetP->next;
}

if (shortServerID != 0
 && targetP == NULL)
{
    // no server found
    result = COAP_404_NOT_FOUND;
}

return result;

}

in lwm2mclient.c

ifdef WITH_TINYDTLS

  fprintf(stdout, "  -p HEXSTRING\tSet the device management or bootstrap server Pre-Shared-Key. If not set use none secure mode\r\n");    

endif

Should be

ifdef WITH_TINYDTLS

   fprintf(stdout, "  -s HEXSTRING\tSet the device management or bootstrap server Pre-Shared-Key. If not set use none secure mode\r\n");    

endif

When I connect to DM server, the updating registration is fail because no endpoint identifier.

Is it necessary to send endpoint identifier to server? I don't see this param is required in spec.

I guess server doesn't recognize the update command and treat it as registration command. That's why return error.

Any idea?

Thanks in advance.

Updating registration...
Sending 22 bytes to [0.0.0.0]:5683
44 02 61 ED ED 61 A0 45 B2 72 64 0A 64 66 5A 58 D.a..a.E.rd.dfZX
6C 65 72 48 45 6C lerHEl
52 bytes received from [0.0.0.0]:5683
64 80 61 ED ED 61 A0 45 C0 FF 43 6C 69 65 6E 74 d.a..a.E..Client
20 6D 75 73 74 20 73 70 65 63 69 66 79 20 61 6E must specify an
20 65 6E 64 70 6F 69 6E 74 20 69 64 65 6E 74 69 endpoint identi
66 69 65 72 fier
Parsed: ver 1, type 2, tkl 4, code 4.00, mid 25069
Content type: 0
Payload: Client must specify an endpoint identifier

=> Registration update FAILED

At the moment you have to set endinaness yourself. A least for the examples this can be automated and make the examples compile on more architectures without changes to any files.

security_get_public_id API and security_get_secret_key are not freeing dataP structure.

see my fix code:

char * security_get_public_id(lwm2m_object_t * obj, int instanceId, int * length){
int size = 1;
lwm2m_data_t * dataP = lwm2m_data_new(size);
dataP->id = 3; // public key or id

obj->readFunc(instanceId, &size, &dataP, obj);
if (dataP != NULL &&
        dataP->type == LWM2M_TYPE_OPAQUE)
{
        *length = dataP->value.asBuffer.length;
     char *buff=(char*)lwm2m_malloc(dataP->value.asBuffer.length);
        if(buff!=0)
        {
            memcpy(buff,dataP->value.asBuffer.buffer,dataP->value.asBuffer.length);
            *length = dataP->value.asBuffer.length;
        }
    lwm2m_data_free(size,dataP);
        return buff;
}else{
    return NULL;
}

}

char * security_get_secret_key(lwm2m_object_t * obj, int instanceId, int * length){
int size = 1;
lwm2m_data_t * dataP = lwm2m_data_new(size);
dataP->id = 5; // secret key

obj->readFunc(instanceId, &size, &dataP, obj);
if (dataP != NULL &&
        dataP->type == LWM2M_TYPE_OPAQUE)
{
        *length = dataP->value.asBuffer.length;
     char *buff=(char*)lwm2m_malloc(dataP->value.asBuffer.length);
        if(buff!=0)
        {
            memcpy(buff,dataP->value.asBuffer.buffer,dataP->value.asBuffer.length);
            *length = dataP->value.asBuffer.length;
        }
    lwm2m_data_free(size,dataP);
        return buff;
}else{
    return NULL;
}

}

static int
get_psk_info(struct dtls_context_t *ctx,
const session_t *session,
dtls_credentials_type_t type,
const unsigned char *id, size_t id_len,
unsigned char *result, size_t result_length) {

// find connection
dtls_connection_t* cnx = connection_find((dtls_connection_t *) ctx->app, &(session->addr.st),session->size);
if (cnx == NULL)
{
    printf("GET PSK session not found\n");
    return dtls_alert_fatal_create(DTLS_ALERT_INTERNAL_ERROR);
}

switch (type) {
    case DTLS_PSK_IDENTITY:
    {
        int idLen;
        char * id;
        id = security_get_public_id(cnx->securityObj, cnx->securityInstId, &idLen);
        if (result_length < idLen)
        {
            if(idLen) lwm2m_free(id);
             printf("cannot set psk_identity -- buffer too small\n");
            return dtls_alert_fatal_create(DTLS_ALERT_INTERNAL_ERROR);
        }

        memcpy(result, id,idLen);
         lwm2m_free(id);
        return idLen;
    }
    case DTLS_PSK_KEY:
    {
        int keyLen;
        char * key;
        key = security_get_secret_key(cnx->securityObj, cnx->securityInstId, &keyLen);

        if (result_length < keyLen)
        {
             if(idLen) lwm2m_free(key);
            printf("cannot set psk -- buffer too small\n");
            return dtls_alert_fatal_create(DTLS_ALERT_INTERNAL_ERROR);
        }

        memcpy(result, key,keyLen);
         lwm2m_free(key);
        return keyLen;
    }
    default:
        printf("unsupported request type: %d\n", type);
}

return dtls_alert_fatal_create(DTLS_ALERT_INTERNAL_ERROR);

}

Hello, the lightclient doesn't work for me. While the lwm2mclient does. I really hope you can help me because I really need to make it work.
This is what I do:

I start the wakaama server, you told to say how did I start it, in this way:
(from the wakaama directory)
cmake tests/server
make
./lwm2mserver

And about the lightclient:
(from the tests directory, since that from wakaama I've just started the server so I cannot call cmake from there)
cmake lightclient
make
./lightclient

And about the lightclient:
(from the tests directory, since that from wakaama I've just started the server so I cannot call cmake from there)
cmake lightclient
make
./lightclient

As soon as I start the client, the client tells this (and this message is repeated several times every x seconds):
State: STATE_REGISTERING
No Bootstrap Server.
LWM2M Servers:

• Server ID 123 status: REGISTRATION FAILED

At the same time the server says:
New client #0 registered.
Client #0:
name: "testlwm2mclient"
binding: "UDP"
lifetime: 300 sec
objects: /1/0, /3/0, /1024/10, /1024/11, /1024/12,

Sending 13 bytes to [::ffff:127.0.0.1]:56830
64 41 79 11 11 79 DC 7D 82 72 64 01 30 dAy..y.}.rd.0
110 bytes received from [::ffff:127.0.0.1]:56830
(then here there's the message received from the client)

I really hope you can help me. Furthermore I have another question: what are the characteristic of this lightclient compared to the lwm2mclient (that is the more complete one)?

Thank you so much

In core/liblwm2m.h the following can be found:

#ifdef WIN32
#include <time.h>
#else
#include <sys/time.h>
#endif

This makes the core effectivly not compatible to any other platform than posix/win32, because neither sys/time.h nor time.h is part of a compiler standard library. This is only used for logging isn't it? Can this be def'd out?

I was trying a non debug (cmake ../client) build of wakaama client. The debug build(cmake ../client -DCMAKE_BUILD_TYPE=Debug) of wakaama client registers successfully with device management server( leshan server). But the non debug client registration fails. Attaching logs

Build system: Ubuntu14.04 LTS, cmake 3.5.2, gcc 4.8.4, GNU Make 3.81)
I also tried the same on mac os x with same results.
Build system: OSX 10.11, cmake 3.5.2, Apple LLVM version 7.3.0, GNU Make 3.81)

Is the release build a work in progress ? Or am I doing any thing wrong with the build process ? I could add add any missing information on need.

Hi,

The size of coap_serialize_get_size() doesn't match the size of coap_serialize_message(). It will cause memory overwrite.

allocLen=51 pktBufferLen=57

`coap_status_t message_send(lwm2m_context_t * contextP,
coap_packet_t * message,
void * sessionH)
{
coap_status_t result = INTERNAL_SERVER_ERROR_5_00;
uint8_t * pktBuffer;
size_t pktBufferLen = 0;
size_t allocLen;

allocLen = coap_serialize_get_size(message);
printf("allocLen=%d\n", allocLen);
if (allocLen == 0) return COAP_500_INTERNAL_SERVER_ERROR;

pktBuffer = (uint8_t *)lwm2m_malloc(allocLen);
if (pktBuffer != NULL)
{
    pktBufferLen = coap_serialize_message(message, pktBuffer);
    printf("pktBufferLen=%d\n", pktBufferLen);
    if (0 != pktBufferLen)
    {
        result = lwm2m_buffer_send(sessionH, pktBuffer, pktBufferLen, contextP->userData);
    }
    lwm2m_free(pktBuffer);
}

return result;

}
`

Trying to bind LWM2M Client to port 56830
LWM2M Client "testlwm2mclient" started on port 56830

Opening connection to server at leshan.eclipse.org:5683
Sending 153 bytes to [5.39.83.206]:5683
44 02 71 5F 5F 71 03 0C B2 72 64 11 28 3D 05 65 D.q__q...rd.(=.e
70 3D 74 65 73 74 6C 77 6D 32 6D 63 6C 69 65 6E p=testlwm2mclien
74 03 62 3D 55 06 6C 74 3D 33 30 30 FF 3C 2F 3E t.b=U.lt=300.</>
3B 72 74 3D 22 6F 6D 61 2E 6C 77 6D 32 6D 22 3B ;rt="oma.lwm2m";
63 74 3D 31 35 34 33 2C 3C 2F 31 2F 30 3E 2C 3C ct=1543,</1/0>,<
2F 33 2F 30 3E 2C 3C 2F 35 2F 30 3E 2C 3C 2F 36 /3/0>,</5/0>,</6
2F 30 3E 2C 3C 2F 31 30 32 34 2F 31 30 3E 2C 3C /0>,</1024/10>,<
2F 31 30 32 34 2F 31 31 3E 2C 3C 2F 31 30 32 34 /1024/11>,</1024
2F 31 32 3E 2C 3C 2F 34 2F 30 3E 2C 3C 2F 37 2F /12>,</4/0>,</7/
30 3E 2C 3C 2F 32 2F 30 3E 0>,</2/0>
22 bytes received from [5.39.83.206]:5683
64 41 71 5F 5F 71 03 0C 82 72 64 0A 78 4B 52 77 dAq__q...rd.xKRw
4F 50 41 4D 59 38 OPAMY8
19 bytes received from [5.39.83.206]:5683
47 01 14 8D 5D A7 F4 AE B9 46 2C B4 31 30 32 34 G...]....F,.1024
02 31 30 .10
allocLen=51
pktBufferLen=57
Sending 57 bytes to [5.39.83.206]:5683
67 45 14 8D 5D A7 F4 AE B9 46 2C C2 06 07 FF 7B gE..]....F,....{
22 65 22 3A 5B 7B 22 6E 22 3A 22 31 22 2C 22 76 "e":[{"n":"1","v
22 3A 32 30 7D 2C 7B 22 6E 22 3A 22 33 22 2C 22 ":20},{"n":"3","
76 22 3A 2D 33 30 7D 5D 7D v":-30}]}

Hi,
some time ago I asked for this already (you remember, @dnav :D), but there was no definite answer. Is there any eclipse CI infrastructure that can be integrated into github, to execute the test suite on every commit and for every merge or can a public solution like travis-ci be used?

I think some source code may be cause a memory leak problem in the file "object_device.c".
It will free 'deviceObj' and return 'NULL' if malloc memory for 'userData' failure.
But it doesn't free 'deviceObj->instanceList' memory ....

    /*
     * Also some user data can be stored in the object with a private structure containing the needed variables 
     */
    if (NULL != deviceObj->userData)
    {
        ((device_data_t*) deviceObj->userData)->battery_level = PRV_BATTERY_LEVEL;
        ((device_data_t*) deviceObj->userData)->free_memory = PRV_MEMORY_FREE;
        ((device_data_t*) deviceObj->userData)->error = PRV_ERROR_CODE;
        ((device_data_t*) deviceObj->userData)->time = 1367491215;
        strcpy(((device_data_t*) deviceObj->userData)->time_offset, "+01:00");
    }
    else
    {
                    //@Fixme: lwm2m_free(objectP->instanceList);  objectP->instanceList = NULL;
        lwm2m_free(deviceObj);
        deviceObj = NULL;
    }

DTLS enabled, bootstrapped Wakaama client crashes if device management server is running and it doesn't contain security credentials for the endpoint name. Attaching logs

Code in sync with wakaama/master.
Compiler: Apple LLVM version 7.3.0 (clang-703.0.29)
Server: Leshan Bootstrap and device management server 0.1.11-M11

Segmentation fault in Server when Client connected.
Client and Sever were build with -DDTLS flag.

I tried bootstrapping wakaama client( DTLS disabled lwm2mclient ) with leshan bootstrap server. But it is failing. Attached logs. The commands used are below. Is the way of invoking wakaama client wrong or is bootstrapping wakaama not yet a complete feature ?

java -jar leshan-bsserver-demo-0.1.11-M9-jar-with-dependencies.jar 
java -jar leshan-server-demo-0.1.11-M9-jar-with-dependencies.jar -lp 5783 -slp 5784 -wp 8082
./lwm2mclient -4 -n Kochi -p 5683 -b

Entry corresponding to Kochi were added in Bootstrap server. If I don't use the bootstrap part, the client successfully registers with device management server( with or without PSK). Of lesser importance: I also tried building/running the wakaama bootstrap server. But it seg faults. I assume it is no more being used.

platform/Linux/platform.c: 61
Abstraction of snprintf doesn't return an integer.

int lwm2m_snprintf(char * str,
                   size_t size,
                   const char * format, ...)
{
    va_list ap;

    va_start(ap, format);

    vsnprintf(str, size, format, ap);

    va_end(ap);
}

core/json.c
Failing all checks that look like the below:

 res = lwm2m_snprintf((char *)buffer, bufferLen, JSON_ITEM_STRING_BEGIN);
        if (res <= 0 || res >= bufferLen) return -1;

TinyDTLS is now an Eclipse project. Would be nice to update the readme for the secureclient test app.
Also maybe that, rather than asking to download and unzip, the tinydtls code should just be git clone'd?

Test Object /1024 and/or resources cannot be read/write after bootstrapping.
Once the bootstrapping is done and the client tries to register to the leshan demo server, the register message does not contain instances to test object </1024>. Whereas in regular mode the wakaama client registers with instance ids also </1024/10>,</1024/11>,</1024/12> . Is this a bug in wakaama client ? Also the output of the >disp command doesn't print any instances unlike non-bootstrap mode.

Wakaama Client registered after bootstrapping

Sending 125 bytes to [10.64.98.70]:5683
44 02 34 4D 4D 34 50 7D B2 72 64 11 28 3D 05 65 D.4MM4P}.rd.(=.e
70 3D 74 65 73 74 6C 77 6D 32 6D 63 6C 69 65 6E p=testlwm2mclien
74 03 62 3D 55 05 6C 74 3D 32 30 FF 3C 2F 3E 3B t.b=U.lt=20.</>;
72 74 3D 22 6F 6D 61 2E 6C 77 6D 32 6D 22 3B 63 rt="oma.lwm2m";c
74 3D 31 35 34 33 2C 3C 2F 31 2F 30 3E 2C 3C 2F t=1543,</1/0>,</
33 2F 30 3E 2C 3C 2F 35 2F 30 3E 2C 3C 2F 36 2F 3/0>,</5/0>,</6/
30 3E 2C 3C 2F 31 30 32 34 3E 2C 3C 2F 34 2F 30 0>,</1024>,</4/0
3E 2C 3C 2F 37 2F 30 3E 2C 3C 2F 32 3E >,</7/0>,</2>

disp
/0: Security object, instances:
/0/0: instanceId: 0, uri: coap://10.64.98.70:5683, isBootstrap: true, shortId: 111, clientHoldOffTime: 1
/0/1: instanceId: 1, uri: coap://10.64.98.70:5683, isBootstrap: false, shortId: 123, clientHoldOffTime: 1
/1: Server object, instances:
/1/0: instanceId: 0, shortServerId: 123, lifetime: 20, storing: true, binding: U
/3: Device object:
time: 1367491215, time_offset: +01:00
/5: Firmware object:
state: 1, supported: false, result: 0
/6: Location object:
latitude: 27.986065, longitude: 86.922623, altitude: 8495.0000, uncertainty: 0.01, timestamp: 1460174150
/1024: Test object, instances:

Wakaama Client without bootstrapping

Sending 153 bytes to [10.64.98.70]:5683
44 02 E1 0B 0B E1 C1 7D B2 72 64 11 28 3D 05 65 D......}.rd.(=.e
70 3D 74 65 73 74 6C 77 6D 32 6D 63 6C 69 65 6E p=testlwm2mclien
74 03 62 3D 55 06 6C 74 3D 33 30 30 FF 3C 2F 3E t.b=U.lt=300.</>
3B 72 74 3D 22 6F 6D 61 2E 6C 77 6D 32 6D 22 3B ;rt="oma.lwm2m";
63 74 3D 31 35 34 33 2C 3C 2F 31 2F 30 3E 2C 3C ct=1543,</1/0>,<
2F 33 2F 30 3E 2C 3C 2F 35 2F 30 3E 2C 3C 2F 36 /3/0>,</5/0>,</6
2F 30 3E 2C 3C 2F 31 30 32 34 2F 31 30 3E 2C 3C /0>,</1024/10>,<
2F 31 30 32 34 2F 31 31 3E 2C 3C 2F 31 30 32 34 /1024/11>,</1024
2F 31 32 3E 2C 3C 2F 34 2F 30 3E 2C 3C 2F 37 2F /12>,</4/0>,</7/
30 3E 2C 3C 2F 32 2F 30 3E 0>,</2/0>

disp
/0: Security object, instances:
/0/0: instanceId: 0, uri: coap://10.64.98.70:5683, isBootstrap: false, shortId: 123, clientHoldOffTime: 10
/1: Server object, instances:
/1/0: instanceId: 0, shortServerId: 123, lifetime: 300, storing: false, binding: U
/3: Device object:
time: 1367491215, time_offset: +01:00
/5: Firmware object:
state: 1, supported: false, result: 0
/6: Location object:
latitude: 27.986065, longitude: 86.922623, altitude: 8495.0000, uncertainty: 0.01, timestamp: 1460174273
/1024: Test object, instances:
/1024/10: shortId: 10, test: 20
/1024/11: shortId: 11, test: 21
/1024/12: shortId: 12, test: 22

1. Start Leshan bootstrap server having an entry for client. Stop the device management server if running.
2. Start DTLS enabled lwm2mclient to be bootstrapped.
3. Wait for the crash.

Attaching non_ipv4_ipv6_address_crash.txt

Note: Will need pull request #178 or else client crashes early on double free.

Code in sync with wakaama/master.
Compiler: Apple LLVM version 7.3.0 (clang-703.0.29)
Server: Leshan Bootstrap server 0.1.11-M11

Wakaama client is successfully bootstrapping from Leshan bootstrap(BS) server and is able to register with Leshan device management(DM) server. Now I tried below steps

1. Start Leshan BS server with no or zero entries in GUI and DM server
2. Start Wakaama client
3. Add entry corresponding to Wakaama client endpoint in Leshan BS server user interface
4. Wakaama client, during retries, doesn't receive the newly added bootstrap credentials

I also tried with Leshan client for the same scenario. But, Leshan client is able to receive the newly added credentials( waits for 600s before doing so) from Leshan bootstrap server. Is Wakaama client expected to handle this scenario ? Attaching logs

Leshan version: 0.1.11-M10
Wakaama: current master branch. Using lwm2mclient with DTLS disabled
Compiler: Apple LLVM version 7.3.0 (clang-703.0.29)

Currently wakaama client updates registration as specified. But if any update registration fails, it doesn't try to re-register. Attaching logs

If wakaama client update registration fails, shouldn't the client try re-registering ? Is this functionality, supposed to added by wakaama library user ?

If so, where do I start on ARM mBed?
Tks

If the Bootstrap Server deletes or overwrites its own account, the status of the matching lwm2m_server_t is set to STATE_DIRTY then to STATE_BS_PENDING.
Then the server lists are not refreshed and the changes are not take into account.

The recent versions of the spec say now TLV can be used for single resources.

"The LWM2M Client MUST support the TLV data format for all
requests." (§6.3 Data Formats for Transferring Resource Information)

(There is a PR in Leshan which implements this)

object_read[1] method in objects.c will return internal server error for empty strings.

Spec appears to allow strings of size zero.

The project repository needs a contribution guide. For guidance, please see:

https://wiki.eclipse.org/Architecture_Council/Contributor_Guide_Recommendation

object_write in object.c

After lwm2m_data_parse , dataP->id seems not assign any value. So dataP->id is always 0.

Should assign "dataP->id = uriP->resourceId;"

coap_status_t object_write(lwm2m_context_t * contextP,
                           lwm2m_uri_t * uriP,
                           lwm2m_media_type_t format,
                           uint8_t * buffer,
                           size_t length)
{
    coap_status_t result = NO_ERROR;
    lwm2m_object_t * targetP;
    lwm2m_data_t * dataP = NULL;
    int size = 0;

    targetP = prv_findObject(contextP, uriP->objectId);
    if (NULL == targetP)
    {
        result = COAP_404_NOT_FOUND;
    }
    else if (NULL == targetP->writeFunc)
    {
        result = COAP_405_METHOD_NOT_ALLOWED;
    }
    else
    {
        size = lwm2m_data_parse(uriP, buffer, length, format, &dataP)

    dataP->id = uriP->resourceId;  // assign here

        if (size == 0)
        {
            result = COAP_406_NOT_ACCEPTABLE;
        }
    }
    if (result == NO_ERROR)
    {
        result = targetP->writeFunc(uriP->instanceId, size, dataP, targetP);
        lwm2m_data_free(size, dataP);
    }
    return result;
}

The lwm2mclient appears no more bootstrapping( irrespective of DTLS ). I am using Leshan bootstrap server. Feels bootstrap is broken after commit 65ab711. Let me know if logs are needed.

Code in sync with wakaama/master.