Directed advertising to Android does not work

[pdunaj]

Describe the bug
I bond the device with various host and then use direct advertising to reconnect.
I am able to connect to Windows 7 with Intel drivers and Windows 10. I am also able to connect to Nordic dongle (pca10059) though Zephyr's option scan with identity must be enabled.

I am unable to connect (using the direct advertising) to an Android devices. I have tried Samsung Galaxy S8 (Android 9.0) and Moto G5 (Android 8.1.0).

Maybe the problem is how these device perform scanning?

To Reproduce
Steps to reproduce the behavior:
See description.

Expected behavior
Direct advertising should work.

Impact
showstopper

Screenshots or console output
N/A

Environment (please complete the following information):
ncs zephyr: e7a0e52 (19de7ec upstream)

Additional context
N/A

[jhedberg]

Could the issue be related to the central using privacy? Do you have CONFIG_BT_CTLR_PRIVACY enabled?

[pdunaj]

Hi @jhedberg , no - it is disabled.

[jhedberg]

Hi @jhedberg , no - it is disabled.

@pdunaj could you enable it and try again? I think it might be needed for doing directed advertising toward a privacy-enabled central.

[jhedberg]

@carlescufi @cvinayak any thoughts on this issue?

[pdunaj]

sure, will enable and retry

[pdunaj]

When I enable privacy I cannot create connection. Device either disconnects right after connection or does not even connect.

[rljordan-zz]

@jhedberg Please review priority.

[jhedberg]

@pdunaj did you already determine if the devices in question use privacy, i.e. that this is the differentiating factor between "works" and "doesn't work"? @carlescufi @cvinayak I'd really need your input here to understand if this is a controller issue or a host issue. @pdunaj just to get this straight, your test procedure is to pair with these devices and then request a connection to them using bt_conn_create_slave_le() and you're passing the remote identity address to this function, correct?

[jhedberg]

@pdunaj also, it'd be good if you could produce an HCI trace of what's going on. See https://docs.zephyrproject.org/latest/guides/bluetooth/bluetooth-dev.html#embedded-hci-tracing

[pdunaj]

Hi @jhedberg ,
we do as follows (case with no privacy):

• device starts with clear settings,
• no bond is established on selected identity - advertise undirectly (bt_le_adv_start),
• host (Android, Windows, nrf840_pca10059) sees device, connects and bonds,
• device reboots,
• bond is present, device starts direct advertising (bt_conn_create_slave_le) to address obtained from info->addr from callback to bt_foreach_bond
• when host is present and is Windows or nrf52840_pca10059 it connects instantly; when host is Android no connection is done
• when no connection is done we do low duty direct advertising but Android still does not connect

Note: for nrf52840_pca10059 we need to enable BT_SCAN_WITH_IDENTITY , as otherwise direct advertising does not work at all.

I have rechecked with privacy (BT_PRIVACY) enabled and the behavior is actually the same. I am able to connect to Windows but not to Android. Previously I was unable to connect at all but maybe I was doing something wrong or the last Zephyr upmerge helped.

[pdunaj]

@jhedberg I will capture traces and try to debug it on Monday.
BTW our app's advertising module is here:
https://github.com/NordicPlayground/fw-nrfconnect-nrf/blob/master/samples/nrf_desktop/src/modules/ble_adv.c

[carlescufi]

Looking through this issue's history, I think that @joerchan might be able to help with it. @joerchan could you take a quick look?

[joerchan]

@carlescufi @jhedberg The issue here is that the Host will not use IRKs for the peer when BT_PRIVACY is not enabled, meaning peers IRK is not stored with the bond.
So since Android (and also iOS) devices use privacy we cannot advertise directly to them when BT_PRIVACY is not enabled (even though BT_CTRL_PRIVACY is enabled or supported).
There are other less obvious drawbacks to this. We cannot properly whitelist privacy enabled devices either.
In my opinion we should enabled storing of the peers IRK even though we are not privacy enabled.
Not sure if it should be a config for just storing peer IRK, it is definitively confusing to know all the configurations that needs to be enabled/disabled to have something working, so maybe not having a config option here is best.

@pdunaj Enabling BT_PRIVACY should work, it did for me

[carlescufi]

@joerchan @jhedberg @pskhansen I think we could split the Host privacy support into two different Kconfig options:

• CONFIG_BT_RPA_GEN_RES: Enables support for privacy as a feature
• CONFIG_BT_PRIVACY (select CONFIG_BT_RPA_GEN_RES): Uses RPA when advertising/scanning

@pdunaj can you verify that enabling CONFIG_BT_PRIVACY removes the issue and update the description correspondingly?

[jhedberg]

@carlescufi I don't think we need CONFIG_BT_RPA_GEN_RES. That should always be supported whenever pairing (SMP) is supported.

[carlescufi]

@jhedberg why is that? I think it would make sense to be able to conditionally compile out IRK management and RPA generation and resolution. Simple applications might want to bond and encrypt but not make use of any IRK-related functionality.

[jhedberg]

@carlescufi because then you can't properly interop with privacy-enabled devices? Maybe I misunderstand what the second option would do.

[jhedberg]

@carlescufi I think I may have misunderstood CONFIG_BT_RPA_GEN_RES - I thought that was for being able to use another devices's IRK to connect to it, but in fact it's about something else?

[pdunaj]

Hi @jhedberg , I checked again and enabling privacy does not work.
Here is the branch I use: https://github.com/pdunaj/fw-nrfconnect-nrf/tree/test_direct_privacy
Build commands (I use debug variant or the app):

( B=pca10056; rm -rf build-$B/ && mkdir build-$B && cd build-$B && cmake .. -GNinja -DCMAKE_BUILD_TYPE=ZDebug -DBOARD=nrf52840_$B )
( B=pca10056; cd build-$B && ninja flash )

You can see in the logs that device is advertising directly to host but there is no connection attempt on the other side.

[00000228] <inf> config: Settings loaded
[00000231] <inf> event_manager: e: module_state_event module:config state:READY
[00000231] <inf> ble_bond: Device has 1 identities
[00000235] <inf> event_manager: e: module_state_event module:ble_bond state:READY
[00000235] <inf> ble_adv: Advertising stopped
[00009355] <inf> ble_adv: Direct advertising to 48:27:ea:30:7e:83 (public)
[00009355] <inf> ble_adv: Advertising started

[pdunaj]

The host device is Samsung Galaxy S8 with Android 9.

I tried again with my Moto G5 (Android 8.1) and it worked there but I had to wait for 20 seconds or more before connection was established. Let me check again with Galaxy S, maybe it will work if I wait long enough...

[pdunaj]

I retried on Galaxy S8 and direct advertised device is not connected even if I wait over a minute.

[pdunaj]

One more comment regarding our app. On mouse we would like to use fast advertising (even directed) which is enabled with CONFIG_DESKTOP_BLE_FAST_ADV=y. It is not enabled by default on DK. With direct advertising it should connect to host instantly when present. If connection cannot be established we switch to normal (slow) advertising.

[pdunaj]

On Galaxy S8 it finally connected but after over 2 minutes after reset and so far I have seen it only once.

[pdunaj]

I run more tests and collected log from HCI code and BLE sniffer. There is nothing unusual happening on the mouse. From the observations I can tell that advertising indeed works but sometimes it takes several minutes before host connects. I showed logs to @joerchan and have some chat offline.
From the logs it could be seen that mouse advertises for long time and at some point phone finally decides to connect to it.

The only conclusions are that direct advertising works on Android if privacy is enabled and that it can take even several minutes before device will be connected to by the peer.

[jhn-nordic]

In nRF5 SDK based HID peripherals we solved this by using undirected advertising with whitelist towards centrals that had privacy enabled (typically iOS and Android) and directed advertsing towards windows centrals. It is a while since then and I am not sure how peripiheral privacy will affect this.

[pdunaj]

@jhn-nordic we will have to do similar thing or simply use undirected advertising only as long as it is fast enough.
The next step is white-listing as it is not implemented in Zephyr yet...
#12874 seems quiet for some time

[carlescufi]

@pdunaj we will try to follow-up on @12874 as soon as possible.