Directed advertising to Android phone without bonding

RE: Directed advertising to Android phone without bonding

droberson — Tue, 19 Mar 2024 19:09:58 GMT

Thanks for having an internal discussion and following up. Bonding it is.

Derek

RE: Directed advertising to Android phone without bonding

Simonr — Tue, 19 Mar 2024 08:47:13 GMT

After discussing with Torbjørn this morning, it seems like a case where it would be possible to do in theory, as the Bluetooth Core spec. doesn't specifically not allow it, but in practice I don't see how it will be possible on Android, since you would need the scanner to use a public or random static address for this to work, but since the Android device will rotate the MAC address every 15 minutes, I don't see how this can be achieved. We have ended up on the stance that this is not something that's supported in our SDKs without doing bonding.

Best regards,

Simon

RE: Directed advertising to Android phone without bonding

Simonr — Mon, 18 Mar 2024 13:50:21 GMT

Hi Derek

On a second look it seems like this might not be possible. I'll keep looking into it and come back to you when I know for sure, but I need some more time to dive into it and discuss it internally. I'll get back to you later this week with more info.

Thank you for your patience.

Best regards,

Simon

RE: Directed advertising to Android phone without bonding

droberson — Thu, 14 Mar 2024 21:52:01 GMT

Hey Simon,

No worries, thanks for the reply.

[quote userid="75734" url="~/f/nordic-q-a/108920/directed-advertising-to-android-phone-without-bonding/473866"]but you need to get the IRK shared somehow to the Android[/quote]

Why does the Android phone need the IRK of the Peripheral device if the Peripheral uses a BLE address type of BLE_GAP_ADDR_TYPE_RANDOM_STATIC? I thought only the Peripheral needed the IRK of the Android phone?

[quote userid="75734" url="~/f/nordic-q-a/108920/directed-advertising-to-android-phone-without-bonding/473866"]

We have a couple of discussions on this in the DevZone already:

[/quote]

I reviewed both of the posts you linked. The post Advertising to pre-shared IRK never resulted in a conclusion, and the original poster was new to C, thus making his effort much more difficult, which he never achieved the desired outcome.

The post Direct advertising with unbonded Android phone resulted in the following comment from FAE Torbjørn:

--------------------------------

The problem in this case is that the directed advertising packet will not be reported to the application as a normal advertising packet, so the phone would have to know about the device in some other way.

This is outside our control since it is handled by the Bluetooth stack in the phone.

Best regards
Torbjørn

--------------------------------

Based on Torbjørn's response, it doesn't seem advertising to an Android phone with a pre-shared IRK is possible. Yet, Susheel and you say it is possible? Which is the case?

I have directed advertising working fine without an IRK. Without IRK, my code is as follows:

// Start advertising
ble_advertising_start(&m_advertising, BLE_ADV_MODE_DIRECTED);

...
This results in event BLE_ADV_EVT_PEER_ADDR_REQUEST
...

case BLE_ADV_EVT_PEER_ADDR_REQUEST:
{
   // This event occurs when directed advertising is used
   Log(BLE, "BLE_ADV_EVT_PEER_ADDR_REQUEST");
   
   ret_code_t retCode;
   uint8_t mac[BLE_GAP_ADDR_LEN] = {0xEE, 0xA5, 0x86, 0x7E, 0xE2, 0x3A};
   ble_gap_addr_t peerAddr;

   // Set GAP structure
   peerAddr.addr_id_peer = 0;
   peerAddr.addr_type = BLE_GAP_ADDR_TYPE_RANDOM_STATIC;
   
   // Copy in MAC but reverse byte order to match GAP address type
   rev_memcpy(peerAddr.addr, mac, sizeof(peerAddr.addr));
   
   retCode = ble_advertising_peer_addr_reply(&m_advertising, &peerAddr);
   APP_ERROR_CHECK(retCode);
   
   break;
}

Edit: Here is a Wireshark capture of my working directed advertising with a random static address (No IRK).

Using the above working code as a template and "Variant #1" in this bounce diagram: https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.s132.api.v3.0.0%2Fgroup___b_l_e___g_a_p___p_r_i_v_a_c_y___a_d_v___d_i_r___p_r_i_v___m_s_c.html&cp=2_3_0_1_1_2_1_3_9_1

My IRK define and BLE_ADV_EVT_PEER_ADDR_REQUEST handler now looks like this:

// Global constants for testing
const ble_gap_id_key_t m_peer1 = 
{
    .id_info =
    {
        // Android phone IRK
        .irk = {0x57, 0x5E, 0xA8, 0xBB, 0x22, 0x20, 0xB4, 0x47, 0xF4, 0xFF, 0xF1, 0x55, 0xE6, 0xCE, 0x02, 0xF1},
    }
};

const ble_gap_id_key_t * m_identities[] = {&m_peer1};

case BLE_ADV_EVT_PEER_ADDR_REQUEST:
{
   uint8_t mac[BLE_GAP_ADDR_LEN] = {0xEE, 0xA5, 0x86, 0x7E, 0xE2, 0x3A}; // Android Phone MAC
   ble_gap_addr_t peerAddr;
   
   // Set IRK so we can use directed advertising with an Android phone that uses a
   // private random resolvable address.
   retCode = sd_ble_gap_device_identities_set(m_identities, NULL, 1);
   APP_ERROR_CHECK(retCode);

   // Set GAP structure
   peerAddr.addr_id_peer = 0;
   peerAddr.addr_type = BLE_GAP_ADDR_TYPE_RANDOM_PRIVATE_RESOLVABLE;
   
   // Copy in MAC but reverse byte order to match GAP address type
   rev_memcpy(peerAddr.addr, mac, sizeof(peerAddr.addr));
   
   retCode = ble_advertising_peer_addr_reply(&m_advertising, &peerAddr);
   APP_ERROR_CHECK(retCode);
   
   break;
}

When I attempt to advertise with ble_advertising_start(&m_advertising, BLE_ADV_MODE_DIRECTED), this function returns error code 0x3202 which I understand to be BLE_ERROR_GAP_INVALID_BLE_ADDR and the device does not advertise at all.

What am I doing wrong?

Thanks,

Derek

RE: Directed advertising to Android phone without bonding

Simonr — Thu, 14 Mar 2024 13:00:51 GMT

Hi Derek

Susheel is out of office, so I have been assigned to this case while he's away. it took a while to get through his cases, so sorry about the delay.

Yes, directed advertising should be possible to do like this, but you need to get the IRK shared somehow to the Android, and the "normal/sensible" way to do so would be by bonding, which is what I would suggest. How you get the IRK on the Android without bonding will need to be handled by you though. We have a couple of discussions on this in the DevZone already:

Best regards,

Simon

RE: Directed advertising to Android phone without bonding

droberson — Mon, 11 Mar 2024 17:17:41 GMT

Susheel,

No worries, thanks for the reply. I already have the IRK from the phone I am trying to directly advertise to.

[quote userid="6207" url="~/f/nordic-q-a/108920/directed-advertising-to-android-phone-without-bonding/473263"]Once you get it and save it, you can use it to check that the new device address used by Android phone is generated by the same IRK or not. You only send directed advertising to devices that pass this translation.[/quote]

I am not sure what you mean by this. "You can use it to check that the new device address" sounds like the Peripheral needs to listen to scan requests from all Centrals. In order to do this, the Peripheral would need to advertise to all Centrals, which defeats the purpose of what I want to achieve (direct advertising).

To summarize and clarify my original post, I want to directly advertise to an Android phone 100% of the time unless connected to the phone. Is this possible so long as the Peripheral device knows the Android phone's IRK?

To me, this doesn't seem possible because the Android phone rotates it's MAC every 15 minutes or so, hence why I am looking for a definitive answer.

Thanks,

Derek

RE: Directed advertising to Android phone without bonding

Susheel Nuguru — Mon, 11 Mar 2024 15:32:00 GMT

Derek,

Sorry for delays, I was stuck in something else and did not manage to unplug from it. Thanks for being nice and patient. Really appreciate it.

[quote user="droberson"]You cannot perform whitelisting and directed advertising at the same time, so how does whitelisting apply to question #2?[/quote]

Yes, sorry, Whitelisting cannot be used with directed advertising as it is assumed that you already know which device you want to communicate with.

If you know that you want to connect to some Android phone, then you need to first connect and pair with it atleast once so that the Android phone can share its IRK with your device. Once you get it and save it, you can use it to check that the new device address used by Android phone is generated by the same IRK or not. You only send directed advertising to devices that pass this translation.

RE: Directed advertising to Android phone without bonding

droberson — Fri, 08 Mar 2024 01:55:07 GMT

Any update Susheel Nuguru ?

Thanks,

Derek

RE: Directed advertising to Android phone without bonding

droberson — Wed, 06 Mar 2024 18:35:22 GMT

Hey Susheel,

Thanks for the reply.

[quote userid="6207" url="~/f/nordic-q-a/108920/directed-advertising-to-android-phone-without-bonding/472467"]Yes, This is how many customers/products have done it aswell. but that was on the older SDK, I need to dig a bit to find how to do this in nRF connect SDK.[/quote]

I am not using nRF Connect SDK. Per the Software section at the beginning of my post, I am using SDK15.2.

[quote userid="6207" url="~/f/nordic-q-a/108920/directed-advertising-to-android-phone-without-bonding/472467"]Again using whitelisting on IRK seems to be the solution here, as IRK wont change over time.[/quote]

You cannot perform whitelisting and directed advertising at the same time, so how does whitelisting apply to question #2?

Source: Whitelisting and Directed Advertising Simultaneously

Thanks,

Derek

RE: Directed advertising to Android phone without bonding

Susheel Nuguru — Wed, 06 Mar 2024 13:04:52 GMT

[quote user=""]Is it possible for a nRF52840 to directly advertise (and connect) to an Android phone with a pre-shared IRK without bonding to it as proposed above?[/quote]

Yes, This is how many customers/products have done it aswell. but that was on the older SDK, I need to dig a bit to find how to do this in nRF connect SDK.

[quote user=""]How does the Peripheral know what BLE MAC to insert into the direct advertising packet if the Android phone changes its MAC every 15 minutes?[/quote]

Again using whitelisting on IRK seems to be the solution here, as IRK wont change over time.

[quote user=""]As far as I know, the IRK stays the same for the life of the phone. Please correct me if I am wrong.[/quote]

You are right.