BlueZ - HCI adapter address via ioctl(hciSocket, HCIGETDEVINFO, &devInfo) doesn't match address via DBus for Adapter1.address

BlueZ - HCI adapter address via ioctl(hciSocket, HCIGETDEVINFO, &devInfo) doesn't match address via DBus for Adapter1.address

[Vieren Frank]

Hallo,

Recently I have been started exploring the BLE world of hardware and software.

In my quest to find the best SW framework to address BLE hardware I have been confronted with this issue as described here : https://bugreports.qt.io/browse/QTBUG-71727 when trying to use the QT BLE SW stack in use with Nordic BLE nRF52832 hardware.

To summarize my findings:
- When the public device address of the Nordic HW is NOT set, meaning in Linux the hcitool dev or hciconfig tooling will show the ZERO device address meaning 00:00:00:00:00:00 assigned to the HCI adapter/controller. The bluetoothctl tool will show the "random" address different from zero's.
- When running in this case(setup) the QT heartrate-server applic (QT v5.11 on Linux Ubuntu 18), the QT application fails to find the proper HCI adapter as it compares the address found by reading out the HCIdevice address via ioctl (resulting in 00:00:00:00:00:00) and the address retrieved from the BlueZ adapter (DBus) that corresponds to the random address created by Nordic (also the address shown via bluetoothctl). 

So my question is after I have set the "public device address" via the hcitool cmd 0x3f 0x006 BD_ADDRESS, the random address is no longer the random address set by Nordic it has changed into the public address (although when looking via DBUS at the address for the Adapter1, the address type is still set as random) I configured and the QT application will succeed as both addresses will match.

Any idea what is happening in this process.

Thanks in advance,
Best regards,
Frank