Remote provisioning link open timeout not triggering

[rmarques]

Hello, I am using SDK 16.0 and mesh SDK 4.2.

We successfully implemented remote provisioning capabilities in our devices' firmware. One thing we are noticing though is that the remote provisioner does not timeout after some time if no PDU is received during the provisioning process as the local provisioner does.

Inspecting the code that initializes the local and remote bearers, I noticed suspicious differences that may be the cause of the process not timing out, namely in the initialization routine we have:

ERROR_CHECK(nrf_mesh_prov_bearer_add(&m_prov_ctx, nrf_mesh_prov_bearer_adv_interface_get(&m_prov_bearer_adv)));
ERROR_CHECK(nrf_mesh_prov_bearer_add(&m_prov_ctx, pb_remote_client_bearer_interface_get(&m_remote_client)));

Inspecting the content of nrf_mesh_prov_bearer_adv_interface_get and pb_remote_client_bearer_interface_get, we see that the callbacks of the interface .link_open are prov_bearer_adv_link_open for the local provisioner and pb_if_link_open_cb for the remote one.

While prov_bearer_adv_link_open has a mention for link_timeout_us inside the callback, where the structure of the bearer is initialized with init_bearer_structure, pb_if_link_open_cb still receives the same link_timeout_us as an argument, but makes no use of it inside the callback, leaving me to believe that the timeout feature is not implemented in the SDK.

So, in prov_provisioner.c, when uint32_t status = p_bearer->p_interface->link_open(p_bearer, p_uuid, NRF_MESH_PROV_LINK_TIMEOUT_MIN_US); is called, the NRF_MESH_PROV_LINK_TIMEOUT_MIN_US is correctly used in the local provisioner but not on the remote one.

Can you please confirm if this is a bug on the SDK side? Did I misunderstand something? Thank you.

[rmarques]

So, this is my idea:

Inside pb_if_link_open_cb I start a timer that triggers a callback that tries to close the link after NRF_MESH_PROV_LINK_TIMEOUT_MIN_US microseconds. This timer is restarted every time a PDU is processed in pb_remote_client_process and is stopped somewhere when the provisioning is complete, probably in prov_evt_handler in my provisioner_helper.c file, on the NRF_MESH_PROV_EVT_LINK_CLOSED case. Am I on the right track?

[Mttrinh]

Hi,

The timeout passed link_open callback is the timeout of the provisioning link, which is the link between the provisioner and an unprovisioned device. In case of PB Remote, this is the link between PB Remote Server and an unprovisioned device. The link between PB Remote Client and PB Remote Server doesn't use this timeout, but instead relies on the PB Remote protocol. This is because PB Remote Client doesn't really know when PB Remote Server established the provisioning link and thus can't manage the timeout correctly. PB Remote Client and Server use reliable messages to exchange the data, so that if the message has not been received by one of the side, it will terminate the remote provisioning process. Since PB-ADV on the PB Remote Server side still uses the timeout, it will call pb_adv_link_closed_cb if link has been timed out (https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/mesh/prov/src/prov_bearer_adv.c#L290). This will go to pb_remote_server_event_link_closed_cb (https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh/blob/master/models/proprietary/pb_remote/src/pb_remote_server.c#L686), which in turns will send a message to PB Remote Client.

Can you check that what I described actually happens on your side and what is PB Remote Server and Client states? If you could provide logs with LOG_SRC_ACCESS | LOG_SRC_BEARER and LOG_LEVEL_DBG3, this might also be helpful.

[rmarques]

Thank you for the useful information as always Mttrinh, we will activate those logs and check what may be happening.

In the meantime, what do you think will happen if the server times out, triggers the link close callback but the reliable message never reaches the remote provisioner client?

I suspect this might be happening in our case. Will the client be eternally waiting for the server to say something?

[Mttrinh]

Hi,

This seems to be true. I see that PB Remote Client messages are acked after they are forwarded by PB Remote Server to PB-ADV, but the reply on those messages comes independently of the reply on the PB Remote Client message. This looks like an omission from the PB Remote protocol side.

So, it might actually be a right thing to run timer in pb_if_link_open_cb in pb_remote_client.c setting the timeout to some reasonable time which is 2-3 times bigger than the provisioning link timeout.

[rmarques]

Thank you for the advice Mttrinh, we will do this.