Devices not in whitelist receiving connected event before being rejected

RE: Devices not in whitelist receiving connected event before being rejected

Emil Lenngren — Sun, 05 Mar 2023 03:41:36 GMT

I assume you're using legacy advertising (ADV_IND from the peripheral, CONNECT_IND from the central). In this case, there is no acknowledgement from the peripheral that it has accepted a connection. Instead, per the specification, the central shall exit the initiating state and enter the connected state as soon as it has sent the CONNECT_IND packet. The connection will instead time out after six missed connection events with the error code "0x3e connection failed to be established". Note that this error code doesn't necessarily mean the connection was rejected; if the CONNECT_IND is lost in the air, e.g. due to a simultaneous SCAN_REQ from another central, the same error will happen.

This issue has in some sense been "fixed" in Bluetooth 5.0 with the new extended advertising, which uses the sequence ADV_EXT_IND, AUX_ADV_IND, AUX_CONNECT_REQ, AUX_CONNECT_RSP. Here, the AUX_CONNECT_REQ is sent by the central and the other packets by the peripheral. The last packet gives the peripheral a chance to accept and acknowledge the connection. First when it's acknowledged, the central will report the connection as complete to its host. This way "connect disconnect loops" can be avoided, but the host running on the central will not be notified when a connection has been rejected.

So when you start advertising, make sure you use the new extended advertising feature. Note that this of course requires support from the central, so no BT 4 centrals.

RE: Devices not in whitelist receiving connected event before being rejected

rberekson — Fri, 03 Mar 2023 14:22:38 GMT

Einar,

Thank you for the clarification. This is the behavior I am seeing, so I can figure out how to work with this for my use case.

RE: Devices not in whitelist receiving connected event before being rejected

Einar Thorsrud — Fri, 03 Mar 2023 14:16:43 GMT

Hi,

Yes, this is expected behavior. There is no way to rejected a connection attempt in Bluetooth, so when a central that is not in the whitelist attempts to connect, the peripheral simply ignores it. And moreover, from the central perspective, the connection has started when the connection indication is sent. However, there is a short timeout before the first packet has been acknowledged by the peer, so you will get a disconnect with reason 0x3E, which means that the connection failed to be established.