BLE connect state to adv state

RE: BLE connect state to adv state

Samruddhi Jadhav — Wed, 11 Feb 2026 11:56:44 GMT

Hi,

Apologies for the delay. The solution here would be to keep advertising without use of whitelist. Then when the device connects, check its Bluetooth address. If the device is the one you want to block, disconnect it right away. By doing this, one host gets blocked and the other Windows/MAC/iOS/ Android devices can pair normally. It is not possible to read the whitelist of any Windows or MAC device as it is private to the host and due to this it can't be accessed by a BLE peripheral and you can't design your own whitelist to match the host's whitelist or to decide which hosts are allowed.

Best Regards,

Samruddhi

RE: BLE connect state to adv state

Liny — Mon, 09 Feb 2026 03:36:23 GMT

“”Our docs only mention whitelist advertising and disconnecting after connect so there's no mentioned way to inspect and reject a connection. You have to let the connection happen and call sd_ble_gap_disconnect() for dropping it. The only way you can block one specific host is by using peer manger in order to manage bonded peers. Then build a whitelist which does not contain that host's peer ID. After that, enable whitelist advertising. “”
Thank you. You mentioned that if I want to pair a new device while blocking connection requests from the host that still has this slave device on its whitelist, I should enable whitelist broadcasting, remove this device from the whitelist, and include the new device instead. My question is, how can I determine the whitelist of the peer device I want to pair with? Since the peer device could be any Windows or Mac computer, I’m unsure how to define the scope of my whitelist while also excluding devices I don’t want to reconnect to.

RE: BLE connect state to adv state

Samruddhi Jadhav — Fri, 06 Feb 2026 14:47:01 GMT

Hi,

For the third question, use a whitelist during advertising and control which bonded devices are allowed. So yes, it limits the scope of who can connect.

What the whitelist does:

When a phone/PC first bonds with your device, the Peer Manager stores it and its given a peer ID. From these, you build the whitelist by using pm_whitelist_set(peer_ids, n_peer_ids).

Then, when advertising uses the whitelist, only devices in this list can connect in fast/slow advertising modes. This works for Windows, iOS, Android, Mac. To combine "pair with any device" + whitelist, there are 2 modes you can use: Normal mode (Whitelist ON) and Pairing Mode. In normal mode, build a whitelist from all peer IDs you want to allow. when advertising module sends BLE_ADV_EVT_WHITELIST_REQUEST, you can then call pm_whitelist_get() and then ble_advertising_whitelist_reply() in order to apply it. This way, only bonded devices are able to reconnect. In pairing mode, you can temporarily turn off whitelist for one connection when you want to pair with a new phone/PC. This way, any Windows/iOS /Android/Mac device will be able to connect and bond once. Advertising automatically will go back to using whitelist after connection ends. When you enter "pairing mode", you can pair with any mainstream OS. Each device after bonding gets a peerID and can be allowed in the whitelist or blocked out.

Question about alternative approach:

Our docs only mention whitelist advertising and disconnecting after connect so there's no mentioned way to inspect and reject a connection. You have to let the connection happen and call sd_ble_gap_disconnect() for dropping it. The only way you can block one specific host is by using peer manger in order to manage bonded peers. Then build a whitelist which does not contain that host's peer ID. After that, enable whitelist advertising.

Best Regards,

Samruddhi

RE: BLE connect state to adv state

Liny — Wed, 04 Feb 2026 13:22:43 GMT

If the above method doesn't work, is there any alternative approach? For example, when the peripheral receives a connection request from the host or detects an error like err4102, it could reply by rejecting the connection or something similar, so that the host won't keep attempting to reconnect repeatedly.

Alternatively, if I set the peripheral to broadcast in non-whitelist mode, will the host still be able to discover my device and try to reconnect?

RE: BLE connect state to adv state

Liny — Wed, 04 Feb 2026 13:14:58 GMT

According to your method, the first one has been achieved. Thank you!

As for the third question, I’d like to ask: Do you mean using a whitelist for broadcasting and limiting the scope of the whitelist? Is that correct?

What I want to know is, if I want to pair with most mainstream Windows, iOS, Android, and Mac devices on the market, how should I configure the scope of the whitelist? In other words, if the whitelist for the new host devices I want to pair with isn’t specific, is your method still effective? And if it is effective, could you provide more detailed guidance? Thank you!

RE: BLE connect state to adv state

Samruddhi Jadhav — Wed, 04 Feb 2026 12:29:49 GMT

Hi,

1) I can suggest a few steps. In order to make the device advertise again when button is pressed, ask the SoftDevice first to disconnect. This you can do by using sd_ble_gap_disconnect(...). Then, when you get the disconnected event in the BLE handler, start advertising.

advertising_init() is called once at the start. After that, you can use advertising_start() again after disconnect.

2) The reason why the central keeps reconnecting is because it remembers the bonding info between your peripheral and central. The peripheral still advertises in a mode that accepts it. Then you advertised normally, so the central tried using the old bond to connect. When the connection fails, it tries again which causes a loop where it connects and disconnects.

3) If you want to only block that central, you can try to use PeerManager and build a whitelist of peers which you want to allow. When advertising module asks for a whitelist, to get the addresses for those peerIDs, you can call pm_whitelist_get(...). These can then be passed to ble_advertising_whitelist_reply(...). So, don't include the central's peer ID in the list passed to pm_whitelist_set().

Let me know if you have any further questions.

Best Regards,

Samruddhi

RE: BLE connect state to adv state

Turbo J — Wed, 04 Feb 2026 10:30:36 GMT

Bad design. A device that exposes HID service will always see aggressive connection attempts from host OS that has a pairing/bonding active. For good reason: Disconnected mouse/keyboard is VERY annoying.

The only good solution is to change the device MAC address dynamically. This is how my BTLE mouse here can support up to 3 different hosts. It has a extra button and status LEDs for this function.

No idea how to do this in either NCS or the old NRF5 SDK though.

RE: BLE connect state to adv state

Liny — Wed, 04 Feb 2026 08:35:39 GMT

I am encountering an issue: as a peripheral, after bonding with a central device, I unilaterally cleared the whitelist. However, when the peripheral re-enters pairing mode, the central device keeps attempting to connect and bond, causing the peripheral to repeatedly connect and then disconnect. How can I avoid this problem? The desired outcome is to prevent connection attempts from this specific central device while still allowing other central devices to scan and connect to the device.