Bug in advertisement filter when filtering on multiple UUIDs

Hi,

When you use `bt_scan_filter_add` to add multiple UUID filters on advertisements, and pass `match_all = true` in `bt_scan_filter_enable`, the system will not behave as expected.

There seems to have been some discussion on this in other threads, but those focus on how the design of the scan filtering system cannot match UUIDs received in different advertisements/scan responses ( How to access all advertisement data in scan filter match callback? ). However, even if the UUIDs are in the same advertisement, the current system does not work.

Specifically, I was trying to match both a UUID32 and UUID128. Using one of the two filters always works.

The issue seems to be the counting logic in `uuid_check` and `adv_uuid_compare` inside `nrf/subsys/bluetooth/scan.c`.

* The uuid check function is called by `bt_data_parse` as it parses incoming advertisement data, and it passes the UUID type (i.e.: 128-bit or 32-bit) along to `adv_uuid_compare`.

* When using "match_all", `adv_uuid_compare` will only return true when it found a match for ALL UUID filters. But this is impossible if you set filters for multiple UUID types, because the function only looks for those types.

* Only when it returns true, does `uuid_check` increment a counter for how many filters have been matched.

The result is that if you have different UUID type filters, `uuid_check` _will_ be called multiple times, and each time `adv_uuid_compare` _will_ find one, but the `filter_match_cnt` will not increment. It seems like there is some logical error in who has to check for the `match_all` filter and counting. This should be the responsibility of `filter_state_check`, and the counting should be done differently. A few small changes there would get this working.

For my specific use case I have decided to only filter on one UUID and do extra filtering manually in the `scan_filter_match` callback so I do not have to keep a patch for NCS around, so there is no urgent fix required for us.

I have been developing with NCS 2.6.0, but the code does not seem to have been touched recently so I expect it to be a problem in the current NCS as well.

Kind regards,

Ernest

Related