Hi Johan/Marcel,
On 02/28/2014 03:51 AM, Marcel Holtmann wrote:
Hi Johan,
The complicated part comes into play when we have devices with
LE Privacy enabled and when they are using resolvable private
addresses. Meaning when our IRK list is populated with identity
addresses and their IRKs. The only way to make this work with the
current available controller features is if we program the RPA
into the white list. Since that RPA is going to change over time,
we need to stop scanning with the white list filter every now and
then, scan for all devices and resolve the RPA. If we see a new
RPA for a know IRK, we have to replace the old RPA in the white
list with the new RPA. And then we go back to scanning with the
white list filter policy.
Now the important question is what are good enough intervals to
make this work smoothly. Devices using LE Privacy will take a hit
in their re-connection time, but that is what we have to trade in
for compared to waking up the host for every single advertising
packet.
My initial idea is to scan 5 minutes using the white list, then
scan 10 seconds without the white list, then back to 5 minutes
using the white list and so on.
The default value for the PRA lifetime according to the
specification is 15 minutes. I timed recent iOS devices which
seem to be using 9 minutes intervals. So we have to play a little
bit with this and see what are good values.
Maybe 3 minutes white list scan and 5 seconds without white list
is better. Things to try out.
I don't think this is a good idea at all. With LE starting
advertising is typically seen as the initiating action of
connection creation (unlike with BR/EDR where HCI_Create_Connection
is the initiating action). Typically peripherals mean "connect to
me now!" when they start connectable advertising.
Let's stay you switch on your peripheral device, or it comes into
range you haven't used it for some time (hours or even days). If
it's using RPAs it's pretty much guaranteed to have a different one
than what we know of and even if we're using 3 minutes white list
scanning the user is on average going to have to wait for 1.5
minutes for the device to get connected which is not acceptable
behavior (the extreme example would be if this is a keyboard or a
mouse which you start using for the first time in the morning -
moving the mouse or pressing a key on the keyboard should certainly
get you a connection in less than 1 second).
HID devices would suffer the most here. Fully agree here.
However since neither Microsoft Windows nor OS X can deal with RPAs
at the moment, I do not think we are entering a dangerous zone here
from an interoperability point of view. Actually Windows 8.1 is not
able to connect to any random address for that matter.
My point is that we certainly not make it worse.
HoG is not the only problem. I'm afraid delaying re-connection 3-5
minutes we might become others profiles impractical (e.g. Fob keeps
beeping even if it is beside the cellphone).
I fully understand the desire to use the white list as it's a very
nice power saving feature, but I don't think we can win here as
long as we don't have a way to have the controller do the resolving
for us.
One thing we could potentially try to do (but which I doubt is
really worth it in the end) is to track the age of resolved RPAs.
If we have an RPA which was resolved say less than 5 minutes ago we
consider it appropriate to place into the white list. Otherwise we
skip using the white list.
I was thinking about this as well. Over time we could learn the age
of a RPA and thus schedule the scanning without white list times most
efficient. Frankly, I want to get the white list usage going first.
As long as you only have public or static addresses, it is the way to
go. And then we optimize it when we have to deal with RPAs.
I agree with Johan about this aging approach, I seems not worthy.
Honestly, I don't see how we would properly deal with white list and LE
Privacy issue by now.
We can not close our eyes to iOS devices using RPAs and I am not
willing to take the power hit of getting flooded with advertising
reports.
To fix this other issue (advertising flooding), filtering duplicates is
just fine.
The problem with enabling filter duplicates in background scan happens
in the following scenario:
* Background scan is running.
* A device disconnects and starts advertising.
* Before host gets the disconnect event, the advertising is reported
to host. Since there is no pending LE connection at that time,
nothing happens.
* Host gets the disconnection event and adds a pending connection.
* No advertising is reported (since controller is filtering) and the
connection is never established.
To address this scenario, all we have to do is: always restart
background scan when a new LE pending connection is added. This way, we
unsure that we don't miss the advertising report.
If you guys agree with this approach I can write the patches.
Regards,
Andre
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
