Re: mgmt API, need some help for my use-case

Hi Marcel,

Thanks for the answer,

Hi Maxime,

quoted

I would like to discuss a use-case that I encountered on my project, and
for which I cannot find a right way to do it with mgmt API.

I have a controller, the 88W8887 that I need to set in 'wakeup host' mode.

I put my host in suspend-to-mem, and the controller toggles a GPIO to wake
it up under certain circumstances, including a Low Energy connection.

To do that, I need to :
	- configure precisely my advertising intervals, to be in low duty
	  cycle advertising, with a long interval between advertisements
	- configure the filter policy, to only process connection
	  requests from whitelisted devices ( we want only whitelisted
	  devices to be able to wakeup our system ).

I previously did that with the HCI lib in my C program, and submitted a
patch to the hci lib, to add the le_set_advertising_parameters to the lib.

I used the following HCI commands :
	- LE clear whitelist ( OCF 0x0010 )
	- LE Add device to whitelist ( OCF 0x0011 )
	- LE Set advertising parameters ( OCF 0x0006 )
	- LE Set advertise enable ( OCF 0x000A )

It turns out this is not the right approach, Johan Hedberg explained to me
on IRC that the hci lib was not intended to be used by external programs.

Therefore, I'm looking for a way to do it using the mgmt API, but I can't
find a way to :
	- Manipulate the whitelist
	- Configure advertising intervals
	- Configure the filter policy

If I missed something in the mgmt API that would allow me to do that, please
point it to me. If these are some missing features, I am willing to spend some
time working on it.

it sounds to me that Add Device with type 0x01 is actually what we really wanted to support here. We currently use that for directed connections. So maybe we introduce a type 0x03 which has different meaning on LE compared to 0x01, but for BR/EDR it would actually result in 0x03 defining the incoming connections type for both bearers. On the other hand, is anybody actually using type 0x01 for LE?

So only tricky part is that when using the whitelist for limiting LL_CONNECT_REQ processing is that we can then not background scan with a whitelist. Since that list might be different. So this is something we need to figure out on what chips actually do here. Or we have to create some combined whitelist and accept false positives that we handle in the host then.

I get what you mean for Add Device with Action 0x03, that would fit my needs.

I think however that there needs to be a way to specify if we take the
whitelist into account while scanning of advertising in connectable mode.

I fail to see when we should take the whitelist into account in the current
workflows proposed by the API. I get that blocking with Block Device
establishes a blacklist, that Add Device could be used to "whitelist" a
device, but I think there needs to be a way to set a mode where only
whitelisted devices are taken into account for discovery and connection.

Sorry if this is unclear, I don't have a full understanding of all the
mecanisms yet.

So when you say "accept false positives that we handle in the host", you
are talking about a BR/EDR device that is not whitelisted but that might
have been seen by the controller since it only takes LE addresses into
account in its whitelist ?

Thanks,

Maxime