QLowEnergyController uses random address when public address is 00:00:00:00:00:00 causes failing creating BT socket as no valid HCI adapter is found

Hallo,

I'm recently exploring the possibilities of using the Nordic nRF52 DK running Zephyr HCI_UART as BLE controller. 

To have a quick BLE peripheral applic up and running I built the QT examples heartrate-server on my Ubuntu 18 Linux  system. 

As I'm using the Nordic HW platform the public address initialy is set to 00:00:00:00:00:00 after powering up.

After some debug work I noticed that the QLowEnergyController object created as peripheral uses the BT random address instead of the BT public address which is the zero-address. By doing so the HciManager and the hciForAddress function fails to create a BT socket as the HCI adapter/controller can not be found based on the random address.

// code placeholder
int HciManager::hciForAddress(const QBluetoothAddress &deviceAdapter){    if (hciSocket < 0)        return -1;     bdaddr_t adapter;    convertAddress(deviceAdapter.toUInt64(), adapter.b);     struct hci_dev_req *devRequest = 0;    struct hci_dev_list_req *devRequestList = 0;    struct hci_dev_info devInfo;    const int devListSize = sizeof(struct hci_dev_list_req)                        + HCI_MAX_DEV * sizeof(struct hci_dev_req);     devRequestList = (hci_dev_list_req *) malloc(devListSize);    if (!devRequestList)        return -1;     QScopedPointer<hci_dev_list_req, QScopedPointerPodDeleter> p(devRequestList);     memset(p.data(), 0, devListSize);    p->dev_num = HCI_MAX_DEV;    devRequest = p->dev_req;     if (ioctl(hciSocket, HCIGETDEVLIST, devRequestList) < 0)        return -1;     for (int i = 0; i < devRequestList->dev_num; i++) {        devInfo.dev_id = (devRequest+i)->dev_id;        if (ioctl(hciSocket, HCIGETDEVINFO, &devInfo) < 0) {            continue;        }         int result = memcmp(&adapter, &devInfo.bdaddr, sizeof(bdaddr_t));        if (result == 0 || deviceAdapter.isNull()) // addresses match            return devInfo.dev_id;    }     return -1;}

QBluetoothAddress QBluetoothLocalDevice::address() const{    if (d_ptr->adapter) {        QDBusPendingReply<QVariantMap> reply = d_ptr->adapter->GetProperties();        reply.waitForFinished();        if (reply.isError())            return QBluetoothAddress();         return QBluetoothAddress(reply.value().value(QStringLiteral("Address")).toString());    } else if (d_ptr->adapterBluez5) {        return QBluetoothAddress(d_ptr->adapterBluez5->address());    }     return QBluetoothAddress();}

In my case the BT random address is always after startup CB:49:DD:88:61:62, as the public address is still 00:00:00:00:00:00.  Thus in the function call hciForAddress there is no match to find the right HCI adapter. BTW in my setup there is only one BT HCI adapter present, the internal one is disabled.

So it seems if the BlueZ stack finds a ZERO address for its Adapter1 it uses rather the random address.

This can be solved by setting the public BD address by calling the hci cmd 0x3f 0x006 "BD-ADDR" (Zephyr specific).  In this case the QLowerPowerController object will correctly find the Hci adapter and create the bluetooth socket, and advertising can be done succesfully.

However when calling with QDbusViewer and quering the org.bluez I see that it now reports as random address the address that was set by the command hci cmd 0x3f 0x006 BD_ADDR. 

So I'm wondering how is making the bug or is this behaviour normal?

So either I can set a public address after powering up the Nordic HW before calling the heartrate-server applic or I can adapt the QT code that should allow zero-address for finding the HCI controller/adapter. Of course the latter is more or less not acceptable. 

Honestly I love the way Qt implements the Bluez stack and makes it much easier to address /implement BLE functionality.

BTW I have also reported the issue on Zephyr and Nordic Dev Zone,

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr (See my comments at the end by Frank)

https://lists.zephyrproject.org/g/devel/topic/28047406#5381

Any idea's?

Thanks,

Best regards,

Frank