This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Android-nRF-Mesh-Library: How to consume/invalidate a unicast address?

Dear Nordic Bluetooth experts,

In the Android-nRF-Mesh-Library, is there a way to mark a unicast address as used? The reason why I'd like to do it is the following:
 
When adding a new node, my Bluetooth mesh app performs the these steps:

  1. Provisions the device.
  2. Connects to the new node.
  3. Assigns the net/app keys and unicast address.

Every now and than it happens that the connection to the new proxy node (step 2.) gets lost because of either "Error: (0x85): GATT ERROR" or "Error: (0x13): GATT CONN TERMINATE PEER USER". If that happens the app simply reconnects and restarts step 3. Sounds like the right thing to do, doesn't it? 

The problem is, that MeshNetwork.nextAvailableUnicastAddress() returns the same unicast address than before the disconnect/reconnect. Passing that address to BaseMeshNetwork.assignUnicastAddress() fails with:
W/System.err: java.lang.IllegalArgumentException: Unicast address is already in use.
 
Now the question is, how can you prevent nextAvailableUnicastAddress() from returning an address that assignUnicastAddress() rejects?
My first idea was to consume (or invalidate) an address if assginUnicastAddress() fails and then simply try again. Question is, how can it be done? Or is there a better way to fix this issue?
 
Any advise from an expert in that matter is very much appreciated.
Thank  you.
 

  • Hi

    I spoke to one of our developers of the Android nRF Mesh library, and it seems like you are trying to assign the unicast address twice to the same device. Usually, you would assign a unicast address as well as a network key during provisioning, and then add additional network/app keys after you have connected. This is according to the Bluetooth Mesh profile spec. so I'm guessing that's what causing these errors when you try assigning a unicast address after the provisioning.

    Best regards,

    Simon

  • Hi Simon,

    Thanks for your help.

    it seems like you are trying to assign the unicast address twice to the same device.

    Sorry, I've oversimplified the explanation. My app first provisions a node, then connects to it and (if the connection is established) assigns and binds the app key. The unicast address is assigned only during provisioning (i.e. the first step). This is the exact same behavior as the demo app.

    The problem is caused by a bug or "design flaw" in Android-nRF-Mesh-Library:

    The bug here is that nextAvailableUnicastAddress() returns an already used address. It obviously shouldn't, but it's happening anyway because Android-nRF-Mesh-Library updates its internal list of nodes (BaseMeshNetwork.nodes) in response of one of the configuration commands (ConfigDefaultTtlGet, ConfigNetworkTransmitSet, ConfigAppKeyAdd, ConfigModelAppBind).
    Now if the connection to the freshly provisioned node fails, non of these commands are sent, and hence the library misses the newly provisioned node, causing nextAvailableUnicastAddress() to return an already used unicast address.

    The question now is how can we get this fixed asap?

  • Hi

    Due to the summer vacation period we are currently understaffed, so delayed replies must be expected. I am sorry about any inconvenience this might cause. I'm currently waiting for an answer internally on this bug you have reported and it's under investigation. Thank you for your patience. I will get back to you as soon as I have more information.

    Best regards,

    Simon

  • Hello Simon,

    Thanks for your help! No big deal if it takes a little longer. I've meanwhile opened an issue at the libraries github repo.

    All the best,
    Michael.

  • Hi again

    The person in charge of the Android nRF Mesh library got back from vacation today and will look at this issue and handle it on GitHub this week. 

    Best regards,

    Simon

Related