All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hedberg <johan.hedberg@gmail.com>
To: Marcel Holtmann <marcel@holtmann.org>
Cc: linux-bluetooth@vger.kernel.org
Subject: Re: Background scanning and white list usage
Date: Fri, 28 Feb 2014 08:44:22 +0200	[thread overview]
Message-ID: <20140228064422.GA28466@localhost.P-661HNU-F1> (raw)
In-Reply-To: <BFAEE1C5-E74F-40F0-A1A4-8F4907FBDCF4@holtmann.org>

Hi Marcel,

On Thu, Feb 27, 2014, Marcel Holtmann wrote:
> 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).

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.

Johan

  reply	other threads:[~2014-02-28  6:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28  3:20 Background scanning and white list usage Marcel Holtmann
2014-02-28  6:44 ` Johan Hedberg [this message]
2014-02-28  6:51   ` Marcel Holtmann
2014-03-06 21:15     ` Andre Guedes
2014-03-07  7:04       ` Johan Hedberg
2014-03-07  7:30       ` Marcel Holtmann
2014-03-10 14:21         ` Andre Guedes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140228064422.GA28466@localhost.P-661HNU-F1 \
    --to=johan.hedberg@gmail.com \
    --cc=linux-bluetooth@vger.kernel.org \
    --cc=marcel@holtmann.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.