HCI_LE_Connection_Complete event with peer address type 2

[OliverB]

Hi,

my firmware is basing on the nRF Connect SDK hci_uart example. I'm using the nRF52840DK as hardware platform and have a STM32 connected to the nRF by HCI with btstack. When I connect the first time from my iOS device and start pairing/bonding, everything is working fine. But I'm not able to reconnect and re-encrypt the connection. Here is, what I found out so far and what I think is the problem:

On the first connect, the iOS device is reported with its resolvable random address

hci.c.2823: LE Connection_complete (status=0) type 1, 59:A2:08:8D:01:A0

On every subsequent connection the address is reported with type 2:

hci.c.2823: LE Connection_complete (status=0) type 2, 88:A9:B7:26:7E:DE

The reported address is exactly the resolved address. What I am additionally wondering about is that type 2 is not specified in the Bluetooth specification:

Here's my current config:

CONFIG_USE_SEGGER_RTT=y
CONFIG_RTT_CONSOLE=y

CONFIG_STDOUT_CONSOLE=n
CONFIG_UART_CONSOLE=n
CONFIG_GPIO=y
CONFIG_SERIAL=y
CONFIG_UART_INTERRUPT_DRIVEN=y
CONFIG_UART_LINE_CTRL=y
CONFIG_LED=y
CONFIG_LED_GPIO=y

CONFIG_BT=y
CONFIG_BT_HCI_RAW=y
CONFIG_BT_HCI_RAW_H4=y
CONFIG_BT_HCI_RAW_H4_ENABLE=y
CONFIG_BT_DEBUG_LOG=n

CONFIG_BT_MAX_CONN=16
CONFIG_BT_ECC=y
CONFIG_BT_TINYCRYPT_ECC=y
CONFIG_BT_HCI_VS_EXT=y

# settings for extended MTU
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
CONFIG_BT_DATA_LEN_UPDATE=y
CONFIG_BT_BUF_ACL_RX_SIZE=255
CONFIG_BT_BUF_ACL_TX_SIZE=255
CONFIG_BT_BUF_CMD_TX_SIZE=255
CONFIG_BT_BUF_EVT_DISCARDABLE_SIZE=255

# controller settings
CONFIG_BT_CTLR_PHY_2M=y
CONFIG_BT_CTLR_PHY_CODED=y
CONFIG_BT_CTLR_CHAN_SEL_2=y
CONFIG_BT_CTLR_ASSERT_HANDLER=y
CONFIG_BT_CTLR_FILTER_ACCEPT_LIST=y
CONFIG_BT_CTLR_PRIVACY=y
CONFIG_BT_CTLR_LE_PING=y

# Workaround: Unable to allocate command buffer when using K_NO_WAIT since
# Host number of completed commands does not follow normal flow control.
CONFIG_BT_BUF_CMD_TX_COUNT=10

CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=512

I'm digging into this for days now, any idea someone? Maybe some CONFIG's I'm missing? I can provide more logs if needed, of course.

Regards,
Oliver

[OliverB]

OliverB said:

The reported address is exactly the resolved address. What I am additionally wondering about is that type 2 is not specified in the Bluetooth specification:

I have to add that this excerpt refers to Vol 4, Part E, 7.7.65.1 (LE Connection Complete event) of the Bluetooth specification v5.3. For other events, e.g. LE Enhanced Connection Complete event, the address type 2 and 3 is defined. 

[Matthias Ringwald]

Hi Oliver. It looks like this was fixed in Zephyr about 2 years ago in this commit:

https://github.com/zephyrproject-rtos/zephyr/commit/76c3a8d9649104e0ee2bbfbfca08b555d5ea103d

I've tried with current version from Zephyr and the address type was reported as public as expected. I don't understand west and the ncs repo well enough to figure out in which version contains the fix, so could you try a newer NCS version or use Zephyr directly?

Cheers

 Matthias

[tesc]

Hi,

I can confirm this is a bug in the SoftDevice Controller, where the address type specified in the enhanced connection complete event is not converted to the address type specified in the legacy connection complete event. According to the SoftDevice team this is an easy fix that should not take too long to fix. In the mean time, there are a couple of possible workarounds:

1. Mask the return address type with 0b1. That is, use only the least significant bit.

2. Alternatively, use the Zephyr Controller instead of the SoftDevice controller. (This is why it may work to use Zephyr directly, since the Zephyr project uses the Zephyr Controller. The SoftDevice Controller is delivered as part of nRF Connect SDK. Please note that we always recommend the SoftDevice Controller which is developed by us, optimized for the nRF SoCs, and certified with a Bluetooth QDID.)

Regards,
Terje

[OliverB]

Hi Matthias,

sorry for the late response, I was on vacation.

I'm on Zephyr 3.1.99 which already contains this fix. But regarding this response this is not an solution because we are using the SoftDevice. 

See also my answers below.

Thanks for your help!

Oliver

[OliverB]

Hi Terje,

thanks for the information. As we are using SoftDevice (and we want to follow Nordics recommandation) I will use the workaround until the SoftDevice is fixed. 

Regards,
Oliver