NRF Mesh Android Library, return device key even if provisioning fails

[jm_solar]

We use the NRF Mesh Android Library (and are developing with iOS version as well). An issue that we are running into on a small number of devices is that the library things provisioning failed, but the device being provisioned thinks it succeeded. This leaves the device provisioned with a device key that we cannot access, as the library does not provide a way to access the device key unless provisioning succeeded. 

We are addressing this on the firmware side, but more generally as a solution we would like to record every device key that we attempted to provision a device with so that we can attempt recovery from the app using these keys. Otherwise these devices end up as RMAs which is very costly when all we need to do is connect to them with the device key and reset them. 

As far as we can tell, this is not currently possible with the NRF Mesh Libraries - is this correct?

Can this feature be added so that provisioning can be made more resilient?

[tesc]

Hi,

In order to ensure we are talking about the same libraries, can you please refer to the nRF Mesh library you are using by link, and preferably also version? We can then consider adding the feature. I clearly do see the benefit in case of scenarios such as the one you describe.

Regarding the devices you are provisioning, do they have any reset mechanism that can be triggered without connecting to them from a configuration device with the correct device key? Such as e.g. long press a button on the device, or some other action requiring physical access to it? Based on your inquiry I assume they do not. I therefore also assume you are properly taking backup of the network configuration database for recovering the devices in case the configuration device should get lost or damaged.

In general, a requirement of knowing the device key for factory resetting the device may be risky in terms of device bricking. Please be vigilant, as given your inquiry I am sure you are, in mitigating this risk. Having a separate reset mechanism may of course also have security implications, and so may not always be feasible.

Regards,
Terje