peer_manager_handler: Connection security failed: error: 1

[Yury Morgunov]

Hi all,

My device is working as a HID device. it's working on android and iPad but not work on macOS. It's can't solve the security procedure and returning error:
<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 1

I was trying to connect to macOS 10.13.6 High Sierra using ble_app_hids_keyboard example. But I got the same error.

My device using NRF52810 with s112 and SDK 15.3.0. Ble_app_hids_keyboard project I had run on pca10040 board with s112 and SDK 15.3.0. The only thing which I changed in ble_app_hids_keyboard example is sdk_config.h

#define NRF_LOG_BACKEND_RTT_ENABLED 1

#define NRF_LOG_DEFAULT_LEVEL 4

Can you help me?
Many thanks in advance.

[Einar Thorsrud]

Hi,

I do not have a High Sierra device at hand, but I tested using macOS Catalina and the ble_app_hids_keyboard example from SDK 15.3. Using that I am not able to reproduce the issue, and pairing succeeds as expected. Are you able to reproduce this with Catalina?

[Yury Morgunov]

tested on old macbook air. not connected. Macbook writes it was not possible to create a pair, nothing happens on the device side.

[Einar Thorsrud]

Hi,

This is odd. I am still a bit unsure about how to read the log since it seems corrupted. Can you make sure to test with NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED set to 0, and upload the log again? Also, please attach a sniffer trace from the same test, so that we can see what is happening on air. This is particularly useful here since I find it hard to explain based on the logs and I am unable to reproduce the issue on my side.

[Yury Morgunov]

Yes, I set the flag NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED to 0.
As for nRF Sniffer - I will write packets to Wireshark tomorrow or after tomorrow and forward them to you

[Yury Morgunov]

I'm sorry for the pause.
I scanned BLE packets in Wireshark.
I downloaded an example of a HID keyboard with logs enabled on the PCA10040 board.
Turned on Wireshark and started trying to connect.
In one file, I connected with an error.
In another file, I could not connect. I rebooted macOS and started connecting, but MacOS was constantly reconnecting to the device.

1777.Connected with error.pcapng

5315.several automatic reconnections.pcapng

P.S. I forgot to give the device MAC address - btle.advertising_address == ce:53:10:cd:68:c7

MAC address macOS device - 20:c9:d0:8d:0f:14 (High Sierra)

[Einar Thorsrud]

Hi,

From the sniffer trace (5315.several automatic reconnections.pcapng) it looks like there is a problem with the packet reception. I don't know if it is just a problem with the sniffer, or also the communication between the DK (keyboard) and Mac, but you can see that almost all of the CONNECT_REQ packets has CRC errors. Interestingly there are no problems in the advertisement packets from the keyboard. Are you ablet o make a sniffer trace without this problem? Does this Mac function with other BLE devices? Or are you testing in a very noisy environment?

For your reference, I have uploaded a sniffer trace (ble_app_hids_keyboard_pca10040_s132_merged_catalina.btt) where I tested the ble_app_hids_keyboard_pca10040_s132_merged.hex attached to this case. I am still not able to see any problems.

[Yury Morgunov]

This behavior when the device is constantly reconnecting occurs only after the MAC reboot. After this, I connected several times, there was no CRC error. Yes, we have a fairly noisy place for ble, but I would not say that all channels are busy.
See file 1777. Connected with error.pcapng the device is connected there, but with the error described in the header

The question I have is this:
The problem occurs after connecting. There is a connection, but the problem arises at the security check stage. Devices exchange this information after connecting and the sniffer does not see these packets. Is there any way to see what is happening at this moment?

And in which program to open a * .btt file?

Now I will try to find another ble device and try to connect.

P.S. I figured out the sniffer nRF_Sniffer_UG_v2.2.pdf

Here is the capture file Connected with errorFULL.pcapng

[Einar Thorsrud]

Hi,

Yury Morgunov said:

Is there any way to see what is happening at this moment?

Looking at "Connected with errorFULL.pcapng" everything seems normal to me. the CONNECT_REQ in #479, followed by MTU update, service discovery, bonding. Then many empty packets (as you would expect to keep the connection active). The encrypted (non-empty) packets are not decrypted by the sniffer, which is a bit odd since the sniffer should be able to sniff the key exchange and decrypt the packets (for legacy pairing as is used here, not LESC). That is likely a problem with the sniffer, though.  

Yury Morgunov said:

And in which program to open a * .btt file?

Sorry, I forgot to mention that. You can view the files with the Ellisys SW. You need to register to download the SW, but it is free to use.

As you can see from my Ellisys trace, it looks very much like yours, except that the sniffer was able to decrypt the encrypted packets. This trace shows the whole process from connecting and pairing to some button presses.

[Yury Morgunov]

Hi!,

I noticed that from one of the devices with macOS (Catalina) when connecting to the device, no packets are visible at all in Wireshark. macOS writes connecting and there are no packages in Wireshark. There is no connection either.
On mac mini (High Sierra) on which I am testing everything, I connected an old version of our device with nrf51 and sdk12 (not sure), which is being developed in VisualStudio. HID worked perfectly on it.
Therefore, I am testing the connection on it.

As it turned out, the device connects to windows without problems. I checked on my laptop and from work. The first time, probably, the driver failed.

Unfortunately, I still have not received a response from Ellisys. Accordingly, I could not read your logs.
Therefore, I compared the record with the connection to the ipad.
8750.connect_to_mac_mini.pcapng
3652.connect_to_ipad.pcapng

It can be seen that after initiating the exchange of IRK and LTK keys (ipad - packet number 4099) (mac mini - packet number 18854). Received packages are very different.
As I understand it, after the key exchange, the process of reading the reading of the characteristics from the peripheral device begins.
Apparently for some reason, mac mini cannot read them. Probably due to some kind of security error.
Why this happens, I don’t understand at all.

[Einar Thorsrud]

Hi,

Comparing the two sniffer traces the second connection in 8750.connect_to_mac_mini.pcapng is quite similar to 3652.connect_to_ipad.pcapng. There is a difference when pairing is done compared to completing service discovery, but that should not matter. I have also tested this on an old Mac mini with High Sierra, and I am still not able to reproduce the issue. It is strange that the sniffer traces look sensible and that I am not able to reproduce it.