• State Not Answered
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 732 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 288636
Options

mesh: duplicate found in network message cache

AndyM

Starting a new ticket since now I have a bit more details to describe what's going on

I have a custom model server that is configured to publish  every 10 seconds with retransmit count of 7 and TTL 10

Configured 2 devices to publish an 1 to subscribe to the publication.

Subscriber is connected to the RTT console

On power up it receives messages from both publishers

After about 2-5 minutes it only receives messages from 1 publisher for several minutes, then messages from the second publisher. then the first one again but never both, as was the case on power up 

The message from the second publisher is received by the stack but not propagated to the application layer

Debug log below shows 

00> [00:19:15.207,244] <dbg> vps_model_c: vps_set_unack: >>> GOT DATA --> message delivered to the application
00> [00:19:20.023,925] <dbg> bt_mesh_net: bt_mesh_net_relay: TTL 10 CTL 0 dst 0xc002
00> [00:19:20.023,956] <dbg> bt_mesh_net: bt_mesh_net_relay: Relaying packet. TTL is now 9
00> [00:19:20.025,207] <dbg> bt_mesh_net: bt_mesh_net_recv: rssi -56 net_if 0
00> [00:19:20.025,268] <dbg> bt_mesh_net: bt_mesh_net_decode: 29 bytes: 6882c477165f86a2c174b0a52dd1094a2eee14e12609d00a45a27a87d2
00> [00:19:20.025,299] <dbg> bt_mesh_net_keys: bt_mesh_net_cred_find:
00> [00:19:20.025,299] <dbg> bt_mesh_net: net_decrypt: NID 0x68
00> [00:19:20.025,329] <dbg> bt_mesh_net: net_decrypt: IVI 0 net->iv_index 0x00000000
00> [00:19:20.025,360] <dbg> bt_mesh_net: net_decrypt: Duplicate found in Network Message Cache
00> [00:19:20.025,360] <dbg> bt_mesh_net: bt_mesh_net_decode: Unable to find matching net for packet

Any ideas what's going on and how to fix?

Thank you

Parents
  • 0

    Hi,

    I can't determine what the cause might be, seems like a strange case. Need some time to look into it and come back to you when I have an update.

  • 0 in reply to Mttrinh

    Hi, 

    After checking in with the team, aside from the publish parameters looking a bit ... excessive, if this is a three node network, the only reason this can happen is if the publishing nodes somehow have the same unicast address (i.e. SRC in the network PDU)?

    Can you check the unicast address of the publishing nodes?

    Otherwise the Network Message Cache would only reject if the 17 least significant bits of the sequence number is the same as a previously received Network PDU, which they can't see how would happen. Even with 7 retransmits every 10 seconds that should be able to give unique 17lsbs of sequence numbers for days, not minutes.

Reply
  • 0 in reply to Mttrinh

    Hi, 

    After checking in with the team, aside from the publish parameters looking a bit ... excessive, if this is a three node network, the only reason this can happen is if the publishing nodes somehow have the same unicast address (i.e. SRC in the network PDU)?

    Can you check the unicast address of the publishing nodes?

    Otherwise the Network Message Cache would only reject if the 17 least significant bits of the sequence number is the same as a previously received Network PDU, which they can't see how would happen. Even with 7 retransmits every 10 seconds that should be able to give unique 17lsbs of sequence numbers for days, not minutes.

Children
Related
Terms of service