Hi Anton, On Thu, Aug 15, 2024 at 1:26 PM Anton Khirnov <anton@xxxxxxxxxxx> wrote: > > Hi Luiz, > Quoting Luiz Augusto von Dentz (2024-08-14 16:47:27) > > Hi Anton, > > > > On Wed, Aug 14, 2024 at 5:14 AM Anton Khirnov <anton@xxxxxxxxxxx> wrote: > > > > > > Hi, > > > I'm developing a program that needs to monitor advertisements from > > > a known LE device (or several) and take action based on their contents. > > > From looking at the kernel code, there seem to be two relevant ways to > > > initiate passive scanning: > > > 1) performing MGMT_OP_ADD_DEVICE with HCI_AUTO_CONN_REPORT; > > > 2) using an advertisement monitor. > > > > > > However, it seems that 1) always enables the duplicates filter, so only > > > one advertisement for a given device is ever reported; meanwhile 2) can > > > (after my recent patch) report all the advertisements, but disables > > > device filtering - so userspace receives reports from all devices, not > > > just those I care about, which seems inefficient. > > > > > > My question then is this - should my use case be implemented by > > > a) extending HCI_AUTO_CONN_REPORT processing code to allow disabling the > > > duplicates filter on request; > > > b) extending the advertisement monitor interface to allow monitoring > > > only specific devices; > > > c) something else? > > > > Have a look at scan.pattern, it sets a filter which can be either the > > name or address using active scanning, passive scanning is only meant > > for auto-connect and depending on things like LL privacy being enable > > the host may not even see the advertisement reports since it would be > > done using acceptlist/whitelist filtering which is done directly in > > the controller. > > I would very much prefer to avoid active scanning. Perhaps it was not > clear from my email, but my program is intended to be a daemon that > spends most of its time waiting for advertisements to come in. In my > understanding it's very undesirable to spend extended periods of time > actively scanning. Then you are after something else, advertising monitor perhaps. > Also, the advertisement monitor interface already does almost exactly > what I want, except for the fact it forces me to receive advertisements > from devices I'm not interested in. Yeah, I was gonna say that, but this is a vendor extension, not really following about forcing you to do anything, or you are saying you want to connect rather than parse something on the advertisement? It is a little bit hard to give you any advice if you are not really explaining what is the use case, also if you are involving a daemon then perhaps you are not really using bluetoothd? > Thanks, > -- > Anton Khirnov -- Luiz Augusto von Dentz
