Connection handle does not match for data length request message

[Mohammad Afaneh]

I have a Central + Peripheral running on the nRF52840 (SDK 14.2.0). I have it configured to automatically connect to 3 Peripheral connections and allow 1 Central connection (from a phone). When I start the application, this is what I'm seeing:

- If I connect the phone first (the 3 Peripheral devices are turned OFF), I don't run into any issues

- If I turn on even one of the Peripherals, the nRF52 board will automatically connect to it, but here's where the problem starts: The phone now cannot connect to the nRF52 board.

- When looking at the sniffer trace, it looks like the nRF52 is not responding to the data length update request

- In the log messages on the nRF52 I am seeing that the phone always connects on conn_handle 0x0 for some reason (even if there were other devices connected already. Is this expected?). But then I see that the data length update request is received for a connection handle that does not match the phone connection handle:

 Peripheral: Peripheral connected on connection handle 0x0
 ble_gatt: Peer on connection 0x2 requested a data length of 251 bytes.
 ble_gatt: Updating data length to 27 bytes on connection 0x2.
 ble_gatt: Data length updated to 27 on connection 0x2.

I'm pretty sure the update request is from the phone (I can see it getting sent in the sniffer trace).

Any ideas why this may be happening? and how to fix it?

[MartinBL]

Hi,

1. What happens if you connect with your phone first, and while connected, turn on a peripheral? Does it all work as expected?
2. Do you get any useful log info from the mobile? 
3. If connection handle 0 isn't being used by another link, it is possible that the central repeatedly gets handle 0. I have written a few words about connection handles here: https://devzone.nordicsemi.com/f/nordic-q-a/28143/ble-connection-handle-value-scope/111113#111113
4. Are you saying that the central "hijacks" handle 0 from a peripheral?
5. Can you upload your sniffer trace?
6. Note that SDK 14.2.0 uses an alpha release of the S140. Last week we released SDK 15 along with a production quality S140 version. It could be a good idea to migrate. 

[Mohammad Afaneh]

Hi MartinBL,

Here are my answers:

1- Yes, everything works as expected if the phone gets connected first.

2- I'm using nRF Connect on the phone. I tried LightBlue and its logs don't say anything other than "time out while interrogating the peripheral"

3- I'll read that post shortly

4- No, it always takes connection handle 0. The others never get it, and so nobody gets hijacked.

5- I'll try to upload that soon.

I have the upgrade to SDK 15 in my plans, but is there a workaround at the moment?

[Mohammad Afaneh]

Martin,

1. It says "Status: Connecting" for a while, and then ends up Disconnecting.
2. I will fix my description, it's a typo. The Data length request message is the one that doesn't get responded to and has the connection handle inconsistency issue (see my log messages in the original post). It always behaves the same.
3. The missing packets are all from distant devices that the "NovelBits GW" device is sending Scan Requests to, but they are not of interest. The NovelBits GW device acts as a Central and as a Peripheral. The sniffer is in close proximity to both the phone and the nRF52 dev kit.
4. I've actually studied the Scheduling section numerous times and I've adjusted the connection parameters but the issue still persists.
5. Yes, it is custom firmware, I actually have it available in this GitHub repo: https://github.com/mafaneh/ble-ebook-project and you can try running it to see if you see the same issue. You can run the "Gateway" Project portion of the Solution. The nRF52840 board will boot up and connect to a Thingy:52 automatically, so you can use that to test. The SES solution file is  "Main Project SES files/NovelBits.emProject". It's configured to run on the nRF52840 board.
6. I'm using an iPhone 7 Plus with iOS version 11.2.6. I've tried from an Android phone and it behaves okay, but I do not see the data length request message coming in, so this might explain why it works in this case.

I'll go ahead and update the description of the ticket as well as the content.

-Mohammad

[MartinBL]

Hi,

Sorry for the late reply. I have been out of office for a while. Have you made any progress?

[Mohammad Afaneh]

Hi Martin,

No problem. No, i have not made any progress on this issue. My next step will be to update to SDK v 15, however this will take some time to migrate so if we can figure out a solution/workaround in the meantime that would be great. 

Thanks. 

[MartinBL]

Hi, 

I did some further digging and I think that this is actually a known issue. The S140 v5.0.0-2.alpha release note mentions this: 

"The conn_handle parameter in the event BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST is not populated correctly (DRGN-8749)."

In our internal bug report system there is a more thorough description which basically describes exactly what you are saying. Unfortunately the bug is embedded in the Softdevice with no workaround. However, you can try upgrading to S140 v5.0.0-3.alpha where the bug is supposed to be fixed. Then you can continue to use SDK 14.2.0, although there are some API changes in the Softdevice. 

[Mohammad Afaneh]

Thanks, Martin. I will check it out.