Devices not in whitelist receiving connected event before being rejected

Question

nRF Connect SDK Version: 2.0.2 
 Network core image: hci_rpmsg 
 I have an nRF5340 device acting as a peripheral. When I initialize advertising with the BT_LE_ADV_OPT_FILTER_CONN flag set and a single address in the filter accept list, a second nRF5340 device acting as a central, but NOT in the filter accept list attempts to connect to the peripheral and receives a "connected" event with no error set. I would expect the connection to be rejected and either no "connected" event to be received, or an error code to be returned. 
 Is this expected behavior? Is there some way to reliably detect a rejected connection?

Einar Thorsrud · Accepted Answer

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.

Emil Lenngren · Answer

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.

Devices not in whitelist receiving connected event before being rejected

Top Replies