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]

Ok, I haven't been able to reproduce this using the Nordic nRF Mesh app. Are you seeing the same behavior if you use our app to "re-provision" the node?

[Andrea Pieretti]

The Nordic app sets always a new address during provisioning.

However, I think that the problem is due by the m_replay_cache list, which is an 64 element array in my case.

Le me explain you:
in transport.c, the function transport_packet_in is called when e mesh network message is received.

Inside this function i''ve noted that replay_cache_has_elem returns false, because It find other element with the same source address and that not respect the Mesh Profile Specification below

/* According to Mesh Profile Specification v1.0 Section 3.8.8, we should discard packets
 * coming IV indexes lower than a previous packet from the same source as well as
 * packets on the same IV index with lower sequence numbers. */

The node reset cause the clear of the m_replay_cache list inside the function replay_cache_clear, called by the replay_cache_init function.

I think that a call of the replay_cache_clear function after a node provision can solve my problem

Am I correct?

Are there any hidden drawbacks?

[Andrea Pieretti]

Any news?

[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?