bt_gatt_notify_uuid() returns ENOTCONN when device connected

[nategreco]

I'm struggling to diagnose an intermittent problem I am seeing with my application. Occasionally, it will enter a state where all 3 of my characteristic notifications (1, 2, 3) will return `-128` ( ENOTCONN ) when connected. This happens after an unexpected disconnect, then all subsequent re-connections will succeed (as far as I know), but then notifications will return ENOTCONN.

I've noticed some patterns that might be clues as to where I should look:
* Only happens when this characteristic is written to (likely this is when first disconnect occurs)

* Happens Frequently when connected to an Android 12 device w/ BLE 5.1, but never to my Android 14 BLE 5.3 smartphone

I realize this question likely doesn't have enough information to diagnose the issue unless there is something grossly misconfigured with the related gatt service or BLE advertisement, so if you could guide me on what I should be looking for, maybe what logging to enable, that would be a great start.

This is a nRF52840 board w/ nRF Connect - SDK 2.3.0. I have not yet made the jump to 2.5.0-rc1, if there was reason to do so I would take that path.

[Amanda Hsieh]

Hi,

Happens Frequently when connected to an Android 12 device w/ BLE 5.1, but never to my Android 14 BLE 5.3 smartphone

Please use nRFSniffer to capture the log with these two smartphones and provide the log to help us know what happened in the air. 

Regards,
Amanda H.

[nategreco]

Hello Amanda,

Sorry for the delay - I'm using nRFSniffer for the first time.  I have attached two files obtained with extcapt:

1. uBikeFTMS-Disconnect-then-no-notifications.pcap
2. uBikeFTMS-good-connect-and-disconnect.pcap

Also, the two MAC addresses of interest:

1. Nordic nRF52 device -  D8:80:E7:6F:45:DF
2. Android 12 Tablet w/ BLE 5.1 - 04:34:F6:23:63:58

For file #1 - There were no issues. The tablet connected to the nRF52 device without issue and read/wrote the appropriate characteristics.

For file #2 - The device immediately connected, and then disconnected.  Once it was re-connected all the notifications failed with - ENOTCONN, despite the connected callback (registered with BT_CONN_CB_DEFINE) indicating that a device was connected. Several attempts to re-connect were made, all with notifications for the relevant characteristics failing.

Really I have two issues:

1. Initial disconnect/failure
2. Subsequent reconnections cannot notify any characteristics

---

One concern I do have in my application is I am using lvgl and the call to lv_task_handler() is quite resource intensive, but I do nothing to prevent bluetooth write characteristics from interrupting that routine.  Is there a best practice for preventing bluetooth interrupts (particularly write characteristic callbacks) from interrupting other routines?

[Amanda Hsieh]

Hi, 

nategreco said:

• uBikeFTMS-Disconnect-then-no-notifications.pcap
• uBikeFTMS-good-connect-and-disconnect.pcap

From these two sniff logs, I don't see CONNECT_IND sent from Android 12 Tablet w/ BLE 5.1 - 04:34:F6:23:63:58. 

What is the brand of the Android 12 Tablet?

nategreco said:

Really I have two issues:

1. Initial disconnect/failure
2. Subsequent reconnections cannot notify any characteristics

Does these two issue both happen to Android 14 BLE 5.3 smartphone?

Because you said "* Happens Frequently when connected to an Android 12 device w/ BLE 5.1, but never to my Android 14 BLE 5.3 smartphone", seems the the issue is relevant to the Android 12 Tablet. Therefore, I would like to see the sniffer logs regarding the same operation on these two devices to compare the behavior.  

Regards,
Amanda H.

[nategreco]

Hello Amanda,

Sorry for the delayed response but I wanted to do more testing so I better understood the issue.

First, apologies that the previous captures weren't correct. I used the nrf_sniffer_ble.bat script instead of the Wireshark integration.  I've now switched to Wireshark extcap and can clearly see the CONNECT_IND frame.

Second - I was wrong about the Android 14 device not having issues. The problem seems to come and go and I must have had a streak of good luck with that device.  After testing today I found that it also fails on my Android 14 device.

The devices:

• D8:80:E7:6F:45:DF - nRF52 based device
• 04:34:F6:23:63:58 - Android 12 Tablet
• 24:95:2f:d4:69:d2 - Android 14 Smartphone

The captures:

• `connectedOK-android-12-1.pcapng`
  • This is a good/healthy example
  • `CONNECT_IND` at t=23.026037
  • Devices remain connected while successfully sending notifications and receiving characteristic writes until t=66.5, at which point the connection is terminated gracefully
  •  04:34:F6:23:63:58
• `badConnect-android-12-3-retries.pcapng`
  • This is failure case I described in the original post - Initial connection fails, then subsequent connections succeed however my device fails to notify on its characteristics, instead the function bt_gatt_notify_uuid() returns ENOTCONN
  • Sequence
    • `CONNECT_IND` at t=0.765119
      • Just a loan frame where seemingly no response comes afterward
      • The app running on the Android 12 laptop indicates connection, but I don't see evidence that it really occurred
    • `CONNECT_IND` at t=39.792048
      • Connection succeeds, but my device takes 5 seconds to reply to LL_FEATURE_REQ
      • Connected for 15 seconds but all my notifications fail with ENOTCONN
    • `CONNECT_IND` at t=74.767483
      • My app never replies to the first LL_FEATURE_REQ
      • Again connected for 20 seconds but all notifications fail with ENOTCONN
    • `CONNECT_IND` at t=97.527738
      • This looks like a legitimately good connection but for some reason, notifications continue to fail with ENOTCONN
• `badConnect-android-14-1/2/3.pcapng`
  • These all look like the 1st example above

There is one specific thing I would like to point out for all failures - I expose a writeable characteristic (0x2AD - FTMS control point) and anytime the Android devices attempt to write to this characteristic I see a "Pairing Request" on the Android device.  When I have a connection failure the "Pairing Request" does not appear.

Questions:

• What triggers the 'Pairing request' requirement for a given characteristic? I know that is an Android feature, not part of Nordic SDK, but I suspect something I am doing about how that characteristic is advertised requires that confirmation.
  • Specifically, this seems closely related to the failures and I wonder if this pairing confirmation wasn't required if there wouldn't be an issue.
• How am I getting into a state where it appears connected but notifications fail?

Some of these cases are clearly failures to connect while others are successful connections that cannot trigger notifications.  I suspect something about the 'pairing request' handshake is leaving the device(s) (both nRF52 and Android app) in a bad state.  Possibly if I don't acknowledge the pair request in time connection fails un-gracefully and that's why it appears connected but notifications fail?

I am making some progress and will continue further testing, but if you have any insight from looking at those captures it would be appreciated. Thank you!connectedOK-android-12-1.pcapngbadConnect-android-12-3-retries.pcapngbadConnect-android-14-1.pcapngbadConnect-android-14-2.pcapngbadConnect-android-14-3.pcapng