Friend node timeout when LPN is re-provisioned with same address

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Fri, 29 May 2020 12:13:24 GMT

Ok, I see.

Any tips or sample code on how to clear the replay cache would be much appreciated.

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Fri, 29 May 2020 05:48:58 GMT

There is no API call to do that. You will have to clear the replay cache manually.

Br,
Joakim

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Tue, 12 May 2020 14:47:24 GMT

Thank you for the info.

Is there a call to tell nodes that they should clear the replay list for a specific address (which has just been re-provisioned with the same address)?

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Wed, 06 May 2020 23:56:43 GMT

Hi.

I currently don't have any news about this.
If you are having issues with this I would suggest to be sure to provision new devices using new addresses.
If you need to use the same address you could manually clear the replay list, although it is not recommended due to security reasons.

I will update the ticket if there is any new information.

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Thu, 30 Apr 2020 13:48:01 GMT

Hello, any new information on this?

Would be great to be able to resolve this issue, it shows up quite a bit when deploying mesh networks in the field.

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Tue, 03 Mar 2020 12:56:29 GMT

Thanks.

I'll forward this to our Mesh developers, so that they can comment on this. Will update the ticket when I get any feedback from them.

Br,
Joakim

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Tue, 03 Mar 2020 09:46:06 GMT

Thank you, response much appreciated.

I fear this problem is deeper than just "don't use the nRF Mesh App for production" (we are not, but reporting issues with another app in the past I have been asked to reproduce with you nRF Mesh App).

As you have pointed out, once the mesh stack starts saving the replay list to flash, there will be NO way to re-provision a device with the same address and have it work reliably.

The problem goes deeper: there seems to be no key in the underlying JSON format to track previously-used addresses.

My understanding is that this JSON format follows a standard schema published by Buetooth SIG, yes?

So, again, the question arises, we should be able to do something to preempt this replay list issue, should it be:

1. Provisioner sets the correct sequence number on LPN when provisioning?

2. Replay list is reset at provisioning-time somehow?

3. JSON schema is extended to track all past addresses?

4. Any other ideas?

We are looking for a hint about the proper approach to tackle this from our end.

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Mon, 02 Mar 2020 09:20:50 GMT

We do appreciate the feedback. and I'll forward this internally so that it can be considered for any future releases.

I would like to note that a power cycle of the device shouldn't clear the replay list. For optimal security with regards to the replay protection, this should be saved to flash. I do believe this is going to be changed in a future release of the nRF5 SDK for Mesh.

Also, the nRF Mesh app isn't actually supposed to be a used in a finalized product, but more as a development tool and a template for developing your own application. As a development tool, it might be good to have the option to provision a device with the same address. That way you can test that the replay protection actually works for your product.

Best regards,
Joakim

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Wed, 26 Feb 2020 13:15:37 GMT

I see what you are saying, but the net effect is:

1. Device is removed and reprovisioned with nRF Mesh App

2. Device can no longer talk to network

I see how what the mesh stack is doing follows the specification, but the objective behavior for users is broken.

Simply removing ONE device and adding a NEW, DIFFERENT device (which is given the same address by the nRF Mesh App) will trigger this bug - it is very easy to trigger in usual operations and results in "broken" behavior where the newly provisioned device cannot talk to the mesh.

Perhaps the nRF Mesh App might:
1. Set the correct sequence number on LPN when provisioning?

2. Track all past addresses and only provision never-before-used addresses?

3. Any other ideas?

Thank you

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Wed, 26 Feb 2020 10:08:29 GMT

This can't actually be classified as a bug, as this is the expected behavior of the replay protection. If a device with the same address starts sending messages with a lower sequence number than expected, the replay protection should filter these messages. This does not only affect the LPN.

You can manually clear the replay list on the LSS. Note that this is not recommended as this will cause a security issue since a device will then allow all incoming messages – enabling an attacker to replay old messages.

If you need to re-provision a device, I recommend that you provision it with a new address. This will allow your device to initiate the friendship.

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Tue, 25 Feb 2020 14:00:03 GMT

I see, thank you for looking into this.

So, how do we commission a device and have it be able to communicate from the start?

Should we:

- query LSS for the sequence number and then set this on the LPN when provisioning?

- send a message to LSS to reset the sequence number?

- some other mechanism?

This is quite a noticeable bug when an LPN in a large network is re-provisioned, suddenly it "doesn't work" and the only solution currently is to turn off breakers and reset devices in the ceiling.

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Wed, 19 Feb 2020 12:08:44 GMT

Hi again.

This is actually expected behavior.
When you are testing the LPN / Light switch server (LSS) examples:
If the LPN is reset / unprovisioned from the app the sequence number on the LPN node will reset to zeros. Therefore, when the LPN is re-provisioned with the same address, all the messages sent by the LPN will get filtered by the replay protection mechanism of the LSS. This will continue to happen until the LPN starts sending messages with a higher sequence number than the one stored in the LSS replay list.

The reason that you are able to re-establish the friendship with the LSS when it's power cycled / reset is that the replay list will be blank upon power cycle.

Best regards,
Joakim Jakobsen

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Wed, 19 Feb 2020 10:07:15 GMT

Hi.

Sorry about the delay.

Yes, I'm seeing the same behavior as you do. Investigating what is causing this.

Will get back to you with more information.

Regards,
Joakim

RE: Friend node timeout when LPN is re-provisioned with same address

sirio — Fri, 14 Feb 2020 13:25:27 GMT

Thank you.

Were you able to reproduce? Any update?

Help much appreciated.

RE: Friend node timeout when LPN is re-provisioned with same address

Joakim Jakobsen — Mon, 27 Jan 2020 11:17:30 GMT

Hi.

Thank you for the report. I'll try to reproduce this from the steps you described and investigate the issue.

Could you also tell me which version of the nRF5 SDK for Mesh you are working with?

I'll get back to you with more information.

Best regards,
Joakim

EDIT:
Just noticed that you listed the version at the bottom of your question.