1. 03 7月, 2014 14 次提交
  2. 13 6月, 2014 3 次提交
  3. 31 5月, 2014 1 次提交
  4. 24 5月, 2014 1 次提交
  5. 20 5月, 2014 1 次提交
  6. 16 5月, 2014 4 次提交
  7. 09 5月, 2014 1 次提交
  8. 12 4月, 2014 1 次提交
  9. 28 3月, 2014 3 次提交
  10. 27 3月, 2014 2 次提交
  11. 21 3月, 2014 1 次提交
    • J
      Bluetooth: Fix address value for early disconnection events · 61b1a7fb
      Johan Hedberg 提交于
      We need to ensure that we do not send events to user space with the
      identity address if we have not yet notified user space of the IRK. The
      code was previously trying to handle this for the mgmt_pair_device
      response (which worked well enough) but this is not the only connection
      related event that might be sent to user space before pairing is
      successful: another important event is Device Disconnected.
      
      The issue can actually be solved more simply than the solution
      previously used for mgmt_pair_device. Since we do have the identity
      address tracked as part of the remote IRK struct we can just copy it
      over from there to the hci_conn struct once we've for real sent the mgmt
      event for the new IRK.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      61b1a7fb
  12. 20 3月, 2014 2 次提交
  13. 13 3月, 2014 1 次提交
  14. 10 3月, 2014 2 次提交
  15. 08 3月, 2014 1 次提交
  16. 28 2月, 2014 2 次提交
    • J
      Bluetooth: Add protections for updating local random address · 8d97250e
      Johan Hedberg 提交于
      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: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      8d97250e
    • M
      Bluetooth: Use __le64 type for LE random numbers · fe39c7b2
      Marcel Holtmann 提交于
      The random numbers in Bluetooth Low Energy are 64-bit numbers and should
      also be little endian since the HCI specification is little endian.
      
      Change the whole Low Energy pairing to use __le64 instead of a byte
      array.
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      fe39c7b2