Bluetooth: Add protections for updating local random address
authorJohan Hedberg <johan.hedberg@intel.com>
Fri, 28 Feb 2014 10:54:14 +0000 (12:54 +0200)
committerMarcel Holtmann <marcel@holtmann.org>
Fri, 28 Feb 2014 15:53:06 +0000 (07:53 -0800)
commit8d97250ea2231736225f2e99a91adb266eedfcbe
tree5a49d319540bf0d60605d7f9016cebf62fccd8e9
parent759331d7cc660be17bcdc5df53f196135f9dfaf6
Bluetooth: Add protections for updating local random address

Different controllers behave differently when HCI_Set_Random_Address is
called while they are advertising or have a HCI_LE_Create_Connection in
progress. Some take the newly written address into use for the pending
operation while others use the random address that we had at the time
that the operation started.

Due to this undefined behavior and for the fact that we want to reliably
determine the initiator address of all connections for the sake of SMP
it's best to simply prevent the random address update if we have these
problematic operations in progress.

This patch adds a set_random_addr() helper function for the use of
hci_update_random_address which contains the necessary checks for
advertising and ongoing LE connections.

One extra thing we need to do is to clear the HCI_ADVERTISING flag in
the enable_advertising() function before sending any commands. Since
re-enabling advertising happens by calling first disable_advertising()
and then enable_advertising() all while having the HCI_ADVERTISING flag
set. Clearing the flag lets the set_random_addr() function know that
it's safe to write a new address at least as far as advertising is
concerned.

Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
net/bluetooth/hci_core.c
net/bluetooth/mgmt.c
This page took 0.02571 seconds and 5 git commands to generate.