• State Not Answered
  • Replies 17 replies
  • Subscribers 25 subscribers
  • Views 701 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 289058
Options

IV Index and LPN devices that leave mesh

user99042

Hello,

We're developing an LPN product that will leave the mesh and stay off the mesh for up to 3 days (possibly more). When it rejoins the mesh, the central server/gateway could have some resets in between. 

Is there a chance the IV index will prevent the nodes from communicating once reconnected to the mesh? 

I am looking at this thread and wondering how much is safe to change:
https://devzone.nordicsemi.com/f/nordic-q-a/80558/bt-mesh-iv-update-parameters-timers

Thank you

  • 0 in reply to user99042

    Hi,

    aross11 said:
    I overrode a client's IV index to be 42 (within). This caused by server to update to IV index 42 as well

    This would be expected behavior, and is explained by client sharing secure beacon which server receives, server noticing it is behind and therefore performing IVI Recovery.

    aross11 said:
    however, even the client can't send a message to the server anymore

    Where does it fail, is it in the sending, or that the server never seem to receive anything? What is the sequence number and IV Index bits of those packets?

    Do you have minimal examples for reproducing this on a DK?

    Based on your descriptions, it sounds like for instance sequence number not being reset could be an explanation, or if the replay protection is not working properly (not reset) when doing IVI Recovery. From what I recall, IV Index is not fully stored neither in packets sent nor in replay list, rather only the least significant bit is used (since the node knows what IV Indexes are possible for the current IV Index and IV Index update state.) If there's a bug somewhere, that sounds like a possible place.

    aross11 said:
    Does the nRF Mesh app for iOS have it's own IV index?

    I do not quite understand what youi mean by that. The nRF Mesh apps (both Android and iOS) follows the Bluetooth mesh specification, which means they should also be able to participate in IV Index Update and IV Index Recovery. I will double check if the phone apps do indeed have IVI Recovery functionality.

    You mention in a separate thread (nRF Mesh App stops workings after IV update) that you think this is a sequence number issue. I agree. Can you share the logs (or other information)I from your testing on this?

    Regards,
    Terje

  • 0 in reply to user8164

    Hello,

    It's worth noting that we took the advice from another thread and set NETWORK_SEQNUM_FLASH_BLOCK_SIZE from 8192 and changed it to 512. 



    I added in the sequence number/IV index

    I'll repeat this with units with a fresh IV index and see if there's any hints there.

    Let me know if there's anywhere I could add debug messages to better see the error.

    Right now the error coming back is timeout so it might be that the server is rejecting messages from the phone 

    Here's the nRF Mesh app for Android log while doing it:

    Here's the server/proxy receiving an 8049 opcode to node 0x0066 (I don't see it here)



Related
Terms of service