IOS Disconnects after exactly 33 seconds with NRF Connect not other app, Android no issue

[SRA]

Trying to track down an issue with IOS disconnecting shortly after connection when using NRF Connect, LightBlue doesn't connect at all.

• We have a few GATT chars with 20 bytes and static data, and two with read/write/notify enabled.
  
  
• The iPhone8 does negotiate a large MTU, 30ms interval, and 2Mbps PHY. We see a lot of UNKNOWNS in the wireshark log, but that's to be expected because our UUID is custom.
  
  
• 33 Seconds to disconnect using NRF Connect. LightBlue times out on INTEROGATTING. BLUExplr works great [1]
  
  
• Logs show in the one that disconnects/doesn't work that MASTER READ REQUESTS go unanswered (master twice sequentially in the log) and a response is skipped (see pic) no response skip activity on the working app/log.
  
  
• The logs are synced up to a point where this operation is done: 1097    54.133299    Master_0x50654523    Slave_0x50654523    ATT    35    Sent Find Information Request, Handles: 0x000d..0x000d  then on non-BLExplr apps the slave (nrf52) response is skipped/never comes.
  
  
• NEXT_CONN_PARAMS_UPDATE_DELAY has no effect on 33s timing.
  
  
• There are errors in the both working and non-working logs like: 521    20.799438    Slave_0x50657c17    Master_0x50657c17    ATT    35    Rcvd Error Response - Attribute Not Found, Handle: 0x0015 (Unknown: Unknown: Unknown) [2]

[1] Does anyone what could be causing the differences in logs / 33 second disconnect / slave unanswered master requests?

[2] Should I be concerned about Attribute Not Found errors?

IOS_Disconnect_2Mbps.pcapng

IOS_NoDisconnect_2Mbps_BLExplr.pcapng

[Einar Thorsrud]

Hi,

The Attribute Not Found is because the iPhone (nRF Connect app) attempts to read a handle (in a range) which does not exist. This is not illegal.

[SRA]

Why would phone try and do that though?

I have three errors like this in my log, at least one is associated to a real handle with a CCCD that is defined exactly like another one next to it, that one has no errors during this service discovery. So it sure seems like maybe I'm missing a descriptor or something.

[Einar Thorsrud]

I just discussed with one of the developers of nRF Connect for iOS. nRF Connect will do a service discovery after connection, and try to read all characteristics. This is a choice they made for nRF Connect  which you can always discuss (and Apparently LightBlue does it differently), but there is nothing illegal about it with regard to the BLE specification as far as I can see. The reason it caused problems in the first case in this thread was the incorrect implementation on the nRF side (not handling the BLE_GATTS_EVT_SYS_ATTR_MISSING event).

[SRA]

Ok, that explains nrfConnect. But not why I'm missing an attribute on my handle 15 but not it's identical copy.

It also doesn't explain or excuse that Nordic plays really fast and loose with event handling. SOMETIMES an event is handled in the examples, SOMETIMES it's not. This is pretty unacceptible to me. The firmware should always be ready to handle anything the softdevice comes up with. You just have to hope you based your code on "the right" example.

[Einar Thorsrud]

Unfortunately, I expect that there will always be some bugs with some of the examples. However, we try to fix the issues (big or small) when they are found, and include the fixes in future SDK releases.

Which example in which SDK version have you based your code on?