Peer removed pairing information - when using both Classic BT and BLE to communicate with same peripheral

Question

Created Sep ’20

Replies 1

Boosts 1

Views 1.7k

Participants 2

Hello,

Our IOS application communicates with some device (Intel NUC) over BLE, writing to some characteristics. We use encrypted characteristics which enforce system pairing at the moment we write to characteristic for the first time.

Another piece of software on the same device is using classic BT to synchronize contacts (Phone Book Access Profile) and stream music from Iphone to Intel NUC. This also requires system pairing.

Once we are paired both for BLE and classic BT profiles (two separate pairing processes) everything works fine. The problem arise when we disconnect from the peripheral either manually from system BT settings. It should not be a problem as we are paired for BLE communication so we should be able to connect with device that is currently disconnected. However, when trying to connect over BLE then we get the error:

Domain=CBATTErrorDomain Code=14 "Peer removed pairing information" UserInfo={NSLocalizedDescription=Peer removed pairing information}

Once we manually connect in system BT settings everything stars working again.

We tried using
CBConnectPeripheralOptionEnableTransportBridgingKey flag passed to CBCentralManager.connect() method, but it's getting even worse. There are problems in system pairing for classic BT profiles and even if we manage to do it somehow, connecting over BLE time outs.

Any idea what might the reason of the problem?

Boost

Answer 1

chrisco OP

Jun ’21

<edit: there also seems to be a bug in this form, it's eating my spacing and punctuation>

Have you had any insight on this? I too, have been struggling with this, but in my case, I would just see a silent failure (non response) from subsequent calls to connect, with the only way to recover being to power-cycle the bluetooth radio in the Settings app (not disabling in control center, but actually powering off BT in Settings).

This would seem to randomly come up with normal app usage - perhaps related to disconnection when releasing CoreBluetooth resources when backgrounding, with the result being that you would get stuck in a cycle where normal connection flows:

restorable CBPeripherhal instances,peripheral records retrieved via a stored UUID,baseline flow of scan + connect.

These flows would all silently fail, when attempting connection, there would be no response from a connection attempt in didConnect, didFail, disconnect, etc.

The only stable connection flow that we found was to only attempt connection to devices that were already reported as connected by the system. This forced the awkward flow of having to force the user to first connect in the Settings app.

I know that I'm not crazy though, as I have used other BLE-only apps that forced the flow through Settings, even though there was no audio / classic function to the device.

0