• State Verified Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 76 subscribers
  • Views 931 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 303897
Options

Devices not in whitelist receiving connected event before being rejected

rberekson

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?

Parents
  • 0

    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.

Reply
  • 0

    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.

Children
No Data
Related
Terms of service