Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832
Hallo Zephyr community,
Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex.
I also see that the random address remains the same after power cycling the nRF board.
Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.
Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).
Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.
Any feedback is very welcome,
Thanks in advance,
Frank
Hi there,
The *public* address is all zeroes because Nordic ICs do not come with one pre-assigned. The *random static* address is set by BlueZ itself, so it will be whatever BlueZ decides it to be.
You don’t typically need a public address to work with BLE.
Carles
Sent: 09 November 2018 11:49
To: Zephyr-devel@...
Subject: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832
Hallo Zephyr community,
Anyone knowing why the BD address is always the ZERO address, when using the nRF52 board running the Zephyr HCI uart hex.
I also see that the random address remains the same after power cycling the nRF board.
Also differences in showing the address for the HCI controller when running the bluetoothctl and hcitool dev commands.
Nor using the hcitool or btmgmt tool makes it possible to adjust the addressing, only so far the hcitool cmd 0x3f 0x006 address makes a difference as long as the board is not power cycled (as the setting is volatile, the default non volatile addresses to zero it seems).
Please see my findings described more in detail here in the Nordic Dev Zone, last reply in the message queue.
Any feedback is very welcome,
Thanks in advance,
Frank
Thanks for the feedback.
It seems the Qt QLowerEnergyController object selects the first valid address different from the zero address for addressing the HCI controller/adapter. In my case for Nordic Zephyr BLE Controller this is the random address when the public address is not set first different from the zero address by the hci cmd 0x3f 0x006 "address".
Best regards,
Frank
Hi Frank,
I understand, so does that mean that you don’t need a public address? Since Qt seems to be doing the right thing.
Carles
Sent: 12 November 2018 09:20
To: devel@...
Subject: Re: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832
[Edited Message Follows]
Hi Carles,
Thanks for the feedback.
It seems the Qt QLowerEnergyController object selects the first valid address different from the zero address for addressing the HCI controller/adapter. In my case for Nordic Zephyr BLE Controller this is the random address when the public address is not set
first different from the zero address by the hci cmd 0x3f 0x006 "address".
Best regards,
Frank
Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727) although I think different parties are to blame, I'm still not sure who is doing really wrong, or miss interprets the data.
Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address 00:00:00:00:00:00.
When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).
As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).
Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology ("Property: AddressType") the public set address still typed as "random".
I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.
Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver. Altough the latter also gives a nice solution for integrating BT in our products.
Best regards,
Frank
Hi Frank,
Right, since this seems to be more about BlueZ and Qt than about Zephyr or nRF, because nRF chipsets do not come with a public address registered and burned into the chip, I have copied a couple of people familiar with BlueZ to see if they can help you.
Regards,
Carles
Sent: 12 November 2018 12:14
To: devel@...
Subject: Re: [Zephyr-devel] Zephyr (v1.13.0) HCI_UART running on nRF52 DK why BD address is always 00:00:00:00:00:00 after power cycle #nrf52832
[Edited Message Follows]
Hi Carles,
Humm... not quite, I have recently created a QT bug report (See : https://bugreports.qt.io/browse/QTBUG-71727) although I think different parties are to blame, I'm still not sure who
is doing really wrong, or miss interprets the data.
Thus to summarize again:
If no public address is set for the Nordic BT controller, the HCI adapter has by default address
00:00:00:00:00:00.
When Qt creates a QLowEnergyController object it uses the BT random address to find the HCI adapter (hciForAddress member function in the HciManager class), but as the random address is
different from the default public address it is not able to create a QT BT socket, and thus all BLE actions will fail (E.g. advertising).
As QT uses the Bluez DBus function for retrieving the address info you could say it is the Bluez stack to blame, as the address is referring to the HCI adapter is the random address and not the public device address (00:00:00:00:00:00) (See attach pic of QDbusViewer).
Thus only after setting the public address different from the zero address (by means of the hcitool cmd) , Qt is able to create a correct LowEnergyController object for starting to advertise. But also in this case you could wonder why is in the DBus topology
("Property: AddressType") the public set address still typed as "random".
I'm wondering how Qt will reply to the issue. Honestly I love to work with QT as a C++ developer.
Also the Zephyr HCI_UART running on the Nordic HW offers a different solution than using the plain C solution (serialize concept when separating connectivity board from application board) offered by Nordic or the C++ solution based on the Nordic PC BLE driver.
Altough the latter also gives a nice solution for integrating BT in our products.
Best regards,
Frank
But I didn't find the packet whose data was what I have set with hcitool command. I wonder if this is normal, and will the whole zero mac-address cause this problem ?
For me using the Nordic's nRFConnect smartphone app is very useful in the debug process.
My experience so far is when the public address of the HCI controller is set as 00:00:00:00:00:00 the client (central) application will detect/discover the peripheral BT device as ANOMYNOUS, thus the advertising is working.
However connecting to it via the nRFConnect makes the client applic crashing when the device is disoverable as ANOMYNOUS. But this is a different kind of issue I'm afraid.
BTW make also sure you are making your device discoverable.
I suggest you set the public address of the HCI controller via the cmd hcitool cmd 0x3f 0x006 0x0 0x0 0x1 0x2 0x21 0xAD (you are of course free to chose a different BD address). Make sure the btattach process is running correctly (e.g. btattach -B /dev/tttyACM0 -S 1000000 -P h4) before setting the address.
Stop the btattach process and restart it. When the cmd is succesfully executed the cmd hcitool dev or hciconfig -a should display the address that was set.
BTW making use of QT example code makes it quite interesting to test out BLE functionality. Also QT DBus viewer can be very helpful in setting and debugging BLE functionality.
Good luck,
Frank
Thanks for your suggestions, The mac address was changed successfully under your instructions, but I still cannot discover the device with nRFConnect smartphone app.
That seems all the difference between us.
After I changed mac address of the controller, I just set advertise data and enabled advertise function:
The advertise data I set was :
hcitool -i hci0 cmd 0x08 0x0008 1e 02 01 06 03 03 aa fe 17 16 aa fe 00 -10 00 01 02 03 04 05 06 07 08 09 0a 0b 0e 0f 00 00 00 00
Then I set advertise function enable:
sudo hcitool -i hci0 cmd 0x08 0x000a 01
would you please tell what commands you executed to make the controller advertise normally ? Thanks
For advertising I don't use the hcitool cmd, however I think a fast and easy check can also be done by using either the bluetootctl or the btmgmt tool.
So after executing the bluetoothctl you can activate advertising by just typing : advertise on. I would also execute : discoverable on, otherwise the nRFConnect will not see the BT device that is advertising.
For a more user friendly approach I would recommend to use a C++ implementation (See e.g. QT heart-rate server applic) to approach the Bluez stack.
Best regards,
Frank
Now our problems are the same, I will read the source codes to find out the problem, also hope others can pay attention and solve this problem too. Look forward to your progress and good news!
No problem. Good to hear your issue is solved.
Using the zero address as public address is not really an issue however nobody so far can explain if it is normal that the BlueZ stack uses the "random address" when the public address is set to zero.
Anyhow QT is looking at it as it creates an issue when using the QT BLE stack for fetching the HCI controller/adaptor when the public address is set to zero (FYI https://bugreports.qt.io/browse/QTBUG-71727)
Best regards,
Frank
And also, why command advertise on take efforts but hcitool commands can not.
So many differences between hcitools and bluetoothctl, Hope anyone can give an accurate explanation.
I think 2 things are mixed up here in this topic, my problem with the ZERO address as public address was not related to advertising but rather why the Bluez takes the random address as address when the public address is set to zero as it is in my case with the Nordic nRF52832.
This behaviour is causing a problem in the QT BT stack when creating the QLowPowerController object as the HCI adapter can not be fetched properly based on this random address.
The bluetoothctl is based on the Bluez stack via DBus, this is the same for the QT BT stack...
IMHO I think your problem was more related to the fact the discover flag was not set.
Anyhow I hope QT can come up with a better solution or at least explain what the real issue is if it is not in their SW stack. Let's see and hear...
Best regards,
Frank
It is correct that a public address starting with 00:00:00 will not work, it is a reserved IEEE address and the addressing scheme follows that standard, see https://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml
And in regards to any similar problems with random addresses, this is because as stated in the core version 5 Bluetooth guide:
"At least one bit of the random part of the address shall be 0
At least one bit of the random part of the address shall be 1"
Hcitools was deprecated in 2017 and is no longer maintained and should not be used, this is why by default when building BlueZ with the default build options you don't get these utilities. And depending upon the version of Qt you use, you get a different interface for using Bluetooth, very old versions of Qt have their own GATT implementation, newer versions use BlueZ and with 5.11 it was re-written.
Thanks,
Jamie
Thanks for your explanation.
However for me it remains a riddle (and probably a bug), why the BlueZ implementation selects the random address as HCI adapter address when the public address is set to zero?
When setting the public address different from zero, the DBus topogoly still keeps the address type as random for Adapter1 despite the hcitool cmd 0x3f 0x006 BD_ADDRESS sets the public address.
Nevertheless this solves the QT issue when the hciForAddress function is called in the HciManager object.
The low level function ioctl(hciSocket, HCIGETDEVINFO, &devInfo) will have a match for the address value in the devInfo when compared to this
new random but still public address (IMHO)
...
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;
....
Best regards,
Frank