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