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

MAC Address Incrementation Pairing issue

Hi,


We are testing mass pairing on our windows machines, as we have seen problems with a high number of paired devices.

I am able to increment the mac address by using sd_ble_gap_addr_set, and saving it in a noinit ram section, and soft reseting the device.

I also erase bonds post reset, and have tried pre reset as well.

I see the advertisement on the incremented mac address, but I receive a pairing error (136 - which from what I have seen, is the result of an invalid state of the PM).

What can I do to fix this?

Thanks!

Roi

Parents
  • Hi,

    Error 136 corresponds to BLE_GAP_SEC_STATUS_UNSPECIFIED assuming it reported via the PM security failed event, so it's not the most helpful error code I'm afraid. I'm not sure how I should try to replicate this error here, can you maybe provide the steps for me?

    high number of paired devices

    Just to confirm, is this an issue on the Windows PC or on the nRF side?

    I also erase bonds post reset, and have tried pre reset as well.

     On PC, nRF, or both?

    I see the advertisement on the incremented mac address

     What's the purpose changing the address, is it to make the windows PC see the nRF as a new device.

    Thanks,

    Vidar

  • Hi Vidar!

    1. Yes, the problem we see is definitely on the windows side. We simply want to try and estimate the number of paired devices windows can deal with before "going crazy".
    2. I erase bonds only on the nRF end, because part of the issue on the windows end is the amount of LTKs and cached GATT tables, so I want to keep them.
    3. You are correct - we want the windows PC to pair with the incremented mac as if it is a new device. Is there a more elegant solution that you can suggest?

    Thanks for your quick reply!

    Roi

  • Hi Roi,

    I think I would probably have created a random BLE address after every boot so I didn't have to keep track of the increment in RAM. Apart from that, it sounds like a good way to test this issue.

    As for the pairing issue, did you try to reset the device after deleting the bonds? It may be an idea to use nrfjprog to erase the flash pages between each test to be absolutely sure the bonding information is erase:

    1. nrfjprog --erasepage <fds_page_start-fds_page_end>

    2. nrfjprog --reset

    Vidar

  • Hi Vidar,
    I also tried erasing bonds before the reset, to no avail.
    We want this test to be able to happen w/o being physically connected to a debugger, so the nrjfprog option is not possible for us.

    Thanks!
    Roi

Reply Children
No Data
Related