- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
When a device, such as an iPhone “un-pairs” itself from a BLE sensor does that get propagated to the BLE sensor as well?
Is there a callback that is triggered?
I know in the case of Encryption changing or Bonding itself that there is a callback triggered but does the un-pairing also get handled there as well?
If two devices are bonded to each other and iPhone "un-bonds" itself by forgetting the device does the BLE sensor side still think it is bonded?
Solved! Go to Solution.
- Labels:
-
SDK 2.X
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is currently no standard way to indicate to the peer, that you are planning to unbond (your application can do it if you are on both sides). The main reason here is that there is no guarantee that device is connected at the time pairing information is deleted.
Please note that your device should not automatically assume that peer dropped bonding and enter pairing state when encryption attempt fails. It should be some user action (button push?). That is one of the well known security attacks. Intruder simulates Bluetooth device address of your iPhone and attempts to connect to your device. Intruder does not know the encryption key, so the encryption will fail. If your device automatically drops previous bonding and pairs to the intruder, the first problem is that intruder uses your device which might not be good, the second problem is that when your iPhone shows up it cannot connect to the device because bonding information is lost.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There is currently no standard way to indicate to the peer, that you are planning to unbond (your application can do it if you are on both sides). The main reason here is that there is no guarantee that device is connected at the time pairing information is deleted.
Please note that your device should not automatically assume that peer dropped bonding and enter pairing state when encryption attempt fails. It should be some user action (button push?). That is one of the well known security attacks. Intruder simulates Bluetooth device address of your iPhone and attempts to connect to your device. Intruder does not know the encryption key, so the encryption will fail. If your device automatically drops previous bonding and pairs to the intruder, the first problem is that intruder uses your device which might not be good, the second problem is that when your iPhone shows up it cannot connect to the device because bonding information is lost.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
However, if one does register with the ConnDown hanlder then it is possible to call the emconinfo_getDiscReason
And determine what the reason for disconnection was … for example, disconnect return of 13 means “Remote user terminated connection”
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, and that would mean that peer disconnected. Nothing else. There is currently no way on the stack level to tell peer that bond is being removed. If you own application on the other side you can introduce such a method. But you will need to deal with scenarios when bond is removed while connection was down.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If peer disconnects or un-pairs itself it will need to re-establish the bonding after it re-connects
So it can be connected but not bonded
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
That is absolutely correct. Please let me know if there is an outstanding question.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes one outstanding concern I have is this …
I am seeing some sporadic behavior with these two functions and I just wanted to make sure I understand their usage.
emconninfo_linkEncrypted & emconninfo_deviceBonded
Does emconninfo_deviceBonded simply mean the peer device was previously “bonded” but not necessarily currently connected & paired (ie, bonded) ?
Does emconninfo_linkEncrypted simply mean the peer is currently connected & paired (ie, bonded) ?
I am not using the Just Works association , I am using the Pass Key PIN entry
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is the answer per AS
emconninfo_linkEncrypted() – this will return TRUE if the link is currently encrypted or not. When true, the connection exists (because it cannot be encrypted without being connected). Also, when true, the peer device must also be paired because unless the two devices are paired encryption is not possible because the pairing processes establishes the encryption keys.
emconninfo_deviceBonded() – this will return TRUE if we are paired with the peer device to which we are connected. This is a prerequisite for the link to be encrypted, though one could be paired, but the connection not encrypted.