BLE filter accept list : BT_LE_ADV_OPT_FILTER_SCAN_REQ doesn't work properly

[jithurm]

Hi,

We have implemented recently the BLE filter accept list based on this sample : https://github.com/zephyrproject-rtos/zephyr/blob/main/samples/bluetooth/peripheral_accept_list/src/main.c

We are using NCS 2.6.0, and a custom board based on nrf5340 device.

It seems to work pretty well, at least the BT_LE_ADV_OPT_FILTER_CONN  functionality we could verify quite easily that it is not possible to connect to device not in the filter accept list.

On the other hand, the scan requests filtering doesn't seem to work consistently. I definitely see that it has an effect, I tested with Ellisys sniffer and just 2 phones (1 in filter accept list and the other not). If the device is advertising, I see that all scan requests from the accepted phone are answered, but sometimes (very randomly, can be once every 2 - 5 minutes), our nrf5340 based device still answers to scan requests from other peers not in the list.

That seems like a bug to me. I'm quite confused by comment of one of your developers here : nRF5340 BLE Filter scan required(whitelist) dose not working... 

Hi,

Any central can still scan the peripheral when you use filter accept list. However, only devices in the filter list (previously called whitelist) are allowed to connect.

The only way you can prevent other centrals from scanning a peripheral is to use directed advertising, where you explicitly advertise specifically to a central. That is generally not recommended though, and for instance Apple writes this in the Accessory Design Guidelines for Apple Devices:

ADV_DIRECT_IND should not be used.

Also, note that a sniffer can still read the packets, it is just that the Bluetooth stacks of the central will filter out directed advertising packets that are intended for other devices. That said, if you really need this, then you can take a look at the Bluetooth: Direct Advertising sample.

I definitely see that using BT_LE_ADV_OPT_FILTER_SCAN_REQ has an effect, with the Ellisys logs I see that most Scan Requests from peers not on the list are left unanswered, but still some go through very rarely.

To me that sounds like a bug. I had a discussion on Discord on the nordic channel where Joakim Anderson (I assume he is a nordic employee) seems to agree with me that it looks like a bug. Example of a on occurrence :

Here it represents the case where device answers to scan request of the non-allowed phone.


As our devices are designed to be used with iOS centrals, we cannot use directed advertisement so it would be wonderful if the scan request filtering worked reliably.

Any help would be much appreciated,

Best regards,

Jimmy

[Elfving]

Hello Jimmy, 

Thanks for letting us know. That does sound like a bug. I am looking into it.

Regards,

Elfving

[Elfving]

Did you get to testing the softdevice controller (ie. CONFIG_BT_LL_SW_SPLIT) like you suggested on the Discord channel?

Regards,

Elfving

[Elfving]

Hello again,

Our team has looked into this, and it doesn't seem to be a bug.

What is happening is that the two scanners ends up sending a scan_request at the same time. So they crash on air, so that both the scanners ends up listening for scanresponse at the same time. The advertiser responds to the scan_request from the scanner that is in the filter accept list, but the scanner that is not in the filter accept list also receives the scan_rsp.

This is allowed, scan_rsp PDU does not have target address hence a peer that listens on 37/38/39 channels will receive the PDU.

Thanks for the report!

Regards,

Elfving

[jithurm]

Thanks for the update ! Now it makes more sense. I haven't had time to test with the CONFIG_BT_LL_SW_SPLIT, but I would guess it behaves similarly if this is a limitation of this feature.

Best regards,

Jimmy