7 Replies Latest reply on Jul 15, 2014 1:33 PM by userc_3711

    Un-pairing / un-bonding from a BLE sensor device

      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?

        • 1. Re: Un-pairing / un-bonding from a BLE sensor device
          VictorZ_46

          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.

          1 of 1 people found this helpful
          • 2. Re: Un-pairing / un-bonding from a BLE sensor device

            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”

            • 3. Re: Un-pairing / un-bonding from a BLE sensor device
              VictorZ_46

              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.

              • 4. Re: Un-pairing / un-bonding from a BLE sensor device

                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

                • 5. Re: Un-pairing / un-bonding from a BLE sensor device
                  VictorZ_46

                  That is absolutely correct.  Please let me know if there is an outstanding question.

                  • 6. Re: Un-pairing / un-bonding from a BLE sensor device

                    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

                    • 7. Re: Un-pairing / un-bonding from a BLE sensor device

                      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.