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

Selectively Connecting To Devices

I have an nrf51822-mkit.

Let's say there are 2 BLE phones continuously searching for my module. Phone 1 connects and communicates with the module. The modules determines that this phone is not the correct phone, so it initiates a disconnect. When Phone 1 senses that it has been disconnected, it immediately starts scanning again for the device to connect to. But the module already knows Phone 1 is incorrect, and it would like to try to connect to Phone 2 instead. However, Phone 1 could continually keep trying to connect to the module to check if it's the correct phone.

Ideally, I would like to implement a sort of temporary blacklist. The module would check the phone, and if it's incorrect get the address of the phone, add it to a blacklist, and prohibit connections to devices that are on that blacklist. After, say, 30 seconds the device would be removed from the blacklist.

I have 2 questions:

  1. How do I go about getting the address of the BLE device (phone) from my module so that it can be added to a blacklist and checked later?

  2. Is it possible to prohibit certain addresses from ever connecting? Or does this have to be taken care of with logic after the connection (e.g. if the address matches a blacklisted address after connection, immediately disconnect). If the latter is the case, is it possible for one device to continuously connect and disconnect, prohibiting other devices from trying?

If anyone has any ideas on how best to implement this, I would very much appreciate them.

    1. The ble_gap_evt_connected_t struct contains the address of the peer.

    2. There is no blacklist feature. When setting up your module, you would have to accept connections until you get Phone 2. Then you can add only Phone 2 to the whitelist, which will then prevent Phone 1 from connecting. Both phones should have an equal chance of connecting to your module, so this should work out fine.

  • The white-listing will work if and only if your application on the BLE device is aware of phone 1 and phone 2. If the application is not aware of phone 2 and does not want phone 1 to connect, it cannot add phone 2 to the whitelist. This whitelist logic may not work well when adding 2 phones to the the device as known peers.

    To manage the addition process: One possible method is to add an ID to the advertising packet. This ID can be a reference to the phones that have the ID should not connect so phones that do not have this ID yet will connect. This works only when you are using your own app on the phone to manage the BLE connections.

    Will this work for you ?

  • I too do not think whitelisting will accomplish my goal.

    I do have control over the app side, so that is an option. Right now I am maintaining a temporary blacklist on the app side with the device name as the identifier. This sounds similar to what you're proposing. The downside to letting the blacklisting reside on the app side is that it leaves the BLE module open to a type of denial of service attack, if it accepts any connection. A malicious device could continuously try to connect to the module, blocking other devices from attempting a connection. This is a consumer device, so that is a concern.

  • Then I suggest that the addition process be done in a private location so there is no possibility of an attacker getting added. Once the addition has been done, use whitelisting for regular operation, manage the whitelist as suggested by @user9384 above. So during normal operation, addition of the phone will not be allowed and whitelisting will be done to manage the phones, this will prevent an attacker from maliciously connecting and blocking the device.

    Will this resolve your issue ?

  • Unfortunately, adding devices in private is not possible with our product. Once the module ships, it advertises in a public location and new devices can be added at any time. It looks like I really would need a form of blacklist to block certain phones rather than allow others (because we have no way of know at runtime which phones will be attempting a connection).

Related