2

I am working on a simple Bluetooth GATT server running on a Raspberry Pi 3 model B. As a start I have used the example code of advertiser and gatt server. These examples are part of Bluez library. In order wrap everything I use example uart code from here.

My problem is that I can connect to Raspberry without any problem, but when I disconnect no actual disconnection happens. I have no any indication of disconnection not in btmon nor in dbus-monitor.

This behavior happens only on iOS (14.2) in Android (11, 8.1) everything works as expected.

There is issue on github here with almost the same problem with python-bluezero (They use dbus under the hood). I have tried suggested solutions but non of them helps.

I have seen the same question before, but this question didn't got any answers. I hope that I will be more lucky...

ArMouReR
  • 33
  • 7
  • So you're saying that the disconnection is working on iOS but not on Android? Are you disconnecting from the iOS app or from the Raspberry Pi? Which apps are you using on Android and iOS? And what version of BlueZ are you using on the Raspberry Pi? – Youssif Saeed Dec 20 '20 at 07:41
  • Exactly the opposite: Android works without issues and iOS do not works. I use Nordic nRF connect App, but in our proprietary app I see the same. I switched to nRF App in order to remove our App from the equation. I disconnect from iOS app and I use Bluez 5.50 – ArMouReR Dec 21 '20 at 13:02
  • Fair enough, it is good that you are removing the app from the equation. Unfortunately I cannot think of a quick way to debug further without a Bluetooth sniffer. If you have one available, you can at least see if the disconnection packet is being sent over the air. – Youssif Saeed Dec 21 '20 at 15:03
  • For now, can you try the following two things:- 1) What happens if you switch off Bluetooth or switch off the iOS device entirely? Do you see a disconnection happening on BlueZ? 2) Can you try running BlueZ through bluetoothctl and see if the behaviour is different? You can see this link for more info:- https://stackoverflow.com/questions/65299644/failed-to-encrypt-the-connection-with-bluez-peripheral-and-ios – Youssif Saeed Dec 21 '20 at 15:04
  • You could try running `sudo btmon` in a different terminal to see what that is reporting on the RPi when the disconnect is sent – ukBaz Dec 21 '20 at 15:24
  • @ukBaz I am trying to work around the problem, Is any easy way to disconnect iOS App from raspberry (I am in peripheral mode) using some dbus command ? – ArMouReR Jan 13 '21 at 19:41

1 Answers1

0

Yes, that behavior is expected per iOS API documentation too and unfortunately there is no good way to make sure that iOS connection gets terminated at physical link layer such that on peripheral side we can notice that central device got disconnected. Because iOS keeps Bluetooth connection in the background to provide smooth experience to the user with the intention that iOS app is going to be used to communicate with the peripheral device over Bluetooth so when app is being re-used/re-open then it won't need to go through full connection process. Though not all use cases are like that, and I really hope iOS team see through other use cases where we need Bluetooth connections to be freed up for other central devices because peripheral has limitations on supporting certain number of connections and so it doesn't make much sense keeping an idle connection in the background. Because simply, central devices should have control over which Bluetooth connections to keep and for how long while that's being taken away when it comes to iOS application while Android allows control over such process.

In the iOS case, an explicit way to terminate even background Bluetooth connection is by turning off Bluetooth by going into system settings screen at least for the time equivalent to supervision timeout. Though probably that's not something you're looking for as an answer.

Dhruv Kakadiya
  • 49
  • 3