Topics

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

frv
 

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.

 

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr/156634#156634

 

Any feedback is very welcome,

Thanks in advance,

Frank

Cufi, Carles
 

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

 

From: devel@... <devel@...> On Behalf Of frv
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.

 

https://devzone.nordicsemi.com/f/nordic-q-a/22194/read-or-change-nrf51-mac-address-on-zephyr/156634#156634

 

Any feedback is very welcome,

Thanks in advance,

Frank

frv
 
Edited

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

Cufi, Carles
 

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

 

From: devel@... <devel@...> On Behalf Of frv
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

frv
 
Edited

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

Cufi, Carles
 

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

 

From: devel@... <devel@...> On Behalf Of frv
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

frv
 

Hi Carles,

Thanks a lot, I hope soon a proper answer can be given, nevertheless progress is made and it just to know if this is normal behaviour. 

Best regards,
Frank

icephyr
 

Hi,guys, It seems that I met a similar problem with Frank.
 
I use nRF52832 running HCI_UART sample as a controller. I want to make the controller advertise unconnectable packets outside, so I use bluez (version 5.48)
 
and hcitool to set advertise data :
sudo hcitool -i hci0 cmd 0x08 0x0008 1f 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
 
and set advertise enable:
sudo hcitool -i hci0 cmd 0x08 0x000a 01
 
I detect the process with btmon, the controller returns success ,like this below:


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 ?

frv
 
Edited

Hi there,

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

icephyr
 

Hi 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

frv
 

Hi,

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

icephyr
 

Thanks a lot Frank, I executed commands advertise on and discoverable on as you mentioned, now I can scan out the device with MAC address I set ! 

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!

frv
 

Hi,

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

icephyr
 

Well,I just wonder why we have to set mac address first to make the advertise function normal,since the bluez stack assigned a random address already.
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.

frv
 

Hi icephyr,

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

lairdjm
 

Hi,
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

frv
 
Edited

Hi 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;

.... 

More details can be read here : https://bugreports.qt.io/browse/QTBUG-71727

Best regards,
Frank