False detection of replay protection

RE: False detection of replay protection

a.da — Thu, 30 Jan 2025 23:51:14 GMT

Hi Terje,

Thank you once again.

Kind regards,

a.da

RE: False detection of replay protection

tesc — Thu, 30 Jan 2025 14:23:40 GMT

Hi,

[quote user="a.da"]When the order is reversed, do any issues or errors other than replay protection occur?
Is the intention for the reversal of the order to be detected by the replay protection logic?[/quote]

The issue is that replay protection leads to out-of-order packets getting discarded at the receiving node. If the application tolerates missing packets, then there should not be further issues or errors.

The purpose of the replay protection logic is to not accept replays of old messages which were previously recorded by a malicious actor. The purpose is not to discard valid messages which happens to arrive out-of-order.

[quote user="a.da"]Is there a debug log that confirms when a packet is dropped?
The two boards are approximately 1 meter apart. The boards are not covered, and there are no obstacles in between.
Is it possible to distinguish whether the packet was actually dropped or if it was not transmitted at all?[/quote]

Packets dropped from replay protection is logged by the target at the "warning" log level. The following line is one example of this log line, found in your target log file:

[00:53:25.676,483] <wrn> bt_mesh_transport: Replay: src 0x1000 dst 0x148d seq 0x002d27

When packets are lost due to packet collision, or due to the receiving node not scanning at the moment, then there is no log trace of that packet at the receiving node. Depending on log level, there may be traces in the logs from the originating node and from relay nodes.

Regards,
Terje

RE: False detection of replay protection

a.da — Thu, 30 Jan 2025 06:15:53 GMT

Hi Terje,

Thank you for your thorough explanation. If reliable sending is necessary, I will try segmented messages.

Let me confirm two additional points.

When the order is reversed, do any issues or errors other than replay protection occur?
Is the intention for the reversal of the order to be detected by the replay protection logic?
Is there a debug log that confirms when a packet is dropped?
The two boards are approximately 1 meter apart. The boards are not covered, and there are no obstacles in between.
Is it possible to distinguish whether the packet was actually dropped or if it was not transmitted at all?

Kind regards,

a.da

RE: False detection of replay protection

tesc — Wed, 29 Jan 2025 14:06:12 GMT

Hi,

When the packets of a Bluetooth Mesh message are transmitted and relayed, they are not sent only once. Rather, they are repeated, according to a configuration for the number of repeats.

From the node sending the message, the packets will be sent 1 + Network Transmit Count number of times.

From the relay node, the packets will be sent 1 + Relay Retransmit Count number of times. Further, the intervals between those retransmissions are controlled by Network Transmit Interval and Relay Retransmit Interval, for originating node and relay nodes respectively.

If you send a message B shortly after a message A, you may end up with the first transmission of the packet containing message B being sent before the last retransmissions of the packet containing message B. Typically this can happen at the relay, especially if the first original transmission for packet A was lost, so that the relay starts relaying after receiving the second or third transmission for that packet.

The following figure shows one example of message order inversion. In this case there is a lot of packet loss. Depending on parameters and timing, as little as one dropped packet might in some situations be enough to cause out-of-order message reception.

To reliably send multiple messages in a row, you can use segmented messages. With segmented messages, the sender is only allowed to send one message at the time. The transmission is considered completed when the message has been ACKed, and then the next message can be sent. Therefore, there is no message order inversion when using segmented messages, regardless of number of relays and amount of packet loss along the way. ACKing of segmented messages is handled by the Bluetooth Mesh stack at the lower transport layer.

See Segmentation and reassembly (SAR) for details on segmented messages.

Please note that the maximum payload for the first segment of a segmented message (8 bytes including opcode) is three bytes less than the maximum payload for an unsegmented message (11 bytes including opcode). This means some messages that originally fits in one unsegmented packet will require two packets when segmented, and therefore take slightly longer to transmit. On the other hand, in the case of a unicast destination, retransmissions are cancelled when ACKed, which means less time is typically spent at the sender end for sending the message.

Regards,
Terje