[ble_advertising] GAP filter policies while using whitelist

[Patrice Rudaz]

Hello,

Working on a project using the pairing and bonding security model, I would like to filter out of a central's scan all already bonded peripheral devices. Or, I could read in the BLE specification that it should be possible using the white-list.

I would really appreciate to have the availability of setting up the filter policies to my convenience with your ble_advertising module. It would be nice to have the possibility of choosing between BLE_GAP_ADV_FP_FILTER_SCANREQ, BLE_GAP_ADV_FP_FILTER_CONNREQ or even BLE_GAP_ADV_FP_FILTER_BOTH ...

Or, looking through the code of the ble_advertising.c files of the SDK 11, 12 ,12.1 and 12.2, I've noticed that the filter policies are hard-coded with the value BLE_GAP_ADV_FP_FILTER_CONNREQ. For now on, the only solution I found is to change the code in the module provided by your SDK, but on each update I have to pass through your code and change it back to my settings...

Do you think it could be possible to change this in a future release of your SDK and give the availability of setting up this parameter as desired ? It could be a general setting of the ble_advertising module given in the ble_advertising_init(...)function, or a more specific parameter when using ble_advertising_start(...) function...

Kind Regards Patrice

[Christopher]

Related to the GAP filter policy, is there a way to send advertising packets and scan responses only to the central/scanner devices which are in the advertising whitelist ? Using the BLE_GAP_ADV_FP_FILTER_SCANREQ filter policy, has soon as one device is scanning, the other scanners are able to see the advertising device. Is this the correct behavior ?

[run_ar]

Advertisements are always visible. the scanreq filter policies stops the advertiser from replying to scan requests from unknown devices.

[run_ar]

Thanks Patrice. I agree this should not have been hardcoded and have added this as an improvement suggestion in our internal tracking system.

[run_ar]

Unfortunately, It was decided to close this issue as won't fix. So unless we get more requests like this, we won't make this improvement. I'm really sorry for the inconvinience.