This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Scanning and blacklisting Devices

Hello everyone,

currently I am working on my application which is based on the multirole example and with the SDK17.1. My target is if one device connected to another the central device should keep the device ID in mind and never connect or better would be newer try to connect again to the same device. For example if there are 10 devices they should never reconnect or try to connect to the same device again. It should always try to connect to a new one. What would be the best way to implement it?

I tried one thing. I store the device ID on the central device and if the device gets the BLE_GAP_EVT_ADV_REPORT Event it went through a for-loop and check if the device was already connected. If yes I started  the disconnect function sd_ble_gap_disconnect(). This method doesnt worked (how can I stop the connecting process?)and I dont like it. What would be the best method to create such kind of "blacklist"?

Best regards

Hani

  • Hi Hani,

    There is no blacklist concept in the SDK or SoftDevice, so you have to implement that yourself by maintaining a list of your own.

    If the device with the blacklist is a peripheral you should for every BLE_GAP_EVT_CONNECTED event, check the Bluetooth address of the device that connected and compare that with the blacklist you are maintaining. If the device is in the black list, disconnect immediately by calling sd_ble_gap_disconnect(). There is unfortunately no way to prevent the device from connecting again, so you may end up in a loop doing this over and over again, but that is how it is.

    If the device with the backlist is a central it can a bit more elegant. There you could scan filtering on whatever parameters you want to filter on, but do not connect on match. When you have a match, compare the address with the blacklist, and only start scanning with the intention to connect (connect_if_match flag set to true if using the nrf_ble_scan module) or call d_ble_gap_connect() if the device is not in the black list.

    Einar

  • Hello Einar,

    thank you for your response. My Device is a central. Currently I am filtering on my unique UUID. If I understood correctly I have to set connect_if_match to false and setup my filter (in my case the UUID) and start the scanning module. If the device detects another device with the unique UUID it will give me an BLE_GAP_EVT_ADV_REPORT event. After that I have the possibility to check the device ID with my blacklist.

    What happens after that? If I set the connect_if_match to true and scan again there is a possibility to connect to another device. Is it not possible to continue the connection process after I received the Event and identified the devie is not in the blacklist?

    Since my application is based on the multirole example I am using the peer manager and some kind of security. I dont want to disturb the complete connection chain.

  • Hani_Montana said:
    What happens after that? If I set the connect_if_match to true and scan again there is a possibility to connect to another device. Is it not possible to continue the connection process after I received the Event and identified the devie is not in the blacklist?

    The Idea is that at this point you change the filter policy, so that instead of filtering on the UUID, you now filter on the address which you know has the UUID and is not in the black list.

    There is one point worth mentioning though, which I forgot in my previous reply. If the devices you want to black list use privacy (resolvable random address), then the blacklisting scheme will not work in cases where the device change address (for instance modern phones do that regularly, typically every 15 minutes). In those cases, you will need the identity resolution key (IRK) of that device which you only get after bonding in order to resolve the address to know if two different addresses are actually from the same device (derived from the same IRK).

Related