iOS 13.4 beta 4 bluetooth disconnects

I'm using iOS 13.4 beta 4 because we got some reports from users who are unable to connect to our devices. I think this is only an issue with beta 4.


Some background info:

Peripheral is an ESP32 with Bluedroid BLE stack

Central is an iPhone XR with iOS 13.4 beta 4


From what I can tell, after a connection event, our app reads the device info service (uuid:0x180A)


CoreBluetooth returns an array of a single characteristic, the serial number string characteristic (uuid:0x2A25). We try to read this characteristic, however, CoreBluetooth also attempts to read the device manufacturer name characteristic (uuid:0x2A29), even though this does not happen on iOS 13.3.1, nor do we attempt to read this value in our code. In iOS 13.3.1, we can read characteristic 0x2A29 without issue.


It looks like the connection times out due to the lack of response to the read of manufacturer name, and CB automatically disconnects.


This behavior is reproducible in nRF Connect, running against the exact same firmware and device (although it works with iOS 13.3.1)



iOS 13.4

  1. Central (phone) connects to peripheral (ESP32) with 72s timeout setting
  2. Central discovers Device Information service
    1. Central issues a read for Serial Number characteristic
    2. Central issues a read for Manufacturer Name characteristic Note: this is not issued by the application
  3. Central subscribes for notifications to Custom Serial Service characteristic
  4. Peripheral replies to Serial Number characteristic
  5. Peripheral does not reply to Manufacturer Name characteristic
  6. Due to no reply to previously issued read (for Mfg Name), Central times out the connection and issues a disconnect

iOS 13.3.1

  1. Central (phone) connects to peripheral (ESP32) with 72s timeout setting
  2. Central discovers Device Information service
  3. Central issues a read for Serial Number characteristic
  4. Central subscribes for notifications to BAF Service characteristic
  5. Peripheral replies to Serial Number characteristic
  6. Any user initiated reads properly respond, even for other characteristics in the Device Info service.


The key difference in behavior is that it seems like CoreBluetooth is automatically issuing a read for the Manufacturer Name characteristic, even though this has not been requested. Does anyone have any experience with similar disconnects?


Replies

We have the same issue on iOS 13.4 both — beta & public release. Reproduced with esp32 hardware. Connection with external device is being lost just after establishing.

Can confirm I’m having the same issue with iOS 13.4 final release. Bluetooth speakers won’t maintain a connection more than a few seconds. I’ve reset all devices, rebooted the iPhone, turned Bluetooth off and on, etc. Results are the same. I can confirm that on previous iOS it still works fine. But if I upgrade a device to 13.4 it drops off.

I have seen this issue with a device as well. In my case, iOS13.4 now seems to be issuing ATT read_by_type requests (at least for manufacturer name, serial number string, an firmware revision string -- all DeviceInfo stuff), which unfortunately our FW wasn't coded to respond to. Since the FW never sent a response, the comms were blocked (only a single outstanding request is allowed) and 30s later, as expected, the phone closed the connection (LL_TERMINATE_IND). Once the FW was implemented to handle the request, all was good. However, since these messages are triggered by the OS during discovery, it's outside of the app's control. Therefore it could be pretty tricky to actually update the FW if the app can't even connect! I don't think the OS is violating BT spec (from what I can tell), but it's clear that these little changes can have a pretty big impact. It's important to test with the beta versions of iOS to get out ahead of these things, I suppose.


Anyways, hope this helps someone.

Same happens with the iOS 13.4.5 beta version released couple days ago.


Hope this will be fixed soon due to the huge impact to BLE companion applications. Some words from Apple's would be much appreciated.

Great documentation of the observed behavior! We are seeing the same issue and believe it is due to not utilizing the 2A25 characteristic, so likely any unpopultated Device Information Service characteristics will cause the central to disconnect. Has anyone developed a non-Apple workaround?


The unfortunate problem is that even if your device can utilize OTA to update firmware in the field, without a Bluetooth connection, that cannot remedy the problem.


Thanks!

We do have a device that have the same disconnection behavior.


But more over, the iOS BLE behavior is now the same as Mac OSX (Catalyst) behavior.


Our device have all the basic device info like (serial number / manufaturer name / harware revision / firmware revision, etc ...) and we have disconnection after around 20 seconds after connection.

With the latest iOS 13.4 and Android 10, users are no longer able to connect to my device via BLE. I am using Bluedroid BLE stack on ESP32.


Thanks to this forum thread, I narrowed down the problem to the "Device Info" service. To test I just disabled the "Device Info" service entirely on my ESP32 firmware and now my problem is gone. But of course now my App can't query the firmware version etc from my device.


The problem doesn't appear to be that I'm lacking some characteristics in the "Device Information Service", since I tried adding all of them and it still doesn't work on iOS 13.4 and Android 10.

Also I looked at several other BLE devices that were nearby and it seems that none of them implement all of the characteristics.


And the BLE spec for the DIS states:


> The Device Information Service may expose one or more of the

> characteristics shown in Table 3.1. It is possible that none of the

> characteristics below are included. Unless otherwise specified, only

> one instance of each characteristic shall be present.


https://www.bluetooth.org/docman/handle ... _id=244369


I also tried removing all of the characteristics except for "Manufacturer Name" (0x2A29) and "Serial Number" (0x2A25), but same results.


So, the only way to get this to work for now is to remove the DIS service completely.


How is this not a big deal? Doesn't this affect countless BLE devices already deployed? What if I had a medical device that I relied on and am no longer able to connect to after a iOS/Android software update?


Hello moderators,

How long does it take to post to this forum? My post has been "Currently being moderated." since Friday, now Monday.

Hello,


With the latest iOS 13.4.5 beta 3 BLE doesn't disconnect after 20 secondes by itself. Problem seems fixed.


Thank you moderators for your answers and support.

I have the name issue in here even though with 13.7 os version.