RPL is full

RE: RPL is full

Elfving — Thu, 30 Mar 2023 13:24:36 GMT

[quote user="Mustafaq"]Is there any relation between increasing CONFIG_BT_MESH_CRPL and the number of LPN devices?[/quote]

I do not believe so. What makes you say that?

[quote user="Mustafaq"]Do I need to increase CONFIG_BT_MESH_CRPL every time I attach a new node to the network?[/quote]

It depends on if this node needs to communicate with all of the others. You can think of this config as the maximum amount of nodes in the network, given that they all communicate with each other. This is often not the case, but it depends on your network. So if you give it a high number now that you think would fit your network well, then you'll never have to bother editing it again. The max is 65535.

Regards,

Elfving

RE: RPL is full

Mustafa — Thu, 30 Mar 2023 12:45:34 GMT

Hey Elving,

After increasing the CONFIG_BT_MESH_CRPL to 100, I cannot reproduce the issue with full replay. (at least until now).

Is there any relation between increasing CONFIG_BT_MESH_CRPL and the number of LPN devices? Do I need to increase CONFIG_BT_MESH_CRPL every time I attach a new node to the network?

Best regards!

RE: RPL is full

Elfving — Thu, 30 Mar 2023 12:00:16 GMT

Ah I see. So this could potentially lead to another related issue, but I am not sure as to how it could lead to the replay list being full in the light switch.

So when you recover and reprovision one of the light nodes with the same address as before, it wouldn't be able to send anything to the rest of the network. That is because of the replay protection list of the other nodes which keeps track of the number of the last previously sent message, of the node in question. If the other nodes know that the last message it sent was #50, and then it sends #1, the other nodes will discard this message. They will in fact discard all other messages of the newly provisioned node until it sends #51. That is why you should reprovision the node with a new address.

This still seems to be a completely separate problem from the full replay list though.. at least I am not seeing the connection yet. try increasing CONFIG_BT_MESH_CRPL.

Regards,

Elfving

RE: RPL is full

Mustafa — Tue, 28 Mar 2023 11:37:03 GMT

Hey Elfving,

Many thanks again for your advice. Currently, this issue occurs mainly when I reset a light node and after that, I reprovision the same light node with the same address which was used before the reprovisioning. then this issue appears.

I will check CONFIG_BT_MESH_CRPL as u suggested.

Best regards,

RE: RPL is full

Elfving — Tue, 28 Mar 2023 11:04:03 GMT

Hello,

What I meant was that this is not an issue you should expect to see, in a normal network, though even if you do it is fixable. I am not saying that recovering is the go-to way to fix this error if it occurs in the future. Recovering was just a suggestion to see what it would take for the issue to go away.

You could for instance see this issue if have a network where all nodes in the network are communicating, and need to keep each others sequence numbers, as opposed to just the ones close-by. If that was the case, this issue could be fixed by increasing CONFIG_BT_MESH_CRPL - Maximum capacity of the replay protection list.

[quote user="Mustafaq"]

the problem is that when the switch device got this attach. then it stuck there and ignores all other devices and stops receiving all publishing messages till reset the whole node and re-provisione it.

[/quote]

I see. I thought this was occurring with just 1 light and 1 switch. But if you have a network of multiple devices it might be that you should increase CONFIG_BT_MESH_CRPL. Try that.

Regards,

Elfving

RE: RPL is full

Mustafa — Mon, 27 Mar 2023 12:04:25 GMT

Hello Elving,

My weekend went well and hope the same for you thanks!

Actually my second question I believe was not clear. what I meant is if this issue occurs. can we (somehow) make some changes to the code to be able to ignore this error without the need to apply the recover process on the device?

Best regards,

RE: RPL is full

Elfving — Mon, 27 Mar 2023 07:29:22 GMT

Hello, and hope you've had a good weekend!

[quote user="Mustafaq"]My application is based on a Light sample (so there is a custom modification). [/quote]

I see. That is fine, but it would be interesting to see if this is occurring for you on the default sample as well. Just to make sure that we need to have a look at the modifications.

[quote user="Mustafaq"]In case the light server publishes messages periodically to the switch device (client light). is it possible to recover the switch device (client device) without needing to reset or recover this device?[/quote]

Yeah you could recover one without recovering the other.

I just wanted to test if this happened if they were just recovered, but I guess you could also try only recovering the one showing the error, and see how soon it happened again after recovering and re-provisioning it.

Regards,

Elfving

RE: RPL is full

Mustafa — Fri, 24 Mar 2023 15:17:42 GMT

Hello,

My application is based on a Light sample (so there is a custom modification).

the application is based on the Light server sending periodic messages to the light client device.

the light server uses NRF52840

I didn't test a recover command yet. I will test it and come back to you.

In case the light server publishes messages periodically to the switch device (client light). is it possible to recover the switch device (client device) without needing to reset or recover this device?

Thanks in advance!

RE: RPL is full

Elfving — Fri, 24 Mar 2023 14:15:34 GMT

Hello,

Has it been sending messages for long? You're saying that this a completely unmodified sample? And the light sample does not get this issue? What device are you using on the other side?

Are you also seeing it when recovering the two devices before flashing them (using "nrfjprog --recover") just to make sure there is nothing left of a previous settings partition?

What it means is that the Mesh Replay List of every sequence number from every node is exhausted. The nodes in Mesh has this to guard against replay attacks. For a better understanding of this, see section 3.8.8 in Mesh Profile Spec.

Regards,

Elfving