samples/bluetooth/periodic_adv/, print random address after every reset

[kaiser-ren]

Is your enhancement proposal related to a problem? Please describe.
periodic_adv is very useful sample to illustrate how periodic advertising works, there is a problem that if you have a packet sniffer and there are a lot of Bluetooth LE devices nearby, it's hard to track this periodic_adv device by eye balls because you don't know the random address of this periodic_adv device.

Describe the solution you'd like
Is it possible to print the random address via printk(). Furthermore, for all the samples which uses Bluetooth LE random address, can Bluetooth LE random address being printk() after every reset?

Describe alternatives you've considered
None.

Additional context

Below is the log, and I find that Identity: F6:14:B5:7B:EC:61 (random) doesn't mean a real device address.

Starting Periodic Advertising Demo
[00:00:00.257,934] bt_hci_core: HW Platform: Nordic Semiconductor (0x0002)
[00:00:00.257,934] bt_hci_core: HW Variant: nRF52x (0x0002)
[00:00:00.257,934] bt_hci_core: Firmware: Standard Bluetooth controller (0x00) Version 2.5 Build 0
[00:00:00.258,514] bt_hci_core: Identity: F6:14:B5:7B:EC:61 (random)
[00:00:00.258,514] bt_hci_core: HCI: version 5.2 (0x0b) revision 0x0000, manufacturer 0x05f1
[00:00:00.258,514] bt_hci_core: LMP: version 5.2 (0x0b) subver 0xffff

[Thalley]

I'm not entirely sure that's possible to do from the application, but I'll try to see what I can do.

[Thalley]

One solution would be to change the advertiser to use the identity, rather than a random generated address.

@kaiser-ren Would it be a better solution if the device kept the same address, rather than printing the newly generated one? I guess that would make sniffing easier.

[kaiser-ren]

One solution would be to change the advertiser to use the identity, rather than a random generated address.
~~I'm not sure what identity means, it looks like a Bluetooth device address, if can leverage it, I believe this is a solution to go.

@kaiser-ren Would it be a better solution if the device kept the same address, rather than printing the newly generated one? I guess that would make sniffing easier.
~~"kept the same address" means to use public address instead of random, correct? If this sample is experimental, that's fine.

[kaiser-ren]

@Thalley , I took into it today for how to print random address, here is the thing:

• Actually, Zephyr Bluetooth stack prints the random address automatically by bt_dev_show_info(), I believe a random address is created during bt_enable()
• Howevery, after calling bt_le_ext_adv_create(), the random address creates again and the new one replaces the one created by bt_enable()
• Thus, the random address printed at bt_dev_show_info() is not the one used for adv ext.
  I think this is a bug, isn't it?

[Thalley]

@Thalley , I took into it today for how to print random address, here is the thing:

• Actually, Zephyr Bluetooth stack prints the random address automatically by bt_dev_show_info(), I believe a random address is created during bt_enable()
• Howevery, after calling bt_le_ext_adv_create(), the random address creates again and the new one replaces the one created by bt_enable()
• Thus, the random address printed at bt_dev_show_info() is not the one used for adv ext.
  I think this is a bug, isn't it?

No, that is a privacy feature.
The address you see from bt_dev_show_info() is the identify address, which may be a public (BT SIG assigned) or random address.

When advertising, you do normally not advertise with your identify to avoid tracking of your device (privacy), so advertising will generally create a new random address (if using extended advertising like here, you'd have a random address per advertising set), which will also be updated periodically (typically around every ~15min).

We can change the advertising parameters so that it will advertise with the identify address, and also stop it from updating that, so that you will advertise with a static address. Since this is a sample, unrelated to privacy, I think that will be right way to go.

[Thalley]

@kaiser-ren Btw, have you tried enabling CONFIG_BT_LOG_SNIFFER_INFO?

[kaiser-ren]

@kaiser-ren Btw, have you tried enabling CONFIG_BT_LOG_SNIFFER_INFO?

I just tried this option, but compiling was failed, how about you? Attached the west build log below:
renkai@Kais-MacBook-Pro zephyr % west build -p auto -b nrf52840dk_nrf52840 ./samples/bluetooth/periodic_adv
-- west build: generating a build system
Including boilerplate (Zephyr base (cached)): /Users/renkai/zephyrproject/zephyr/cmake/app/boilerplate.cmake
-- Application: /Users/renkai/zephyrproject/zephyr/samples/bluetooth/periodic_adv
-- Zephyr version: 2.5.99 (/Users/renkai/zephyrproject/zephyr)
-- Found west (found suitable version "0.9.0", minimum required is "0.7.1")
-- Board: nrf52840dk_nrf52840
-- Cache files will be written to: /Users/renkai/Library/Caches/zephyr
-- Found dtc: /usr/local/bin/dtc (found suitable version "1.6.0", minimum required is "1.4.6")
-- Found toolchain: gnuarmemb (/Users/renkai/gcc-arm-none-eabi-9-2019-q4-major)
-- Found BOARD.dts: /Users/renkai/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840.dts
-- Generated zephyr.dts: /Users/renkai/zephyrproject/zephyr/build/zephyr/zephyr.dts
-- Generated devicetree_unfixed.h: /Users/renkai/zephyrproject/zephyr/build/zephyr/include/generated/devicetree_unfixed.h
-- Generated device_extern.h: /Users/renkai/zephyrproject/zephyr/build/zephyr/include/generated/device_extern.h
Parsing /Users/renkai/zephyrproject/zephyr/Kconfig
Loaded configuration '/Users/renkai/zephyrproject/zephyr/boards/arm/nrf52840dk_nrf52840/nrf52840dk_nrf52840_defconfig'
Merged configuration '/Users/renkai/zephyrproject/zephyr/samples/bluetooth/periodic_adv/prj.conf'
Merged configuration '/Users/renkai/zephyrproject/zephyr/samples/bluetooth/periodic_adv/boards/nrf52840dk_nrf52840.conf'
Configuration saved to '/Users/renkai/zephyrproject/zephyr/build/zephyr/.config'
Kconfig header saved to '/Users/renkai/zephyrproject/zephyr/build/zephyr/include/generated/autoconf.h'
-- The C compiler identification is GNU 9.2.1
-- The CXX compiler identification is GNU 9.2.1
-- The ASM compiler identification is GNU
-- Found assembler: /Users/renkai/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc
CMake Warning at ../../../subsys/bluetooth/host/CMakeLists.txt:80 (message):
One of these options are enabled:

CONFIG_BT_DEBUG_SMP CONFIG_BT_DEBUG_KEYS CONFIG_BT_LOG_SNIFFER_INFO.
Private security keys such as the LTK will be printed out, do not use in
production.

CMake Deprecation Warning at /Users/renkai/zephyrproject/modules/lib/civetweb/CMakeLists.txt:2 (cmake_minimum_required):
Compatibility with CMake < 2.8.12 will be removed from a future version of
CMake.

Update the VERSION argument value or use a ... suffix to tell
CMake that the project does not need compatibility with older versions.

-- Configuring done
-- Generating done
-- Build files have been written to: /Users/renkai/zephyrproject/zephyr/build
-- west build: building application
[1/197] Preparing syscall dependency handling

[190/197] Linking C executable zephyr/zephyr_prebuilt.elf
FAILED: zephyr/zephyr_prebuilt.elf zephyr/zephyr_prebuilt.map
: && ccache /Users/renkai/gcc-arm-none-eabi-9-2019-q4-major/bin/arm-none-eabi-gcc zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -o zephyr/zephyr_prebuilt.elf -Wl,-T zephyr/linker.cmd -Wl,-Map=/Users/renkai/zephyrproject/zephyr/build/zephyr/zephyr_prebuilt.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a zephyr/lib/libc/minimal/liblib__libc__minimal.a zephyr/lib/posix/liblib__posix.a zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a zephyr/soc/arm/nordic_nrf/nrf52/libsoc__arm__nordic_nrf__nrf52.a zephyr/subsys/bluetooth/common/libsubsys__bluetooth__common.a zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a zephyr/subsys/bluetooth/controller/libsubsys__bluetooth__controller.a zephyr/subsys/net/libsubsys__net.a zephyr/subsys/random/libsubsys__random.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/serial/libdrivers__serial.a zephyr/drivers/entropy/libdrivers__entropy.a modules/hal_nordic/nrfx/libmodules__hal_nordic__nrfx.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -L"/Users/renkai/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v7e-m/nofp" -L/Users/renkai/zephyrproject/zephyr/build/zephyr -lgcc zephyr/arch/common/libisr_tables.a -mcpu=cortex-m4 -mthumb -mabi=aapcs -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--orphan-handling=warn && cd /Users/renkai/zephyrproject/zephyr/build/zephyr && /usr/local/Cellar/cmake/3.19.3/bin/cmake -E echo
/Users/renkai/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: zephyr/subsys/bluetooth/host/libsubsys__bluetooth__host.a(hci_core.c.obj): in function bt_dev_show_info': /Users/renkai/zephyrproject/zephyr/subsys/bluetooth/host/hci_core.c:6152: undefined reference to bt_keys_foreach'
/Users/renkai/gcc-arm-none-eabi-9-2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld: /Users/renkai/zephyrproject/zephyr/subsys/bluetooth/host/hci_core.c:6137: undefined reference to `bt_keys_show_sniffer_info'
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.
FATAL ERROR: command exited with status 1: /usr/local/bin/cmake --build /Users/renkai/zephyrproject/zephyr/build
renkai@Kais-MacBook-Pro zephyr %

[Thalley]

@kaiser-ren I haven't tried that myself yet (I'm unfortunately quite busy at the moment). If the compile fails, then I guess we should create another Github issue for that :) This enhancement is still valid regardless though.

[joerchan]

I just tried this option, but compiling was failed, how about you?

Yes, I have submitted a fix for that, there was an issue with enabling it without BT_SMP enabled.
Fix here: #33653

Thus, the random address printed at bt_dev_show_info() is not the one used for adv ext.
I think this is a bug, isn't it?

It is intentional and as Thalley explained, each time the non-connectable advertiser (broadcaster) is started it generates a new NRPA address, one option as mentioned is to disable this behavior with the USE_IDENTITY option.

In most cases bt_le_ext_adv_oob_get_local could have been used here to get the NRPA, except for this case.
I will investigate if that is something that should be supported.

For now I think using CONFIG_BT_LOG_SNIFFER_INFO might be the best option for you after it has been fixed since your use-case is one of the reasons it was added.

[kaiser-ren]

I just tried this option, but compiling was failed, how about you?

Yes, I have submitted a fix for that, there was an issue with enabling it without BT_SMP enabled.
Fix here: #33653

Thus, the random address printed at bt_dev_show_info() is not the one used for adv ext.
I think this is a bug, isn't it?

It is intentional and as Thalley explained, each time the non-connectable advertiser (broadcaster) is started it generates a new NRPA address, one option as mentioned is to disable this behavior with the USE_IDENTITY option.

In most cases bt_le_ext_adv_oob_get_local could have been used here to get the NRPA, except for this case.
I will investigate if that is something that should be supported.

For now I think using CONFIG_BT_LOG_SNIFFER_INFO might be the best option for you after it has been fixed since your use-case is one of the reasons it was added.

Great, I'm looking forward to having this fix merged ASAP.

[cvinayak]

This is not an enhancement, but a test requirement, to be able to sniff packets. User samples should not compromise on security features.

Users to update local version of sample (with conscious decision to use identity address) or use tests/bluetooth/shell application for test purposes.

[kaiser-ren]

I just tried this option, but compiling was failed, how about you?

Yes, I have submitted a fix for that, there was an issue with enabling it without BT_SMP enabled.
Fix here: #33653

Thus, the random address printed at bt_dev_show_info() is not the one used for adv ext.
I think this is a bug, isn't it?

It is intentional and as Thalley explained, each time the non-connectable advertiser (broadcaster) is started it generates a new NRPA address, one option as mentioned is to disable this behavior with the USE_IDENTITY option.
In most cases bt_le_ext_adv_oob_get_local could have been used here to get the NRPA, except for this case.
I will investigate if that is something that should be supported.
For now I think using CONFIG_BT_LOG_SNIFFER_INFO might be the best option for you after it has been fixed since your use-case is one of the reasons it was added.

Great, I'm looking forward to having this fix merged ASAP.

I verified, CONFIG_BT_LOG_SNIFFER_INFO method works. I can capture the address of periodic advertise after reset the board.

[Thalley]

I verified, CONFIG_BT_LOG_SNIFFER_INFO method works. I can capture the address of periodic advertise after reset the board.

@kaiser-ren Is that enough to close this issue?

[kaiser-ren]

Great works, thanks.