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>
