The initial implementation of RPL check for Subnet Bridge wasn't fully
correct. It decides whether to relay or not a PDU based on RPL of only
received messages. However, the spec section 3.9.8 says:
```
In addition, a Subnet Bridge node shall implement replay protection for
all Access and Transport Control messages that are sent to bridged
subnets.
A Subnet Bridge node shall maintain the most recent IVISeq value for
each source address authorized to send messages to bridged subnets.
Messages received by the Subnet Bridge node with the IVISeq value less
than or equal to the last stored value from that source address shall
be discarded immediately upon reception. When a message is retransmitted
to a bridged subnet, the stored IVISeq value shall be updated. In this
way, bridged subnets are protected against replay attacks from other
subnets.
```
This was noticed with MESH/NODE/SBR/NET/BV-02-C test. It passes when
PTS misses the message at step 3 and 4, and fails when PTS manages to
receive the message.
This commit fixes the wrong behavior by removing argument for
`bt_mesh_rpl_check` function making store a new message and bypassing
`local_match` check in case of Subnet Bridge node.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
Align the capitalization of the term "Bluetooth Mesh" to Bluetooth mesh"
in the documentation. This is done to to match the new updated naming
convention done in Bluetooth SIG. In the upcoming spec versions, it its
used "Bluetooth mesh" with the lower case convention.
Signed-off-by: Ingar Kulbrandstad <ingar.kulbrandstad@nordicsemi.no>
The current approach with storing RPL by timeout doesn't solve all
issues as the node may loss power before the timer is fired.
In addition to that this may wear out flash quickly if short timeout is
used.
This change adds an API to store the pending RPL entry upon user
request. Additional Kconfig option allows to completely disable timer
so that the whole storing relies on the user.
The mesh stack still stays responsible for outdating RPL entries in case
of IV Index update as this happens implicitly for the user.
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
To prevent the transport layer from accepting duplicate or out of order
segmented messages, add an RPL-like check for the SeqAuth of the
segmented messages when their context is allocated. This prevents
duplicate receives of the same segmented messages in the case where a
single source address sends two segmented messages in parallel (to two
different addresses):
Previously, when receiving two segmented messages, the first message
would go through to the access layer, then the second. Then, if the
transport layer received any repeated segments for the first message, it
would fail to identify the SeqAuth as old, as all its segments were of
new sequence numbers, and the "already complete SDU" check would only
look at the second message. Thus, the segmented message got processed
again and passed to the access layer, even though it was a duplicate.
To solve this, we need a mechanism like RPL, but only for the segmented
messages' SeqAuth. We cannot re-use the actual RPL mechanism, as it
can't support the scenario provoked by the "blocking tx" mechanism in
transport. This mechanism allocates the SeqAuth when the message is
first passed to the transport layer. The ongoing message that caused the
block would keep sending segments with higher sequence numbers than
the blocked message got, which will cause the blocked message to fail
the RPL check.
This patch adds a parallel SeqAuth mechanism to the RPL module, which
only deals with the SeqAuth of the segmented messages. This list gets
checked when the segmented message is first allocated, in the same
manner as the general RPL mechanism. The storage gets hooked into the
RPL mechanism, by adding a separate seg field to each RPL entry.
Signed-off-by: Trond Einar Snekvik <Trond.Einar.Snekvik@nordicsemi.no>
The mesh settings.c module is a giant piece of code responsible for
storing the mesh stack configuration. Such approach makes it difficult
to control the data to be stored, breaks the stack modules'
encapsulation by forcing them to reveal the internal kitchen, which
leads to unpleasant issues such as #19799.
This commit moves the responsibility of storing the configuration
to corresponding modules while keeping control of the moment of storing
the configuration and of starting the stack after the settingss loading
is completed.
This doesn't introduce any abstraction between the mesh settings.c and
other modules as it will add more complexity and overhead than necessary
for the actual task.
Fixes#19850
Signed-off-by: Pavel Vasilyev <pavel.vasilyev@nordicsemi.no>
