False detection of replay protection

Hello.

I am developing using nRF5340DK and nRF Connect SDK v2.9.0.
However, this PR has been applied.
I connected one smartphone app and two boards(nRF5340DK) to the mesh network.
When I sent multiple messages requiring a response from the smartphone app to the board, replay protection was detected.

  1. Send five messages from the smartphone app.
  2. A board that is not the destination relays messages.
    relay.log line: 1-20
    dst 0x148d seq 0x2d27
    dst 0x148b seq 0x2d28
    dst 0x1492 seq 0x2d29
    dst 0x1490 seq 0x2d2a
    dst 0x1491 seq 0x2d2b
    The order of reception and sequence numbers is correct
  3. A board that is the destination processes messages.
    target.log line: 1-81
    dst 0x148b seq 0x2d28
    dst 0x148d seq 0x2d27
    dst 0x1492 seq 0x2d29
    dst 0x1490 seq 0x2d2a
    dst 0x1491 seq 0x2d2b
    Message "dst 0x148d seq 0x2d27" was not processed due to replay protection because Message "dst 0x148b seq 0x2d28" was processed first. line: 12-13

[00:55:12.775,756] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148d seq 0x00002d27 friend_match 0
[00:55:12.775,787] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e663a8f53210c
[00:55:12.775,817] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x148d
[00:55:12.775,848] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:12.778,503] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148b seq 0x00002d28 friend_match 0
[00:55:12.778,564] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e22936b04f3dd
[00:55:12.778,564] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x148b
[00:55:12.778,594] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:12.781,097] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1492 seq 0x00002d29 friend_match 0
[00:55:12.781,127] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e26081a4951a3e613a3
[00:55:12.781,158] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x1492
[00:55:12.781,158] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:12.783,660] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1490 seq 0x00002d2a friend_match 0
[00:55:12.783,691] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4ed61a708616e7d7e6dd
[00:55:12.783,721] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x1490
[00:55:12.783,721] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:12.787,963] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1491 seq 0x00002d2b friend_match 0
[00:55:12.787,994] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e2e7ea21b2a5f7dc41d
[00:55:12.787,994] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x1491
[00:55:12.788,024] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:12.862,213] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x148b dst 0x1000 seq 0x00000044 friend_match 0
[00:55:12.862,243] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e5569eed983e234f2
[00:55:12.862,274] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 7 CTL 0 dst 0x1000
[00:55:12.862,274] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 6
[00:55:12.951,477] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1492 dst 0x1000 seq 0x00000045 friend_match 0
[00:55:12.951,507] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4edba9f760787ca59f7818fe
[00:55:12.951,538] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 7 CTL 0 dst 0x1000
[00:55:12.951,538] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 6
[00:55:13.066,192] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1491 dst 0x1000 seq 0x00000047 friend_match 0
[00:55:13.066,223] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e1dd50813bc2a7fdcb3a25b
[00:55:13.066,223] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 7 CTL 0 dst 0x1000
[00:55:13.066,253] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 6
[00:55:17.365,783] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148d seq 0x00002d2c friend_match 0
[00:55:17.365,814] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e93a68d5fca50
[00:55:17.365,844] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x148d
[00:55:17.365,875] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:17.368,530] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1490 seq 0x00002d2d friend_match 0
[00:55:17.368,560] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4ed05deb3e026adde9c7
[00:55:17.368,560] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 5 CTL 0 dst 0x1490
[00:55:17.368,591] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 4
[00:55:17.473,968] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x148d dst 0x1000 seq 0x00000048 friend_match 0
[00:55:17.473,999] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e5733badac8b78c0577ff
[00:55:17.473,999] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 7 CTL 0 dst 0x1000
[00:55:17.474,029] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 6
[00:55:17.539,001] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1490 dst 0x1000 seq 0x00000049 friend_match 0
[00:55:17.539,031] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e246f75358238dc443e481d
[00:55:17.539,031] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 7 CTL 0 dst 0x1000
[00:55:17.539,062] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 6

[00:53:25.664,276] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148b seq 0x00002d28 friend_match 0
[00:53:25.664,306] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e22936b04f3dd
[00:53:25.664,337] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:25.664,337] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:25.665,039] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:25.665,069] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x148b
[00:53:25.665,100] <dbg> bt_mesh_access: bt_mesh_model_recv: len 2: ****
[00:53:25.665,100] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:25.676,391] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148d seq 0x00002d27 friend_match 0
[00:53:25.676,422] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e663a8f53210c
[00:53:25.676,452] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:25.676,452] <wrn> bt_mesh_rpl: bt_mesh_rpl_check: rpl->seq 0x002d28, rx->seq 0x002d27
[00:53:25.676,483] <wrn> bt_mesh_transport: Replay: src 0x1000 dst 0x148d seq 0x002d27
[00:53:25.702,728] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x148b
[00:53:25.702,758] <dbg> bt_mesh_access: bt_mesh_access_send: len 4: ********
[00:53:25.702,758] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:25.702,789] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 4: ********
[00:53:25.703,552] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x148b dst 0x1000 len 9 headroom 9 tailroom 11
[00:53:25.703,582] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 9: 4e5569eed983e234f2
[00:53:25.703,582] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000044
[00:53:25.703,613] <dbg> bt_mesh_net: net_header_encode: src 0x148b dst 0x1000 ctl 0 seq 0x000044
[00:53:25.722,076] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1492 seq 0x00002d29 friend_match 0
[00:53:25.722,106] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e26081a4951a3e613a3
[00:53:25.722,137] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:25.722,137] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:25.722,869] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:25.722,869] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x1492
[00:53:25.722,900] <dbg> bt_mesh_access: bt_mesh_model_recv: len 5: **********
[00:53:25.722,930] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:25.725,860] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1490 seq 0x00002d2a friend_match 0
[00:53:25.725,891] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4ed61a708616e7d7e6dd
[00:53:25.725,921] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:25.725,952] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:25.726,654] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:25.726,654] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x1490
[00:53:25.726,684] <dbg> bt_mesh_access: bt_mesh_model_recv: len 5: **********
[00:53:25.726,715] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:25.750,335] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x1492
[00:53:25.750,366] <dbg> bt_mesh_access: bt_mesh_access_send: len 7: **************
[00:53:25.750,366] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:25.750,396] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 7: **************
[00:53:25.751,129] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x1492 dst 0x1000 len 12 headroom 9 tailroom 8
[00:53:25.751,190] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 12: 4edba9f760787ca59f7818fe
[00:53:25.751,190] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000045
[00:53:25.751,190] <dbg> bt_mesh_net: net_header_encode: src 0x1492 dst 0x1000 ctl 0 seq 0x000045
[00:53:25.763,214] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x1490
[00:53:25.763,244] <dbg> bt_mesh_access: bt_mesh_access_send: len 7: **************
[00:53:25.763,244] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:25.763,275] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 7: **************
[00:53:25.764,007] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x1490 dst 0x1000 len 12 headroom 9 tailroom 8
[00:53:25.764,068] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 12: 4ec1b94ec04f4f8249ab220c
[00:53:25.764,068] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000046
[00:53:25.764,068] <dbg> bt_mesh_net: net_header_encode: src 0x1490 dst 0x1000 ctl 0 seq 0x000046
[00:53:25.805,755] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1491 seq 0x00002d2b friend_match 0
[00:53:25.805,786] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e2e7ea21b2a5f7dc41d
[00:53:25.805,816] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:25.805,847] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:25.806,549] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:25.806,549] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x1491
[00:53:25.806,579] <dbg> bt_mesh_access: bt_mesh_model_recv: len 5: **********
[00:53:25.806,610] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:25.825,256] <dbg> bt_mesh_net: bt_mesh_net_recv: rssi -65 net_if 0
[00:53:25.825,317] <dbg> bt_mesh_net: bt_mesh_net_decode: 25 bytes: 00c413796f3a49237a6f0d061b8c0bb17139c24ccd671979b4
[00:53:25.825,317] <dbg> bt_mesh_net: net_decrypt: NID 0x00
[00:53:25.825,347] <dbg> bt_mesh_net: net_decrypt: IVI 0 net->iv_index 0x00000000
[00:53:25.825,531] <dbg> bt_mesh_net: net_decrypt: Dropping locally originated packet
[00:53:25.825,561] <dbg> bt_mesh_net: bt_mesh_net_decode: Unable to find matching net for packet
[00:53:25.841,247] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x1491
[00:53:25.841,278] <dbg> bt_mesh_access: bt_mesh_access_send: len 7: **************
[00:53:25.841,278] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:25.841,308] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 7: **************
[00:53:25.842,041] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x1491 dst 0x1000 len 12 headroom 9 tailroom 8
[00:53:25.842,102] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 12: 4e1dd50813bc2a7fdcb3a25b
[00:53:25.842,102] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000047
[00:53:25.842,102] <dbg> bt_mesh_net: net_header_encode: src 0x1491 dst 0x1000 ctl 0 seq 0x000047
[00:53:25.939,147] <dbg> bt_mesh_net: bt_mesh_net_recv: rssi -65 net_if 0
[00:53:25.939,208] <dbg> bt_mesh_net: bt_mesh_net_decode: 25 bytes: 00ececa7b143a2831bb2e0bdf3a55b147740cd245c201d4bea
[00:53:25.939,239] <dbg> bt_mesh_net: net_decrypt: NID 0x00
[00:53:25.939,239] <dbg> bt_mesh_net: net_decrypt: IVI 0 net->iv_index 0x00000000
[00:53:25.939,453] <dbg> bt_mesh_net: net_decrypt: Dropping locally originated packet
[00:53:25.939,453] <dbg> bt_mesh_net: bt_mesh_net_decode: Unable to find matching net for packet
[00:53:30.242,523] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x148d seq 0x00002d2c friend_match 0
[00:53:30.242,553] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4e93a68d5fca50
[00:53:30.242,584] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:30.242,614] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:30.243,316] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:30.243,347] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x148d
[00:53:30.243,377] <dbg> bt_mesh_access: bt_mesh_model_recv: len 2: ****
[00:53:30.243,408] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:30.246,185] <dbg> bt_mesh_transport: bt_mesh_trans_recv: src 0x1000 dst 0x1490 seq 0x00002d2d friend_match 0
[00:53:30.246,215] <dbg> bt_mesh_transport: bt_mesh_trans_recv: Payload 4ed05deb3e026adde9c7
[00:53:30.246,215] <dbg> bt_mesh_transport: trans_unseg: AFK 1 AID 0x0e
[00:53:30.246,246] <dbg> bt_mesh_transport: sdu_recv: AKF 1 AID 0x0e
[00:53:30.246,948] <dbg> bt_mesh_transport: sdu_recv: Decrypted (AppIdx: 0x000)
[00:53:30.246,978] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x1000 dst 0x1490
[00:53:30.247,009] <dbg> bt_mesh_access: bt_mesh_model_recv: len 5: **********
[00:53:30.247,009] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x********
[00:53:30.272,644] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x148d
[00:53:30.272,674] <dbg> bt_mesh_access: bt_mesh_access_send: len 6: ************
[00:53:30.272,674] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:30.272,705] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 6: ************
[00:53:30.273,437] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x148d dst 0x1000 len 11 headroom 9 tailroom 9
[00:53:30.273,468] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 11: 4e5733badac8b78c0577ff
[00:53:30.273,498] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000048
[00:53:30.273,498] <dbg> bt_mesh_net: net_header_encode: src 0x148d dst 0x1000 ctl 0 seq 0x000048
[00:53:30.291,870] <dbg> bt_mesh_net: bt_mesh_net_recv: rssi -67 net_if 0
[00:53:30.294,555] <dbg> bt_mesh_access: bt_mesh_access_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000 src 0x1490
[00:53:30.294,586] <dbg> bt_mesh_access: bt_mesh_access_send: len 7: **************
[00:53:30.294,586] <dbg> bt_mesh_transport: bt_mesh_trans_send: net_idx 0x0000 app_idx 0x0000 dst 0x1000
[00:53:30.294,616] <dbg> bt_mesh_transport: bt_mesh_trans_send: len 7: **************
[00:53:30.295,349] <dbg> bt_mesh_net: bt_mesh_net_send: src 0x1490 dst 0x1000 len 12 headroom 9 tailroom 8
[00:53:30.295,410] <dbg> bt_mesh_net: bt_mesh_net_send: Payload len 12: 4e246f75358238dc443e481d
[00:53:30.295,410] <dbg> bt_mesh_net: bt_mesh_net_send: Seq 0x000049
[00:53:30.295,410] <dbg> bt_mesh_net: net_header_encode: src 0x1490 dst 0x1000 ctl 0 seq 0x000049

Do you know the reason why the order of the relayed messages is reversed?

I have one more question.
There are messages among the ones the board responded to that were not relayed.

  1. Send five messages from the board.
    target.log line: 18-72
    src 0x148d dst 0x1000 seq 0x0044
    src 0x1492 dst 0x1000 seq 0x0045
    src 0x1490 dst 0x1000 seq 0x0046
    src 0x1491 dst 0x1000 seq 0x0047
  2. A board that is not the destination relays messages.
    relay.log line: 21-32
    src 0x148d dst 0x1000 seq 0x0044
    src 0x1492 dst 0x1000 seq 0x0045
    src 0x1491 dst 0x1000 seq 0x0047
    Message "src 0x1490 dst 0x1000 seq 0x0046" is lost.

When there is only one board, this issue does not occur. Therefore, it seems that the relay process is related to the problem.

Thanks for reading.

a.da

  • 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

  • Hi Terje,

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

    Let me confirm two additional points.

    1. 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?

    2. 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

  • Hi,

    a.da said:
    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?

    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.

    a.da said:
    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?

    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

  • Hi Terje,

    Thank you once again.

    Kind regards,

    a.da

Related