Topics

Concern about #BluetoothMesh Sequence number #bluetoothmesh


Vikrant More <vikrant8051@...>
 

Hello to all,

SoC like nRF52840 supports only 10k write cycles.

Is that means, saving sequence no. as soon as NODE receives message, on flash could corrupt it after 500 days if it receives 20 messages per day from same source address ?

----------------------------------------------------------------------------

Suppose scenario, in which Node 'A' with Server Model switched OFF which is part of Group 'Hall', and Node with Client Model is still active and sending messages to other Nodes of Group 'Hall'. 

Meanwhile attacker, captured the frames.

So he could use those messages to trigger Node 'A' after it switched ON. Am I right ? 

----------------------------------------------------------------------------

Is there any other variable similar to sequence no. which updates continuously & that we have to save on SoC flash ?

Thank You !!


Johan Hedberg
 

Hi Vikrant,

On Fri, Feb 16, 2018, Vikrant More wrote:
SoC like nRF52840 supports only 10k write cycles.

Is that means, saving sequence no. as soon as NODE receives message,
Do you mean "sends" and not "receives"? The local sequence number is
updated whenever you send a message. It's the RPL that's updated when
you receive a message. Or are you talking about the RPL?

on flash could corrupt it after 500 days if it receives 20 messages
per day from same source address ?
That only holds true if you don't do any wear leveling. And even with
wear leveling it would be a quite suboptimal implementation of sequence
number persitency. A more optimal solution is to update the sequence
number in flash e.g. only for every 100th message, and then add 100 to
the stored value when you boot up. More advanced products might not
store the sequence number actively in flash at all, but instead have a
"backup" capacitor that has enough energy to write the current sequence
number to flash when the main power is lost.

If you were referring to the RPL rather than the local sequence number,
then similar approaches could be used for that as well.

Johan


Vikrant More <vikrant8051@...>
 

Hi Johan, 

Thanks for clarification & providing other additional important details.

I think, Local sequence no. (for sender) & RPL (for receiver ) both are same for flash in terms of write cycle. Ultimately this gonna headache in #BluetoothMesh implementation. :)

Regards,
vikrant8051


On Feb 16, 2018 11:13 PM, "Johan Hedberg" <johan.hedberg@...> wrote:
Hi Vikrant,

On Fri, Feb 16, 2018, Vikrant More wrote:
> SoC like nRF52840 supports only 10k write cycles.
>
> Is that means, saving sequence no. as soon as NODE receives message,

Do you mean "sends" and not "receives"? The local sequence number is
updated whenever you send a message. It's the RPL that's updated when
you receive a message. Or are you talking about the RPL?

> on flash could corrupt it after 500 days if it receives 20 messages
> per day from same source address ?

That only holds true if you don't do any wear leveling. And even with
wear leveling it would be a quite suboptimal implementation of sequence
number persitency. A more optimal solution is to update the sequence
number in flash e.g. only for every 100th message, and then add 100 to
the stored value when you boot up. More advanced products might not
store the sequence number actively in flash at all, but instead have a
"backup" capacitor that has enough energy to write the current sequence
number to flash when the main power is lost.

If you were referring to the RPL rather than the local sequence number,
then similar approaches could be used for that as well.

Johan