nRF840 - S140 : How to fetch MAC addresses of surrounding mobile devices during nRF52840 scanning using Bluetooth 5.

[Bharat]

Hello Nordic Team,

We are using nRF52840 ble chip with S140 nordic stack and SDK 15.2.0 on the  SEGGER IDE installed on  the Windows OS. We want nRF52840 chip  to detect surrounding mobile devices and also nRF52840 can fetch MAC addresses of mobile devices during scanning. We would like to know from your side that whether this is feasible or not ?. If yes, then can you please suggest us how to do it.

We are looking forward to hear from you.

Thanks
Bharat Gopani
Lumium Design
India.

[Einar Thorsrud]

Hi,

You can find example projects that scans and logs in this post. It does active scanning as well, but you can adapt it to not do active scanning and only log the MAC address. You can refer to this post in the same thread for how to add logging of the MAC address.

[Bharat]

Hello Einar,

Thanks for the reply.

We have procured nRF52-DK development board from Mouser India and we are using S140 stack on the Windows platform for our PoC.

Our application requires that nRF52840 should be able to scan and fetch MAC address (public address) of surrounding Android smart phone.

Currently, we are able to scan and fetch random private resolvable and  non resolvable addresses of surrounding Android smart phone and also public address of the smart BLE  watch but our project needs public address of the smart phone, so whether it's possible or not and if yes then how it can be done ?

It would be helpful if you could suggest for the same.

Thanks

Bharat Gopani

Lumium Design

India

[Bharat]

Hi Einar,

Thanks for your support.

1 . We have tried peer manager  programs like ble_app_proximity and ble_app_hids_keyboard,              , however it connects initially and disconnects immediately.

We are using nRF UART v2.0 to connect with nRF52840.

What coud be possible reason for this  ??

2. In ble_app_uart  pheripheral example, Device manager is used instead of peer manager. can you guide us for implementing peer manager in place of device manager  ?

It would be helpful if you could guide us for the above.

Regards

Bharat

[Einar Thorsrud]

Hi,

Bharat said:

What coud be possible reason for this  ??

On the nRF side, you sould get a disconnect reason indicating why. A typical reason for the nRF or phone to disconnect when you use bonding is if you have deleted bonding information on one side. In that case, you will either see that the peer attempts to encrypt the link, but the bond does not exist on the other side. Alternatively the peer with no bonding information will try to bond, but the peer will refuse bonding as it is allready bonded. You should make sure to delete bonding information on both sides in this case, or alternatively configure the nRF to allow repairing.

Bharat said:

2. In ble_app_uart  pheripheral example, Device manager is used instead of peer manager. can you guide us for implementing peer manager in place of device manager  ?

It would be helpful if you could guide us for the above.

The device manager is legacy software and is no longer supported, and should not be used. It does not exist in any SDK with production support for nRF52840 (>= 15.0.0). 

[Bharat]

Thanks for the suggestions.

We have gone through ble_app_proximity example for understanding of peer manager and found that pm_evt_handler is event handler during bonding.

How can we get MAC address of the connected device from this event handler   ??

Regards

Bharat

[Einar Thorsrud]

Hi,

If you are acting as peripheral you will get the MAC address of the connected central in the BLE event handler (ble_evt_handler() in most SDK examples) when it handles the BLE_GAP_EVT_CONNECTED event. You should find it as something like p_ble_evt->gap_evt.connected.peer_addr.addr, as a 6 byte uint8_t array.

[Bharat]

Thanks for the reply.

This way we get an private resolvable address of the connected device but how we can get public address(MAC) using IRK and peer manager.

Regards

Bharat

[Einar Thorsrud]

You cannot get the MAC address of the peer from the IRK directly. However, you can resolve the MAC address based on the IRK. That is: when you have obtained both the IRK and a MAC address of the peer you can verify that the MAC address is derived from the IRK. So, when the MAC address change, you can resolve it again and know that even if it changed, it was from the same peer (same IRK).

[Bharat]

Thank you very much.

Could you please elaborate resolving process for the peer address  ?

If peer address changes and if we resolves it again  then how can we come conclude that it is same peer  ?

where can we get the IRK  in the stack ?

Regards

Bharat

[Einar Thorsrud]

If you use whitelist scanning, then this can be handled by the AAR peripheral, but it would filter out any other advertising packets, so this is probably not what you want if I understood your use case correct (track any BLE advertisers in range). Therefor you probably want to use pm_address_resolve(), and iterate over all IRK you have in the list of bonded devices. You can get a list of all bonds using pm_peer_id_list().

[Bharat]

Thanks for the reply.

IRK for bonded device is fixed or variable  ??

Can you please tell us more about working of resolving process using  these  functions pm_address_resolve() and pm_peer_id_list().

If possible, can you please share the document related to this procedure.

Regards

Bharat

[Einar Thorsrud]

Hi,

Bharat said:

IRK for bonded device is fixed or variable  ??

The IRK is typically fixed for the lifetime of a device. It is possible to change it, but in that case any already bonded devices will not be able to resolve the address any more (since it is derived from a new IRK that is different from what they got during the bonding procedure).

Bharat said:

Can you please tell us more about working of resolving process using  these  functions pm_address_resolve() and pm_peer_id_list().

If possible, can you please share the document related to this procedure.

We do not have any documentation that describes it, but it is quite straight-forward:

1. Get the MAC address you want to resolve (typically from a advertising packet in this case).
2. Check that the MAC address type is a private resolvable address. If no, then just use the MAC address as is. This is indicated by the most significant bits in the address.
3. If the MAC address is resolvable, iterate over the IRK's you have by using pm_peer_id_list(). Call pm_address_resolve() with the MAC address you want to resolve and a IRK, and iterate through the list of IRK's until you get a match or the end of the list. If you get a match, stop as you have already resolved it. If you don't get a match you know that this address was derived from an IRK which you don't have, so you cannot resolve it.