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,

I have tested several Mac's and MacOS versions now, and I am not able to reproduce this. This is basically an unmodified SDK example, just with the additional logging you have added. Do you still get problems using this hex (ble_app_hids_keyboard_pca10040_s132_merged.hex - include both app and SoftDevice)?

It is a bit difficult to read your RTT logs and some things seem missing, which may be because you probably have NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED set to 1 in the sdk_config.h. Please set this to 0.

The only problem I am able to reproduce is a few expected problems. When deleting the bonding information on the Mac but not on the nRF, I get this:

<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 133

And when deleting the donging information on the nRF only, I get this:

<info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Encryption, error: 4102

[Yury Morgunov]

I will describe each step that I take:
1) I connect the PCA10040 1.2.4 board to the PC
2) I launch j-flash Lite V6.60 and select nRF52832_xxAA
3) Erase chip
4) Download to Board - s132_nrf52_6.1.1_softdevice.hex
5) Upload to Board - ble_app_hids_keyboard_pca10040_s132_merged.hex (what you sent me)
6) LED1 started flashing
7) I go to the iMAC version of Catalina I do not see in the list of bluetooth devices.
8) When I started looking for the device on the android, LED1 stopped flashing. Restarted the PCA10040.
9) I saw Nordic_Keyboard on the android, after half a minute I went to iMAC. The device is not visible, but LED1 is still blinking. Androyd still sees Nordic_Keyboard.
10) Restarted the device and immediately started searching on the iMAC. The Nordic_Keyboard device has appeared. But the connection does not occur.
11) The LED has stopped flashing. I restarted the PCA10040. I connected with android without problems.

First I wrote what I was doing, then I do it.

Then I set:

#define PM_LOG_LEVEL 4

#define NRF_FPRINTF_FLAG_AUTOMATIC_CR_ON_LF_ENABLED  0

I completed steps 1 through 4

1) make clean
2) make -j 2 (Of course, there were no errors)
3) I load s132_nrf52_6.1.1_softdevice.hex into the board
4) Download the firmware to the board
5) LED1 started flashing
6) I connect via RTT Viewer V6.60c, I see the logs.
7) Connect to iMAC High Sierra (Did not give a computer with a Catalina) (device is not visible, restart).
Logs after restart:

00> <info> app: HID Keyboard example started.
00> <info> app: Erase bonds!
00> <debug> peer_manager_handler: Event PM_EVT_PEERS_DELETE_SUCCEEDED
00> <info> peer_manager_handler: All peers deleted.
00> <info> app: m_whitelist_peer_cnt 1, MAX_PEERS_WLIST 8
00> <debug> app: pm_whitelist_get returns 0 addr in whitelist and 0 irk whitelist
00> <info> app: Fast advertising.
00> <info> app: Connected
00> <debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 104 bytes.
00> <debug> nrf_ble_gatt: Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0.
00> <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_START
00> <debug> peer_manager_handler: Connection security procedure started: role: Peripheral, conn_handle: 0, procedure: Bonding
00> <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_PARAMS_REQ
00> <debug> peer_manager_handler: Security parameter request
00> <debug> peer_manager_handler: Event PM_EVT_CONN_SEC_FAILED
00> <info> peer_manager_handler: Connection security failed: role: Peripheral, conn_handle: 0x0, procedure: Bonding, error: 1

[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.