Provisioning Link Establishment

[smart_life]

Hey everyone, 

1) can you explain me please what is going on by the Link Establishment Process by the Provisioning: do we set up a connection like by the TCP and after the Link is Opened we will get an acknowledgement  for every provisioning message ?  (why do wee need the link establishment process in this point ?)

2) where can i find code for he private key derivation from the exchanged public keys on both sides  ?

[awneil]

Are you talking about Bluetooth Mesh?

Are you asking in general, or specifically about one of the Nordic Mesh SDK demos?

The Nordic Mesh SDK includes all the source code.

[smart_life]

I'm asking in general about Bluetooth Mesh which is specified in v1.0 but if there are some differences between the specification and  nordic implementation than please tell me additional about the differences also 

[awneil]

smart_life said:

I'm asking in general about Bluetooth Mesh

Remember that we can't read your mind - so you need to say that in your post!

The Bluetooth Specification defines what happens within the mesh - where BLE is used as the transport.

See the Bluetooth SIG pages for details.

See the links here for starters: https://devzone.nordicsemi.com/f/nordic-q-a/39892/ble-mesh-1-0-cellphone/154813#154813

How details about the provisioning process get communicated to things outside the Mesh is beyond the scope of the specification - so implementations will vary as required for the specific application.

eg, the Nordic light switch demo uses the Dev Kit buttons, and log messages for status output...

[smart_life]

Im not talking about the whole Provisioning Process , I just what to know the reason for the Link Establishment in the Specification v1.0 in (5.3.2) .  In Nordic Mesh provisioning Introduction it seems that you also use the Link Establishment Mechanism as the Bluetooth SIG specified it: see picture below (in the begin in blue you have Link establishment  Messages) . It is also necessary and you implement it but i don't understand the reason. Do we have a connection after link establishment messages between the provisioner and provisionee with handshake and necessary message acknowledgement or it is done for some other reasons?

[Bjørn Kvaale]

Yes, if you compare the diagram you uploaded with the diagram in Figure 5.10 in the Mesh Spec, you notice they are almost identical:

We are required to follow the spec so that our mesh stack is Bluetooth SIG certified. The SIG writes the spec & the developers follow the spec, but can decide how to best implement the spec in code.

smart_life said:

Do we have a connection after link establishment messages between the provisioner and provisionee with handshake and necessary message acknowledgement or it is done for some other reasons?

Like the spec says, the link is established to provision the unprovisioned device. If this answer is not satisfactory, I am afraid I do not fully understand the question. The link is first established between the provisioner & unprovisioned device, then the provisioning process occurs & finally the link closes.

[Bjørn Kvaale]

Regarding Q2 in your original question, see the mesh_provisionee.c file of the light switch server in mesh sdk v2.2.0:

        case NRF_MESH_PROV_EVT_STATIC_REQUEST:
            APP_ERROR_CHECK(nrf_mesh_prov_auth_data_provide(&m_prov_ctx,
                                                                 m_params.p_static_data,
                                                                 NRF_MESH_KEY_SIZE));

In the provisioner example, you can take a look at prov_provisioner.c:

        case NRF_MESH_PROV_OOB_METHOD_STATIC:
            /* Request static provisioning data from the application. */
            event.type = NRF_MESH_PROV_EVT_STATIC_REQUEST;
            event.params.static_request.p_context =  p_ctx;
            p_ctx->state = NRF_MESH_PROV_STATE_WAIT_OOB_STATIC;
            p_ctx->event_handler(&event);

& also provisioner_helper.c:

   case NRF_MESH_PROV_EVT_STATIC_REQUEST:
        {
            const uint8_t static_data[NRF_MESH_KEY_SIZE] = STATIC_AUTH_DATA;
            ERROR_CHECK(nrf_mesh_prov_auth_data_provide(p_evt->params.static_request.p_context, static_data, NRF_MESH_KEY_SIZE));
            __LOG(LOG_SRC_APP, LOG_LEVEL_INFO, "Static authentication data provided\n");
            break;