Unable to receive publish from server after unprovision and re-provision the same node

[Andrea Pieretti]

Hello,

I've developed a BLE Mesh Network using the NRF MESH 3.1.0 SDK and the nR5F SDK 15.2.0.

My network has 1 client node and max 63 server nodes: I'm using the generic on-off model to implement a light switch.

I've found this strange behaviour:

If I "un-provision" a server node and then provision the same node with the same address, sometimes the client doesn't receive the server's publish. I think that it's a client issue, because i'm pretty sure that the server is publishing correctly and I'm able to turn on-off the light.

In some cases the client start to receive the server's publish after some minutes, in other cases I need to reboot the client node.

Can someone explain this behaviour? Is it due to the re-assign of the same address to the same node?

[Joakim Jakobsen]

Hi. 

I haven't seen this issue before. I wasn't able to reproduce it either. 

How are you provisioning the devices? Are you using the nRF Mesh app or the static provisioning example in the SDK?

I can ask our Mesh team if they have seen something similar and if this is a known issue. 

Best regards, 
Joakim Jakobsen

[Andrea Pieretti]

I'm provisioning the devices using the smartphone with our app, which is based on Nordic Libraries.

I see that this behaviour happens especially when I re-provision a node with the same address.

[Joakim Jakobsen]

Hi. 

Sorry about the delay here. 

Your question have been forwarded to our Mesh developers so that they can confirm this. 
I'll get back to you when I have more information from them. 

Best regards, 
Joakim

[Andrea Pieretti]

Ok,

please let me know when you've some news

[Joakim Jakobsen]

Got some feedback on this. 

After you unprovision the server node, and reprovision it, this will cause sequence number on the server nodes to reset to zeros. Therefore all the messages sent by the server nodes will get filtered by the replay protection mechanism of the client node. This will continue to happen until the server node starts sending messages with a higher sequence number than the one stored in the client's replay list.

Secondly, your suggestion of clearing of the replay list of the client after re-provisioning the server node is not valid. Because for a node which is provisioned, replay list should not be cleared manually.

Best regards

[Andrea Pieretti]

Thank you for the feedback.

I understand what happens, but waiting the correct sequence number from the server will cause the loss of many messagges.

If I can't clear the replay list, how can I fix this?

 

[Joakim Jakobsen]

Hi again! 

I might have misunderstood the feedback from our Mesh team. 

Joakim Jakobsen said:

Secondly, your suggestion of clearing of the replay list of the client after re-provisioning the server node is not valid. Because for a node which is provisioned, replay list should not be cleared manually.

 This was not quite correct from my side. 

If your application is able to tolerate the risk of clearing the replay cache, you can clear the replay list manually. Note that this will have implications for the replay protection.

Best regards, 
Joakim

[Andrea Pieretti]

Ok, Thank you for the feedback.

In my case, I will take the risk ;)

[Joakim Jakobsen]

No problem. 
Sorry about the confusion! 

I'll close the case for now. If you have any further questions, you are welcome to create a new ticket. 

Best regards, 
Joakim