Zephyr: nRF52840-PCA10056/59: Cannot bring up HCI0 when using HCI_USB sample

[mike-scott]

$ lsusb
Bus 002 Device 021: ID 2fe3:0100 
$ hciconfig hci0
hci0:   Type: Primary  Bus: USB
    BD Address: 00:00:00:00:00:00  ACL MTU: 251:19  SCO MTU: 0:0
    DOWN 
    RX bytes:227 acl:0 sco:0 events:18 errors:0
    TX bytes:85 acl:0 sco:0 commands:18 errors:0
$ sudo hciconfig hci0 up
Can't init device hci0: Cannot assign requested address (99)

[mike-scott]

hcitool commands like lescan work, but without a correct BD addr, using the dongle for IPSP networking fails.

[carlescufi]

This is probably BlueZ not knowing how to work without a public address. I will assign this to people with BlueZ knowledge

[jhedberg]

BlueZ knows how to work without a public address. bluetoothd will auto-generate a static random address and keep using that. You do need a fairly recent kernel though. Note that all the legacy commands like hcitool and hciconfig are completely oblivious to LE, which is why e.g. hciconfig only knows about the public address and has no identity address concept (which with these controllers would be a static random address)

[jhedberg]

Anyway, if you think there's some BlueZ bug I think that'd be best reported to the linux-bluetooth mailing list instead of Zephyr github.

[carlescufi]

@mike-scott you said that "Using the dongle for IPSP fails". I assume that is not the case with hci_uart? So maybe there's something different there, between the initialization done by btattach and the one done by the USB class loader? @jhedberg do you know?

[mike-scott]

@carlescufi yes, running hci_uart sample w/ latest Zephyr works, however we do enable additional buffers as such:

diff --git a/samples/bluetooth/hci_uart/nrf5.conf b/samples/bluetooth/hci_uart/nrf5.conf
index f2c2ac51f4..02ff4f0c45 100644
--- a/samples/bluetooth/hci_uart/nrf5.conf
+++ b/samples/bluetooth/hci_uart/nrf5.conf
@@ -13,3 +13,10 @@ CONFIG_BT_MAX_CONN=16
 CONFIG_BT_TINYCRYPT_ECC=n
 CONFIG_BT_CTLR_DTM_HCI=y
 CONFIG_BT_CTLR_ASSERT_HANDLER=y
+CONFIG_BT_CTLR_RX_BUFFERS=18
+CONFIG_BT_CTLR_TX_BUFFERS=19
+CONFIG_BT_CTLR_TX_BUFFER_SIZE=251
+CONFIG_BT_CTLR_DATA_LENGTH_MAX=251
+CONFIG_BT_HCI_CMD_COUNT=20
+CONFIG_BT_RX_BUF_COUNT=20
+CONFIG_BT_RX_BUF_LEN=264

[mike-scott]

I updated the title and description of the problem to be more accurate. This was tested on kernel: 4.18.16

[mike-scott]

Update:
BlueZ 5.47 was generating the error trying to bring hci0 up. I update to 5.49 and that error goes away.

Now with hci0 up, I try joining nodes to 6lowpan but am unable to ping them once connected.

Still debugging.

[finikorg]

Can this be related? Issue #11232

[finikorg]

Could you check the bug with the fixes for Control endpoint? Basically before you were not able to send more then 64 bytes to the control endpoint which is HCI commands are using. PR #11713

[galak]

@mike-scott any update on this?

[hasslerb]

I experienced the same issue with hciconfig. Instead I needed to bring up the controller with btmgmt per Nordic's documentation.

sudo btmgmt --index 0
[hci0]# static-addr FF:02:03:04:05:FF
[hci0]# auto-power

After this, hciconfig correctly showed the device as up.

[jhedberg]

@hasslerb hciconfig is a legacy tool that hasn't been updated (and wont be updated) to deal e.g. with single-mode devices without a public address. That said, if you have an anywhere recent bluetoothd running it should take care of the same thing that you just did manually using btmgmt.

[jhedberg]

I'll assume this as resolved since there's been no update from the reporter. Please re-open if the issue still persists.

[beikeland]

Experiencing the same issue with hci_usb using a nrf52840 dongle and zephyr 2.2.99 Can't init device hci0: Cannot assign requested address (99)and setting a static address with btmgmt does bring up the device (still showing 00:00:00:00:00:00 in hciconfig

hci_usb was just a quick test, aiming to use hci_uart just wanted to report the issue is still present. Unlike OP I also experience the same with hci_uart and hci_usb. Will try updating bluez.

[kuvaldini]

The same issue with latest zephyr [git bc6f11b730 2020-05-21 10:30:18 +0800] and bluez 5.49 on openwrt 18.06

Solved by:

# btattach -B /dev/ttyACM0 -S 1000000 -P h4 &
Attaching Primary controller to /dev/ttyACM0
Switched line discipline from 0 to 15
Device index 0 attached
# btmgmt --index 0
[hci0]# static-addr FF:02:03:04:05:FF
Static address successfully set
[hci0]# auto-power
Found controller with index 0
Successfully enabled controller with index 0
[hci0]# find -l
Discovery started
hci0 type 6 discovering on
hci0 dev_found: 63:59:3E:05:43:25 type LE Random rssi -72 flags 0x0000
AD flags 0x1a
eir_len 17
hci0 dev_found: CA:0A:69:8B:37:AB type LE Random rssi -71 flags 0x0000
AD flags 0x06
name DAVINCI IQ
hci0 type 6 discovering off

[ChristianHirsch]

I recently had the same problem on a Raspberry Pi 3, BlueZ 5.50 and a nRF52840 dongle running the HSI_USB sample. When I started the Bluetooth deamon, I saw that it complained about missing crypto implementations. Then, I came across this article, recompiled the Kernel with the specified crypto modules and now everything works fine without setting anything manually.