Mesh node self provisioning

RE: Mesh node self provisioning

Pm7 — Fri, 10 Dec 2021 14:37:12 GMT

      dsm_local_unicast_address_t local_address = {1, ACCESS_ELEMENT_COUNT};
      dsm_handle_t net_handle,dev_handle,app_handle,vendor_handle,handle;

      ERROR_CHECK(dsm_local_unicast_addresses_set(&local_address));
      ERROR_CHECK(dsm_subnet_add(0, KEY.privacy_key, &net_handle));
      ERROR_CHECK(dsm_devkey_add(local_address.address_start, net_handle, KEY.privacy_key, &dev_handle));
      KEY.privacy_key[15]=0xA0;
      ERROR_CHECK(dsm_appkey_add(0, net_handle ,KEY.privacy_key, &app_handle));

      ERROR_CHECK(config_server_bind(dev_handle));
      IsValid = vendor_handle_get(&vendor_handle);
      if(IsValid==0)  while(1); //stay locked
      ERROR_CHECK(access_model_application_bind(vendor_handle, app_handle));

      // Add the address to the DSM as a subscription address:
      i = dsm_address_subscription_add(GROUP_SUB_ADDR, &handle);
      // Add the subscription to the model:
      i = access_model_subscription_add(vendor_handle, handle);

      mesh_stack_device_reset();  //power cycle after self provisioning
    }

Here is my version that works with vendor model

RE: Mesh node self provisioning

Hung Bui — Tue, 24 Sep 2019 14:52:24 GMT

Hi Nishant,

The device key is generated using prov_utils_derive_keys(). My understanding is that it's calculated on both side the provisioner and provisionee (should have the same result) using that function. So that key is not exchanged between them.

RE: Mesh node self provisioning

nish — Mon, 23 Sep 2019 13:22:02 GMT

Hi Hung, I am trying to do a similar thing as this post, but I need to ask, where does teh device key come from?

RE: Mesh node self provisioning

Hung Bui — Mon, 18 Mar 2019 16:25:21 GMT

Hi Patrik,

This code worked for me. There is no model configured but I can see I can receive the message to address 0xC001 on access layer. This is a very minimum code, you would need to add device key, bind the appkey to model etc.

uint32_t my_mesh_stack_provisioning_data_store()
{
    dsm_handle_t netkey_handle, devkey_handle;
    dsm_local_unicast_address_t local_address;
    uint8_t netkey[16]={0x79,0xF5,0xF1,0x6A,0x43,0x22,0x17,0xDF,0x1D,0xC1,0x59,0x10,0x13,0x0A,0x31,0x6F};
    uint8_t appkey[16]={0x5B,0xD8,0xDE,0xB4,0x49,0xAB,0x15,0x1B,0x72,0x7F,0xD4,0x56,0xF5,0x49,0x81,0x9B};
    local_address.address_start = 0x99;
    local_address.count = ACCESS_ELEMENT_COUNT;
    uint32_t status;
    dsm_handle_t app_handle;
    /* Store received provisioning data in the DSM */
    status = dsm_local_unicast_addresses_set(&local_address);
    if (status != NRF_SUCCESS)
    {
        return status;
    }
    status = dsm_subnet_add(0, netkey, &netkey_handle);
    if (status != NRF_SUCCESS)
    {
        return status;
    }
    NRF_MESH_ERROR_CHECK(net_state_iv_index_set(0,0));

    dsm_handle_t network_handle = dsm_net_key_index_to_subnet_handle(0);
    status = dsm_appkey_add(0, network_handle, appkey, &app_handle);
    dsm_handle_t subscription_address_handle;
    status = dsm_address_subscription_add(0xC001, &subscription_address_handle);
    return status;
}

Note that to print out the "RX:" log in access.c you need to enable logging at level DBG1.

(Posted this just to find out that you figured it out 20 minutes earlier :) . Good news Patrik. )

RE: Mesh node self provisioning

Patrik — Mon, 18 Mar 2019 16:07:10 GMT

But there also must be some function, which calculates all those values from the netkey. Dont know so far.

RE: Mesh node self provisioning

Patrik — Mon, 18 Mar 2019 16:02:11 GMT

Resolved !!!

It was pain to debug. It was also necessary to set the identical encryption key, privacy key, network id - all members of the structure nrf_mesh_network_secmat_t. Not to acces this structure directly, using device manager function dsm_net_secmat_from_keyindex_get()

RE: Mesh node self provisioning

Hung Bui — Fri, 15 Mar 2019 15:37:04 GMT

Hi Patrik,

I will try to do some tests here. But be aware that appkeys are used in the transport layer to decrypt message before the access layer. You can find in the access.c all messages are already decrypted.

Also, hardcoded provisioning is not suggested and is not fully following the spec.

RE: Mesh node self provisioning

Patrik — Fri, 15 Mar 2019 14:01:26 GMT

checked the iv index, network key, netkey index, iv update, key refresh, subscription and publish address. the same by provisioning the node by external provisioner (nrf mesh app) and by self provisioning. still not working. controlling if receiving messages at the other side at the access layer. can it be problem with some other encryption key? any other idea?

RE: Mesh node self provisioning

Hung Bui — Tue, 12 Mar 2019 12:30:27 GMT

Not Netkey but IV Index you need to set net_state_iv_index_set()

Could you try adding a breakpoint in mesh_stack_provisioning_data_store() when you provisioning your client (using a provisioner) to see if there is any difference in the provisioning data compare to what you do on your code ?

RE: Mesh node self provisioning

Patrik — Tue, 12 Mar 2019 10:34:43 GMT

netkey set to zero, but the result is the same

RE: Mesh node self provisioning

Patrik — Tue, 12 Mar 2019 10:28:23 GMT

Ouu, yes all the keys are arrays. It is wrong above in the code snippet, but in my code it is ok. I made the mistake by editing to devzone. Double checked the rest of the code above and it is identical with my code.

RE: Mesh node self provisioning

Hung Bui — Tue, 12 Mar 2019 08:55:15 GMT

Hi Patrik,

We spotted that you used the wrong key defines. They should be uint8_t[16] an array, not just an uint8_t.

In addition the IV Index need to be set as well (you can try to set it to 0 ).

We have this function here that apply provisioning data after received from provisioner that you may want to have a look.

RE: Mesh node self provisioning

Patrik — Mon, 11 Mar 2019 00:58:17 GMT

Thank you for the reply, Hung. I printed the TX and RX info in both of the functions mesh_msg_handle() and packet_tx(). I found out, that the self provisioned client is sending the message on the air. To confirm I am really sending messages on the air, in the access.c in mesh_evt_cb() I added printing functions:

static void mesh_evt_cb(const nrf_mesh_evt_t * p_evt)
{
    switch (p_evt->type)
    {
        case NRF_MESH_EVT_MESSAGE_RECEIVED:
            SEGGER_RTT_printf(0, "%s(): Received message from address 0x%04x\n", __func__, p_evt->params.message.src.value);
            mesh_msg_handle(&p_evt->params.message);
            break;
         case NRF_MESH_EVT_TX_COMPLETE:
            SEGGER_RTT_printf(0, "%s(): Message has been sent on the air with token number %u\n", __func__, p_evt->params.tx_complete.token);
            break;
        default:
            /* Ignore */
            break;
    }

}

On the self provisioned client side: checked the NRF_MESH_EVT_TX_COMPLETE event, because this event happens when the packet is sent on the air. I could also watch in packet_tx() sending to destination address, the source address and the whole message:

static uint32_t packet_tx(access_model_handle_t handle,
                          const access_message_tx_t * p_tx_message,
                          const access_message_rx_t * p_rx_message,
                          const uint8_t *p_access_payload,
                          uint16_t access_payload_len)
{
    ....
    ....
    ....
    status = nrf_mesh_packet_send(&tx_params, NULL);
    if (status == NRF_SUCCESS)
    {
        __LOG(LOG_SRC_ACCESS, LOG_LEVEL_DBG1, "TX: [aop: 0x%04x] \n", p_tx_message->opcode.opcode);
        __LOG_XB(LOG_SRC_ACCESS, LOG_LEVEL_DBG1, "TX: Msg", p_tx_message->p_buffer, p_tx_message->length);
        
        SEGGER_RTT_printf(0, "TX: Sending message to address 0x%04x\n", tx_params.dst.value);
        SEGGER_RTT_printf(0, "TX: The source address of message: 0x%04x\n", tx_params.src);
    }
}

On the server side, which I provisioned and configured by nrf mesh app: checked NRF_MESH_EVT_MESSAGE_RECEIVED event, which is triggered when incomming message.

In my case the event NRF_MESH_EVT_TX_COMPLETE occurs every time on the client side, but the event NRF_MESH_EVT_MESSAGE_RECEIVED is not occuring on the server side. I am working with group address, publication group address on the client side and subscription address on the server side set the same, checked many times and confirmed, that on both side set the same netkey, appkey, iv index. Not sure if necessary, but in my case on both sides set the same appkey index and netkey index.

To simulate my case, please try the light switch client example from mesh v1.0.1 on one board and the light switch server example from mesh version 3.1.0 on the second board. The server example I provisioned with nrf mesh app. In the client example I commented the following lines (to prevent provisioning of external nodes):

static void button_event_handler(uint32_t button_number)
{
    __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Button %u pressed\n", button_number);
//    if (m_configured_devices == 0)
//    {
//        __LOG(LOG_SRC_APP, LOG_LEVEL_WARN, "No devices provisioned\n");
//        return;
//    }
//    else if (m_configured_devices <= button_number && button_number != BUTTON_NUMBER_GROUP)
//    {
//        __LOG(LOG_SRC_APP, LOG_LEVEL_WARN, "Device %u not provisioned yet.\n", button_number);
//        return;
//    }

    uint32_t status = NRF_SUCCESS;
    switch (button_number)
    {
        case 0:
        case 1:
        case 2:
            /* Invert LED. */
            status = simple_on_off_client_set(&m_clients[button_number],
                                              !hal_led_pin_get(BSP_LED_0 + button_number));
            break;
        case 3:
            /* Group message: invert all LEDs. */
            status = simple_on_off_client_set_unreliable(&m_clients[GROUP_CLIENT_INDEX],
                                                         !hal_led_pin_get(BSP_LED_0 + button_number), 3);
            break;
        default:
            break;
    }
    
    ....
    ....
    ....
}

static void access_setup(void)
{
    ....
    ....
    ....
    
//    provisioner_init();
//    if (m_configured_devices < m_provisioned_devices)
//    {
//        provisioner_configure(UNPROV_START_ADDRESS + m_configured_devices);
//    }
//    else if (m_provisioned_devices < SERVER_COUNT)
//    {
//        provisioner_wait_for_unprov(UNPROV_START_ADDRESS + m_provisioned_devices);
//    }

}

I know that the server example contains the generic on off client model and the server example contains the simple on off server model, two different models, but up to the access layer the message should be processed even if not the same appkeys but the publication group address on the client side and subscription address on the server side set the same, network key set the same on both sides, iv index the same on both sides, not sure for appkey index and network index but in my case set the same on both sides. -- > in this case NRF_MESH_EVT_MESSAGE_RECEIVED event should occur on the server side when sending messages from client node. I tried it, but this event is not triggered. Dont know why ... Please, try to simulate that case :)

RE: Mesh node self provisioning

Hung Bui — Thu, 07 Mar 2019 15:27:43 GMT

Hi Patrik,

A good source of reference is to have a look at our Mesh SDK v1.0.1's light switch example. In that example we have the provisioner and the client combined. And we actually have hardcoded provisioning in that example.

It looks pretty good in your code, I don't think there is any thing missing. I would suggest to debug on access layer , if you look at the code you can find where we printout "TX:" and "RX:" in access.c (Inside mesh_msg_handle() and packet_tx().

Could you try to printout the message data and meta data on the client when you press the button (check TX) and on the server when there is any message arrives (check RX)

I would also suggest to double check the netkey and app key received on the server after you provision the node using the phone, just to double check if they are identical to what you have on the client.