• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 4 replies
  • Subscribers 74 subscribers
  • Views 1618 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 201726
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST after terminating connection

swlnk

I have encountered a scenario in which my application is terminating the BLE connection via a call to sd_ble_gap_disconnect, while around the same time I receive a write request from a peer device. This write request is for a characteristic that has authorization permissions set, so a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST is sent from the Soft Device; however this event comes before I receive a BLE_GAP_EVT_DISCONNECTED event (that I would expect once the connection termination has completed). When I call sd_ble_gatts_rw_authorize_reply to respond to the request (immediately after receiving it), I receive a NRF_ERROR_INVALID_STATE error. According to the API reference, this error message should only occur for "Invalid Connection State or no authorization request pending." In my case, the authorization request was definitely pending, so I can only assume that the Soft Device is returning the error because the BLE connection has been terminated.

My questions here are:

1. Is this situation possible? It would expect the Soft Device to have sent the BLE_GAP_EVT_DISCONNECTED to me first if the connection was terminated. Or is this some kind of race condition that can happen based on the timing of the call to sd_ble_gap_disconnect and the write request. Note that I am using a Bluetooth sniffer and also have some logging capabilities within my application, so I'm pretty sure that my analysis is correct.

2. Assuming that this situation is possible and my analysis, how should I handle this situation? My thought was this: in my application I can maintain a global state flag of the connected status that I set to FALSE as soon as I call sd_ble_gap_disconnect (as well as anytime a BLE_GAP_EVT_DISCONNECTED event occurs). When I receive the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST and if this flag is set to FALSE then I can then simply ignore the event and not call sd_ble_gatts_rw_authorize_reply. Will any problems be caused by me not calling sd_ble_gatts_rw_authorize_reply?

Thanks!

  • FormerMember
    0 FormerMember

    Yes, the situation you describe is possible.  (But I would expect it to be something that doesn't occur very often.)

    The easiest solution is, as you suggest, to use a flag holding the current connection state, "connected" or "disconnected".

    There should not be any problems by not responding to the write request. The Bluetooth Core Specification v.5.0, Vol. 3, Part F, chapter 3.3.3 (Transaction) says the following about non-completed ATT transactions:

    A transaction not completed within 30 seconds shall time out. Such a transaction shall be considered to have failed and the local higher layers shall be informed of this failure. No more attribute protocol requests, commands, indications or notifications shall be sent to the target device on this ATT Bearer.

    ...

    If the ATT Bearer is disconnected during a transaction, then the transaction shall be considered to be closed, and any values that were being modified on the server will be in an undetermined state, and any queue that was prepared by the client using this ATT Bearer shall be cleared.

  • 0 in reply to FormerMember

    Hi Kristin-

    Thanks for the reply. I just want to clarify the reason for my question about whether it is safe to ignore the BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST and not call sd_ble_gatts_rw_authorize_reply; I'm aware of the core specification's text related to handing in case of a disconnected ATT bearer; my question is more specific to the Nordic soft device. Since I don't have the source code for the soft device I wasn't sure if there is some kind of state machine that is used for handling authorization requests. Even though the spec allows for not replying to the request, I didn't know for sure if the soft device requires this response to function properly. Based on your response it seems like it's safe to do so I'll go ahead and implement it as suggested.

    Thanks!

  • FormerMember
    +1 FormerMember in reply to swlnk

    Yes, the softdevice should follow the spec, and it should be safe to not reply to the write request.

    (Instead of having a flag holding the connection state, it is also an option to just handle the error code NRF_ERROR_INVALID_STATE in a separate manner after calling sd_ble_gatts_rw_authorize_reply(). )

Related
Terms of service