• State Suggested Answer
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 90 subscribers
  • Views 3078 views
  • Users 0 members are here
Attachments (6) Download All
Nordic Case Info
  • Case ID: 284276
Options

nrf52840-DK Central nRF Connect SDK 1.8 with BT_SECURITY_L4 connection dropped

Paul Clark

Hi,

I am using the nrf52840-DK with the nRF Connect SDK version 1.8.

I have modified the central_multilink sample to connect to a BLE peripheral which requires a secure connection.

I request BT_SECURITY_L4 via a call to bt_conn_set_security(conn, BT_SECURITY_L4) in the 'connected' callback handler.

The trace I have captured in Wireshark suggests that after I have established a connection using a passkey, there is some additional pairing traffic, suggesting that some negotiation (for the secure connection) or similar is occurring, but is not completing...

The initial connection looks similar to a successful attempt (e.g. from an Android phone), but shows limited 'keys', as follows:

A connection from an android phone shows additional 'keys' (and securely connects). I am not clear whether this is the problem, or how I can gain control of this via the nRF Connect SDK

Parents
  • 0

    It may seem from the screenshots that the difference here is the initiator of the security procedures. Typically it is the central that initiate security, and the security level aquired may depend on either the security level supported by the peer and/or the security level required by the chateristics in the peer. It's not possible to read/write to characteristics with higher security level than active at any time. As a side note: If you read the Apple Bluetooth Guidelines you can find that this procedure should be initiated by the central, and not the peripheral.

    My recommendation is that you delay the bt_conn_set_security() from the peripheral, instead only use it as a fallback solution if the central for instance does not initiate it within let's say a few seconds. The central will not be able to use the characterisitcs before this occurs in any case. Let the central first spend time to execute other procedures if it needs to (e.g. feature exchange, length exchance, mtu exchange, database discovery etc, before it will initiate the security procedure).

    Best regards,
    Kenneth

Reply
  • 0

    It may seem from the screenshots that the difference here is the initiator of the security procedures. Typically it is the central that initiate security, and the security level aquired may depend on either the security level supported by the peer and/or the security level required by the chateristics in the peer. It's not possible to read/write to characteristics with higher security level than active at any time. As a side note: If you read the Apple Bluetooth Guidelines you can find that this procedure should be initiated by the central, and not the peripheral.

    My recommendation is that you delay the bt_conn_set_security() from the peripheral, instead only use it as a fallback solution if the central for instance does not initiate it within let's say a few seconds. The central will not be able to use the characterisitcs before this occurs in any case. Let the central first spend time to execute other procedures if it needs to (e.g. feature exchange, length exchance, mtu exchange, database discovery etc, before it will initiate the security procedure).

    Best regards,
    Kenneth

Children
Related
Terms of service