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>
Showing
Please register or sign in to comment