This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Pairing always fail with nRF52/Raspberry Pi 4/Win10 and an Omron BPM.

Hello! I will try to make this as simple as possible with the details regarding this issue

What I have

  • nRF52840 DK (pca10056) (As BLE sniffer)
  • nRF52 (pca10040) (Used in the nRF Connect win10 application)
  • Raspberry Pi 4 
  • OMRON BP7350 BPM
  • Hope (just kidding)

One thing to have in mind

Whenever I test this with my phone in the nRF Connect for mobile or in the native OMRON Connect US application this process works perfectly, I am able to connect, pair and read blood pressure data from the sensor.

Description

I am working with an OMRON BP7350 BPM Sensor trying to read blood pressure data from it and I have problems with pairing process using the nRF Connect v3.6.0 - Bluetooth Low Energy application, but basically in order to get data from the BPM is required to connect to it and pair to be able to access to their blood pressure service/characteristics. At this point I have tested a lot of different use cases without success. 

My main purpose is to get it to work in the Raspberry Pi 4 but this issue happens also in the nRF52 (PCA10040) and nRF52840 (PCA10056) (I tried backwards) so I think that this might lead me to solve the issue in the raspberry pi (perhaps?). 

In the Pi I have bluez v5.50, in the nRF BLE application tool the version is v2.4.2.

And whenever I tried pairing in the Pi 4 or in the nRF52 board BLE application I have this:

> ACL Data RX: Handle 64 flags 0x02 dlen 6                                                         #20 [hci0] 26.420475
      SMP: Pairing Failed (0x05) len 1
        Reason: Unspecified reason (0x08)


This also happens with another devices like in WIN10 with virtual machines with Debian with bluez, Fedora linux OS, all of them testing with bluetoothctl
which is the same tool that I use in the Pi 4.


What I have tried

For debugging I used the nRF Connect for Mobile application and there I am able to bond/pair to the device successfully with my android and do whatever I want, I am also able to sniff this communication process using wireshark and nRF52 board that I have.

First the request from nRF Connect in my android device to "bond"

 

And here is the response from BPM

BUT when I do the pairing process with my raspberry pi 4 (And the nRF52) the connection fails with an "Unspecified Reason"

The Response from the BPM

I used sudo btmon to monitor the behavior inside the Raspberry Pi

> ACL Data RX: Handle 64 flags 0x02 dlen 6                                                         #17 [hci0] 26.323537
      SMP: Security Request (0x0b) len 1
        Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
< ACL Data TX: Handle 64 flags 0x00 dlen 11                                                        #18 [hci0] 26.323661
      SMP: Pairing Request (0x01) len 6
        IO capability: NoInputNoOutput (0x03)
        OOB data: Authentication data not present (0x00)
        Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
        Max encryption key size: 16
        Initiator key distribution: EncKey Sign (0x05)
        Responder key distribution: EncKey IdKey Sign (0x07)
> HCI Event: Number of Completed Packets (0x13) plen 5                                             #19 [hci0] 26.371976
        Num handles: 1
        Handle: 64
        Count: 2
> ACL Data RX: Handle 64 flags 0x02 dlen 6                                                         #20 [hci0] 26.420475
      SMP: Pairing Failed (0x05) len 1
        Reason: Unspecified reason (0x08)

I also tested to pair with the GUI tool and gatttool, no success.

-----------------------------------------------------------------------------------------------

And of course, this is the response from the nRF BLE application everytime I tried to pair: 

Authentication failed with status BLE_GAP_SEC_STATUS_UNSPECIFIED

I also tried to reproduce the same requirements as the android appears to share with the BPM in terms of: 

- IO Capability: Keyboard, Display (0x04)

- AuthReq: 0x05, MITM Flag, Boding Flags: Bonding 

This with always a pairing failed response... 

Conclusion

So I honestly would like to know what do you think I might need to do to be able to pair successfully the raspberry pi with this BPM device. Do you know what exactly means the "Unspecified reason (0x08)" or what is required to change when you have a Pairing Failed (0x05) in the SMP?

I honestly do not understand how the Initiator Key(s) / Responder Key(s) works and how are able to be changed in order to make work this communication process as I need in the nRF52 with the BLE application, is this something more "device specific"? 

From my point of view, there is something in the security layer that is not ending to be completed to achieve a completed pairing process... But I don't know what is it yet

Any suggestion will be helpful on issue. Thank you for your time.

  

  • Hi Fabian, 
    If you look at the trace between the RPI and the BPM you can find that the Secure Connection Flag is set to True (as well as the CT2 bit in the reserved flags) when it's false in the trace with the phone. 

    The response from the BPM also showed that Secure Connection is not supported. 
    Usually if it doesn't support Secure Connection and send such response, the central device will not use Secure Connection pairing and it should be fine. But I guess in this case the BPM doesn't understand what the flag is and just refuse the bonding process. 

    Please try to capture a sniffer trace with the NRF52 with Secure Connection turn off (SEC_PARAM_LESC = 0). 

  • Hi Hung, 

    Thank you for such a great response, is definitely something different from what people have said to me before. 

    However, I capture the trace with the nRF52 (PCA10040) and the BPM with the following setup:
    - Secure Connection turned off
    - CT2 bit flag turned off
    - Enabling/disabling the MITM Flag 

    With no progress Disappointed

    This test was developed with the inbuilt software that comes when you select an nRF52 device in the Bluetooth Low Energy Application in the nRF Connect v3.6.0

    Another thing is that the error looks like its happenning in the SMP Protocol according to the sniffer trace. 

    Response from the BPM 

    Following the same logic as you did, is it possible that is might be required to enable the IRK initiator/responder type key? Because it seems that the BPM supports it and is part of the request and response between devices (Android - BPM). 

    ANOTHER HINT THAT I FOUND TODAY:

    I have another android device, an Amazon Fire HD 10 where I installed the nRF Connect for Mobile app and before anything else I tried to pair with the BPM. the Response was failed, then I decided to try with the native Omron Application to pair with the device, this pair process was successful, then I deleted the bond information from the nRF android app and tried again and this time the pairing process was a success... Weird right? 

    Here is the request and response from the Amazon Fire HD 10 android device:

    response here

    I will keep in touch with you to get more help, thank you!! 

  • Please send us the full sniffer trace when you use the Omron Application app to pair. There could be a special command that Omron designed for their own device to accept pairing or not. (and the sniffer trace when you use the nRF52 DK)
    You can also test with bonding with IRK in the Initiator Key Distribution using sd_ble_gap_privacy_set() and sd_ble_gap_device_identities_set().

  • Hi and sorry for my lack of response. 

    I have some news, I realized that I was reproducing my scenario as it was no suppossed to be done. 

    Now I am able to pair the nRF52 board and the Pi to my BPM, I still have problems to retrieve data from the BPM to the Raspberry Pi.  

    With the nRF52 it was very easy to do after the pairing process was done. I am sharing you both wireshark files if you want to take alook 

    nRF52 - BPM.pcapngRpi-BPM.pcapng

    In the Pi I have an error everytime I write to the correspondent handle to retrieve data from the BPM. 

    The test command: 

    [28:FF:B2:8A:DF:2F][LE]> connect 28:FF:B2:8A:DF:2F
    Attempting to connect to 28:FF:B2:8A:DF:2F
    Connection successful
    [28:FF:B2:8A:DF:2F][LE]> char-desc 0x0810 0x0820
    handle: 0x0810, uuid: 00002803-0000-1000-8000-00805f9b34fb
    handle: 0x0811, uuid: 00002a35-0000-1000-8000-00805f9b34fb
    handle: 0x0812, uuid: 00002902-0000-1000-8000-00805f9b34fb
    handle: 0x0820, uuid: 00002803-0000-1000-8000-00805f9b34fb
    [28:FF:B2:8A:DF:2F][LE]> char-write-req 0x0812 0200
    Characteristic value was written successfully
    [28:FF:B2:8A:DF:2F][LE]>
    (gatttool:11667): GLib-WARNING **: 15:03:18.681: Invalid file descriptor.

    And the response using btmon tool 

    < ACL Data TX: Handle 64 flags 0x00 dlen 9
                                                                           #489 [hci0] 697.495168
          ATT: Write Request (0x12) len 4
            Handle: 0x0812
              Data: 0200
    > ACL Data RX: Handle 64 flags 0x02 dlen 5
                                                                           #490 [hci0] 697.556732
          ATT: Write Response (0x13) len 0
    > ACL Data RX: Handle 64 flags 0x02 dlen 6
                                                                           #491 [hci0] 697.557374
          SMP: Security Request (0x0b) len 1
            Authentication requirement: Bonding, No MITM, Legacy, No Keypresses (0x01)
    < HCI Command: LE Start Encryption (0x08|0x0019) plen 28
                                                                           #492 [hci0] 697.557456
            Handle: 64
            Random number: 0x4a0b5a95a287eb03
            Encrypted diversifier: 0xfe7b
            Long term key: 92a67452d8ae4a615340ea18b743669c
    > HCI Event: Command Status (0x0f) plen 4
                                                                           #493 [hci0] 697.557975
          LE Start Encryption (0x08|0x0019) ncmd 1
            Status: Success (0x00)
    > HCI Event: Encryption Change (0x08) plen 4
                                                                           #494 [hci0] 697.646939
            Status: PIN or Key Missing (0x06)
            Handle: 64
            Encryption: Disabled (0x00)
    < HCI Command: Disconnect (0x01|0x0006) plen 3
                                                                           #495 [hci0] 697.647023
            Handle: 64
            Reason: Authentication Failure (0x05)
    > HCI Event: Command Status (0x0f) plen 4
                                                                           #496 [hci0] 697.647413
          Disconnect (0x01|0x0006) ncmd 1
            Status: Success (0x00)
    > HCI Event: Number of Completed Packets (0x13) plen 5
                                                                           #497 [hci0] 697.677408
            Num handles: 1
            Handle: 64
            Count: 1
    > HCI Event: Disconnect Complete (0x05) plen 4
                                                                           #498 [hci0] 697.677506
            Status: Success (0x00)
            Handle: 64
            Reason: Connection Terminated By Local Host (0x16)
    @ MGMT Event: Device Disconnected (0x000c) plen 8

    So the problem that I want to solve now is to understand why I have an 

    > HCI Event: Encryption Change (0x08) plen 4
    #494 [hci0] 697.646939
    Status: PIN or Key Missing (0x06)
    Handle: 64
    Encryption: Disabled (0x00)

    Please let me know if you are able to provide me more information about what could be the issue on this case.

  • Hi, 

    In the RPI trace you provided, what I can get is that the first connection worked and they paired properly. 
    However, on the second connection the RPI tried to re-encrypt with stored bond but the BPM rejected with "Pin or Key missing". This meant that the bond information on the BPM was missing or it didn't store the bond information. You may want to try erase all bond information on the BPM and test again. 

Related