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>
4fbd0cb0ca